From pce-bounces@ietf.org Wed Mar 2 16:11:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27132; Wed, 2 Mar 2005 16:11:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6b8l-00031Y-5J; Wed, 02 Mar 2005 16:12:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b6M-000420-IW; Wed, 02 Mar 2005 16:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b6J-00040Y-SV for pce@megatron.ietf.org; Wed, 02 Mar 2005 16:09:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26954 for ; Wed, 2 Mar 2005 16:09:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6b7X-0002zk-Qs for pce@ietf.org; Wed, 02 Mar 2005 16:11:04 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2005 13:10:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j22L9YZV011071; Wed, 2 Mar 2005 13:09:35 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-77.cisco.com [10.86.240.77]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA00860; Wed, 2 Mar 2005 13:09:33 -0800 (PST) In-Reply-To: <10e801c51b33$77c57b00$adcb2bd4@Puppy> References: <02bf01c51b0b$7e457ac0$37316e0a@huawei.com> <10e801c51b33$77c57b00$adcb2bd4@Puppy> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <505f458abc7859cfa7dd417149ac1f76@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] PCE Discovery Requirements Date: Wed, 2 Mar 2005 16:09:51 -0500 To: Adrian Farrel , zrh X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Hi, On Feb 25, 2005, at 7:11 AM, Adrian Farrel wrote: > Hi Zhang, > > Thanks for your comments. > >> 1)In section 5.2,the last PCE computation capabilities to be >> advertised > is "The PCE capacity in terms of computation power", for the reasion of > weighted load balancing of requests in case PCEs do not have the same > capacity. >> >> I think this is not enough, before PCC sends a request to PCE for a >> path > compution,PCC should also know if the PCE is busy, how busy(maybe the > PCE > has many path compution requests from another PCCs which have not reply > for some reason even if the PCE have pawerful CPU). >> To reasonably distribute PCCs's computation requests to PCEs ,PCCs > should know the current status of all PCEs's CPU. so I think the > status of > PCE's CPU(or number of requests which have not been replied, etc) can > be > included in the hello packet sent by PCE,maybe such hello packet is > needed. > > On the face of it, this is a reasonable requirement. As you say, the > PCC > would ideally select the least busy PCE to perform its computation for > it. > > We need to be careful to separate this requirement from how it might be > satisfied. So discussion of hello packets snet by PCE should be > avoided at > this stage. This is probably important because the use of a hello > packet > might not be a good way of satisfying this requirement - the > computation > time for a single PCE request is likely to be no more than a few > hundred > milliseconds and we would certainly need to think hard before asking > that > each PCE sends a new status message to every PCC in the network every > hundred milliseconds. > > I have a concern however. Suppose you had a network with two PCEs and a > lot of active PCCs. In the event that one PCE was slightly more busy > than > the other, all of the PCCs would send their requests to the other PCE > causing immediate congestion. > > So here is a suggestion. Suppose instead of measuring queue size and > CPU > capacity we simply allow a PCE to report its status as "congested" if > it > deems that it is too busy. PCEs may still continue to send requests to > a > congested PCE, but may use this information to prefer a different PCE. > > The congested flag can be set and flooded instantly the PCE believes > that > it is congested, and only releases under a threshold and on a normal > discovery refresh. a few comments: - PCE resource availability could be announced by various means indeed. Potential oscillations could be avoided by implementing an appropriate resource availability estimation algorithm on the PCE itself and/or an appropriate PCE selection algorithms on PCCs. Note that both mechanisms would be implementation dependent and may not require to the standardized. - I agree with Adrian that focus must be given to the requirements here rather than the solution which will be discussed right after. For the sake of illustration, IGP/BGP but also the PCC/PCE communication protocol could be used for example to explicitly notify of a congested state so as to provoke a path computation request reroute to another PCE (that said, even in this case, this requires oscillation prevention mechanisms, ...). > >> 2)In section 5.3,the backup PCEs are discussed,the location of backup > PCE is advertised by PCE. >> >> I don't think location of backup PCE can be decided by PCE . >> Each PCE may has different abilities for path compution,so PCC may > select different PCE to send request for different request,backup PCE > is > also not fixed.In other words,the selection of PCE and buckup PCE are > also > relevant to the computation requests,and are not fixed because of the > different requirement of computation. > > Well, a PCE *might* know that it has a partner that matches (or > betters) > its capabilities and which acts as its backup. In this case, why > should it > not advertise this information? Furthermore, a carrier may decide to configure a PCE to act a backup only. Thanks. JP. > >> 3)In section 5.5 third paragraph"The delay for such detection MUST be > beyond 60s" >> Maybe a "not" is needed. > > Indeed. > > Thanks, > Adrian > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Mar 5 04:32:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26170; Sat, 5 Mar 2005 04:32:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7VfY-0005Pu-FL; Sat, 05 Mar 2005 04:33:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7VbH-00069Q-A4; Sat, 05 Mar 2005 04:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Van-000688-FI for pce@megatron.ietf.org; Sat, 05 Mar 2005 04:29:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26010; Sat, 5 Mar 2005 04:28:59 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7VcX-0005Mr-3T; Sat, 05 Mar 2005 04:30:49 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 83BBDE00022E; Sat, 5 Mar 2005 09:28:45 +0000 (GMT) Received: from Puppy ([212.43.203.52] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 09:27:52 +0000 Message-ID: <076101c52165$d18d5080$19cb2bd4@Puppy> From: "Adrian Farrel" To: Date: Sat, 5 Mar 2005 09:27:11 -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-OriginalArrivalTime: 05 Mar 2005 09:27:53.0406 (UTC) FILETIME=[9B7DE5E0:01C52165] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, Bill Fenner , statements@ietf.org, Scott Bradner Subject: [Pce] Path Computation Element Working Group in the IETF 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit To: Mr. Yoichi Maeda, chairman ITU-T Study Group 15 Cc: Mr. Scott Bradner, IETF liaison coordinator with the ITU-T Alex Zinin and Bill Fenner, IETF Routing Area Directors From: Adrian Farrel and JP Vasseur, IETF PCE working group chairs Subject: Path Computation Element Working Group in the IETF For: Action Deadline: 1st April 2005 Dear Mr. Maeda, We would like to inform you and Study Group 15 of the creation of a new working group within the IETF to work on the Path Computation Element (PCE). The charter of this working group is shown below and provides a brief definition of the PCE. Further understanding of what the IETF means by PCE can be found in http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt although this should be seen as a work in progress. We believe that some work may already have been carried out within the ITU-T (probably within SG15) on determining a functional architecture for a similar logical entity - that is, for a logically distinct control plane component that is responsible for performing path computations. We are anxious to leverage this work so that we can produce a solution that most closely matches the needs of the ITU-T community, so that we do not waste effort re-inventing anything, and so that we can move our own work forwards as rapidly as possible. Could you please pass this liaison to all interested parties within the ITU-T and particularly to the Questions that may have worked on a similar topic with a request that they give us pointers to all related and previous work. Once we have established direct contact with the relevant groups we will continue to liaise our progress to them and will solicit their opinions especially with respect to architecture and functional requirements. Thank you for your help. Best regards, Adrian Farrel and JP Vasseur ===== Path Computation Element Working Group Charter Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and obustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05 Submit first draft of PCE architecture document Feb 05 Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05 Submit first draft of the PCE communication protocol requirements May 05 Submit first draft of the definition of objective metrics Jul 05 Submit first draft of the PCE communication protocol specification Aug 05 Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05 Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05 Submit first draft of the MIB module for the PCE protocol Dec 05 Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05 Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05 Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06 Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06 Evaluate WG progress, recharter or close _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Mar 7 19:49:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00987; Mon, 7 Mar 2005 19:49:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8SxA-000564-Ap; Mon, 07 Mar 2005 19:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8SsJ-0007sY-LG; Mon, 07 Mar 2005 19:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8SsH-0007p3-GG for pce@megatron.ietf.org; Mon, 07 Mar 2005 19:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00650 for ; Mon, 7 Mar 2005 19:46:55 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8SuW-00050I-97 for pce@ietf.org; Mon, 07 Mar 2005 19:49:21 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 161C9E0001F7 for ; Tue, 8 Mar 2005 00:46:45 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 00:40:24 +0000 Message-ID: <003c01c52377$a0e4d980$a4858182@Puppy> From: "Adrian Farrel" To: Date: Tue, 8 Mar 2005 00:40:03 -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-OriginalArrivalTime: 08 Mar 2005 00:40:24.0295 (UTC) FILETIME=[6A640F70:01C52377] X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Subject: [Pce] Agenda and slides now on line 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit See http://www.olddog.co.uk/62/pce.htm Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 12:33:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22567; Tue, 8 Mar 2005 12:33:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8id4-0002ZT-VN; Tue, 08 Mar 2005 12:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iUI-00065q-GS; Tue, 08 Mar 2005 12:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iUG-00065l-QV for pce@megatron.ietf.org; Tue, 08 Mar 2005 12:27:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21610 for ; Tue, 8 Mar 2005 12:27:13 -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.33) id 1D8iWg-0002MO-L9 for pce@ietf.org; Tue, 08 Mar 2005 12:29:47 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2005 10:44:11 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107734400"; d="scan'208"; a="232662700:sNHT22047456" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28HQuq8010464; Tue, 8 Mar 2005 09:26:56 -0800 (PST) Received: from [130.129.135.17] (rtp-vpn3-385.cisco.com [10.82.217.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA22940; Tue, 8 Mar 2005 09:27:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0453047611f0601d9f78ddcf45e93085@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 8 Mar 2005 11:27:20 -0600 To: pce@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: nabil.n.bitar@verizon.com Subject: [Pce] New member of the Design Team 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, We just wanted to announce that Nabil Bitar has joined the Design Team; his expertise and skills will certainly help continuing the good work which has been started to come up with the PCE communication requirement ID. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 12:39:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23782; Tue, 8 Mar 2005 12:39:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ii5-0002mv-VW; Tue, 08 Mar 2005 12:41:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8idU-0007Zq-Br; Tue, 08 Mar 2005 12:36:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8idT-0007Zl-RP for pce@megatron.ietf.org; Tue, 08 Mar 2005 12:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23387 for ; Tue, 8 Mar 2005 12:36:44 -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.33) id 1D8ift-0002gM-O0 for pce@ietf.org; Tue, 08 Mar 2005 12:39:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 09:50:38 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j28HaZZV002077 for ; Tue, 8 Mar 2005 09:36:36 -0800 (PST) Received: from [130.129.135.17] (rtp-vpn3-385.cisco.com [10.82.217.131]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA09810 for ; Tue, 8 Mar 2005 09:36:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <3f5391901238ba96fe00eba115942e67@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Tue, 8 Mar 2005 11:36:52 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit All, We discussed yesterday draft-ash-pce-architecure-01 (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) for which there was a pretty large consensus in the room to adopt it as a WG document. Let us know bring this question on the list. Could you please express your opinion on whether this draft should be adopted as a working group document (Y/N) ? ps: note that comments were made yesterday (include a paragraph on unsolicited PCE path computation, ...) which should be taken care of in the next revision. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 14:36:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05420; Tue, 8 Mar 2005 14:36:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kXx-0005V9-7S; Tue, 08 Mar 2005 14:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kPC-0001Wv-Hh; Tue, 08 Mar 2005 14:30:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kP9-0001Wl-Ja for pce@megatron.ietf.org; Tue, 08 Mar 2005 14:30:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04706 for ; Tue, 8 Mar 2005 14:30:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kRa-0005LO-G8 for pce@ietf.org; Tue, 08 Mar 2005 14:32:39 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8kP6-00046x-2y; Tue, 08 Mar 2005 19:30:05 +0000 Message-ID: <422DFD3E.30802@psg.com> Date: Tue, 08 Mar 2005 20:30:06 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? References: <3f5391901238ba96fe00eba115942e67@cisco.com> In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit hi jp - from my record the "statefull PCE" comment is also to be addressed as cases for which this would be useful is not described in the document it may be actually be interesting to list all the comments that would require further work thanks, - dimitri. JP Vasseur wrote: > All, > > We discussed yesterday draft-ash-pce-architecure-01 > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > for which there was a pretty large consensus in the room to adopt it as > a WG document. > > Let us know bring this question on the list. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? > > ps: note that comments were made yesterday (include a paragraph on > unsolicited PCE path computation, ...) which should be taken care of in > the next revision. > > Thanks. > > JP and Adrian. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 14:46:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06707; Tue, 8 Mar 2005 14:46:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8khY-0005tC-Gg; Tue, 08 Mar 2005 14:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kcR-00038H-Sv; Tue, 08 Mar 2005 14:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kcQ-000387-6e for pce@megatron.ietf.org; Tue, 08 Mar 2005 14:43:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06188 for ; Tue, 8 Mar 2005 14:43:48 -0500 (EST) Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8keo-0005iw-Sy for pce@ietf.org; Tue, 08 Mar 2005 14:46:22 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j28JhX3R018047 for ; Tue, 8 Mar 2005 14:43:34 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 4229269A000A9439; Tue, 8 Mar 2005 14:43:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Tue, 8 Mar 2005 13:43:31 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C88E3@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Thread-Index: AcUkFeT+bWqWmTLVR1qyNbHTFJyRewAAGc3w From: "Ash, Gerald R \(Jerry\), ALABS" To: , , "JP Vasseur" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Hi Dimitri, > from my record the "stateful PCE" comment is also to be=20 > addressed as cases for which this would be useful is not > described in the document There is already some discussion of useful applications of stateful PCEs in Section 6.8. If you have other useful applications to suggest, please let us know. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 14:58:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08980; Tue, 8 Mar 2005 14:58:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kso-0006bl-Oa; Tue, 08 Mar 2005 15:00:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kol-0006bP-JO; Tue, 08 Mar 2005 14:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kok-0006bJ-In for pce@megatron.ietf.org; Tue, 08 Mar 2005 14:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08531 for ; Tue, 8 Mar 2005 14:56:32 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8krC-0006U7-Ix for pce@ietf.org; Tue, 08 Mar 2005 14:59:06 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 20:51:36 +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] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WGdocument ? Date: Tue, 8 Mar 2005 20:51:37 +0100 Message-ID: Thread-Topic: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WGdocument ? Thread-Index: AcUkBap244CeV0c1Ry+9f7VN7/Jd6QAEo8uQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 08 Mar 2005 19:51:36.0000 (UTC) FILETIME=[3C55D400:01C52418] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Y >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de JP Vasseur >Envoy=E9 : mardi 8 mars 2005 18:37 >=C0 : pce@ietf.org >Objet : [Pce] Opinion on adopting=20 >draft-ash-pce-architecture-01 as a PCE WGdocument ? > > >All, > >We discussed yesterday draft-ash-pce-architecure-01=20 >(http://www.ietf.org/internet-drafts/draft-ash-pce-architecture -01.txt)=20 for which there was a pretty large consensus in the room to adopt it as=20 a WG document. Let us know bring this question on the list. Could you please express your opinion on whether this draft should be=20 adopted as a working group document (Y/N) ? ps: note that comments were made yesterday (include a paragraph on=20 unsolicited PCE path computation, ...) which should be taken care of in=20 the next revision. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 14:58:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09038; Tue, 8 Mar 2005 14:58:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kt4-0006dq-6f; Tue, 08 Mar 2005 15:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kgh-0004ES-5W; Tue, 08 Mar 2005 14:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kgf-0004EN-Iw for pce@megatron.ietf.org; Tue, 08 Mar 2005 14:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06871 for ; Tue, 8 Mar 2005 14:48:11 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kj7-0005wI-ET for pce@ietf.org; Tue, 08 Mar 2005 14:50:45 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 9648EE0001B1; Tue, 8 Mar 2005 19:47:58 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 19:47:49 +0000 Message-ID: <023301c52417$ed581e30$a4858182@Puppy> From: "Adrian Farrel" To: , , "JP Vasseur" References: <3f5391901238ba96fe00eba115942e67@cisco.com> <422DFD3E.30802@psg.com> Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? Date: Tue, 8 Mar 2005 19:49:11 -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-OriginalArrivalTime: 08 Mar 2005 19:47:49.0665 (UTC) FILETIME=[B56DD910:01C52417] 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: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Hi Dimitri, > from my record the "statefull PCE" comment is also to be addressed as > cases for which this would be useful is not described in the document I beg to differ. Section 6.8 contains... Note that although this allows for optimal path computation and increased path computation success ...which is an implicit use case. But also section 6.8 contains... There is benefit in knowing which LSPs exist, and their routing, to support such applications as placing a high priority LSP in a crowded network such that it preempts as few other LSPs as possible. Note that preempting based on the minimum number of links might not result in the smallest number of LSPs being disrupted. Another application concerns the construction and maintenance of a Virtual Network Topology [MRN]. It is also helpful to understand which other LSPs exist in the network in order to decide how to manage the forward adjacencies that exist or need to be set up. The cost-benefit of stateful PCE computation would be helpful to determine if the benefit in path computation is sufficient to offset the additional drain on the network computational resources. ...which gives several applications. > it may be actually be interesting to list all the comments that would > require further work Yes, I think that would be useful. In fact, I hope the editor is doing this to track the work for the draft. Do either of these comments lead you to an answer to JP's question? Thanks, Adrian > JP Vasseur wrote: > > All, > > > > We discussed yesterday draft-ash-pce-architecure-01 > > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > > for which there was a pretty large consensus in the room to adopt it as > > a WG document. > > > > Let us know bring this question on the list. > > > > Could you please express your opinion on whether this draft should be > > adopted as a working group document (Y/N) ? > > > > ps: note that comments were made yesterday (include a paragraph on > > unsolicited PCE path computation, ...) which should be taken care of in > > the next revision. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 15:19:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13361; Tue, 8 Mar 2005 15:19:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lD4-0007cq-4Q; Tue, 08 Mar 2005 15:21:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l7i-0003cf-DP; Tue, 08 Mar 2005 15:16:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l7g-0003cR-HL for pce@megatron.ietf.org; Tue, 08 Mar 2005 15:16:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12817 for ; Tue, 8 Mar 2005 15:16:06 -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.33) id 1D8lA8-0007WJ-S0 for pce@ietf.org; Tue, 08 Mar 2005 15:18:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 12:30:05 -0800 Received: from dchengw2k (sjc-vpn6-160.cisco.com [10.21.120.160]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28KFsq8007930; Tue, 8 Mar 2005 12:15:56 -0800 (PST) Message-Id: <200503082015.j28KFsq8007930@sj-core-2.cisco.com> From: "Dean Cheng \(dcheng\)" To: "'JP Vasseur'" , Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WGdocument ? Date: Tue, 8 Mar 2005 12:15:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUkBbT/+ZsWOvsGTJS37OEETIV/AgAFcDNQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcheng@cisco.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Yes > >Could you please express your opinion on whether this draft >should be adopted as a working group document (Y/N) ?Y _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 15:28:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14510; Tue, 8 Mar 2005 15:28:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lLr-0007uJ-Ho; Tue, 08 Mar 2005 15:30:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lEL-0005IJ-4x; Tue, 08 Mar 2005 15:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lEK-0005IE-DA for pce@megatron.ietf.org; Tue, 08 Mar 2005 15:23:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13916 for ; Tue, 8 Mar 2005 15:22:58 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lGl-0007kD-MZ for pce@ietf.org; Tue, 08 Mar 2005 15:25:32 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j28KMmAZ022771; Tue, 8 Mar 2005 15:22:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14393; Tue, 8 Mar 2005 15:22:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Mar 2005 15:22:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B454114@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'JP Vasseur'" Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Tue, 8 Mar 2005 15:22:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Yes --> -----Original Message----- --> From: pce-bounces@lists.ietf.org --> [mailto:pce-bounces@lists.ietf.org]On --> Behalf Of JP Vasseur --> Sent: Tuesday, March 08, 2005 12:37 PM --> To: pce@ietf.org --> Subject: [Pce] Opinion on adopting --> draft-ash-pce-architecture-01 as a --> PCE WG document ? --> --> --> All, --> --> We discussed yesterday draft-ash-pce-architecure-01 --> (http://www.ietf.org/internet-drafts/draft-ash-pce-architect ure-01.txt) for which there was a pretty large consensus in the room to adopt it as a WG document. Let us know bring this question on the list. Could you please express your opinion on whether this draft should be adopted as a working group document (Y/N) ? ps: note that comments were made yesterday (include a paragraph on unsolicited PCE path computation, ...) which should be taken care of in the next revision. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 15:35:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16566; Tue, 8 Mar 2005 15:35:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lSr-0008SJ-0i; Tue, 08 Mar 2005 15:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lLb-0007CP-CC; Tue, 08 Mar 2005 15:30:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lLZ-0007C3-QL for pce@megatron.ietf.org; Tue, 08 Mar 2005 15:30:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15263 for ; Tue, 8 Mar 2005 15:30:27 -0500 (EST) Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lNu-00083n-JO for pce@ietf.org; Tue, 08 Mar 2005 15:33:01 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id j28KTtj13511; Wed, 9 Mar 2005 05:29:55 +0900 (JST) Received: from usjk1037 (localhost [127.0.0.1]) by usjk1006.kddi.com with SMTP id j28KTtQ00883; Wed, 9 Mar 2005 05:29:55 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.150]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20050308202948.IQOS24157.usjk1009.kddi.com@[127.0.0.1]>; Wed, 9 Mar 2005 05:29:48 +0900 Date: Wed, 09 Mar 2005 05:29:42 +0900 From: Kenji Kumaki To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> References: <3f5391901238ba96fe00eba115942e67@cisco.com> Message-Id: <20050309052843.4B94.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] X-WAuditID: 0503090529490000022886 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Yes. > > Let us know bring this question on the list. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? > -- Kenji Kumaki _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 15:38:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17185; Tue, 8 Mar 2005 15:38:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lWE-0000AQ-NA; Tue, 08 Mar 2005 15:41:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lTC-0000zS-3H; Tue, 08 Mar 2005 15:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lTA-0000yp-1w for pce@megatron.ietf.org; Tue, 08 Mar 2005 15:38:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17105 for ; Tue, 8 Mar 2005 15:38:17 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lVc-00008y-Cf for pce@ietf.org; Tue, 08 Mar 2005 15:40:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 12:38:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j28Kc7YO023592; Tue, 8 Mar 2005 12:38:08 -0800 (PST) Received: from [130.129.135.17] (sjc-vpn6-330.cisco.com [10.21.121.74]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA02817; Tue, 8 Mar 2005 12:38:01 -0800 (PST) In-Reply-To: <422DFD3E.30802@psg.com> References: <3f5391901238ba96fe00eba115942e67@cisco.com> <422DFD3E.30802@psg.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9e0f767a2a34325237021dfe55105270@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Tue, 8 Mar 2005 14:36:54 -0600 To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi Dimitri, On Mar 8, 2005, at 1:30 PM, dimitri papadimitriou wrote: > hi jp - > > from my record the "statefull PCE" comment is also to be addressed as > cases for which this would be useful is not described in the document > > it may be actually be interesting to list all the comments that would > require further work > adopting this document as a WG document does not mean that the work is over of course (see my ps:) ... the question was "Could you please express your opinion on whether this draft should be adopted as a working group document (Y/N) ?" Thanks. JP. > thanks, > - dimitri. > > JP Vasseur wrote: >> All, >> We discussed yesterday draft-ash-pce-architecure-01 >> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture >> -01.txt) for which there was a pretty large consensus in the room to >> adopt it as a WG document. >> Let us know bring this question on the list. >> Could you please express your opinion on whether this draft should be >> adopted as a working group document (Y/N) ? >> ps: note that comments were made yesterday (include a paragraph on >> unsolicited PCE path computation, ...) which should be taken care of >> in the next revision. >> Thanks. >> JP and Adrian. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 16:29:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21874; Tue, 8 Mar 2005 16:29:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mJZ-0001dG-C6; Tue, 08 Mar 2005 16:32:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mFQ-0000Uh-7Q; Tue, 08 Mar 2005 16:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mFO-0000Uc-PK for pce@megatron.ietf.org; Tue, 08 Mar 2005 16:28:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21621 for ; Tue, 8 Mar 2005 16:28:08 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mHr-0001Zu-45 for pce@ietf.org; Tue, 08 Mar 2005 16:30:44 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS1N1011228; Wed, 9 Mar 2005 06:28:01 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS1uG020879; Wed, 9 Mar 2005 06:28:01 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS10O020870; Wed, 9 Mar 2005 06:28:01 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS0Hr010904; Wed, 9 Mar 2005 06:28:00 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS0cs010899; Wed, 9 Mar 2005 06:28:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LS0U8000349; Wed, 9 Mar 2005 06:28:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LRxIf007418; Wed, 9 Mar 2005 06:27:59 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j28LRxGm007415; Wed, 9 Mar 2005 06:27:59 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id GAA29319; Wed, 9 Mar 2005 06:27:57 +0900 (JST) Date: Wed, 09 Mar 2005 06:27:54 +0900 From: Eiji Oki To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> References: <3f5391901238ba96fe00eba115942e67@cisco.com> Message-Id: <20050309062618.4478.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.08 [ja] X-Spam-Score: 2.2 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Yes. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 16:59:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24623; Tue, 8 Mar 2005 16:59:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mmS-0002Ix-S4; Tue, 08 Mar 2005 17:02:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mjo-0004HB-7T; Tue, 08 Mar 2005 16:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mc6-0003JX-GA for pce@megatron.ietf.org; Tue, 08 Mar 2005 16:51:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23650 for ; Tue, 8 Mar 2005 16:51:36 -0500 (EST) Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8meW-00026F-Lu for pce@ietf.org; Tue, 08 Mar 2005 16:54:11 -0500 Received: from localhost (jau@localhost) by coe.drexel.edu (8.12.9/8.12.9) with ESMTP id j28LoODX021919; Tue, 8 Mar 2005 16:50:24 -0500 (EST) Date: Tue, 8 Mar 2005 16:50:24 -0500 (EST) From: Jaudelice Cavalcante de Oliveira To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> Message-ID: References: <3f5391901238ba96fe00eba115942e67@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Tue, 08 Mar 2005 16:59:34 -0500 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 > Let us know bring this question on the list. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? Yes, definitely. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 17:09:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25113; Tue, 8 Mar 2005 17:09:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mvf-0002Rr-3m; Tue, 08 Mar 2005 17:11:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8msg-0005Zd-RA; Tue, 08 Mar 2005 17:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mse-0005ZY-PU for pce@megatron.ietf.org; Tue, 08 Mar 2005 17:08:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25060 for ; Tue, 8 Mar 2005 17:08:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mv7-0002Qr-0g for pce@ietf.org; Tue, 08 Mar 2005 17:11:18 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8msV-000KZU-KO; Tue, 08 Mar 2005 22:08:36 +0000 Message-ID: <422E2263.8080001@psg.com> Date: Tue, 08 Mar 2005 23:08:35 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? References: <3f5391901238ba96fe00eba115942e67@cisco.com> <422DFD3E.30802@psg.com> <023301c52417$ed581e30$a4858182@Puppy> In-Reply-To: <023301c52417$ed581e30$a4858182@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit hi adrian, i don't think the point has been well understood then, the question is not whether you can or not find an example where it could be used but whether it is appropriate as part of this "architecture" document now, to be more accurate here it can be advisable to start discussing what a path computation state more precisely means (in particular make the distinction between a path state and path computation state since they are different beasts) - which information it maintains and how this maintenance is expected to occur e.g. incremental - otherwise determination of the feasibility of this approach sounds difficult as part of this document hope this clarifies my concerns, - dimitri. Adrian Farrel wrote: > Hi Dimitri, > > >>from my record the "statefull PCE" comment is also to be addressed as >>cases for which this would be useful is not described in the document > > > I beg to differ. > Section 6.8 contains... > > Note that although this allows for optimal path > computation and increased path computation success > > ...which is an implicit use case. > > But also section 6.8 contains... > There is benefit in knowing which LSPs exist, and their routing, to > support such applications as placing a high priority LSP in a crowded > network such that it preempts as few other LSPs as possible. Note that > preempting based on the minimum number of links might not result in the > smallest number of LSPs being disrupted. Another application concerns > the construction and maintenance of a Virtual Network Topology [MRN]. > It is also helpful to understand which other LSPs exist in the network > in order to decide how to manage the forward adjacencies that exist or > need to be set up. The cost-benefit of stateful PCE computation would > be > helpful to determine if the benefit in path computation is sufficient > to > offset the additional drain on the network computational resources. > > ...which gives several applications. > > >>it may be actually be interesting to list all the comments that would >>require further work > > > Yes, I think that would be useful. > In fact, I hope the editor is doing this to track the work for the draft. > > Do either of these comments lead you to an answer to JP's question? > > Thanks, > Adrian > > >>JP Vasseur wrote: >> >>>All, >>> >>>We discussed yesterday draft-ash-pce-architecure-01 >>> > > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > >>>for which there was a pretty large consensus in the room to adopt it > > as > >>>a WG document. >>> >>>Let us know bring this question on the list. >>> >>>Could you please express your opinion on whether this draft should be >>>adopted as a working group document (Y/N) ? >>> >>>ps: note that comments were made yesterday (include a paragraph on >>>unsolicited PCE path computation, ...) which should be taken care of > > in > >>>the next revision. > > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 17:09:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25145; Tue, 8 Mar 2005 17:09:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mvu-0002SS-BU; Tue, 08 Mar 2005 17:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8msa-0005ZQ-Hm; Tue, 08 Mar 2005 17:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8msZ-0005ZL-5B for pce@megatron.ietf.org; Tue, 08 Mar 2005 17:08:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25048 for ; Tue, 8 Mar 2005 17:08:36 -0500 (EST) Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mv0-0002QZ-BN for pce@ietf.org; Tue, 08 Mar 2005 17:11:12 -0500 Received: from INOUE-LETS-CFW2.lab.ntt.co.jp (wireless-130-129-135-162.ietf62.ietf.org [130.129.135.162]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 3BABD278D for ; Wed, 9 Mar 2005 07:08:32 +0900 (JST) Message-Id: <6.0.0.20.2.20050309070816.067aa630@cronos.ocn.ne.jp> X-Sender: inoue.ichiro@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 09 Mar 2005 07:08:41 +0900 To: pce@ietf.org From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WGdocument ? In-Reply-To: <3f5391901238ba96fe00eba115942e67@cisco.com> References: <3f5391901238ba96fe00eba115942e67@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Yes, At 11:36 05/03/08 -0600, JP Vasseur wrote: >All, > >We discussed yesterday draft-ash-pce-architecure-01 (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) for which there was a pretty large consensus in the room to adopt it as a WG document. > >Let us know bring this question on the list. > >Could you please express your opinion on whether this draft should be adopted as a working group document (Y/N) ? > >ps: note that comments were made yesterday (include a paragraph on unsolicited PCE path computation, ...) which should be taken care of in the next revision. > >Thanks. > >JP and Adrian. > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 8 17:32:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26592; Tue, 8 Mar 2005 17:32:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nHp-0002q4-Kj; Tue, 08 Mar 2005 17:34:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nDy-00088m-Gg; Tue, 08 Mar 2005 17:30:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nDx-00088h-70 for pce@megatron.ietf.org; Tue, 08 Mar 2005 17:30:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26533 for ; Tue, 8 Mar 2005 17:30:42 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nGQ-0002oY-8A for pce@ietf.org; Tue, 08 Mar 2005 17:33:18 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 80B70E0000D4; Tue, 8 Mar 2005 22:30:28 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 22:21:29 +0000 Message-ID: <02b901c5242d$63cee980$a4858182@Puppy> From: "Adrian Farrel" To: , References: <3f5391901238ba96fe00eba115942e67@cisco.com> <422DFD3E.30802@psg.com> <023301c52417$ed581e30$a4858182@Puppy> <422E2263.8080001@psg.com> Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? Date: Tue, 8 Mar 2005 22:22:48 -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-OriginalArrivalTime: 08 Mar 2005 22:21:29.0430 (UTC) FILETIME=[2CD65760:01C5242D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: pce@ietf.org 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Hi, Yes (and thanks for the off-line discussions). It seems that the co-chairs are a little confused about what is an architecture I-D and what is a framework I-D. We will get some advice form our ADs when we meet them tomorrow morning, and come back to y'all. With regard to defining "what is state?"; this is clearly important to the definition of what is "stateful". There is clearly a very wide spectrum of state information, and many of the differences in opinion about the meta-question must be dependent on different opinions of what comprises state and how much state we are talking about. Clearly more discussion and debate is needed. In the context of a framework I-D, it is probably sufficient to state a desire for (or against) stateful PCE, and to give a few examples to set expectations of the range of potential options. In the context of a requirements draft, it is necessary to understand which scenarios are being addressed and what state is required to be retained. So where does an architecture I-D fit in? I'm not sure. Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: ; "JP Vasseur" ; Sent: Tuesday, March 08, 2005 10:08 PM Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? > > hi adrian, i don't think the point has been well understood then, the > question is not whether you can or not find an example where it could be > used but whether it is appropriate as part of this "architecture" document > > now, to be more accurate here it can be advisable to start discussing > what a path computation state more precisely means (in particular make > the distinction between a path state and path computation state since > they are different beasts) - which information it maintains and how this > maintenance is expected to occur e.g. incremental - otherwise > determination of the feasibility of this approach sounds difficult as > part of this document > > hope this clarifies my concerns, > - dimitri. > > Adrian Farrel wrote: > > Hi Dimitri, > > > > > >>from my record the "statefull PCE" comment is also to be addressed as > >>cases for which this would be useful is not described in the document > > > > > > I beg to differ. > > Section 6.8 contains... > > > > Note that although this allows for optimal path > > computation and increased path computation success > > > > ...which is an implicit use case. > > > > But also section 6.8 contains... > > There is benefit in knowing which LSPs exist, and their routing, to > > support such applications as placing a high priority LSP in a crowded > > network such that it preempts as few other LSPs as possible. Note that > > preempting based on the minimum number of links might not result in the > > smallest number of LSPs being disrupted. Another application concerns > > the construction and maintenance of a Virtual Network Topology [MRN]. > > It is also helpful to understand which other LSPs exist in the network > > in order to decide how to manage the forward adjacencies that exist or > > need to be set up. The cost-benefit of stateful PCE computation would > > be > > helpful to determine if the benefit in path computation is sufficient > > to > > offset the additional drain on the network computational resources. > > > > ...which gives several applications. > > > > > >>it may be actually be interesting to list all the comments that would > >>require further work > > > > > > Yes, I think that would be useful. > > In fact, I hope the editor is doing this to track the work for the draft. > > > > Do either of these comments lead you to an answer to JP's question? > > > > Thanks, > > Adrian > > > > > >>JP Vasseur wrote: > >> > >>>All, > >>> > >>>We discussed yesterday draft-ash-pce-architecure-01 > >>> > > > > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > > > >>>for which there was a pretty large consensus in the room to adopt it > > > > as > > > >>>a WG document. > >>> > >>>Let us know bring this question on the list. > >>> > >>>Could you please express your opinion on whether this draft should be > >>>adopted as a working group document (Y/N) ? > >>> > >>>ps: note that comments were made yesterday (include a paragraph on > >>>unsolicited PCE path computation, ...) which should be taken care of > > > > in > > > >>>the next revision. > > > > > > > > . > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Mar 9 13:32:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04895; Wed, 9 Mar 2005 13:32:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D961J-0007ML-Ia; Wed, 09 Mar 2005 13:34:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D95rK-0000xC-7X; Wed, 09 Mar 2005 13:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D95rI-0000x7-8c for pce@megatron.ietf.org; Wed, 09 Mar 2005 13:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04076 for ; Wed, 9 Mar 2005 13:24:32 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D95tv-00077X-RV for pce@ietf.org; Wed, 09 Mar 2005 13:27:20 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j29IOL77017039; Wed, 9 Mar 2005 13:24:21 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25730; Wed, 9 Mar 2005 13:24:18 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Mar 2005 13:24:19 -0500 Message-ID: From: "Morris, Stephen" To: "'Adrian Farrel'" , dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aP CE WG document ? Date: Wed, 9 Mar 2005 13:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Hi Adrian Very good document. I vote yes. I had a few minor comments. 1) Is there an assumption that the PCE would be single tasking in nature? If it handles multiple path requests simultaneously then would this have an effect on the result? Maybe a comment is needed to clarify this 2) I'm interested to see how the PCE capabilities (e.g., around section 4.4) would be exposed to an external management system. Maybe a few lines or a placeholder paragraph would keep this in scope, e.g., the API might be SNMP-based or use an RPC mechanism 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems not to fit in the context of RFC2547 4) Section 4.5 heading: "Plan" should be "Plane" I look forward to the next draft! Best wishes Stephen Morris -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]On Behalf Of Adrian Farrel Sent: 08 March 2005 22:23 To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be Cc: pce@ietf.org Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? Hi, Yes (and thanks for the off-line discussions). It seems that the co-chairs are a little confused about what is an architecture I-D and what is a framework I-D. We will get some advice form our ADs when we meet them tomorrow morning, and come back to y'all. With regard to defining "what is state?"; this is clearly important to the definition of what is "stateful". There is clearly a very wide spectrum of state information, and many of the differences in opinion about the meta-question must be dependent on different opinions of what comprises state and how much state we are talking about. Clearly more discussion and debate is needed. In the context of a framework I-D, it is probably sufficient to state a desire for (or against) stateful PCE, and to give a few examples to set expectations of the range of potential options. In the context of a requirements draft, it is necessary to understand which scenarios are being addressed and what state is required to be retained. So where does an architecture I-D fit in? I'm not sure. Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: ; "JP Vasseur" ; Sent: Tuesday, March 08, 2005 10:08 PM Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? > > hi adrian, i don't think the point has been well understood then, the > question is not whether you can or not find an example where it could be > used but whether it is appropriate as part of this "architecture" document > > now, to be more accurate here it can be advisable to start discussing > what a path computation state more precisely means (in particular make > the distinction between a path state and path computation state since > they are different beasts) - which information it maintains and how this > maintenance is expected to occur e.g. incremental - otherwise > determination of the feasibility of this approach sounds difficult as > part of this document > > hope this clarifies my concerns, > - dimitri. > > Adrian Farrel wrote: > > Hi Dimitri, > > > > > >>from my record the "statefull PCE" comment is also to be addressed as > >>cases for which this would be useful is not described in the document > > > > > > I beg to differ. > > Section 6.8 contains... > > > > Note that although this allows for optimal path > > computation and increased path computation success > > > > ...which is an implicit use case. > > > > But also section 6.8 contains... > > There is benefit in knowing which LSPs exist, and their routing, to > > support such applications as placing a high priority LSP in a crowded > > network such that it preempts as few other LSPs as possible. Note that > > preempting based on the minimum number of links might not result in the > > smallest number of LSPs being disrupted. Another application concerns > > the construction and maintenance of a Virtual Network Topology [MRN]. > > It is also helpful to understand which other LSPs exist in the network > > in order to decide how to manage the forward adjacencies that exist or > > need to be set up. The cost-benefit of stateful PCE computation would > > be > > helpful to determine if the benefit in path computation is sufficient > > to > > offset the additional drain on the network computational resources. > > > > ...which gives several applications. > > > > > >>it may be actually be interesting to list all the comments that would > >>require further work > > > > > > Yes, I think that would be useful. > > In fact, I hope the editor is doing this to track the work for the draft. > > > > Do either of these comments lead you to an answer to JP's question? > > > > Thanks, > > Adrian > > > > > >>JP Vasseur wrote: > >> > >>>All, > >>> > >>>We discussed yesterday draft-ash-pce-architecure-01 > >>> > > > > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > > > >>>for which there was a pretty large consensus in the room to adopt it > > > > as > > > >>>a WG document. > >>> > >>>Let us know bring this question on the list. > >>> > >>>Could you please express your opinion on whether this draft should be > >>>adopted as a working group document (Y/N) ? > >>> > >>>ps: note that comments were made yesterday (include a paragraph on > >>>unsolicited PCE path computation, ...) which should be taken care of > > > > in > > > >>>the next revision. > > > > > > > > . > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Mar 9 14:02:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08202; Wed, 9 Mar 2005 14:02:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96V6-0008JG-2d; Wed, 09 Mar 2005 14:05:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96RD-0007Ny-Sw; Wed, 09 Mar 2005 14:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96RD-0007Nf-47 for pce@megatron.ietf.org; Wed, 09 Mar 2005 14:01:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08121 for ; Wed, 9 Mar 2005 14:01:41 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96Tr-0008H8-D4 for pce@ietf.org; Wed, 09 Mar 2005 14:04:27 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 0ABF6E0000AB; Wed, 9 Mar 2005 19:01:29 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 18:52:11 +0000 Message-ID: <038a01c524d9$51876ca0$a4858182@Puppy> From: "Adrian Farrel" To: "Morris, Stephen" References: Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Wed, 9 Mar 2005 18:53:26 -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-OriginalArrivalTime: 09 Mar 2005 18:52:11.0848 (UTC) FILETIME=[1A592480:01C524D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: pce@ietf.org 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Hi, Thanks for your comments. In line... Adrian > 1) Is there an assumption that the PCE would be single tasking in nature? If > it handles multiple path requests simultaneously then would this have an > effect on the result? Maybe a comment is needed to clarify this Certainly there is no attempt to constrain (or even discuss) implementation choices. Clearly different algorithms or orders of computation will make a difference to the paths that are derived. In fact, using multiple PCEs responsible for a single domain would have the same effect. However, this is not SPF. - The MPLS TE path computed by PCE must be the "best" at the time of computation. - It is always possible that a computed path cannot be provisioned (failure of resources, provisioning of other LSPs, etc., etc., etc.) Thus, I believe that this is an implementaiton issue only. We could add a few wise words to this if the WG thinks it would be helpful, but I don't want to go into much detail in the draft. > 2) I'm interested to see how the PCE capabilities (e.g., around section 4.4) > would be exposed to an external management system. Maybe a few lines or a > placeholder paragraph would keep this in scope, e.g., the API might be > SNMP-based or use an RPC mechanism OK. I think the ability to configure, manage and inspect a PCE will be the subject of a MIB module. However, there is a fine line for us to draw. Operational or implementation choices that describe the computation in a PCE are out of scope. Functioning of the protocols are in scope. Thus (silly example!): - configure the number of CPUs that can be dedicated to PCE processing - out of scope - inspect the value for CPU congestion and capablities reported by the PCE discovery protocol - in scope > 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems not > to fit in the context of RFC2547 LSPs are not only used in the context of RFC2547 :-) Hint1: GMPLS Overlay draft Hint2: GVPN draft > 4) Section 4.5 heading: "Plan" should be "Plane" Thanks. > I look forward to the next draft! > Best wishes > Stephen Morris _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Mar 9 18:08:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00571; Wed, 9 Mar 2005 18:08:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9AKa-0005a8-GG; Wed, 09 Mar 2005 18:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AH8-0005f8-1n; Wed, 09 Mar 2005 18:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AH6-0005eO-K6 for pce@megatron.ietf.org; Wed, 09 Mar 2005 18:07:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00464 for ; Wed, 9 Mar 2005 18:07:29 -0500 (EST) 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.33) id 1D9AJm-0005Z6-Vg for pce@ietf.org; Wed, 09 Mar 2005 18:10:19 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2005 15:22:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,152,1107763200"; d="scan'208"; a="618617970:sNHT30580116" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j29N7HuC014749; Wed, 9 Mar 2005 15:07:18 -0800 (PST) Received: from [10.4.0.173] (sjc-vpn5-392.cisco.com [10.21.89.136]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA20090; Wed, 9 Mar 2005 15:07:19 -0800 (PST) In-Reply-To: <038a01c524d9$51876ca0$a4858182@Puppy> References: <038a01c524d9$51876ca0$a4858182@Puppy> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8a2a8734a82e1dfd079a53e562d529e0@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Wed, 9 Mar 2005 17:07:38 -0600 To: Stephen Morris X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Hi, Few comments in line, On Mar 9, 2005, at 12:53 PM, Adrian Farrel wrote: > Hi, > > Thanks for your comments. > In line... > > Adrian > >> 1) Is there an assumption that the PCE would be single tasking in > nature? If >> it handles multiple path requests simultaneously then would this have >> an >> effect on the result? Maybe a comment is needed to clarify this > > Certainly there is no attempt to constrain (or even discuss) > implementation choices. > > Clearly different algorithms or orders of computation will make a > difference to the paths that are derived. > In fact, using multiple PCEs responsible for a single domain would have > the same effect. > Fully agree with Adrian's comments here. Note that indeed, an implementation may decide to serialize path computation requests or perform some requests packing under specific conditions but as already pointed out, this is implementation specific. > However, this is not SPF. Just to avoid confusion ... of course, CSPF algorithms could be used on the PCE. Thanks for your comments. JP. > - The MPLS TE path computed by PCE must be the "best" at > the time of computation. > - It is always possible that a computed path cannot be provisioned > (failure of resources, provisioning of other LSPs, etc., etc., etc.) > Thus, I believe that this is an implementaiton issue only. > > We could add a few wise words to this if the WG thinks it would be > helpful, but I don't want to go into much detail in the draft. > >> 2) I'm interested to see how the PCE capabilities (e.g., around >> section > 4.4) >> would be exposed to an external management system. Maybe a few lines >> or > a >> placeholder paragraph would keep this in scope, e.g., the API might be >> SNMP-based or use an RPC mechanism > > OK. I think the ability to configure, manage and inspect a PCE will be > the > subject of a MIB module. However, there is a fine line for us to draw. > Operational or implementation choices that describe the computation in > a > PCE are out of scope. Functioning of the protocols are in scope. Thus > (silly example!): > - configure the number of CPUs that can be dedicated to PCE processing > - out of scope > - inspect the value for CPU congestion and capablities reported by the > PCE discovery protocol > - in scope > >> 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This >> seems > not >> to fit in the context of RFC2547 > > LSPs are not only used in the context of RFC2547 :-) > > Hint1: GMPLS Overlay draft > Hint2: GVPN draft > >> 4) Section 4.5 heading: "Plan" should be "Plane" > > Thanks. > >> I look forward to the next draft! >> Best wishes >> Stephen Morris > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Mar 11 11:16:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09428; Fri, 11 Mar 2005 11:16:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mrA-0003Sk-Cb; Fri, 11 Mar 2005 11:19:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mmc-0002v4-Sy; Fri, 11 Mar 2005 11:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mma-0002t7-Qr for pce@megatron.ietf.org; Fri, 11 Mar 2005 11:14:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09288 for ; Fri, 11 Mar 2005 11:14:34 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mpc-0003P1-V3 for pce@ietf.org; Fri, 11 Mar 2005 11:17:45 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2BGEK77006785; Fri, 11 Mar 2005 11:14:20 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03543; Fri, 11 Mar 2005 11:14:18 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 11 Mar 2005 11:14:19 -0500 Message-ID: From: "Morris, Stephen" To: "'Adrian Farrel'" Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Fri, 11 Mar 2005 11:13:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Thanks for the comments Adrian I just had one observation. You're right, there is a fine line between operational and implementation choices. I'm increasingly thinking that manageability is a genuine architectural quality attribute (along with extensibility, availability, security, etc.). Ultimately, manageability (e.g., of a PCE entity) is embodied in the workflows that occur during use. Leaving this until definition of the MIB module almost seems a little late for consideration of manageability (if the latter is architectural :-)). So, ideally I try to think about manageability prior to MIB design. I'm not sure when is the best time in this context :-). Does anyone have any thoughts on this? Best wishes Stephen -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 09 March 2005 18:53 To: Morris, Stephen Cc: pce@ietf.org Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Hi, Thanks for your comments. In line... Adrian > 1) Is there an assumption that the PCE would be single tasking in nature? If > it handles multiple path requests simultaneously then would this have an > effect on the result? Maybe a comment is needed to clarify this Certainly there is no attempt to constrain (or even discuss) implementation choices. Clearly different algorithms or orders of computation will make a difference to the paths that are derived. In fact, using multiple PCEs responsible for a single domain would have the same effect. However, this is not SPF. - The MPLS TE path computed by PCE must be the "best" at the time of computation. - It is always possible that a computed path cannot be provisioned (failure of resources, provisioning of other LSPs, etc., etc., etc.) Thus, I believe that this is an implementaiton issue only. We could add a few wise words to this if the WG thinks it would be helpful, but I don't want to go into much detail in the draft. > 2) I'm interested to see how the PCE capabilities (e.g., around section 4.4) > would be exposed to an external management system. Maybe a few lines or a > placeholder paragraph would keep this in scope, e.g., the API might be > SNMP-based or use an RPC mechanism OK. I think the ability to configure, manage and inspect a PCE will be the subject of a MIB module. However, there is a fine line for us to draw. Operational or implementation choices that describe the computation in a PCE are out of scope. Functioning of the protocols are in scope. Thus (silly example!): - configure the number of CPUs that can be dedicated to PCE processing - out of scope - inspect the value for CPU congestion and capablities reported by the PCE discovery protocol - in scope > 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems not > to fit in the context of RFC2547 LSPs are not only used in the context of RFC2547 :-) Hint1: GMPLS Overlay draft Hint2: GVPN draft > 4) Section 4.5 heading: "Plan" should be "Plane" Thanks. > I look forward to the next draft! > Best wishes > Stephen Morris _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Mar 11 11:50:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13298; Fri, 11 Mar 2005 11:50:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9nOi-0005SN-3b; Fri, 11 Mar 2005 11:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9nIX-0006Jb-VT; Fri, 11 Mar 2005 11:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9nIW-0006JW-TF for pce@megatron.ietf.org; Fri, 11 Mar 2005 11:47:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12972 for ; Fri, 11 Mar 2005 11:47:34 -0500 (EST) Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9nLY-0005IG-Kf for pce@ietf.org; Fri, 11 Mar 2005 11:50:45 -0500 Received: from localhost (localhost [127.0.0.1]) by coe.drexel.edu (8.12.9/8.12.9) with SMTP id j2BGlYHw014723 for ; Fri, 11 Mar 2005 11:47:34 -0500 (EST) Message-Id: <200503111647.j2BGlYHw014723@coe.drexel.edu> Date: Fri, 11 Mar 2005 11:47:34 -0500 (EST) From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? To: pce@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: w0Ogf0CT2IqO1fBg3Rh29g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.8 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaudelice Cavalcante de Oliveira List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ------------- Begin Forwarded Message ------------- Date: Tue, 8 Mar 2005 16:50:24 -0500 (EST) From: Jaudelice Cavalcante de Oliveira To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Cc: pce@ietf.org > Let us know bring this question on the list. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? Yes, definitely. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------------- End Forwarded Message ------------- ~~~~~~ Jaudelice C. de Oliveira, Assistant Professor Electrical and Computer Engineering Department Drexel University, Philadelphia PA 19104 Tel: 215.895.2248 Fax: 215.895.1695 E-Mail: jau@ece.drexel.edu URL: http://www.ece.drexel.edu/faculty/jau.html ~~~~~~ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Mar 11 18:12:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17162; Fri, 11 Mar 2005 18:12:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tLy-00080E-DO; Fri, 11 Mar 2005 18:15:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tHh-0004fk-Ob; Fri, 11 Mar 2005 18:11:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9tHf-0004ff-FH for pce@megatron.ietf.org; Fri, 11 Mar 2005 18:11:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17059 for ; Fri, 11 Mar 2005 18:11:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tKl-0007u0-6z for pce@ietf.org; Fri, 11 Mar 2005 18:14:19 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9tHc-000FJz-T7; Fri, 11 Mar 2005 23:11:05 +0000 Message-ID: <4232258F.5090806@psg.com> Date: Sat, 12 Mar 2005 00:11:11 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as aPCE WG document ? References: <3f5391901238ba96fe00eba115942e67@cisco.com> <422DFD3E.30802@psg.com> <023301c52417$ed581e30$a4858182@Puppy> <422E2263.8080001@psg.com> <02b901c5242d$63cee980$a4858182@Puppy> In-Reply-To: <02b901c5242d$63cee980$a4858182@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit hi adrian, see in-line concerning the architecture i-d fit question: Adrian Farrel wrote: > Hi, > > Yes (and thanks for the off-line discussions). > > It seems that the co-chairs are a little confused about what is an > architecture I-D and what is a framework I-D. > We will get some advice form our ADs when we meet them tomorrow morning, > and come back to y'all. > > With regard to defining "what is state?"; this is clearly important to the > definition of what is "stateful". There is clearly a very wide spectrum of > state information, and many of the differences in opinion about the > meta-question must be dependent on different opinions of what comprises > state and how much state we are talking about. Clearly more discussion and > debate is needed. > > In the context of a framework I-D, it is probably sufficient to state a > desire for (or against) stateful PCE, and to give a few examples to set > expectations of the range of potential options. In the context of a > requirements draft, it is necessary to understand which scenarios are > being addressed and what state is required to be retained. > > So where does an architecture I-D fit in? taking an analogy with RFC 3945, it would in the present case be a document that puts together the protocol building blocks i.e the PCC/E<->PCE communication, the discovery, the transactions, etc. such document usually builds up as the work progresses to give provide at the end the glue between the different elements thanks, - dimitri. > I'm not sure. > > Adrian > > ----- Original Message ----- > From: "dimitri papadimitriou" > To: "Adrian Farrel" > Cc: ; "JP Vasseur" ; > > Sent: Tuesday, March 08, 2005 10:08 PM > Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as > aPCE WG document ? > > > >>hi adrian, i don't think the point has been well understood then, the >>question is not whether you can or not find an example where it could be >>used but whether it is appropriate as part of this "architecture" > > document > >>now, to be more accurate here it can be advisable to start discussing >>what a path computation state more precisely means (in particular make >>the distinction between a path state and path computation state since >>they are different beasts) - which information it maintains and how this >>maintenance is expected to occur e.g. incremental - otherwise >>determination of the feasibility of this approach sounds difficult as >>part of this document >> >>hope this clarifies my concerns, >>- dimitri. >> >>Adrian Farrel wrote: >> >>>Hi Dimitri, >>> >>> >>>>from my record the "statefull PCE" comment is also to be addressed as >>> >>>>cases for which this would be useful is not described in the document >>> >>> >>>I beg to differ. >>>Section 6.8 contains... >>> >>> Note that although this allows for optimal path >>> computation and increased path computation success >>> >>>...which is an implicit use case. >>> >>>But also section 6.8 contains... >>> There is benefit in knowing which LSPs exist, and their routing, to >>> support such applications as placing a high priority LSP in a > > crowded > >>> network such that it preempts as few other LSPs as possible. Note > > that > >>> preempting based on the minimum number of links might not result in > > the > >>> smallest number of LSPs being disrupted. Another application > > concerns > >>> the construction and maintenance of a Virtual Network Topology > > [MRN]. > >>> It is also helpful to understand which other LSPs exist in the > > network > >>> in order to decide how to manage the forward adjacencies that exist > > or > >>> need to be set up. The cost-benefit of stateful PCE computation > > would > >>>be >>> helpful to determine if the benefit in path computation is > > sufficient > >>>to >>> offset the additional drain on the network computational resources. >>> >>>...which gives several applications. >>> >>> >>> >>>>it may be actually be interesting to list all the comments that would >>>>require further work >>> >>> >>>Yes, I think that would be useful. >>>In fact, I hope the editor is doing this to track the work for the > > draft. > >>>Do either of these comments lead you to an answer to JP's question? >>> >>>Thanks, >>>Adrian >>> >>> >>> >>>>JP Vasseur wrote: >>>> >>>> >>>>>All, >>>>> >>>>>We discussed yesterday draft-ash-pce-architecure-01 >>>>> >>> >>> > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt) > >>>>>for which there was a pretty large consensus in the room to adopt it >>> >>>as >>> >>> >>>>>a WG document. >>>>> >>>>>Let us know bring this question on the list. >>>>> >>>>>Could you please express your opinion on whether this draft should be >>>>>adopted as a working group document (Y/N) ? >>>>> >>>>>ps: note that comments were made yesterday (include a paragraph on >>>>>unsolicited PCE path computation, ...) which should be taken care of >>> >>>in >>> >>> >>>>>the next revision. >>> >>> >>> >>>. >>> >> >> > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Mar 12 11:39:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19706; Sat, 12 Mar 2005 11:39:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA9he-0001Yd-F2; Sat, 12 Mar 2005 11:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA9cz-0006zL-Ba; Sat, 12 Mar 2005 11:38:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA9cx-0006zC-5t for pce@megatron.ietf.org; Sat, 12 Mar 2005 11:38:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19585 for ; Sat, 12 Mar 2005 11:38:08 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA9gC-0001W2-Ai for pce@ietf.org; Sat, 12 Mar 2005 11:41:32 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 922C2E00008B; Sat, 12 Mar 2005 16:37:51 +0000 (GMT) Received: from Puppy ([212.43.203.9] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Mar 2005 16:28:13 +0000 Message-ID: <008401c52720$b5389c30$09cb2bd4@Puppy> From: "Adrian Farrel" To: "Morris, Stephen" References: Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? Date: Sat, 12 Mar 2005 16:29:02 -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-OriginalArrivalTime: 12 Mar 2005 16:28:14.0093 (UTC) FILETIME=[7D1593D0:01C52720] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Oh, I agree completely. (draft-farrel-rtg-manageability-requirements-00.txt) So, yes, the manageability of PCE must show up both in the architecture and in the requirements. Thanks, Adrian ----- Original Message ----- From: "Morris, Stephen" To: "'Adrian Farrel'" Cc: Sent: Friday, March 11, 2005 4:13 PM Subject: RE: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? > Thanks for the comments Adrian > I just had one observation. You're right, there is a fine line between > operational and implementation choices. I'm increasingly thinking that > manageability is a genuine architectural quality attribute (along with > extensibility, availability, security, etc.). > > Ultimately, manageability (e.g., of a PCE entity) is embodied in the > workflows that occur during use. Leaving this until definition of the MIB > module almost seems a little late for consideration of manageability (if the > latter is architectural :-)). So, ideally I try to think about manageability > prior to MIB design. I'm not sure when is the best time in this context :-). > > Does anyone have any thoughts on this? > Best wishes > Stephen > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 09 March 2005 18:53 > To: Morris, Stephen > Cc: pce@ietf.org > Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as > a PCE WG document ? > > > Hi, > > Thanks for your comments. > In line... > > Adrian > > > 1) Is there an assumption that the PCE would be single tasking in > nature? If > > it handles multiple path requests simultaneously then would this have an > > effect on the result? Maybe a comment is needed to clarify this > > Certainly there is no attempt to constrain (or even discuss) > implementation choices. > > Clearly different algorithms or orders of computation will make a > difference to the paths that are derived. > In fact, using multiple PCEs responsible for a single domain would have > the same effect. > > However, this is not SPF. > - The MPLS TE path computed by PCE must be the "best" at > the time of computation. > - It is always possible that a computed path cannot be provisioned > (failure of resources, provisioning of other LSPs, etc., etc., etc.) > Thus, I believe that this is an implementaiton issue only. > > We could add a few wise words to this if the WG thinks it would be > helpful, but I don't want to go into much detail in the draft. > > > 2) I'm interested to see how the PCE capabilities (e.g., around section > 4.4) > > would be exposed to an external management system. Maybe a few lines or > a > > placeholder paragraph would keep this in scope, e.g., the API might be > > SNMP-based or use an RPC mechanism > > OK. I think the ability to configure, manage and inspect a PCE will be the > subject of a MIB module. However, there is a fine line for us to draw. > Operational or implementation choices that describe the computation in a > PCE are out of scope. Functioning of the protocols are in scope. Thus > (silly example!): > - configure the number of CPUs that can be dedicated to PCE processing > - out of scope > - inspect the value for CPU congestion and capablities reported by the > PCE discovery protocol > - in scope > > > 3) In section 4.4, does anyone actually create CE-to-CE LSPs? This seems > not > > to fit in the context of RFC2547 > > LSPs are not only used in the context of RFC2547 :-) > > Hint1: GMPLS Overlay draft > Hint2: GVPN draft > > > 4) Section 4.5 heading: "Plan" should be "Plane" > > Thanks. > > > I look forward to the next draft! > > Best wishes > > Stephen Morris > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Mar 15 11:53:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19460; Tue, 15 Mar 2005 11:43:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFCr-0003gl-0O; Tue, 15 Mar 2005 11:47:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBEvh-000415-Ov; Tue, 15 Mar 2005 11:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9n61-0002LI-Uc for pce@megatron.ietf.org; Fri, 11 Mar 2005 11:34:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11795 for ; Fri, 11 Mar 2005 11:34:39 -0500 (EST) Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9n93-0004eQ-GX for pce@ietf.org; Fri, 11 Mar 2005 11:37:50 -0500 Received: from localhost (localhost [127.0.0.1]) by coe.drexel.edu (8.12.9/8.12.9) with SMTP id j2BGYdHw012633 for ; Fri, 11 Mar 2005 11:34:39 -0500 (EST) Message-Id: <200503111634.j2BGYdHw012633@coe.drexel.edu> Date: Fri, 11 Mar 2005 11:34:39 -0500 (EST) From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? To: pce@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uWp7TgCIZxua2YDq8K2OwA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.8 SunOS 5.8 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Tue, 15 Mar 2005 11:30:00 -0500 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaudelice Cavalcante de Oliveira List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ------------- Begin Forwarded Message ------------- Date: Tue, 8 Mar 2005 16:50:24 -0500 (EST) From: Jaudelice Cavalcante de Oliveira To: JP Vasseur Subject: Re: [Pce] Opinion on adopting draft-ash-pce-architecture-01 as a PCE WG document ? > Let us know bring this question on the list. > > Could you please express your opinion on whether this draft should be > adopted as a working group document (Y/N) ? Yes, definitely. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------------- End Forwarded Message ------------- ~~~~~~ Dr. Jaudelice C. de Oliveira, Assistant Professor Electrical and Computer Engineering Department Drexel University, Philadelphia PA 19104 Tel: 215.895.2248 Fax: 215.895.1695 E-Mail: jau@ece.drexel.edu URL: http://www.ece.drexel.edu/faculty/jau.html ~~~~~~ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Mar 16 07:46:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14403; Wed, 16 Mar 2005 07:46:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBXzJ-0001eH-NN; Wed, 16 Mar 2005 07:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXv0-0001Jx-9g; Wed, 16 Mar 2005 07:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXuy-0001Hz-2b for pce@megatron.ietf.org; Wed, 16 Mar 2005 07:46:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14372 for ; Wed, 16 Mar 2005 07:46:30 -0500 (EST) 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.33) id 1DBXyz-0001dS-9x for pce@ietf.org; Wed, 16 Mar 2005 07:50:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2005 05:02:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,167,1107763200"; d="scan'208"; a="619971406:sNHT47206722" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2GCkH6d013437 for ; Wed, 16 Mar 2005 04:46:17 -0800 (PST) Received: from [192.168.1.102] (che-vpn-cluster-2-159.cisco.com [10.86.242.159]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA11584 for ; Wed, 16 Mar 2005 04:46:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <82c0fccf79e31986cd624402eef74b17@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Wed, 16 Mar 2005 07:46:39 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Pce] First WG doc: draft-ash-pce-architecture 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Dear WG, Considering the WG consensus, draft-ash-pce-architecture is adopted as a PCE WG document. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Mar 18 11:06:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21978; Fri, 18 Mar 2005 11:06:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCK3t-0002xV-Fp; Fri, 18 Mar 2005 11:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJxN-00066U-IF; Fri, 18 Mar 2005 11:04:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJxL-00066F-Kd for pce@megatron.ietf.org; Fri, 18 Mar 2005 11:04:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21736 for ; Fri, 18 Mar 2005 11:04:08 -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.33) id 1DCK1o-0002tO-49 for pce@ietf.org; Fri, 18 Mar 2005 11:08:49 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2005 08:04:01 -0800 X-IronPort-AV: i="3.91,102,1110182400"; d="scan'208"; a="237313814:sNHT63466528" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2IG3uDr006714 for ; Fri, 18 Mar 2005 08:03:57 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-2-189.cisco.com [10.86.242.189]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA29796 for ; Fri, 18 Mar 2005 08:03:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: pce@ietf.org Message-Id: <3f782884cb90801c1647d24b4322f3ec@cisco.com> From: JP Vasseur Date: Fri, 18 Mar 2005 11:04:17 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 757213506fa7686cfc6a78c7feebc88f Subject: [Pce] PCE WG meeting: draft minutes 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="===============0475814772==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 507ad05d8e517f8285c14ade4dc3acf0 --===============0475814772== Content-Type: multipart/alternative; boundary=Apple-Mail-1--289328176 --Apple-Mail-1--289328176 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Please find below the draft minutes of the PCE WG meeting. Let us know =20= if you have comments: A special thank to Jaudelice and Zafar for having taken the minutes. PCE WG meeting minutes =96 IETF-62 - Minneapolis --------------------------------------------------------------- CHAIR REPORT ---------------------- Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area =20 TE) first Milestones have very aggressive timeline Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications. Work in progress to be presented today: - Draft on PCE architecture - Draft on PCE discovery requirements and protocol extensions - Draft on PCE communication Immediate next work: Draft on PCE communication protocol specification Draft on PCE discovery protocol Draft on objective metrics End of chair report ------------------- Question from audience on objective metrics: Metrics to evaluate PCE. JP gave a few examples of metrics of interest: E.g., How fast you can respond to topology changes, etc. First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash ------------------------------------------------------------------------=20= ---- Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics. Issued raised on the list - already responded (text added to several sections with respect to every comment) added to 6.4: PCE should advertise capabilities added to 6.6: Path computation request include if near-disjoint paths acceptable added to 6.7: TED information can include info from sources other than =20= IGP added to 6.8: elaborate on advantages of stateful PCE & pitfalls of =20 using stateful PCE in a distributed PCE environment added to 7: Further metrics proposed to evaluate PCE solutions next steps: propose draft as PCE WG draft Questions raised: ------------------ Question: Concern raised on how feasible is the considered approach (stateful PCE). An element performing optimal computational might take infinite time to =20= do so. Concern about delegating the distributed control plane =20 responsibility to PCE. Question on possibility of unsolicited requests PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well? Are there specific requirements on response time of PCE? (for global optimization) JP: will be part of the evaluation metrics. Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly) message sent to ITU-T about PCE working group. What is in the ITU-T? Audience member said that G7715 on ITU-T has similar function. Dimtri asked a question on stateful vs. stateless PCE in the document; =20= how feasible is stateful PCE? Is it reasonable to assume stateful PCE? Jerry: yes for some applications. Dimitri: Is this can be assumed manageable? Given control to PCE that =20= is otherwise done by a distributed control plan. JP added: It=92s applicable for some applications requiring global =20 optimization. Kireeti: (Global Optimality) is NOT a good target. Stateful PCE =20 provides lot of complexity, while nice- not feasible. Dimitri: Re; global optimization, what is responsible? JP: Evaluation Metric is to be used for this purpose. Igore: Similar comments for stateful vs. stateless. Adrian: ITU-T also requires similar functionality. Liaison Statement to =20= ITU-T is completed. We think SG-15 would be a god start. J. Sadder: Yes, there is similar work pursued at ITU-T. JP Pooled the audience for the Architecture document. JP: Majority in favor it as a WG document. We will confirm at the =20 mailing list. Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis ------------------------------------------------------------------------=20= ------------ PCE Discovery requirements The draft addresses PCE discovery within and across domain(s). Remaining issues: Address comments received in the next version * Need to improve security particularly for Inter-AS PCE discovery * Discovery of dynamic parameters such as the PCE CPU state * PCE aliveness detection Consensus for a WG doc? Questions raised: --------------------- Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? comment2: If there is a need, routing is a better place than signalling. JP reminded that the document is just identifying requirements but not solutions. Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). =20= How did the 60 seconds rule was defined? Need to include how that was =20 decided. Dimitri: Are we not already overloading the PCEs? Need to define the =20 right level of abstraction... It is an open question. Needs further =20 discussion. Correct the overload problem before hand. Concern: Enumeration of the set of minimum requirements. Right now it shows an enumerations of possible solutions. Need to focus on minimal requirements. JP: Reminder that the draft is in its first version. Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery =20 includes CPU load factor, it will complicate the PCC system. Dimitri: you haven=92t design the system and are worried about the =20 overloaded system. General problem of the overload should be solved at =20= the root (architecture). Tony Li: As far as process is concerned, start off with a good =20 requirement document, enumerate minimum set of requirements. What you =20= got right now is iteration from the solution space. Focus on minimum =20 requirement and what is the basic problem we are trying to solve. Adrian: This was only first revision of the document. Igor: We need to advertise backup PCE, why backup PCE and not =20 load-balanced. JL: The SP thinks that having a dedicated backup could also be useful. =20= But this is optional. JP: Few sensitive topics like advertisement of dynamic capability needs =20= more discussion on the mailing list. Richard Rabbot: Not all ABR are PCE in your Figure. JL: It is just an example case used for illustration purpose only. Richard Rabbot: How did you come up with 60 second requirement? JL: There are number of SP on the ID and we think 60 sec is a good =20 target. Will provide more details on this. Dimitri: Does these requirements covers inter-AS case? JL: Yes. Dimitri: If today a router may be overloaded and we don=92t do anything =20= specific, should we worry about PCE overloaded cases? We need to make =20= sure that right level of details are provided in the document. The =20 basic stuff like, how to find reachable addresses is not there in the =20= document. We don=92t have basic stuff in the document. JL: No reachability stuff is detailed in the document. There is mention =20= of domain ID-es: area-ID & AS number. JP: This is not a flushed out version. Thanks to DT for their effort in =20= putting this together. Requires more discussion in the mailing list =20 before asking to adopt this ID as a WG document. Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash ------------------------------------------------------------------------=20= ---------- PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) Various issues raised on the list: for example extensive discussions =20 about re-use of RSVP object encodings Questions raised: ---------------------- Arthi: Is there a requirement of unsolicited PCE to PCC communication. Zafar: Yes, there are cases where unsolicited PCE to PCC communication =20= is required. Many: Is it suitabe to list candidates on this documents? JP: candidates are out of the scope of this protocol. Document is a =20 very first cut. Kireeti: Stateless x stateful. There are needs and there are benefits. Comment: Contradiction, scalability reqirements. Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make =20 decision that is related to the forwarding plan? Jerry: The intension was to mention requirement to include some QOS =20 parameters in the PCC-PCE messages. JP: clarified that the intention was to include possibility of QoS considerations in path computation. JP/ Jerry: I.e., Path Computation Constraints related parameters. Kireeti: On GR of PCE: When it comes to GR, there is a huge difference =20= between stateful and stateless PCE. Recommend to put it in an =20 applicability statement. JP: Yes, complexity analysis is meant for this purpose. Adrian/ JP: Estimates some work to flush-out details. It=92s a huge list = =20 of requirements. We want to handle simple problem first. Candidate =20 protocols are not considered or within scope. Zafar: Relationship with other WG-es. Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS =20 usage of PCE, inter-domain stuff is example of cases where input from =20= CCAMP is needed. Dimitri: on Head-less optical nodes. GMPLS requirements from CCAMP. Conclusion: Needs more discussion on the list. This document will be the basis of the work. Other discussions: ----------------- CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE. JP mentioned that many of the drafts were posted recently and did not =20= have a slot in this meeting mostly because the focus was on the main =20 documents and to flash out the requirements JP/ Adrian: Many of the drafts were put in and right now we are =20 flushing out first milestone. Other applications will be addressed =20 later. Charter at present does not include candidate (solutions). =20 Questions like what layer PCE should work on? Should PCC-PCE be based =20= on a reliable transport? TCP is reliable, is it a candidate? are among =20= the question charter addresses. Discussion on statement on the requirement of reliability. Dimitri: The biggest question is if we can use RSVP for PCC-PCE =20 communication. Zafar: It=92s funny that when we talk about IGP-es, people settle with =20= what we have today, and when it comes to signaling we tent to have such =20= a large diversion. In my opinion signaling is a very small piece of the =20= overall architecture and we should make use of what we have today. Dimitri: But RSVP is design for label exchange and not PCC-PCE =20 communication. What about transport. Zafar: Let=92s be clear on what we mean here. We are talking about use = of =20 RSVP for encoding. At the transport level we can still rely on TCP. Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for this =20= purpose. Zafar: We know that PCC is going to signal using RSVP-TE, why not =20 provide information encoded in RSVP format to minimize useless copying =20= of the data (from one format to the other). Kireeti: Not all objects are defined for RSVP today. Zafar: The new objects can be defined. There are also other =20 applications for the use of the objects require by PCE. Kireeti: Well, this is convoluted; we don=92t have support for all so =20= let=92s extend RSVP, which is not designed for this purpose. Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other =20 client server based protocols. I recommend taking a look at such =20 protocols. Concern/Comment on RSVP usage and PCC-PCE communication JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself JP: Opinions about future candidates are welcome and the final =20 coomunication will of course be the result of the WG consensus * Comment/confusion on PCC being a node/client * Comment agreeing with Dimitri * Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements. * Comment on not excluding options that are not available today Conclusion: To Continue on the mailing list Dimitri: Question on the discovery of the PCE (possibility of proxification mechanism for PCE discovery). JP and Adrian.= --Apple-Mail-1--289328176 Content-Type: text/enriched; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, Please find below the draft minutes of the PCE WG meeting. Let us know if you have comments: A special thank to Jaudelice and Zafar for having taken the minutes. PCE WG meeting minutes =96 IETF-62 - Minneapolis --------------------------------------------------------------- CHAIR REPORT ---------------------- Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area TE) first Milestones have very aggressive timeline Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications. Work in progress to be presented today: - Draft on PCE architecture - Draft on PCE discovery requirements and protocol extensions - Draft on PCE communication Immediate next work: Draft on PCE communication protocol specification Draft on PCE discovery protocol Draft on objective metrics End of chair report ------------------- Question from audience on objective metrics: Metrics to evaluate PCE. JP gave a few examples of metrics of interest: E.g., How fast you can respond to topology changes, etc. First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash = --------------------------------------------------------------------------= -- Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics. Issued raised on the list - already responded (text added to several sections with respect to every comment) added to 6.4: PCE should advertise capabilities added to 6.6: Path computation request include if near-disjoint paths acceptable added to 6.7: TED information can include info from sources other than IGP added to 6.8: elaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment added to 7: Further metrics proposed to evaluate PCE solutions next steps: propose draft as PCE WG draft Questions raised: ------------------ Question: Concern raised on how feasible is the considered approach (stateful PCE). An element performing optimal computational might take infinite time to do so. Concern about delegating the distributed control plane responsibility to PCE. Question on possibility of unsolicited requests PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well? Are there specific requirements on response time of PCE? (for global optimization) JP: will be part of the evaluation metrics. Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly) message sent to ITU-T about PCE working group. What is in the ITU-T? Audience member said that G7715 on ITU-T has similar function. Dimtri asked a question on stateful vs. stateless PCE in the document; how feasible is stateful PCE? Is it reasonable to assume stateful PCE?=20 Jerry: yes for some applications.=20 Dimitri: Is this can be assumed manageable? Given control to PCE that is otherwise done by a distributed control plan.=20 JP added: It=92s applicable for some applications requiring global optimization. Kireeti: (Global Optimality) is NOT a good target. Stateful PCE provides lot of complexity, while nice- not feasible.=20 Dimitri: Re; global optimization, what is responsible?=20 JP: Evaluation Metric is to be used for this purpose.=20 Igore: Similar comments for stateful vs. stateless.=20 Adrian: ITU-T also requires similar functionality. Liaison Statement to ITU-T is completed. We think SG-15 would be a god start.=20 J. Sadder: Yes, there is similar work pursued at ITU-T.=20 JP Pooled the audience for the Architecture document.=20 JP: Majority in favor it as a WG document. We will confirm at the mailing list. Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis = --------------------------------------------------------------------------= ---------- PCE Discovery requirements The draft addresses PCE discovery within and across domain(s). Remaining issues: Address comments received in the next version * Need to improve security particularly for Inter-AS PCE discovery * Discovery of dynamic parameters such as the PCE CPU state * PCE aliveness detection Consensus for a WG doc? Questions raised: --------------------- Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? comment2: If there is a need, routing is a better place than signalling. JP reminded that the document is just identifying requirements but not solutions. Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). How did the 60 seconds rule was defined? Need to include how that was decided. Dimitri: Are we not already overloading the PCEs? Need to define the right level of abstraction... It is an open question. Needs further discussion. Correct the overload problem before hand. Concern: Enumeration of the set of minimum requirements. Right now it shows an enumerations of possible solutions. Need to focus on minimal requirements. JP: Reminder that the draft is in its first version. Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery includes CPU load factor, it will complicate the PCC system.=20 Dimitri: you haven=92t design the system and are worried about the overloaded system. General problem of the overload should be solved at the root (architecture).=20 Tony Li: As far as process is concerned, start off with a good requirement document, enumerate minimum set of requirements. What you got right now is iteration from the solution space. Focus on minimum requirement and what is the basic problem we are trying to solve.=20 Adrian: This was only first revision of the document. Igor: We need to advertise backup PCE, why backup PCE and not load-balanced.=20 JL: The SP thinks that having a dedicated backup could also be useful. But this is optional.=20 JP: Few sensitive topics like advertisement of dynamic capability needs more discussion on the mailing list.=20 Richard Rabbot: Not all ABR are PCE in your Figure.=20 JL: It is just an example case used for illustration purpose only.=20 Richard Rabbot: How did you come up with 60 second requirement? JL: There are number of SP on the ID and we think 60 sec is a good target. Will provide more details on this.=20 Dimitri: Does these requirements covers inter-AS case?=20 JL: Yes.=20 Dimitri: If today a router may be overloaded and we don=92t do anything specific, should we worry about PCE overloaded cases? We need to make sure that right level of details are provided in the document. The basic stuff like, how to find reachable addresses is not there in the document. We don=92t have basic stuff in the document.=20 JL: No reachability stuff is detailed in the document. There is mention of domain ID-es: area-ID & AS number. =20 JP: This is not a flushed out version. Thanks to DT for their effort in putting this together. Requires more discussion in the mailing list before asking to adopt this ID as a WG document. Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash = -------------------------------------------= --------------------------------------- PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) Various issues raised on the list: for example extensive discussions about re-use of RSVP object encodings Questions raised: ---------------------- Arthi: Is there a requirement of unsolicited PCE to PCC communication.=20= Zafar: Yes, there are cases where unsolicited PCE to PCC communication is required.=20 Many: Is it suitabe to list candidates on this documents? JP: candidates are out of the scope of this protocol. Document is a very first cut. Kireeti: Stateless x stateful. There are needs and there are benefits. Comment: Contradiction, scalability reqirements. Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make decision that is related to the forwarding plan?=20 Jerry: The intension was to mention requirement to include some QOS parameters in the PCC-PCE messages.=20 JP: clarified that the intention was to include possibility of QoS considerations in path computation. JP/ Jerry: I.e., Path Computation Constraints related parameters.=20 Kireeti: On GR of PCE: When it comes to GR, there is a huge difference between stateful and stateless PCE. Recommend to put it in an applicability statement.=20 JP: Yes, complexity analysis is meant for this purpose. Adrian/ JP: Estimates some work to flush-out details. It=92s a huge list of requirements. We want to handle simple problem first. Candidate protocols are not considered or within scope.=20 Zafar: Relationship with other WG-es.=20 Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS usage of PCE, inter-domain stuff is example of cases where input from CCAMP is needed.=20 Dimitri: on Head-less optical nodes.=20 GMPLS requirements from CCAMP.=20 Conclusion: Needs more discussion on the list. This document will be the basis of the work. Other discussions: ----------------- CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE. JP mentioned that many of the drafts were posted recently and did not have a slot in this meeting mostly because the focus was on the main documents and to flash out the requirements JP/ Adrian: Many of the drafts were put in and right now we are flushing out first milestone. Other applications will be addressed later. Charter at present does not include candidate (solutions). Questions like what layer PCE should work on? Should PCC-PCE be based on a reliable transport? TCP is reliable, is it a candidate? are among the question charter addresses.=20= Discussion on statement on the requirement of reliability. Dimitri: The biggest question is if we can use RSVP for PCC-PCE communication.=20 Zafar: It=92s funny that when we talk about IGP-es, people settle with what we have today, and when it comes to signaling we tent to have such a large diversion. In my opinion signaling is a very small piece of the overall architecture and we should make use of what we have today.=20 Dimitri: But RSVP is design for label exchange and not PCC-PCE communication. What about transport.=20 Zafar: Let=92s be clear on what we mean here. We are talking about use of RSVP for encoding. At the transport level we can still rely on TCP.=20= Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for this purpose.=20 Zafar: We know that PCC is going to signal using RSVP-TE, why not provide information encoded in RSVP format to minimize useless copying of the data (from one format to the other).=20 Kireeti: Not all objects are defined for RSVP today.=20 Zafar: The new objects can be defined. There are also other applications for the use of the objects require by PCE.=20 Kireeti: Well, this is convoluted; we don=92t have support for all so let=92s extend RSVP, which is not designed for this purpose.=20 Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other client server based protocols. I recommend taking a look at such protocols.=20 Concern/Comment on RSVP usage and PCC-PCE communication JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself JP: Opinions about future candidates are welcome and the final coomunication will of course be the result of the WG consensus * Comment/confusion on PCC being a node/client * Comment agreeing with Dimitri * Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements. * Comment on not excluding options that are not available today Conclusion: To Continue on the mailing list Dimitri: Question on the discovery of the PCE (possibility of proxification mechanism for PCE discovery). JP and Adrian.= --Apple-Mail-1--289328176-- --===============0475814772== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0475814772==-- From pce-bounces@ietf.org Fri Mar 18 14:03:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11414; Fri, 18 Mar 2005 14:03:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMpp-0002FW-3P; Fri, 18 Mar 2005 14:08:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMkY-0008LF-LM; Fri, 18 Mar 2005 14:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMkX-0008LA-P6 for pce@megatron.ietf.org; Fri, 18 Mar 2005 14:03:09 -0500 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11296 for ; Fri, 18 Mar 2005 14:03:07 -0500 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2005 20:02:38 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2IJ25mC021996 for ; Fri, 18 Mar 2005 20:02:35 +0100 (MET) Received: from xmb-ams-338.cisco.com ([144.254.231.83]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 18 Mar 2005 20:02:34 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2005 19:58:51 +0100 Message-ID: <1F2FBF50FB955441A11316BAE835CED490C805@xmb-ams-338.emea.cisco.com> Thread-Topic: Pce Digest, Vol 7, Issue 11 Thread-Index: AcUr3OJtwcup1NfyTG+OiZMr059NJgADk9Qw From: "Hani El-Sakkout \(hsakkout\)" To: X-OriginalArrivalTime: 18 Mar 2005 19:02:34.0362 (UTC) FILETIME=[0B1CFDA0:01C52BED] Content-Transfer-Encoding: quoted-printable Subject: [Pce] RE: Pce Digest, Vol 7, Issue 11 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Content-Transfer-Encoding: quoted-printable Hi, Thank you for a set of clear and pretty comprehensive minutes. I raised a question on whether PCE's will be allowed to exchange arbitrary information (in an arbitrary format).=20 The answer at the time was yes. I can see a similar question listed as a question on PCE information exchange, but I don't believe it captured this question and answer precisely. Best regards, Hani El-Sakkout -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of pce-request@lists.ietf.org Sent: Friday, March 18, 2005 12:07 PM To: pce@lists.ietf.org Subject: Pce Digest, Vol 7, Issue 11 Send Pce mailing list submissions to pce@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@lists.ietf.org You can reach the person managing the list at pce-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. PCE WG meeting: draft minutes (JP Vasseur) ---------------------------------------------------------------------- Message: 1 Date: Fri, 18 Mar 2005 11:04:17 -0500 From: JP Vasseur Subject: [Pce] PCE WG meeting: draft minutes To: pce@ietf.org Message-ID: <3f782884cb90801c1647d24b4322f3ec@cisco.com> Content-Type: text/plain; charset=3D"windows-1252" Hi, Please find below the draft minutes of the PCE WG meeting. Let us know =20 if you have comments: A special thank to Jaudelice and Zafar for having taken the minutes. PCE WG meeting minutes - IETF-62 - Minneapolis --------------------------------------------------------------- CHAIR REPORT ---------------------- Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area =20 TE) first Milestones have very aggressive timeline Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications. Work in progress to be presented today: - Draft on PCE architecture - Draft on PCE discovery requirements and protocol extensions - Draft on PCE communication Immediate next work: Draft on PCE communication protocol specification Draft on PCE discovery protocol Draft on objective metrics End of chair report ------------------- Question from audience on objective metrics: Metrics to evaluate PCE. JP gave a few examples of metrics of interest: E.g., How fast you can respond to topology changes, etc. First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash ------------------------------------------------------------------------ ---- Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics. Issued raised on the list - already responded (text added to several sections with respect to every comment) added to 6.4: PCE should advertise capabilities added to 6.6: Path computation request include if near-disjoint paths acceptable added to 6.7: TED information can include info from sources other than =20 IGP added to 6.8: elaborate on advantages of stateful PCE & pitfalls of =20 using stateful PCE in a distributed PCE environment added to 7: Further metrics proposed to evaluate PCE solutions next steps: propose draft as PCE WG draft Questions raised: ------------------ Question: Concern raised on how feasible is the considered approach (stateful PCE). An element performing optimal computational might take infinite time to do so. Concern about delegating the distributed control plane =20 responsibility to PCE. Question on possibility of unsolicited requests PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well? Are there specific requirements on response time of PCE? (for global optimization) JP: will be part of the evaluation metrics. Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly) message sent to ITU-T about PCE working group. What is in the ITU-T? Audience member said that G7715 on ITU-T has similar function. Dimtri asked a question on stateful vs. stateless PCE in the document; =20 how feasible is stateful PCE? Is it reasonable to assume stateful PCE? Jerry: yes for some applications. Dimitri: Is this can be assumed manageable? Given control to PCE that =20 is otherwise done by a distributed control plan. JP added: It's applicable for some applications requiring global =20 optimization. Kireeti: (Global Optimality) is NOT a good target. Stateful PCE =20 provides lot of complexity, while nice- not feasible. Dimitri: Re; global optimization, what is responsible? JP: Evaluation Metric is to be used for this purpose. Igore: Similar comments for stateful vs. stateless. Adrian: ITU-T also requires similar functionality. Liaison Statement to ITU-T is completed. We think SG-15 would be a god start. J. Sadder: Yes, there is similar work pursued at ITU-T. JP Pooled the audience for the Architecture document. JP: Majority in favor it as a WG document. We will confirm at the =20 mailing list. Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis ------------------------------------------------------------------------ ------------ PCE Discovery requirements The draft addresses PCE discovery within and across domain(s). Remaining issues: Address comments received in the next version * Need to improve security particularly for Inter-AS PCE discovery * Discovery of dynamic parameters such as the PCE CPU state * PCE aliveness detection Consensus for a WG doc? Questions raised: --------------------- Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? comment2: If there is a need, routing is a better place than signalling. JP reminded that the document is just identifying requirements but not solutions. Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). =20 How did the 60 seconds rule was defined? Need to include how that was =20 decided. Dimitri: Are we not already overloading the PCEs? Need to define the =20 right level of abstraction... It is an open question. Needs further =20 discussion. Correct the overload problem before hand. Concern: Enumeration of the set of minimum requirements. Right now it shows an enumerations of possible solutions. Need to focus on minimal requirements. JP: Reminder that the draft is in its first version. Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery =20 includes CPU load factor, it will complicate the PCC system. Dimitri: you haven't design the system and are worried about the =20 overloaded system. General problem of the overload should be solved at =20 the root (architecture). Tony Li: As far as process is concerned, start off with a good =20 requirement document, enumerate minimum set of requirements. What you =20 got right now is iteration from the solution space. Focus on minimum =20 requirement and what is the basic problem we are trying to solve. Adrian: This was only first revision of the document. Igor: We need to advertise backup PCE, why backup PCE and not =20 load-balanced. JL: The SP thinks that having a dedicated backup could also be useful. =20 But this is optional. JP: Few sensitive topics like advertisement of dynamic capability needs more discussion on the mailing list. Richard Rabbot: Not all ABR are PCE in your Figure. JL: It is just an example case used for illustration purpose only. Richard Rabbot: How did you come up with 60 second requirement? JL: There are number of SP on the ID and we think 60 sec is a good =20 target. Will provide more details on this. Dimitri: Does these requirements covers inter-AS case? JL: Yes. Dimitri: If today a router may be overloaded and we don't do anything =20 specific, should we worry about PCE overloaded cases? We need to make =20 sure that right level of details are provided in the document. The =20 basic stuff like, how to find reachable addresses is not there in the =20 document. We don't have basic stuff in the document. JL: No reachability stuff is detailed in the document. There is mention of domain ID-es: area-ID & AS number. JP: This is not a flushed out version. Thanks to DT for their effort in putting this together. Requires more discussion in the mailing list =20 before asking to adopt this ID as a WG document. Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash ------------------------------------------------------------------------ ---------- PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) Various issues raised on the list: for example extensive discussions =20 about re-use of RSVP object encodings Questions raised: ---------------------- Arthi: Is there a requirement of unsolicited PCE to PCC communication. Zafar: Yes, there are cases where unsolicited PCE to PCC communication =20 is required. Many: Is it suitabe to list candidates on this documents? JP: candidates are out of the scope of this protocol. Document is a =20 very first cut. Kireeti: Stateless x stateful. There are needs and there are benefits. Comment: Contradiction, scalability reqirements. Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make =20 decision that is related to the forwarding plan? Jerry: The intension was to mention requirement to include some QOS =20 parameters in the PCC-PCE messages. JP: clarified that the intention was to include possibility of QoS considerations in path computation. JP/ Jerry: I.e., Path Computation Constraints related parameters. Kireeti: On GR of PCE: When it comes to GR, there is a huge difference =20 between stateful and stateless PCE. Recommend to put it in an =20 applicability statement. JP: Yes, complexity analysis is meant for this purpose. Adrian/ JP: Estimates some work to flush-out details. It's a huge list =20 of requirements. We want to handle simple problem first. Candidate =20 protocols are not considered or within scope. Zafar: Relationship with other WG-es. Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS =20 usage of PCE, inter-domain stuff is example of cases where input from =20 CCAMP is needed. Dimitri: on Head-less optical nodes. GMPLS requirements from CCAMP. Conclusion: Needs more discussion on the list. This document will be the basis of the work. Other discussions: ----------------- CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE. JP mentioned that many of the drafts were posted recently and did not =20 have a slot in this meeting mostly because the focus was on the main =20 documents and to flash out the requirements JP/ Adrian: Many of the drafts were put in and right now we are =20 flushing out first milestone. Other applications will be addressed =20 later. Charter at present does not include candidate (solutions). =20 Questions like what layer PCE should work on? Should PCC-PCE be based =20 on a reliable transport? TCP is reliable, is it a candidate? are among =20 the question charter addresses. Discussion on statement on the requirement of reliability. Dimitri: The biggest question is if we can use RSVP for PCC-PCE =20 communication. Zafar: It's funny that when we talk about IGP-es, people settle with =20 what we have today, and when it comes to signaling we tent to have such a large diversion. In my opinion signaling is a very small piece of the overall architecture and we should make use of what we have today. Dimitri: But RSVP is design for label exchange and not PCC-PCE =20 communication. What about transport. Zafar: Let's be clear on what we mean here. We are talking about use of RSVP for encoding. At the transport level we can still rely on TCP. Kireeti: Not for RSVP as PCC-PCE protocol. It's not defined for this =20 purpose. Zafar: We know that PCC is going to signal using RSVP-TE, why not =20 provide information encoded in RSVP format to minimize useless copying =20 of the data (from one format to the other). Kireeti: Not all objects are defined for RSVP today. Zafar: The new objects can be defined. There are also other =20 applications for the use of the objects require by PCE. Kireeti: Well, this is convoluted; we don't have support for all so =20 let's extend RSVP, which is not designed for this purpose. Mathew: PCC-PCE is a client server protocol. We've a lot of other =20 client server based protocols. I recommend taking a look at such =20 protocols. Concern/Comment on RSVP usage and PCC-PCE communication JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself JP: Opinions about future candidates are welcome and the final =20 coomunication will of course be the result of the WG consensus * Comment/confusion on PCC being a node/client * Comment agreeing with Dimitri * Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements. * Comment on not excluding options that are not available today Conclusion: To Continue on the mailing list Dimitri: Question on the discovery of the PCE (possibility of proxification mechanism for PCE discovery). JP and Adrian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 12563 bytes Desc: not available Url : http://www1.ietf.org/pipermail/pce/attachments/20050318/5b0388a8/attachm ent-0001.bin ------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 7, Issue 11 ********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Mar 18 15:24:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21766; Fri, 18 Mar 2005 15:24:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO5l-0005iG-TI; Fri, 18 Mar 2005 15:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCO0C-00067T-MT; Fri, 18 Mar 2005 15:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCO0A-00067I-Cz for pce@megatron.ietf.org; Fri, 18 Mar 2005 15:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21475 for ; Fri, 18 Mar 2005 15:23:20 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO4d-0005eW-Qy for pce@ietf.org; Fri, 18 Mar 2005 15:28:02 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 2360CE000190; Fri, 18 Mar 2005 20:23:01 +0000 (GMT) Received: from Puppy ([212.43.203.118] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 20:19:38 +0000 Message-ID: <064b01c52bf8$0a0460b0$dccb2bd4@Puppy> From: "Adrian Farrel" To: , "JP Vasseur" References: <3f782884cb90801c1647d24b4322f3ec@cisco.com> Subject: Re: [Pce] PCE WG meeting: draft minutes Date: Fri, 18 Mar 2005 18:34:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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-OriginalArrivalTime: 18 Mar 2005 20:19:39.0423 (UTC) FILETIME=[CFDD4AF0:01C52BF7] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Thanks to the note takers and to JP for editing. Seems to be some duplication. Comments in-line. Adrian > PCE WG meeting minutes =96 IETF-62 - Minneapolis > --------------------------------------------------------------- [SNIP] > message sent to ITU-T about PCE working group. What is in the ITU-T? > Audience member said that G7715 on ITU-T has similar function. "Audience member" was Jonathan Sadler as shown when identical point appears in the minutes later. [SNIP] > Igore: Similar comments for stateful vs. stateless. That's "Igor" [SNIP] > Adrian: ITU-T also requires similar functionality. Liaison Statement to > ITU-T is completed. We think SG-15 would be a god start. Or maybe a "good start" :-) [SNIP] > JP Pooled the audience for the Architecture document. "Polled" [SNIP] Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? "Kireeti" I think he said "PCE-PCC communication" [SNIP] >Concern: Enumeration of the set of minimum requirements. Right now it > shows an enumerations of possible solutions. Need to focus on minimal > requirements. I think that this was Tony Li as when the identical issue appears later i= n the minutes. > JP: Reminder that the draft is in its first version. That was me (as when the identical point appears later in the minutes) [SNIP] > Richard Rabbot: Not all ABR are PCE in your Figure. That's "Rabbat" [SNIP] > Zafar: It=92s funny that when we talk about IGP-es, people settle with > what we have today, and when it comes to signaling we tent to have such "tend" _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Mar 19 04:48:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29323; Sat, 19 Mar 2005 04:48:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCadm-0006Qv-7u; Sat, 19 Mar 2005 04:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCaYV-0005gl-4u; Sat, 19 Mar 2005 04:47:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCaY7-0005bj-Py for pce@megatron.ietf.org; Sat, 19 Mar 2005 04:47:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29282 for ; Sat, 19 Mar 2005 04:47:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCack-0006PV-5e for pce@ietf.org; Sat, 19 Mar 2005 04:52:02 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCaY4-000Er3-Ey; Sat, 19 Mar 2005 09:47:13 +0000 Message-ID: <423BF52E.8040200@psg.com> Date: Sat, 19 Mar 2005 10:47:26 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] PCE WG meeting: draft minutes References: <3f782884cb90801c1647d24b4322f3ec@cisco.com> In-Reply-To: <3f782884cb90801c1647d24b4322f3ec@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA29282 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Content-Transfer-Encoding: quoted-printable hi jp - some edits/comments in-line: JP Vasseur wrote: > Hi, >=20 > Please find below the draft minutes of the PCE WG meeting. Let us know = =20 > if you have comments: >=20 > A special thank to Jaudelice and Zafar for having taken the minutes. >=20 > PCE WG meeting minutes =96 IETF-62 - Minneapolis > --------------------------------------------------------------- >=20 > CHAIR REPORT > ---------------------- >=20 > Work group established, WG should concentrate > on first milestones: G/MPLS TE and Simple configurations (Inter-area =20 > TE) first >=20 > Milestones have very aggressive timeline >=20 > Applications for PCE: Encouraged to continue to work on applications > for PCE (though out of scope for the moment). Not to expect to become > WG document, but encouraged to work on future applications. >=20 > Work in progress to be presented today: >=20 > - Draft on PCE architecture > - Draft on PCE discovery requirements and protocol extensions > - Draft on PCE communication >=20 > Immediate next work: >=20 > Draft on PCE communication protocol specification > Draft on PCE discovery protocol > Draft on objective metrics >=20 > End of chair report > ------------------- >=20 > Question from audience on objective metrics: Metrics to evaluate PCE. >=20 > JP gave a few examples of metrics of interest: > E.g., How fast you can respond to topology changes, etc. >=20 >=20 > First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash > -----------------------------------------------------------------------= -=20 > ---- >=20 > Drafts discusses terminology, assumptions, motivation, architectural > considerations, security & confidentiality and evaluation metrics. >=20 > Issued raised on the list - already responded (text added to several > sections with respect to every comment) >=20 > added to 6.4: PCE should advertise capabilities > added to 6.6: Path computation request include if near-disjoint paths > acceptable > added to 6.7: TED information can include info from sources other than = IGP > added to 6.8: elaborate on advantages of stateful PCE & pitfalls of us= ing > stateful PCE in a distributed PCE environment > added to 7: Further metrics proposed to evaluate PCE solutions > =20 > next steps: propose draft as PCE WG draft >=20 > Questions raised: > ------------------ > Question: Concern raised on how feasible is the considered approach > (stateful PCE). >=20 > An element performing optimal computational might take infinite time to= do > so. Concern about delegating the distributed control plane responsibi= lity > to PCE. >=20 > Question on possibility of unsolicited requests > PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? >=20 > PCE-PCE communication: communicating paths exchange only or other is it > possible to communicate other info as well? >=20 > Are there specific requirements on response time of PCE? (for global > optimization) >=20 > JP: will be part of the evaluation metrics. >=20 > Kireeti: need to be careful with pce, not trying global optimal solutio= n > stateful x stateless: can't keep all info on lsps (costly) >=20 > message sent to ITU-T about PCE working group. What is in the ITU-T? > Audience member said that G7715 on ITU-T has similar function. >=20 >=20 > Dimtri asked a question on stateful vs. stateless PCE in the document; = =20 > how feasible is stateful PCE? Is it reasonable to assume stateful PCE? >=20 > Jerry: yes for some applications. >=20 > Dimitri: Is this can be assumed manageable? Given control to PCE that =20 > is otherwise done by a distributed control plan. >=20 > JP added: It=92s applicable for some applications requiring global =20 > optimization. >=20 > Kireeti: (Global Optimality) is NOT a good target. Stateful PCE =20 > provides lot of complexity, while nice- not feasible. >=20 > Dimitri: Re; global optimization, what is responsible? -> replace by "Concerning global optimization, raises issue about the=20 trigger and maintenance of this process (responsibility) that is now=20 pulled outside of the local node and delegated to a third party ->=20 therefore there is now a system impact in terms of performance of the=20 global system" > JP: Evaluation Metric is to be used for this purpose. -> add "dimitri: but these are not evaluation metrics in terms of=20 computation results these are specific metrics for evaluating the=20 correct behaviour of the system" note: if i well remember you agreed with this - please confirm > Igore: Similar comments for stateful vs. stateless. >=20 > Adrian: ITU-T also requires similar functionality. Liaison Statement to= =20 > ITU-T is completed. We think SG-15 would be a god start. >=20 > J. Sadder: Yes, there is similar work pursued at ITU-T. > > JP Pooled the audience for the Architecture document. >=20 > JP: Majority in favor it as a WG document. We will confirm at the =20 > mailing list. >=20 >=20 > Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis > -----------------------------------------------------------------------= -=20 > ------------ > PCE Discovery requirements >=20 > The draft addresses PCE discovery within and across domain(s). >=20 > Remaining issues: >=20 > Address comments received in the next version >=20 > * Need to improve security particularly for Inter-AS PCE discovery > * Discovery of dynamic parameters such as the PCE CPU state > * PCE aliveness detection >=20 > Consensus for a WG doc? >=20 >=20 > Questions raised: > --------------------- >=20 > Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? >=20 > comment2: If there is a need, routing is a better place than signalling. >=20 > JP reminded that the document is just identifying requirements but not > solutions. >=20 > Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). = How > did the 60 seconds rule was defined? Need to include how that was deci= ded. >=20 > Dimitri: Are we not already overloading the PCEs? Need to define the r= ight > level of abstraction... It is an open question. Needs further =20 > discussion. Correct the overload problem before hand. -> replace "correct ..." by "correct architecture design is required to=20 address the overload problem before hand" > Concern: Enumeration of the set of minimum requirements. Right now it > shows an enumerations of possible solutions. Need to focus on minimal > requirements. >=20 > JP: Reminder that the draft is in its first version. >=20 > Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery =20 > includes CPU load factor, it will complicate the PCC system. >=20 > Dimitri: you haven=92t design the system and are worried about the =20 > overloaded system. General problem of the overload should be solved at = =20 > the root (architecture). -> adding the following note here: the sense in which i used the term=20 architecture is not exactly the same as the one used per this doc. here=20 i do refer to the set of the protocol mechanisms and underlying=20 operations - not the global framework architecture" > Tony Li: As far as process is concerned, start off with a good =20 > requirement document, enumerate minimum set of requirements. What you =20 > got right now is iteration from the solution space. Focus on minimum =20 > requirement and what is the basic problem we are trying to solve. >=20 > Adrian: This was only first revision of the document. >=20 > Igor: We need to advertise backup PCE, why backup PCE and not =20 > load-balanced. >=20 > JL: The SP thinks that having a dedicated backup could also be useful. = =20 > But this is optional. >=20 > JP: Few sensitive topics like advertisement of dynamic capability needs= =20 > more discussion on the mailing list. >=20 > Richard Rabbot: Not all ABR are PCE in your Figure. >=20 > JL: It is just an example case used for illustration purpose only. >=20 > Richard Rabbot: How did you come up with 60 second requirement? >=20 > JL: There are number of SP on the ID and we think 60 sec is a good =20 > target. Will provide more details on this. >=20 > Dimitri: Does these requirements covers inter-AS case? > > JL: Yes. >=20 > Dimitri: If today a router may be overloaded and we don=92t do anything= =20 > specific, should we worry about PCE overloaded cases?=20 -> replace by "Today, overloading cases may occur as part of a label switch router - and we just start discussions concerning the overload problems - as we have after several years of active work the conditions where the (distributed) overload occurs, therefore should we worry about PCE overload instead of focusing on the right level of detail at this point in time" > We need to make sure that right level of details are provided in the do= cument. The =20 > basic stuff like, how to find reachable addresses is not there in the =20 > document. We don=92t have basic stuff in the document. >=20 > JL: No reachability stuff is detailed in the document. There is mention= =20 > of domain ID-es: area-ID & AS number. >=20 > JP: This is not a flushed out version. Thanks to DT for their effort in= =20 > putting this together. Requires more discussion in the mailing list =20 > before asking to adopt this ID as a WG document. >=20 >=20 > Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash > -----------------------------------------------------------------------= -=20 > ---------- > PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) >=20 > Various issues raised on the list: for example extensive discussions =20 > about re-use of RSVP object encodings >=20 >=20 > Questions raised: > ---------------------- >=20 > Arthi: Is there a requirement of unsolicited PCE to PCC communication. >=20 > Zafar: Yes, there are cases where unsolicited PCE to PCC communication = =20 > is required. >=20 > Many: Is it suitabe to list candidates on this documents? >=20 > JP: candidates are out of the scope of this protocol. Document is a =20 > very first cut. >=20 > Kireeti: Stateless x stateful. There are needs and there are benefits. >=20 > Comment: Contradiction, scalability reqirements. >=20 > Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make =20 > decision that is related to the forwarding plan? >=20 > Jerry: The intension was to mention requirement to include some QOS =20 > parameters in the PCC-PCE messages. >=20 > JP: clarified that the intention was to include possibility of QoS > considerations in path computation. >=20 > JP/ Jerry: I.e., Path Computation Constraints related parameters. >=20 > Kireeti: On GR of PCE: When it comes to GR, there is a huge difference = =20 > between stateful and stateless PCE. Recommend to put it in an =20 > applicability statement. >=20 > JP: Yes, complexity analysis is meant for this purpose. >=20 > Adrian/ JP: Estimates some work to flush-out details. It=92s a huge lis= t =20 > of requirements. We want to handle simple problem first. Candidate =20 > protocols are not considered or within scope. >=20 > Zafar: Relationship with other WG-es. > Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS =20 > usage of PCE, inter-domain stuff is example of cases where input from =20 > CCAMP is needed. >=20 > Dimitri: on Head-less optical nodes. -> question was "dimitri: what about the reachability of PCE location(s)=20 for non-IP terminating nodes" i think that the below corresponds to the reply of Adrian that did point out to the GMPLS requirements from CCAMP WG > GMPLS requirements from CCAMP. >=20 >=20 > Conclusion: Needs more discussion on the list. This document will be th= e > basis of the work. >=20 > Other discussions: > ----------------- > CCAMP was to provide areas where PCE would be useful. There is already = a > draft on the GMPLS use of PCE. >=20 > JP mentioned that many of the drafts were posted recently and did not = have > a slot in this meeting mostly because the focus was on the main docume= nts > and to flash out the requirements >=20 >=20 > JP/ Adrian: Many of the drafts were put in and right now we are =20 > flushing out first milestone. Other applications will be addressed =20 > later. Charter at present does not include candidate (solutions). =20 > Questions like what layer PCE should work on? Should PCC-PCE be based =20 > on a reliable transport? TCP is reliable, is it a candidate? are among = =20 > the question charter addresses. >=20 > Discussion on statement on the requirement of reliability. >=20 > Dimitri: The biggest question is if we can use RSVP for PCC-PCE =20 > communication. >=20 > Zafar: It=92s funny that when we talk about IGP-es, people settle with = =20 > what we have today, and when it comes to signaling we tent to have such= =20 > a large diversion. In my opinion signaling is a very small piece of the= =20 > overall architecture and we should make use of what we have today. >=20 > Dimitri: But RSVP is design for label exchange and not PCC-PCE =20 > communication. What about transport. -> please replace the above by: "dimitri: But RSVP is designed for end-to-end (session) signaling and not a PCC-PCE client-server exchange. Instead, what about considering communication relying on the transport layer (TCP)" > Zafar: Let=92s be clear on what we mean here. We are talking about use = of =20 > RSVP for encoding. At the transport level we can still rely on TCP. >=20 > Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for this = =20 > purpose. >=20 > Zafar: We know that PCC is going to signal using RSVP-TE, why not =20 > provide information encoded in RSVP format to minimize useless copying = =20 > of the data (from one format to the other). > Kireeti: Not all objects are defined for RSVP today. >=20 > Zafar: The new objects can be defined. There are also other =20 > applications for the use of the objects require by PCE. -> add "dimitri: considering these objects on the PCE does not provide=20 more rationale for considering RSVP as communication protocol between=20 the PCC and the PCE" > Kireeti: Well, this is convoluted; we don=92t have support for all so =20 > let=92s extend RSVP, which is not designed for this purpose. >=20 > Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other =20 > client server based protocols. I recommend taking a look at such =20 > protocols. >=20 > Concern/Comment on RSVP usage and PCC-PCE communication >=20 > JP: Mention discussion of the design team on using RSVP encoding withou= t > using RSVP itself >=20 > JP: Opinions about future candidates are welcome and the final =20 > coomunication will of course be the result of the WG consensus >=20 > * Comment/confusion on PCC being a node/client > * Comment agreeing with Dimitri > * Constraint that you can communicate using RSVP today. Agreeing with > Dimitri that we should first specify the needs/requirements. > * Comment on not excluding options that are not available today >=20 >=20 > Conclusion: To Continue on the mailing list >=20 > Dimitri: Question on the discovery of the PCE (possibility of > proxification mechanism for PCE discovery). >=20 > JP and Adrian. >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Mar 19 10:30:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00890; Sat, 19 Mar 2005 10:30:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCfyd-0004iS-FW; Sat, 19 Mar 2005 10:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCfsY-0003hk-EK; Sat, 19 Mar 2005 10:28:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCfsW-0003hf-68 for pce@megatron.ietf.org; Sat, 19 Mar 2005 10:28:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00803 for ; Sat, 19 Mar 2005 10:28:38 -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.33) id 1DCfxB-0004dm-Fy for pce@ietf.org; Sat, 19 Mar 2005 10:33:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2005 07:28:30 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2JFSLgE003332; Sat, 19 Mar 2005 07:28:22 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-2-118.cisco.com [10.86.242.118]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA22498; Sat, 19 Mar 2005 07:28:26 -0800 (PST) In-Reply-To: <423BF52E.8040200@psg.com> References: <3f782884cb90801c1647d24b4322f3ec@cisco.com> <423BF52E.8040200@psg.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <556f314d456522c8c72878e833454ab5@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] PCE WG meeting: draft minutes Date: Sat, 19 Mar 2005 10:28:46 -0500 To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Content-Transfer-Encoding: quoted-printable hi Dimitri, On Mar 19, 2005, at 4:47 AM, dimitri papadimitriou wrote: > hi jp - some edits/comments in-line: > > JP Vasseur wrote: > >> Hi, >> Please find below the draft minutes of the PCE WG meeting. Let us =20 >> know if you have comments: >> A special thank to Jaudelice and Zafar for having taken the minutes. >> PCE WG meeting minutes =96 IETF-62 - Minneapolis >> --------------------------------------------------------------- >> CHAIR REPORT >> ---------------------- >> Work group established, WG should concentrate >> on first milestones: G/MPLS TE and Simple configurations (Inter-area = =20 >> TE) first >> Milestones have very aggressive timeline >> Applications for PCE: Encouraged to continue to work on applications >> for PCE (though out of scope for the moment). Not to expect to become >> WG document, but encouraged to work on future applications. >> Work in progress to be presented today: >> - Draft on PCE architecture >> - Draft on PCE discovery requirements and protocol extensions >> - Draft on PCE communication >> Immediate next work: >> Draft on PCE communication protocol specification >> Draft on PCE discovery protocol >> Draft on objective metrics >> End of chair report >> ------------------- >> Question from audience on objective metrics: Metrics to evaluate PCE. >> JP gave a few examples of metrics of interest: >> E.g., How fast you can respond to topology changes, etc. >> First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash >> = ----------------------------------------------------------------------=20= >> -- ---- >> Drafts discusses terminology, assumptions, motivation, architectural >> considerations, security & confidentiality and evaluation metrics. >> Issued raised on the list - already responded (text added to several >> sections with respect to every comment) >> added to 6.4: PCE should advertise capabilities >> added to 6.6: Path computation request include if near-disjoint paths >> acceptable >> added to 6.7: TED information can include info from sources other =20 >> than IGP >> added to 6.8: elaborate on advantages of stateful PCE & pitfalls of =20= >> using >> stateful PCE in a distributed PCE environment >> added to 7: Further metrics proposed to evaluate PCE solutions >> next steps: propose draft as PCE WG draft >> Questions raised: >> ------------------ >> Question: Concern raised on how feasible is the considered approach >> (stateful PCE). >> An element performing optimal computational might take infinite time =20= >> to do >> so. Concern about delegating the distributed control plane =20 >> responsibility >> to PCE. >> Question on possibility of unsolicited requests >> PCC-to PCE request/PCE-PCC reply or also unsolicited requests =20 >> possible? >> PCE-PCE communication: communicating paths exchange only or other is =20= >> it >> possible to communicate other info as well? >> Are there specific requirements on response time of PCE? (for global >> optimization) >> JP: will be part of the evaluation metrics. >> Kireeti: need to be careful with pce, not trying global optimal =20 >> solution >> stateful x stateless: can't keep all info on lsps (costly) >> message sent to ITU-T about PCE working group. What is in the ITU-T? >> Audience member said that G7715 on ITU-T has similar function. >> Dimtri asked a question on stateful vs. stateless PCE in the =20 >> document; how feasible is stateful PCE? Is it reasonable to assume =20= >> stateful PCE? >> Jerry: yes for some applications. >> Dimitri: Is this can be assumed manageable? Given control to PCE that = =20 >> is otherwise done by a distributed control plan. >> JP added: It=92s applicable for some applications requiring global =20= >> optimization. >> Kireeti: (Global Optimality) is NOT a good target. Stateful PCE =20 >> provides lot of complexity, while nice- not feasible. >> Dimitri: Re; global optimization, what is responsible? > > -> replace by "Concerning global optimization, raises issue about the =20= > trigger and maintenance of this process (responsibility) that is now =20= > pulled outside of the local node and delegated to a third party -> =20 > therefore there is now a system impact in terms of performance of the =20= > global system" > will update >> JP: Evaluation Metric is to be used for this purpose. > > -> add "dimitri: but these are not evaluation metrics in terms of =20 > computation results these are specific metrics for evaluating the =20 > correct behaviour of the system" > > note: if i well remember you agreed with this - please confirm > I indeed agreed on the fact that it is out of the scope to make =20 algorithmic evaluation. Thanks for your comments. JP. >> Igore: Similar comments for stateful vs. stateless. >> Adrian: ITU-T also requires similar functionality. Liaison Statement =20= >> to ITU-T is completed. We think SG-15 would be a god start. >> J. Sadder: Yes, there is similar work pursued at ITU-T. >> >> JP Pooled the audience for the Architecture document. >> JP: Majority in favor it as a WG document. We will confirm at the =20= >> mailing list. >> Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis >> = ----------------------------------------------------------------------=20= >> -- ------------ >> PCE Discovery requirements >> The draft addresses PCE discovery within and across domain(s). >> Remaining issues: >> Address comments received in the next version >> * Need to improve security particularly for Inter-AS PCE discovery >> * Discovery of dynamic parameters such as the PCE CPU state >> * PCE aliveness detection >> Consensus for a WG doc? >> Questions raised: >> --------------------- >> Kiretti: Discovery of PCEs: better rely on PCE-PCE communication? >> comment2: If there is a need, routing is a better place than =20 >> signalling. >> JP reminded that the document is just identifying requirements but = not >> solutions. >> Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). = =20 >> How >> did the 60 seconds rule was defined? Need to include how that was =20= >> decided. >> Dimitri: Are we not already overloading the PCEs? Need to define the = =20 >> right >> level of abstraction... It is an open question. Needs further =20 >> discussion. Correct the overload problem before hand. > > -> replace "correct ..." by "correct architecture design is required =20= > to address the overload problem before hand" > >> Concern: Enumeration of the set of minimum requirements. Right now it >> shows an enumerations of possible solutions. Need to focus on minimal >> requirements. >> JP: Reminder that the draft is in its first version. >> Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery =20 >> includes CPU load factor, it will complicate the PCC system. >> Dimitri: you haven=92t design the system and are worried about the =20= >> overloaded system. General problem of the overload should be solved =20= >> at the root (architecture). > > -> adding the following note here: the sense in which i used the term =20= > architecture is not exactly the same as the one used per this doc. =20 > here i do refer to the set of the protocol mechanisms and underlying =20= > operations - not the global framework architecture" > >> Tony Li: As far as process is concerned, start off with a good =20 >> requirement document, enumerate minimum set of requirements. What you = =20 >> got right now is iteration from the solution space. Focus on minimum = =20 >> requirement and what is the basic problem we are trying to solve. >> Adrian: This was only first revision of the document. >> Igor: We need to advertise backup PCE, why backup PCE and not =20 >> load-balanced. >> JL: The SP thinks that having a dedicated backup could also be =20 >> useful. But this is optional. >> JP: Few sensitive topics like advertisement of dynamic capability =20 >> needs more discussion on the mailing list. >> Richard Rabbot: Not all ABR are PCE in your Figure. >> JL: It is just an example case used for illustration purpose only. >> Richard Rabbot: How did you come up with 60 second requirement? >> JL: There are number of SP on the ID and we think 60 sec is a good =20= >> target. Will provide more details on this. >> Dimitri: Does these requirements covers inter-AS case? > > >> JL: Yes. >> Dimitri: If today a router may be overloaded and we don=92t do = anything =20 >> specific, should we worry about PCE overloaded cases? > > -> replace by "Today, overloading cases may occur as part of a label > switch router - and we just start discussions concerning the overload > problems - as we have after several years of active work the = conditions > where the (distributed) overload occurs, therefore should we worry =20 > about > PCE overload instead of focusing on the right level of detail at this > point in time" > >> We need to make sure that right level of details are provided in the =20= >> document. The basic stuff like, how to find reachable addresses is =20= >> not there in the document. We don=92t have basic stuff in the =20 >> document. >> JL: No reachability stuff is detailed in the document. There is =20 >> mention of domain ID-es: area-ID & AS number. >> JP: This is not a flushed out version. Thanks to DT for their effort =20= >> in putting this together. Requires more discussion in the mailing =20= >> list before asking to adopt this ID as a WG document. >> Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash >> = ----------------------------------------------------------------------=20= >> -- ---------- >> PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) >> Various issues raised on the list: for example extensive discussions = =20 >> about re-use of RSVP object encodings >> Questions raised: >> ---------------------- >> Arthi: Is there a requirement of unsolicited PCE to PCC = communication. >> Zafar: Yes, there are cases where unsolicited PCE to PCC =20 >> communication is required. >> Many: Is it suitabe to list candidates on this documents? >> JP: candidates are out of the scope of this protocol. Document is a =20= >> very first cut. >> Kireeti: Stateless x stateful. There are needs and there are = benefits. >> Comment: Contradiction, scalability reqirements. >> Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make =20= >> decision that is related to the forwarding plan? >> Jerry: The intension was to mention requirement to include some QOS =20= >> parameters in the PCC-PCE messages. >> JP: clarified that the intention was to include possibility of QoS >> considerations in path computation. >> JP/ Jerry: I.e., Path Computation Constraints related parameters. >> Kireeti: On GR of PCE: When it comes to GR, there is a huge =20 >> difference between stateful and stateless PCE. Recommend to put it =20= >> in an applicability statement. >> JP: Yes, complexity analysis is meant for this purpose. >> Adrian/ JP: Estimates some work to flush-out details. It=92s a huge =20= >> list of requirements. We want to handle simple problem first. =20 >> Candidate protocols are not considered or within scope. >> Zafar: Relationship with other WG-es. >> Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS = =20 >> usage of PCE, inter-domain stuff is example of cases where input from = =20 >> CCAMP is needed. >> Dimitri: on Head-less optical nodes. > > -> question was "dimitri: what about the reachability of PCE =20 > location(s) for non-IP terminating nodes" > > i think that the below corresponds to the reply of Adrian that did =20 > point > out to the GMPLS requirements from CCAMP WG > >> GMPLS requirements from CCAMP. >> Conclusion: Needs more discussion on the list. This document will be =20= >> the >> basis of the work. >> Other discussions: >> ----------------- >> CCAMP was to provide areas where PCE would be useful. There is =20 >> already a >> draft on the GMPLS use of PCE. >> JP mentioned that many of the drafts were posted recently and did not = =20 >> have >> a slot in this meeting mostly because the focus was on the main =20 >> documents >> and to flash out the requirements >> JP/ Adrian: Many of the drafts were put in and right now we are =20 >> flushing out first milestone. Other applications will be addressed =20= >> later. Charter at present does not include candidate (solutions). =20= >> Questions like what layer PCE should work on? Should PCC-PCE be based = =20 >> on a reliable transport? TCP is reliable, is it a candidate? are =20 >> among the question charter addresses. >> Discussion on statement on the requirement of reliability. >> Dimitri: The biggest question is if we can use RSVP for PCC-PCE =20 >> communication. >> Zafar: It=92s funny that when we talk about IGP-es, people settle = with =20 >> what we have today, and when it comes to signaling we tent to have =20= >> such a large diversion. In my opinion signaling is a very small =20 >> piece of the overall architecture and we should make use of what we =20= >> have today. >> Dimitri: But RSVP is design for label exchange and not PCC-PCE =20 >> communication. What about transport. > > -> please replace the above by: > > "dimitri: But RSVP is designed for end-to-end (session) signaling and > not a PCC-PCE client-server exchange. Instead, what about considering > communication relying on the transport layer (TCP)" > >> Zafar: Let=92s be clear on what we mean here. We are talking about = use =20 >> of RSVP for encoding. At the transport level we can still rely on =20= >> TCP. >> Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for = this =20 >> purpose. >> Zafar: We know that PCC is going to signal using RSVP-TE, why not =20= >> provide information encoded in RSVP format to minimize useless =20 >> copying of the data (from one format to the other). >> Kireeti: Not all objects are defined for RSVP today. >> Zafar: The new objects can be defined. There are also other =20 >> applications for the use of the objects require by PCE. > > -> add "dimitri: considering these objects on the PCE does not provide = =20 > more rationale for considering RSVP as communication protocol between =20= > the PCC and the PCE" > >> Kireeti: Well, this is convoluted; we don=92t have support for all so = =20 >> let=92s extend RSVP, which is not designed for this purpose. >> Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other =20= >> client server based protocols. I recommend taking a look at such =20 >> protocols. >> Concern/Comment on RSVP usage and PCC-PCE communication >> JP: Mention discussion of the design team on using RSVP encoding =20 >> without >> using RSVP itself >> JP: Opinions about future candidates are welcome and the final =20 >> coomunication will of course be the result of the WG consensus >> * Comment/confusion on PCC being a node/client >> * Comment agreeing with Dimitri >> * Constraint that you can communicate using RSVP today. Agreeing with >> Dimitri that we should first specify the needs/requirements. >> * Comment on not excluding options that are not available today >> Conclusion: To Continue on the mailing list >> Dimitri: Question on the discovery of the PCE (possibility of >> proxification mechanism for PCE discovery). >> JP and Adrian. >> = ----------------------------------------------------------------------=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@ietf.org Sun Mar 20 11:23:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28797; Sun, 20 Mar 2005 11:23:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD3I5-0001Vp-V2; Sun, 20 Mar 2005 11:28:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD3Bx-0003Lz-EC; Sun, 20 Mar 2005 11:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCecd-0006IG-DT for pce@megatron.ietf.org; Sat, 19 Mar 2005 09:08:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22702; Sat, 19 Mar 2005 09:08:09 -0500 (EST) Received: from vsmail510.nifty.com ([202.248.37.241]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCehH-0001CC-OW; Sat, 19 Mar 2005 09:13:00 -0500 Received: from vsmail510.nifty.com by vsmail510.nifty.com with ESMTP id j2JE7RSh013905; Sat, 19 Mar 2005 23:07:27 +0900 Received: from mail530.nifty.com (tsiml11m-pip1 [172.22.54.40])by vsmail510.nifty.com with ESMTP id j2JE7QKV013895; Sat, 19 Mar 2005 23:07:26 +0900 Received: from [192.168.1.22] (p1210-ipbf303hodogaya.kanagawa.ocn.ne.jp [222.144.93.210]) (authenticated) by mail530.nifty.com with ESMTP id j2JE7MRd010052; Sat, 19 Mar 2005 23:07:23 +0900 Date: Sat, 19 Mar 2005 23:07:22 +0900 From: Yoichi Maeda To: "Adrian Farrel" In-Reply-To: <076101c52165$d18d5080$19cb2bd4@Puppy> References: <076101c52165$d18d5080$19cb2bd4@Puppy> Message-Id: <20050319225134.2B38.MAEDA@ansl.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20.04 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 20 Mar 2005 11:22:16 -0500 Cc: pce@ietf.org, maeda@ansl.ntt.co.jp, Bill Fenner , statements@ietf.org, Scott Bradner Subject: [Pce] Re: Path Computation Element Working Group in the IETF X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maeda@ansl.ntt.co.jp List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: 7bit Dear Adrian; Thank you for your information. I am sorry for my delayed reply to your initial e-mail. I have been in Geneva for two weeks. As for your question on the PCE-WG issue, I have surveyed and identified that Q.6, Q.12 and Q.14 in SG15 will be relevant for your PCE issues. I have transferred your information to each Questions and asked their replies. **** 6/15 Characteristics of optical systems for terrestrial transport networks 12/15 Transport network architectures 14/15 Management and control of transport systems and equipment **** We are interested in the study and we will appoint a liaison officer in order to follow the activities of PCE-WG if required. I hope we can send a Liaison Statement to you before April. Best regards, Yoichi On Sat, 5 Mar 2005 09:27:11 -0000 "Adrian Farrel" wrote: > To: Mr. Yoichi Maeda, chairman ITU-T Study Group 15 > Cc: Mr. Scott Bradner, IETF liaison coordinator with the ITU-T > Alex Zinin and Bill Fenner, IETF Routing Area Directors > From: Adrian Farrel and JP Vasseur, IETF PCE working group chairs > Subject: Path Computation Element Working Group in the IETF > For: Action > Deadline: 1st April 2005 > > Dear Mr. Maeda, > > We would like to inform you and Study Group 15 of the creation of a new > working group within the IETF to work on the Path Computation Element > (PCE). The charter of this working group is shown below and provides a > brief definition of the PCE. Further understanding of what the IETF means > by PCE can be found in > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt > although this should be seen as a work in progress. > > We believe that some work may already have been carried out within the > ITU-T (probably within SG15) on determining a functional architecture for > a similar logical entity - that is, for a logically distinct control plane > component that is responsible for performing path computations. We are > anxious to leverage this work so that we can produce a solution that most > closely matches the needs of the ITU-T community, so that we do not waste > effort re-inventing anything, and so that we can move our own work > forwards as rapidly as possible. > > Could you please pass this liaison to all interested parties within the > ITU-T and particularly to the Questions that may have worked on a similar > topic with a request that they give us pointers to all related and > previous work. Once we have established direct contact with the relevant > groups we will continue to liaise our progress to them and will solicit > their opinions especially with respect to architecture and functional > requirements. > > Thank you for your help. > > Best regards, > Adrian Farrel and JP Vasseur > > ===== > Path Computation Element Working Group Charter > > Description of Working Group: > The PCE Working Group is chartered to specify a Path Computation Element > (PCE) based architecture for the computation of paths for MPLS and GMPLS > Traffic Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) LSR, but on some other path computation entity that may > physically not be located on the head-end LSR. > > The PCE WG will work on application of this model within a single domain > or within a small group of domains (where a domain is a layer, IGP area or > Autonomous System with limited visibility from the head-end LSR). At this > time, applying this model to large groups of domains such as the Internet > is not thought to be possible, and the PCE WG will not spend energy on > that topic. > > The WG will specify a protocol for communication between LSRs (termed Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing and > signaling protocols in support of PCE discovery and signaling of > inter-domain paths. Candidate protocols for extensions are RSVP-TE, > OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in > collaboration with the Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to evaluate > path quality, scalability, responsiveness and obustness of path > computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) reoptimization and load balancing. The WG will address > the inter-area (single IGP domain) scenario first. WG progress will be > evaluated before inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done > in conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > Goals and Milestones: > Feb 05 Submit first draft of PCE architecture document > Feb 05 Submit first draft of PCE discovery requirements and protocol > extensions > documents > Apr 05 Submit first draft of the PCE communication protocol requirements > May 05 Submit first draft of the definition of objective metrics > Jul 05 Submit first draft of the PCE communication protocol specification > Aug 05 Submit PCE architecture specification to the IESG to be considered > as > Informational RFC > Nov 05 Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols and > protocol > extensions for inter-area MPLS and GMPLS Traffic Engineering) > Nov 05 Submit first draft of the MIB module for the PCE protocol > Dec 05 Submit PCE communication protocol requirements to the IESG to be > considered > as an Informational RFC > Dec 05 Submit PCE discovery protocol extensions specifications to the > IESG to be > considered as a Proposed Standard > Dec 05 Submit PCE communication protocol specification to the IESG to be > considered > as a Proposed Standard > Feb 06 Submit the applicability and metrics documents to the IESG to be > considered as > Informational RFC > Feb 06 Evaluate WG progress, recharter or close ****************************************************** Yoichi MAEDA NTT Corporation, Access Service Systems Laboratories, Chairman ITU-T Study Group 15 Address: 1-6 Nakase, Mihama-ku, Chiba-shi, 261-0023, JAPAN Tel: +81-43-211-3274, Fax: +81-43-211-8282 E-mail: maeda@ansl.ntt.co.jp ******************************************************* _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Mar 21 16:02:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22553; Mon, 21 Mar 2005 16:02:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDU86-00018L-Vd; Mon, 21 Mar 2005 16:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTbS-0005UV-M0; Mon, 21 Mar 2005 15:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTbP-0005TY-FN; Mon, 21 Mar 2005 15:34:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15320; Mon, 21 Mar 2005 15:34:14 -0500 (EST) Message-Id: <200503212034.PAA15320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Mar 2005 15:34:14 -0500 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-00.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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) Architecture Author(s) : A. Farrel, et al. Filename : draft-ietf-pce-architecture-00.txt Pages : 22 Date : 2005-3-21 Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-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-ietf-pce-architecture-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-ietf-pce-architecture-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. --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: <2005-3-21154321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154321.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@ietf.org Wed Mar 23 03:58:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18387; Wed, 23 Mar 2005 03:58:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1n4-0006V6-Nj; Wed, 23 Mar 2005 04:04:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1fL-0005uk-VZ; Wed, 23 Mar 2005 03:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1fH-0005uc-LW; Wed, 23 Mar 2005 03:56:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18241; Wed, 23 Mar 2005 03:56:33 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1ki-0006IU-Kr; Wed, 23 Mar 2005 04:02:13 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:55:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] contribution to charter item / definition of objective metrics: dratf-stephan-ippm-multimetrics-00.txt Date: Wed, 23 Mar 2005 09:55:36 +0100 Message-ID: Thread-Topic: [Pce] contribution to charter item / definition of objective metrics: dratf-stephan-ippm-multimetrics-00.txt Thread-Index: AcT5o06MSWseXMU/TPuxFj7VFDY1Fg13NrDQ From: "STEPHAN Emile RD-CORE-LAN" To: "JP Vasseur" X-OriginalArrivalTime: 23 Mar 2005 08:55:37.0466 (UTC) FILETIME=[150465A0:01C52F86] X-Spam-Score: 0.2 (/) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Cc: pce@ietf.org, ippm@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: , Content-Type: multipart/mixed; boundary="===============0277772017==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf This is a multi-part message in MIME format. --===============0277772017== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52F86.143C8B84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52F86.143C8B84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 Objective metrics include 2 main categories: Those for measuring the performance (the rapidity) of a PCE entity; Those for measuring the accuracy of the PCE computation:=20 Do the quality and the performance of the path computed by PCEs entities = complies with the query? =20 Regarding the second point, Lei and I merged 3 I-Ds in one which defines = "Spatial and Multicast Metrics for IPPM" = (http://www.ietf.org/internet-drafts/draft-stephan-ippm-multimetrics-00.t= xt = ). It defines 2 sets of metrics, spatial and one-to-group:=20 The intend of the spatial metrics part is clearly to provide TE and = interdomain with metrics to decompose end-to-end performance; The intend of the spatial metrics part and one-to-group part are to = provide metrics to decompose the performance of point-to-multipoint = services; =20 The draft was presented at Minneapolis during the IPPM WG. I clearly = designed it to become an IPPM WG item. I take a special care to select = metrics which conform to the IPPM framework (RFC2330) and which are = directly usable for unicast or multicast TE.=20 =20 This draft will be discussed in the IPPM mailing. Mid April, chairs will = decide its status evolution. =20 I have no doubt that there are a lot of missing points in the discussion = section such as case study, applicability... So please read the document = and send your comment in PCE and IPPM list. =20 Regards Emile =20 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 13 janvier 2005 20:09 =C0 : STEPHAN Emile RD-CORE-LAN Cc : pce@ietf.org Objet : Re: [Pce] contribution to charter item =20 Salut Emile,=20 =20 On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote:=20 =20 Dear JP, Adrian and all=20 =20 There is an important item in the PCE WG charter, which is the = definition of MIBs and management procedures related to the new = protocols, protocol extensions and operational elements.=20 =20 I am interested to contribute to this WG item.=20 =20 =20 Great !=20 =20 Considering your involvement in IPPM, you may also be interested by:=20 =20 May 05: Submit first draft of the definition of objective metrics=20 =20 Please let me know when you will start this activity.=20 =20 =20 As indicated in the WG Milestones ... of course, for the MIB, this = requires some time until we make progress on the protocol(s).=20 =20 Cheers.=20 =20 JP.=20 =20 Regards=20 =20 Emile=20 _______________________________________________=20 Pce mailing list=20 Pce@lists.ietf.org=20 https://www1.ietf.org/mailman/listinfo/pce=20 ------_=_NextPart_001_01C52F86.143C8B84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

Objective metrics include 2 main categories:

Those for = measuring the performance (the rapidity) of a PCE entity;

Those for = measuring the accuracy of the PCE computation:

Do the quality and the performance of the path computed by PCEs entities complies with = the query?

 

Regarding the second point, Lei and I merged 3 = I-Ds in one which defines "Spatial and Multicast Metrics for IPPM" = (http://www.ietf.org/internet-drafts/draft-step= han-ippm-multimetrics-00.txt ). It defines 2 sets of metrics, spatial and one-to-group: =

The intend of = the spatial metrics part is clearly to provide TE and interdomain with metrics to = decompose end-to-end performance;

The intend of = the spatial metrics part and one-to-group part are to provide metrics to decompose = the performance of point-to-multipoint services;

 

The draft was presented at Minneapolis during = the IPPM WG. I clearly designed it to become an IPPM WG item. I take a = special care to select metrics which conform to the IPPM framework (RFC2330) and = which are directly usable for unicast or multicast TE.

 

This draft will be discussed in the IPPM = mailing. Mid April, chairs will decide its status evolution.

 

I have no doubt that there are a lot of = missing points in the discussion section such as case study, applicability… So = please read the document and send your comment in PCE and IPPM = list.

 

Regards

Emile

 

De :<= /span> JP Vasseur [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 13 = janvier 2005 20:09
=C0 : STEPHAN Emile = RD-CORE-LAN
Cc : pce@ietf.org
Objet : Re: [Pce] contribution to charter item

 

Salut Emile,

 

On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote: =

 

Dear JP, Adrian and = all

 

There is an important item in the PCE WG charter, which is the definition of MIBs and management = procedures related to the new protocols, protocol = extensions and operational elements.

 

I am interested to contribute to this WG item. =

 

 

Great !

 

Considering your involvement in IPPM, you may also be interested = by:

 

May 05: Submit first draft of the definition of = objective metrics

 

Please let me know when you will start this activity. =

 

 

As indicated in the WG Milestones ... of course, for the MIB, = this requires some time until we make progress on the protocol(s). =

 

Cheers.

 

JP.

 

Regards

 

Emile

_______________________________________________ =

Pce mailing list

Pce@lists.ietf.org

https://www1.ietf.org/mailman/listinfo/pce

------_=_NextPart_001_01C52F86.143C8B84-- --===============0277772017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0277772017==-- From pce-bounces@ietf.org Sat Mar 26 13:07:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17144; Sat, 26 Mar 2005 13:07:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFFnP-0006Pp-VN; Sat, 26 Mar 2005 13:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFFgE-0005Xx-GM; Sat, 26 Mar 2005 13:06:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFFgD-0005Xs-J1 for pce@megatron.ietf.org; Sat, 26 Mar 2005 13:06:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16949; Sat, 26 Mar 2005 13:06:24 -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.33) id 1DFFmB-0006Np-2F; Sat, 26 Mar 2005 13:12:48 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2005 10:06:17 -0800 X-IronPort-AV: i="3.91,125,1110182400"; d="scan'208"; a="241222013:sNHT58759408" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2QI6DDr009065; Sat, 26 Mar 2005 10:06:13 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-2-110.cisco.com [10.86.242.110]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA03120; Sat, 26 Mar 2005 10:06:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: proceedings@ietf.org Message-Id: <135d230265cc95df1799cad6f76c0f49@cisco.com> From: JP Vasseur Date: Sat, 26 Mar 2005 13:06:31 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52005c17383d4e3f609075a067e11971 Cc: pce@ietf.org Subject: [Pce] IETF-62 Proceeding Submission - PCE WG Minutes 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="===============0121621917==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ec0f3d4960e6167ab597cf7076be2db --===============0121621917== Content-Type: multipart/alternative; boundary=Apple-Mail-39-409205338 --Apple-Mail-39-409205338 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Path Computation Element (PCE) Working Group - 03/07/2005 - IETF-62 - =20= Minneapolis Thanks to Jaudelice De Oliveira and Zafar Ali for having taken the =20 minutes. CHAIR REPORT ------------------------ Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area =20 TE) first Milestones have very aggressive timeline Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications. Work in progress to be presented today: - Draft on PCE architecture - Draft on PCE discovery requirements and protocol extensions - Draft on PCE communication Immediate next work: Draft on PCE communication protocol specification Draft on PCE discovery protocol Draft on objective metrics End of chair report ------------------- Question from audience on objective metrics: Metrics to evaluate PCE. JP gave a few examples of metrics of interest: E.g., How fast you can respond to topology changes, etc. First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash ------------------------------------------------------------------------=20= ---- Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics. Issued raised on the list - already responded (text added to several sections with respect to every comment) added to 6.4: PCE should advertise capabilities added to 6.6: Path computation request include if near-disjoint paths acceptable added to 6.7: TED information can include info from sources other than =20= IGP added to 6.8: elaborate on advantages of stateful PCE & pitfalls of =20 using stateful PCE in a distributed PCE environment added to 7: Further metrics proposed to evaluate PCE solutions next steps: propose draft as PCE WG draft Questions raised: ------------------ Question: Concern raised on how feasible is the considered approach (stateful PCE). An element performing optimal computational might take infinite time to =20= do so. Concern about delegating the distributed control plane =20 responsibility to PCE. Question on possibility of unsolicited requests PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well? Are there specific requirements on response time of PCE? (for global optimization) JP: will be part of the evaluation metrics. Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly) Dimtri asked a question on stateful vs. stateless PCE in the document; =20= how feasible is stateful PCE? Is it reasonable to assume stateful PCE? Jerry: yes for some applications. Dimitri: Is this can be assumed manageable? Given control to PCE that =20= is otherwise done by a distributed control plan. JP added: It=92s applicable for some applications requiring global =20 optimization. Kireeti: (Global Optimality) is NOT a good target. Stateful PCE =20 provides lot of complexity, while nice- not feasible. Dimitri: Concerning global optimization, raises issue about the trigger =20= and maintenance of this process (responsibility) that is now pulled =20 outside of the local node and delegated to a third party -> therefore =20= there is now a system impact in terms of performance of the global =20 system JP: Evaluation Metric is to be used for this purpose. Dimitri: but these are not evaluation metrics in terms of computation =20= results these are specific metrics for evaluating the correct behaviour =20= of the system JP agreed on the fact that it is out of the scope to make algorithmic =20= evaluation. Igor: Similar comments for stateful vs. stateless. Adrian: ITU-T also requires similar functionality. Liaison Statement to =20= ITU-T is completed. We think SG-15 would be a good start. J. Sadler: Yes, there is similar work pursued at ITU-T. G7715 on ITU-T =20= has similar function. JP Polled the audience for the Architecture document. JP: Majority in favor it as a WG document. We will confirm at the =20 mailing list. Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis ------------------------------------------------------------------------=20= ------------ PCE Discovery requirements The draft addresses PCE discovery within and across domain(s). Remaining issues: Address comments received in the next version * Need to improve security particularly for Inter-AS PCE discovery * Discovery of dynamic parameters such as the PCE CPU state * PCE aliveness detection Consensus for a WG doc? Questions raised: --------------------- Kiretti: Discovery of PCEs: better rely on PCC-PCE communication? comment2: If there is a need, routing is a better place than signalling. JP reminded that the document is just identifying requirements but not =20= solutions. Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). =20= How did the 60 seconds rule was defined? Need to include how that was =20= decided. Dimitri: Are we not already overloading the PCEs? Need to define the =20 right level of abstraction... It is an open question. Needs further =20 discussion. Correct architecture design is required to address the =20 overload problem before hand. Adrian: Reminder that the draft is in its first version. Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery =20 includes CPU load factor, it will complicate the PCC system. Dimitri: you haven=92t design the system and are worried about the =20 overloaded system. General problem of the overload should be solved at =20= the root (architecture). The sense in which i used the term =20 architecture is not exactly the same as the one used per this doc. here =20= i do refer to the set of the protocol mechanisms and underlying =20 operations - not the global framework architecture Tony Li: As far as process is concerned, start off with a good =20 requirement document, enumerate minimum set of requirements. What you =20= got right now is iteration from the solution space. Focus on minimal =20 requirements and what is the basic problem we are trying to solve. Adrian: This was only first revision of the document. Igor: We need to advertise backup PCE, why backup PCE and not =20 load-balanced. Jean-Louis: The SP thinks that having a dedicated backup could also be =20= useful. But this is optional. JP: Few sensitive topics like advertisement of dynamic capability needs =20= more discussion on the mailing list. Richard Rabbat: Not all ABR are PCE in your Figure. Jean-Louis: It is just an example case used for illustration purpose =20 only. Richard Rabbat: How did you come up with 60 second requirement? Jean-Louis: There are number of SP on the ID and we think 60 sec is a =20= good target. Will provide more details on this. Dimitri: Does these requirements covers inter-AS case? Jean-Louis: Yes. Dimitri: Today, overloading cases may occur as part of a label switch =20= router - and we just start discussions concerning the overload problems =20= - as we have after several years of active work the conditions where =20 the (distributed) overload occurs, therefore should we worry about PCE =20= overload instead of focusing on the right level of detail at this point =20= in time. We need to make sure that right level of details are provided =20= in the document. The basic stuff like, how to find reachable addresses =20= is not there in the document. We don=92t have basic stuff in the =20 document. Jean-Louis: No reachability stuff is detailed in the document. There is =20= mention of domain ID-es: area-ID & AS number. JP: This is not a flushed out version. Thanks to DT for their effort in =20= putting this together. Requires more discussion in the mailing list =20 before asking to adopt this ID as a WG document. Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash ------------------------------------------------------------------------=20= ----------------------- PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) Various issues raised on the list: for example extensive discussions =20 about re-use of RSVP object encodings Questions raised: ------------------------- Arthi: Is there a requirement of unsolicited PCE to PCC communication. Zafar: Yes, there are cases where unsolicited PCE to PCC communication =20= is required. Many: Is it suitabe to list candidates on this documents? JP: candidates are out of the scope of this protocol. Document is a =20 very first cut. Kireeti: Stateless x stateful. There are needs and there are benefits. Comment: Contradiction, scalability reqirements. Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make =20 decision that is related to the forwarding plan? Jerry: The intension was to mention requirement to include some QOS =20 parameters in the PCC-PCE messages. JP: clarified that the intention was to include possibility of QoS considerations in path computation. JP/ Jerry: I.e., Path Computation Constraints related parameters. Kireeti: On GR of PCE: When it comes to GR, there is a huge difference =20= between stateful and stateless PCE. Recommend to put it in an =20 applicability statement. JP: Yes, complexity analysis is meant for this purpose. Adrian/ JP: Estimates some work to flush-out details. It=92s a huge list = =20 of requirements. We want to handle simple problem first. Candidate =20 protocols are not considered or within scope. Zafar: Relationship with other WG-es. Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS =20 usage of PCE, inter-domain stuff is example of cases where input from =20= CCAMP is needed. Dimitri: what about the reachability of PCE location(s) for non-IP =20 terminating nodes. Adrian: GMPLS requirements from CCAMP. Conclusion: Needs more discussion on the list. This document will be the basis of the work. Other discussions: --------------------------- CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE. JP mentioned that many of the drafts were posted recently and did not =20= have a slot in this meeting mostly because the focus was on the main =20 documents and to flesh out the requirements. JP/ Adrian: Many of the drafts were put in and right now we are =20 flushing out first milestone. Other applications will be addressed =20 later. Charter at present does not include candidate (solutions). =20 Questions like what layer PCE should work on? Should PCC-PCE be based =20= on a reliable transport? TCP is reliable, is it a candidate? are among =20= the question charter addresses. Discussion on statement on the requirement of reliability. Dimitri: The biggest question is if we can use RSVP for PCC-PCE =20 communication. Zafar: It=92s funny that when we talk about IGP-es, people settle with =20= what we have today, and when it comes to signaling we tend to have such =20= a large diversion. In my opinion signaling is a very small piece of the =20= overall architecture and we should make use of what we have today. Dimitri: But RSVP is designed for end-to-end (session) signaling and =20 not a PCC-PCE client-server exchange. Instead, what about considering communication relying on the transport layer (TCP) Zafar: Let=92s be clear on what we mean here. We are talking about use = of =20 RSVP for encoding. At the transport level we can still rely on TCP. Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for this =20= purpose. Zafar: We know that PCC is going to signal using RSVP-TE, why not =20 provide information encoded in RSVP format to minimize useless copying =20= of the data (from one format to the other). Kireeti: Not all objects are defined for RSVP today. Zafar: The new objects can be defined. There are also other =20 applications for the use of the objects require by PCE. Dimitri: considering these objects on the PCE does not provide more =20 rationale for considering RSVP as communication protocol between the =20 PCC and the PCE Kireeti: Well, this is convoluted; we don=92t have support for all so =20= let=92s extend RSVP, which is not designed for this purpose. Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other =20 client server based protocols. I recommend taking a look at such =20 protocols. Concern/Comment on RSVP usage and PCC-PCE communication JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself JP: Opinions about future candidates are welcome and the final =20 coomunication will of course be the result of the WG consensus * Comment/confusion on PCC being a node/client * Comment agreeing with Dimitri * Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements. * Comment on not excluding options that are not available today Conclusion: To Continue on the mailing list Dimitri: Question on the discovery of the PCE (possibility of =20 proliferation mechanism for PCE discovery). JP and Adrian.= --Apple-Mail-39-409205338 Content-Type: text/enriched; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Path Computation Element (PCE) Working Group - 03/07/2005 - IETF-62 - Minneapolis Thanks to Jaudelice De Oliveira and Zafar Ali for having taken the minutes. CHAIR REPORT ------------------------ Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area TE) first Milestones have very aggressive timeline Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications. Work in progress to be presented today: - Draft on PCE architecture - Draft on PCE discovery requirements and protocol extensions - Draft on PCE communication Immediate next work: Draft on PCE communication protocol specification Draft on PCE discovery protocol Draft on objective metrics End of chair report ------------------- Question from audience on objective metrics: Metrics to evaluate PCE. JP gave a few examples of metrics of interest: E.g., How fast you can respond to topology changes, etc. First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash = --------------------------------------------------------------------------= -- Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics. Issued raised on the list - already responded (text added to several sections with respect to every comment) added to 6.4: PCE should advertise capabilities added to 6.6: Path computation request include if near-disjoint paths acceptable added to 6.7: TED information can include info from sources other than IGP added to 6.8: elaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment added to 7: Further metrics proposed to evaluate PCE solutions next steps: propose draft as PCE WG draft Questions raised: ------------------ Question: Concern raised on how feasible is the considered approach (stateful PCE). An element performing optimal computational might take infinite time to do so. Concern about delegating the distributed control plane responsibility to PCE. Question on possibility of unsolicited requests PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible? PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well? Are there specific requirements on response time of PCE? (for global optimization) JP: will be part of the evaluation metrics. Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly) Dimtri asked a question on stateful vs. stateless PCE in the document; how feasible is stateful PCE? Is it reasonable to assume stateful PCE?=20= Jerry: yes for some applications.=20 Dimitri: Is this can be assumed manageable? Given control to PCE that is otherwise done by a distributed control plan.=20 JP added: It=92s applicable for some applications requiring global optimization. Kireeti: (Global Optimality) is NOT a good target. Stateful PCE provides lot of complexity, while nice- not feasible.=20 Dimitri: Concerning global optimization, raises issue about the trigger and maintenance of this process (responsibility) that is now pulled outside of the local node and delegated to a third party -> therefore there is now a system impact in terms of performance of the global system JP: Evaluation Metric is to be used for this purpose.=20 Dimitri: but these are not evaluation metrics in terms of computation results these are specific metrics for evaluating the correct behaviour of the system JP agreed on the fact that it is out of the scope to make algorithmic evaluation. Igor: Similar comments for stateful vs. stateless.=20 Adrian: ITU-T also requires similar functionality. Liaison Statement to ITU-T is completed. We think SG-15 would be a good start.=20 J. Sadler: Yes, there is similar work pursued at ITU-T. G7715 on ITU-T has similar function. JP Polled the audience for the Architecture document.=20 JP: Majority in favor it as a WG document. We will confirm at the mailing list. Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis = --------------------------------------------------------------------------= ---------- PCE Discovery requirements The draft addresses PCE discovery within and across domain(s). Remaining issues: Address comments received in the next version * Need to improve security particularly for Inter-AS PCE discovery * Discovery of dynamic parameters such as the PCE CPU state * PCE aliveness detection Consensus for a WG doc? Questions raised: --------------------- Kiretti: Discovery of PCEs: better rely on PCC-PCE communication? comment2: If there is a need, routing is a better place than signalling. JP reminded that the document is just identifying requirements but not solutions. Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). How did the 60 seconds rule was defined? Need to include how that was decided. Dimitri: Are we not already overloading the PCEs? Need to define the right level of abstraction... It is an open question. Needs further discussion. Correct architecture design is required to address the overload problem before hand. Adrian: Reminder that the draft is in its first version. Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery includes CPU load factor, it will complicate the PCC system.=20 Dimitri: you haven=92t design the system and are worried about the overloaded system. General problem of the overload should be solved at the root (architecture). The sense in which i used the term architecture is not exactly the same as the one used per this doc. here i do refer to the set of the protocol mechanisms and underlying operations - not the global framework architecture Tony Li: As far as process is concerned, start off with a good requirement document, enumerate minimum set of requirements. What you got right now is iteration from the solution space. Focus on minimal requirements and what is the basic problem we are trying to solve.=20 Adrian: This was only first revision of the document. Igor: We need to advertise backup PCE, why backup PCE and not load-balanced.=20 Jean-Louis: The SP thinks that having a dedicated backup could also be useful. But this is optional.=20 JP: Few sensitive topics like advertisement of dynamic capability needs more discussion on the mailing list.=20 Richard Rabbat: Not all ABR are PCE in your Figure.=20 Jean-Louis: It is just an example case used for illustration purpose only.=20 Richard Rabbat: How did you come up with 60 second requirement? Jean-Louis: There are number of SP on the ID and we think 60 sec is a good target. Will provide more details on this.=20 Dimitri: Does these requirements covers inter-AS case?=20 Jean-Louis: Yes.=20 Dimitri: Today, overloading cases may occur as part of a label switch router - and we just start discussions concerning the overload problems - as we have after several years of active work the conditions where the (distributed) overload occurs, therefore should we worry about PCE overload instead of focusing on the right level of detail at this point in time. We need to make sure that right level of details are provided in the document. The basic stuff like, how to find reachable addresses is not there in the document. We don=92t have basic stuff in the document.=20 Jean-Louis: No reachability stuff is detailed in the document. There is mention of domain ID-es: area-ID & AS number. =20 JP: This is not a flushed out version. Thanks to DT for their effort in putting this together. Requires more discussion in the mailing list before asking to adopt this ID as a WG document. Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash = --------------------------------------------------------------------------= --------------------- PCE/PCE Communication requirements (PCC-PCE & PCE-PCE) Various issues raised on the list: for example extensive discussions about re-use of RSVP object encodings Questions raised: ------------------------- Arthi: Is there a requirement of unsolicited PCE to PCC communication.=20= Zafar: Yes, there are cases where unsolicited PCE to PCC communication is required.=20 Many: Is it suitabe to list candidates on this documents? JP: candidates are out of the scope of this protocol. Document is a very first cut. Kireeti: Stateless x stateful. There are needs and there are benefits. Comment: Contradiction, scalability reqirements. Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make decision that is related to the forwarding plan?=20 Jerry: The intension was to mention requirement to include some QOS parameters in the PCC-PCE messages.=20 JP: clarified that the intention was to include possibility of QoS considerations in path computation. JP/ Jerry: I.e., Path Computation Constraints related parameters.=20 Kireeti: On GR of PCE: When it comes to GR, there is a huge difference between stateful and stateless PCE. Recommend to put it in an applicability statement.=20 JP: Yes, complexity analysis is meant for this purpose. Adrian/ JP: Estimates some work to flush-out details. It=92s a huge list of requirements. We want to handle simple problem first. Candidate protocols are not considered or within scope.=20 Zafar: Relationship with other WG-es.=20 Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS usage of PCE, inter-domain stuff is example of cases where input from CCAMP is needed.=20 Dimitri: what about the reachability of PCE location(s) for non-IP terminating nodes.=20 Adrian: GMPLS requirements from CCAMP.=20 Conclusion: Needs more discussion on the list. This document will be the basis of the work. Other discussions: --------------------------- CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE. JP mentioned that many of the drafts were posted recently and did not have a slot in this meeting mostly because the focus was on the main documents and to flesh out the requirements. JP/ Adrian: Many of the drafts were put in and right now we are flushing out first milestone. Other applications will be addressed later. Charter at present does not include candidate (solutions). Questions like what layer PCE should work on? Should PCC-PCE be based on a reliable transport? TCP is reliable, is it a candidate? are among the question charter addresses.=20 Discussion on statement on the requirement of reliability. Dimitri: The biggest question is if we can use RSVP for PCC-PCE communication.=20 Zafar: It=92s funny that when we talk about IGP-es, people settle with what we have today, and when it comes to signaling we tend to have such a large diversion. In my opinion signaling is a very small piece of the overall architecture and we should make use of what we have today.=20 Dimitri: But RSVP is designed for end-to-end (session) signaling and not a PCC-PCE client-server exchange. Instead, what about considering communication relying on the transport layer (TCP)=20 Zafar: Let=92s be clear on what we mean here. We are talking about use of RSVP for encoding. At the transport level we can still rely on TCP.=20= Kireeti: Not for RSVP as PCC-PCE protocol. It=92s not defined for this purpose.=20 Zafar: We know that PCC is going to signal using RSVP-TE, why not provide information encoded in RSVP format to minimize useless copying of the data (from one format to the other).=20 Kireeti: Not all objects are defined for RSVP today.=20 Zafar: The new objects can be defined. There are also other applications for the use of the objects require by PCE.=20 Dimitri: considering these objects on the PCE does not provide more rationale for considering RSVP as communication protocol between the PCC and the PCE Kireeti: Well, this is convoluted; we don=92t have support for all so let=92s extend RSVP, which is not designed for this purpose.=20 Mathew: PCC-PCE is a client server protocol. We=92ve a lot of other client server based protocols. I recommend taking a look at such protocols.=20 Concern/Comment on RSVP usage and PCC-PCE communication JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself JP: Opinions about future candidates are welcome and the final coomunication will of course be the result of the WG consensus * Comment/confusion on PCC being a node/client * Comment agreeing with Dimitri * Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements. * Comment on not excluding options that are not available today Conclusion: To Continue on the mailing list Dimitri: Question on the discovery of the PCE (possibility of proliferation mechanism for PCE discovery). JP and Adrian.= --Apple-Mail-39-409205338-- --===============0121621917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0121621917==-- From pce-bounces@ietf.org Mon Mar 28 06:02:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03219; Mon, 28 Mar 2005 06:02:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFs78-0007eE-PJ; Mon, 28 Mar 2005 06:08:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFrzK-0001Hp-5e; Mon, 28 Mar 2005 06:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFrzI-0001Hk-FK for pce@megatron.ietf.org; Mon, 28 Mar 2005 06:00:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03155 for ; Mon, 28 Mar 2005 06:00:49 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFs5l-0007cn-Lt for pce@ietf.org; Mon, 28 Mar 2005 06:07:34 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j2SB2w24025380 for ; Mon, 28 Mar 2005 04:02:59 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j2SB1JE1029475 for ; Mon, 28 Mar 2005 05:01:20 -0600 (CST) Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Mar 2005 16:30:37 +0530 Message-ID: <653138C25D8AD6118292000347080A371829BA6D@zin05exm02.corp.mot.com> From: Vivek Dubey-G20041 To: pce@ietf.org Date: Mon, 28 Mar 2005 16:30:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Pce] draft-ietf-pce-architecture-00 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@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi, Section 6.4 : Multiple PCE Path Computation with Inter-PCE Communication: The PCE in Section 5.3 was >> should be "6.3" Section 7.1: Centralized Computation Model >> Does Centralized Computation Model provides for backup/standby PCE. If so, it should be mentioned here Section 7.3: Synchronization In this case of non-synchronized path computation, the path computation of a set of TE LSPs can be shared among a set of PCEs (that is, one path computed by each PCE). >> This sharing decision can be made by PCE or PCC or either? Section 7.3: Synchronization each PCE can be backed up by one or more PCEs, should it fail >> more PCEs mean how many? Any specific reason to provide for more than one backup PCEs. Section 7.4: PCE Discovery and Load Balancing The PCE architecture requires that the PCC knows the location of >> The PCE architecture requires that the PCC/PCE knows the location of Section 7.4: PCE Discovery and Load Balancing This information would help a PCC that dynamically learns about PCEs available on the network to decide which of them to use >> PCC/PCE Section 7.5: Detecting PCE Liveness the inability of a PCE to service a request (perhaps due to excessive load) may be determined by the PCC through the use of timers >> Failure message from PCE would be better. Section 7.8: Stateful Versus Stateless PCEs in Section 6.7 also come into play >> Should be Section 7.7 Section 7.10: Policy and Confidentiality As mentioned in section 6.9 >> No such section Thanks Vivek _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Mar 30 14:43:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02838; Wed, 30 Mar 2005 14:43:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGjDM-0000TV-Fs; Wed, 30 Mar 2005 14:50:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGj4A-0008M2-Ci; Wed, 30 Mar 2005 14:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGj49-0008Ls-04 for pce@megatron.ietf.org; Wed, 30 Mar 2005 14:41:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02654 for ; Wed, 30 Mar 2005 14:41:23 -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.33) id 1DGjB6-0000Ri-Fb for pce@ietf.org; Wed, 30 Mar 2005 14:48:37 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2005 11:41:10 -0800 X-IronPort-AV: i="3.91,135,1110182400"; d="scan'208"; a="243093109:sNHT3965474284" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UJf8Dr023663 for ; Wed, 30 Mar 2005 11:41:08 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-142.cisco.com [10.86.240.142]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA27730 for ; Wed, 30 Mar 2005 11:41:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Wed, 30 Mar 2005 14:41:23 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Pce] First Milestone: done 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="===============1904190447==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --===============1904190447== Content-Type: multipart/alternative; boundary=Apple-Mail-8-760497591 --Apple-Mail-8-760497591 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, Just a quick note to let you know that our first Milestone is done: Goals and Milestones: Done Submit first draft of PCE architecture document JP and Adrian. --Apple-Mail-8-760497591 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Just a quick note to let you know that our first Milestone is done: TimesGoals and Milestones: TimesDone Submit first draft of PCE architecture document JP and Adrian. --Apple-Mail-8-760497591-- --===============1904190447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1904190447==--