From mailman-bounces@ietf.org Sat Jan 1 05:25: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 FAA06038 for ; Sat, 1 Jan 2005 05:25:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkgdH-0006Yx-1h for pce-archive@ietf.org; Sat, 01 Jan 2005 05:37:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg5k-0002Il-4P for pce-archive@ietf.org; Sat, 01 Jan 2005 05:02:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pce-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:41 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for pce-archive@ietf.org: List Password // URL ---- -------- pce@lists.ietf.org geebfe https://www1.ietf.org/mailman/options/pce/pce-archive%40ietf.org From pce-bounces@ietf.org Tue Jan 4 17:20:40 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 RAA27950; Tue, 4 Jan 2005 17:20:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClxF7-00024s-CF; Tue, 04 Jan 2005 17:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clwz7-0006WP-DZ; Tue, 04 Jan 2005 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClwAL-0004Cu-SK; Tue, 04 Jan 2005 16:24:33 -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 QAA23761; Tue, 4 Jan 2005 16:24:31 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClwMk-0000lf-HL; Tue, 04 Jan 2005 16:37:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j04LNxi32084; Tue, 4 Jan 2005 23:23:59 +0200 Date: Tue, 4 Jan 2005 23:23:59 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: <200412231907.OAA09150@ietf.org> Message-ID: References: <200412231907.OAA09150@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Tue, 04 Jan 2005 17:16:59 -0500 Cc: pce@ietf.org Subject: [Pce] Re: WG Review: Path Computation Element (pce) 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: b7b9551d71acde901886cc48bfc088a6 On Thu, 23 Dec 2004, The IESG wrote: > A new IETF working group has been proposed in the Routing Area. The IESG > has not made any determination as yet. The following description was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by December 30th. The deadline is already past, but here's my couple of cents. In short, I think the WG is tasked with a lot of work items, with no clear priorization and/or requirement for the order in which this work is to be conducted. I fear this would result in a rush to get the protocols out, with little regard to thinking about the requirements and the framework. > 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. This seems like useful work, and the same concept could be applied to a lot of other uses as well if it proves a success here (e.g., intserv-like QoS, soBGP/sBGP). However, to focus the work, let's just look at this narrowly now. It might make sense to s/Path/MPLS-TE Path/ in the WG name. > 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. These are good topics. > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation involving > PCEs of multiple administrative entities. It might make sense to focus first on the requirements part only. > - 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 (OSPF, ISIS and 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. These are presumptive of the approach for the solution, and I'm not sure if it makes good sense to include these at this point in the charter, at least without a disclaimer that these will be worked on later. For example, the second bullet presumes the PCE discovery would be done using a routing protocol. The discovery might be done using a completely different kind of protocol, or just using manual configuration. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Jan 6 19:11: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 TAA08418; Thu, 6 Jan 2005 19:11:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhwM-0008LR-62; Thu, 06 Jan 2005 19:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmhh9-0007Hb-S6; Thu, 06 Jan 2005 19:09:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmhas-0004rO-BM; Thu, 06 Jan 2005 19:03:06 -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 TAA08037; Thu, 6 Jan 2005 19:03:03 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhnY-0008Ax-FO; Thu, 06 Jan 2005 19:16:12 -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 645FDE000064; Fri, 7 Jan 2005 00:02:13 +0000 (GMT) Received: from Puppy ([81.179.230.199] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jan 2005 00:02:12 +0000 Message-ID: <008a01c4f44c$48e9a4e0$0301a8c0@Puppy> From: "Adrian Farrel" To: "Pekka Savola" , References: <200412231907.OAA09150@ietf.org> Subject: Re: [Pce] Re: WG Review: Path Computation Element (pce) Date: Fri, 7 Jan 2005 00:01:36 -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: 07 Jan 2005 00:02:12.0828 (UTC) FILETIME=[23C8F1C0:01C4F44C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi Pekka, As you say, the deadline is past, but that doesn't stop the chairs (if a WG is formed) being sensitive to the points you raise and carrying them forward into the operation of the WG. See in line. Cheers, Adrian > > A new IETF working group has been proposed in the Routing Area. The IESG > > has not made any determination as yet. The following description was > > submitted, and is provided for informational purposes only. Please send > > your comments to the IESG mailing list (iesg@ietf.org) by December 30th. > > The deadline is already past, but here's my couple of cents. > > In short, I think the WG is tasked with a lot of work items, with no > clear priorization and/or requirement for the order in which this work > is to be conducted. I fear this would result in a rush to get the > protocols out, with little regard to thinking about the requirements > and the framework. IMHO the milestones give a clear prioritization. In these matters I would hope that we can depend on the chairs to ensure that an appropriate ordering is followed. The ADs will (of course) be watching. > > 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. > > This seems like useful work, and the same concept could be applied to > a lot of other uses as well if it proves a success here (e.g., > intserv-like QoS, soBGP/sBGP). However, to focus the work, let's just > look at this narrowly now. Absolutely. And you'll notice that first off we are significantly limiting the scope even within the bounds of (G)MPLS-TE LSPs. > It might make sense to s/Path/MPLS-TE Path/ in the WG name. Well may be. What's in a name? > > Work Items: [SNIP] > > - Specification of requirements and protocol extensions related to > > the policy, and security aspects of PCE-based path computation involving > > PCEs of multiple administrative entities. > > It might make sense to focus first on the requirements part only. If only requirements are in the charter, one might ask why both with requirements? Thus solution is also in charter, but we would assume that the focus would be on the requirements first. See the milestones. > > - 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 (OSPF, ISIS and 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. > > These are presumptive of the approach for the solution, and I'm not > sure if it makes good sense to include these at this point in the > charter, at least without a disclaimer that these will be worked on > later. I don't believe they make this presumption at all. There is a presumed architecture (this was a requirement before the charter was drafted) and this places certain assumptions on the solution: - there will be a communication between PCC and PCE - PCE discovery is needed - every attemot will be made to re-use existing routing and signaling protocols used to establish TE LSPs - the current routing and signaling protocols MIGHT NOT be adequate to support TE LSP establishment in the presence of PCE. > For example, the second bullet presumes the PCE discovery would be > done using a routing protocol. The discovery might be done using a > completely different kind of protocol, or just using manual > configuration. No, it doesn't say this at all. It says "Where such techniques result in the extensions of existing protocols..." which acknowledges that discovery might use a routing protocol, but doesn't say it must. This text is important because we do not want a PCE WG modifying the routing protocols without consultation with the WG that owns the protocol. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Jan 8 22:19: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 WAA24378; Sat, 8 Jan 2005 22:19:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnTpS-0005h8-2B; Sat, 08 Jan 2005 22:33:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnTXH-0005AB-Tk; Sat, 08 Jan 2005 22:14:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnMiz-0000pB-C9; Sat, 08 Jan 2005 14:58: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 OAA27028; Sat, 8 Jan 2005 14:58:12 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnMvp-00064G-N3; Sat, 08 Jan 2005 15:11:55 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j08JvAC16843; Sat, 8 Jan 2005 21:57:10 +0200 Date: Sat, 8 Jan 2005 21:57:10 +0200 (EET) From: Pekka Savola To: Adrian Farrel Subject: Re: [Pce] Re: WG Review: Path Computation Element (pce) In-Reply-To: <008a01c4f44c$48e9a4e0$0301a8c0@Puppy> Message-ID: References: <200412231907.OAA09150@ietf.org> <008a01c4f44c$48e9a4e0$0301a8c0@Puppy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Sat, 08 Jan 2005 22:14:34 -0500 Cc: pce@ietf.org, iesg@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: 5011df3e2a27abcc044eaa15befcaa87 On Fri, 7 Jan 2005, Adrian Farrel wrote: >> In short, I think the WG is tasked with a lot of work items, with no >> clear priorization and/or requirement for the order in which this work >> is to be conducted. I fear this would result in a rush to get the >> protocols out, with little regard to thinking about the requirements >> and the framework. > > IMHO the milestones give a clear prioritization. In these matters I would > hope that we can depend on the chairs to ensure that an appropriate > ordering is followed. The ADs will (of course) be watching. This may be one approach, but builds on the WG chair being able to convice the WG that the proposed priorization is in fact the right one. This seems optimistic, as the WG participants are very likely eager to jump to the solutions already :). I've seen many WGs stumble because the charter did not restrict and guide the steps of the WG well enough. Such a charter is easier for the WG chairs as well because they have concrete levers they can pull to justify working in a specific order. > >>> - Specification of requirements and protocol extensions related to >>> the policy, and security aspects of PCE-based path computation involving >>> PCEs of multiple administrative entities. >> >> It might make sense to focus first on the requirements part only. > > If only requirements are in the charter, one might ask why both with > requirements? > Thus solution is also in charter, but we would assume that the focus would > be on the requirements first. See the milestones. Yes, one would hope so. As I write above, it would make the job of the WG and WG chairs (and ultimately the ADs) easier if this assumption was clearly written in the charter, maybe as a requirement how the work should be done. >>> - Specification of techniques in support of PCE discovery within and >>> across domains. Where such techniques result in the extensions of >>> existing protocols (OSPF, ISIS and BGP), this work will be done in >>> conjunction with the appropriate WGs. [...] >> >> These are presumptive of the approach for the solution, and I'm not >> sure if it makes good sense to include these at this point in the >> charter, at least without a disclaimer that these will be worked on >> later. > > I don't believe they make this presumption at all. > There is a presumed architecture (this was a requirement before the > charter was drafted) and this places certain assumptions on the solution: > - there will be a communication between PCC and PCE > - PCE discovery is needed > - every attemot will be made to re-use existing routing > and signaling protocols used to establish TE LSPs > - the current routing and signaling protocols MIGHT NOT > be adequate to support TE LSP establishment in the > presence of PCE. OK. However, the second bullet was the one that struck me as requiring wordsmithing, below... >> For example, the second bullet presumes the PCE discovery would be >> done using a routing protocol. The discovery might be done using a >> completely different kind of protocol, or just using manual >> configuration. > > No, it doesn't say this at all. > It says "Where such techniques result in the extensions of existing > protocols..." which acknowledges that discovery might use a routing > protocol, but doesn't say it must. This text is important because we do > not want a PCE WG modifying the routing protocols without consultation > with the WG that owns the protocol. The text says: "Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (OSPF, ISIS and BGP), this work will be done in conjunction with the appropriate WGs." The implication seems to be: ".. existing _routing_ protocols (OSPF, ISIS, and BGP)". Is PCE discovery, requiring extensions to existing non-routing protocols (e.g., DNS) off the table? I.e., the text seems to assume that "protocol" == "routing protocol". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 10 20:34: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 UAA22136; Mon, 10 Jan 2005 20:34:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoB8w-0008Jk-O0; Mon, 10 Jan 2005 20:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoAs2-00034m-Tn; Mon, 10 Jan 2005 20:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoArD-0002uG-MF; Mon, 10 Jan 2005 20:30:03 -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 UAA21855; Mon, 10 Jan 2005 20:30:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoB4v-0008Fa-AN; Mon, 10 Jan 2005 20:44:14 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoArA-0001AM-Ha; Tue, 11 Jan 2005 01:30:01 +0000 Date: Mon, 10 Jan 2005 17:29:52 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1165425845.20050110172952@psg.com> To: Pekka Savola Subject: Re: [Pce] Re: WG Review: Path Computation Element (pce) In-Reply-To: References: <200412231907.OAA09150@ietf.org> <008a01c4f44c$48e9a4e0$0301a8c0@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: pce@ietf.org, iesg@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin 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.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Pekka, Adrian- Pekka, first thanks for actually reviewing the charter and providing your comments. Reading is such a rare quality these days ;) The IESG discussed this last thursday. Inline comments below. >> IMHO the milestones give a clear prioritization. In these matters I would >> hope that we can depend on the chairs to ensure that an appropriate >> ordering is followed. The ADs will (of course) be watching. > This may be one approach, but builds on the WG chair being able to > convice the WG that the proposed priorization is in fact the right > one. This seems optimistic, as the WG participants are very likely > eager to jump to the solutions already :). > I've seen many WGs stumble because the charter did not restrict and > guide the steps of the WG well enough. Such a charter is easier for > the WG chairs as well because they have concrete levers they can pull > to justify working in a specific order. Both WG chairs and ADs were comfortable with using milestones as the means of prioritization. The IESG was also fine with this. > The text says: > "Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (OSPF, ISIS and BGP), this work will be done in > conjunction with the appropriate WGs." The IESG thought that my suggestion to tweak the wording a bit to say "(e.g. OSPF, ISIS, or BGP)" would address this problem as long as there's understanding that there's no such presumption, which is the case, I believe. Where we are with the charter now: the charter is tentantively approved, the secretariat expects the final text tweaks and a go-ahead from me, which is when they will send out the announcement. Alex _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Jan 12 16:06: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 QAA15870; Wed, 12 Jan 2005 16:06:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Copv9-0007xr-Br; Wed, 12 Jan 2005 16:20:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copag-0004be-QQ; Wed, 12 Jan 2005 15:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopHA-0002JM-Vj; Wed, 12 Jan 2005 15:39:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12287; Wed, 12 Jan 2005 15:39:31 -0500 (EST) Message-Id: <200501122039.PAA12287@ietf.org> From: The IESG To: IETF-Announce@ietf.org Date: Wed, 12 Jan 2005 15:39:31 -0500 Cc: pce@ietf.org Subject: [Pce] WG Action: Path Computation Element (pce) 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: 8f374d0786b25a451ef87d82c076f593 A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel JP Vasseur Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ 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 robustness 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 Thu Jan 13 07:08: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 HAA01146; Thu, 13 Jan 2005 07:08:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp40o-0001Px-9K; Thu, 13 Jan 2005 07:23:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3jP-0003Cd-H6; Thu, 13 Jan 2005 07:05:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp3bq-0001xM-Dk for pce@megatron.ietf.org; Thu, 13 Jan 2005 06:57: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 GAA00249 for ; Thu, 13 Jan 2005 06:57:46 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp3q3-0001B5-S7 for pce@ietf.org; Thu, 13 Jan 2005 07:12:32 -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 14FB4E0003BA; Thu, 13 Jan 2005 11:57:15 +0000 (GMT) Received: from Puppy ([212.43.203.220] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 11:57:14 +0000 Message-ID: <02bc01c4f967$2c65bff0$b4cb2bd4@Puppy> From: "Adrian Farrel" To: Date: Thu, 13 Jan 2005 10:50:55 -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: 13 Jan 2005 11:57:14.0991 (UTC) FILETIME=[05F1FFF0:01C4F967] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: acee@cisco.com Subject: [Pce] Fw: WG Last Call for "Extensions to OSPF for Advertising Optional Router" 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: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Folks, This draft has some interest to PCE. Please send any comments to the OSPF list or to Acee himself. Adrian ----- Original Message ----- From: "Acee Lindem" To: Sent: Saturday, January 08, 2005 3:31 AM Subject: WG Last Call for "Extensions to OSPF for Advertising Optional Router" > This the start of the Working Group Last Call for "Extensions to OSPF for > Advertising Optional Router" - draft-ietf-ospf-cap-05.txt. > All comments must be sent to the OSPF list by 12:00 AM EST on Monday, > January 24, 2005. > > > A URL for this Internet-draft is provided below: > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt > > Thanks, > Acee > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Jan 13 14:28:53 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 OAA06049; Thu, 13 Jan 2005 14:28:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAse-0003u0-P5; Thu, 13 Jan 2005 14:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpARk-0006G1-Qx; Thu, 13 Jan 2005 14:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpALM-0002zM-K5 for pce@megatron.ietf.org; Thu, 13 Jan 2005 14:09: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 OAA04444 for ; Thu, 13 Jan 2005 14:09:14 -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 1CpAZe-0003N3-1f for pce@ietf.org; Thu, 13 Jan 2005 14:24:02 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2005 11:12:10 -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 j0DJ8gjw024415; Thu, 13 Jan 2005 11:08:43 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-48.cisco.com [10.86.240.48]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA04021; Thu, 13 Jan 2005 11:08:41 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <90A0B610-6596-11D9-8C2F-000D93330B14@cisco.com> From: JP Vasseur Subject: Re: [Pce] contribution to charter item Date: Thu, 13 Jan 2005 14:08:53 -0500 To: "STEPHAN Emile RD-CORE-LAN" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Content-Type: multipart/mixed; boundary="===============0426043626==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============0426043626== Content-Type: multipart/alternative; boundary=Apple-Mail-19-634597836 --Apple-Mail-19-634597836 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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 --Apple-Mail-19-634597836 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: TimesMay 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 --Apple-Mail-19-634597836-- --===============0426043626== 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 --===============0426043626==-- From pce-bounces@ietf.org Sun Jan 16 12:56: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 MAA01756; Sun, 16 Jan 2005 12:56:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqEsi-000761-QM; Sun, 16 Jan 2005 13:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqEbP-00011Y-EQ; Sun, 16 Jan 2005 12:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqEZX-0008V3-RW for pce@megatron.ietf.org; Sun, 16 Jan 2005 12:52:19 -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 MAA01172 for ; Sun, 16 Jan 2005 12:52:16 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqEoP-0006xV-FH for pce@ietf.org; Sun, 16 Jan 2005 13:07:42 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id D94DFE00021B for ; Sun, 16 Jan 2005 17:51:35 +0000 (GMT) Received: from Puppy ([212.43.203.231] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Jan 2005 17:51:34 +0000 Message-ID: <00a201c4fbf4$2ca7e850$e7cb2bd4@Puppy> From: "Adrian Farrel" To: Date: Sun, 16 Jan 2005 17:48:53 -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: 16 Jan 2005 17:51:34.0777 (UTC) FILETIME=[05012690:01C4FBF4] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Subject: [Pce] Fw: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit FYI ----- Original Message ----- From: To: Sent: Friday, January 14, 2005 3:09 PM Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN > There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting > in Minneapolis, MN: > > February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions > > All initial Internet-Drafts (-00) must be submitted by Monday, February > 14th at 9:00 AM ET. > As always, all initial submissions (-00) with a filename beginning with > "draft-ietf" must be approved by the appropriate WG Chair before they > can be processed or announced. > WG Chair approval must be received by Monday, February 7th at 9:00 AM > ET. > > February 21st: Cutoff Date for Revised (i.e., -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (-01 and higher) must be submitted by > Monday, February 21st at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts directory > or announced, and will have to be resubmitted. Please do not wait until > the last minute to submit. The Secretariat will begin accepting > Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, > but may not post or announce them until Monday, March 14th. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Jan 24 10:16:05 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 KAA19951; Mon, 24 Jan 2005 10:16:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6DE-0007Yr-Vu; Mon, 24 Jan 2005 10:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct5tb-0001Ux-U1; Mon, 24 Jan 2005 10:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct5Y9-0002SO-De for pce@megatron.ietf.org; Mon, 24 Jan 2005 09:50: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 JAA16776 for ; Mon, 24 Jan 2005 09:50:39 -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 1Ct5of-0006VQ-Da for pce@ietf.org; Mon, 24 Jan 2005 10:07:46 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2005 07:58:42 +0000 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 j0OEo6Nt027953; Mon, 24 Jan 2005 06:50:06 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-92.cisco.com [10.86.240.92]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA26998; Mon, 24 Jan 2005 06:50:04 -0800 (PST) In-Reply-To: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <4359757A-6E17-11D9-8F15-000D93330B14@cisco.com> From: JP Vasseur Date: Mon, 24 Jan 2005 09:50:17 -0500 To: raymond zhang X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 X-Mailman-Approved-At: Mon, 24 Jan 2005 10:12:51 -0500 Cc: "Jerry , pce@ietf.org" Subject: [Pce] Re: [mpls] Mailing List for Path Computation Element (PCE) 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="===============1737026602==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 --===============1737026602== Content-Type: multipart/alternative; boundary=Apple-Mail-4--578001081 --Apple-Mail-4--578001081 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Raymond, Thanks for your comments - see in line, On Oct 12, 2004, at 5:10 PM, raymond zhang wrote: > > Hi Adrian, JP, Jerry, > > I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I > think this document has very well stated the architectural objectives > and need for a separate WG for this area. > > Also please find some minor comments below: > > - section 3. Definitions > > " Path Computation Element (PCE) is an entity that is capable of > computing a network path or route based on a network graph, and > applying > computational constraints. The PCE entity can be located within an > application" > > (RZ: I'd suggest some rewording here: The PCE entity is an application > process > that can be located on a network node or component, on an out-of- > network server, etc.) Good suggestion, changes done. > > - Page 4, first paragraph: > 1) Path computation is applicable in both intra-domain, inter-domain, > and inter-layer contexts. Inter-domain path computation may involve the > correlation of topology and routing information between domains. > Overlapping domains are not within the scope of this document. > In the inter-domain case, the domains may belong to a single or > multiple > > (RZ:"inter-layer contexts" is mentioned at the beginning of this > paragraph so it would be good to explain this a bit as did for > inter-domain) Text added: "Inter-layer path computation refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at such layers." > > - Page 4. 3) "Centralized computation model" ... There would (RZ: add > "be")... ok > - Page 6, 2nd paragraph: > (RZ: From SP's perspective, it is not a difficult thing to migrate a > legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane > supporting TE ext. So I dont seem to see a strong case for this...) > We do agree but we wanted to mention this case for the sake of exhaustiveness. That said, this could happen in some cases with "small" edge devices not supporting the TE extensions for which TE LSPs would be required. That said, again, not a strong and usual case. > - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say > on one hand this > scenario does not relay on loose hops, yet on the other hand PCE based > solution provides loose hops in the computed paths ?) Good catch, the text is indeed ambiguous - New Text: "This scenario suggests a solution that does not involve doing computation on the ingress router, and that does not rely on static loose hops configuration in which case optimal paths could hardly be achieved. A distinct PCE-based solution can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops." > > - Page 7, section 5.1. 5.1. Composite PCE > > "Figure 1 below shows the components of a typical composite PCE node > (that is, a router that also implements the PCE functionality) that > utilizes path computation. The routing protocol is used to exchange TE > information from which the TED is constructed. Service requests are > received by the node and converted into signaling requests" > > (RZ:it would be good to clarify between service requests to the PCE or > inter- > PCE requests and service requests to signal a TE-LSP request) ... > Some text added to clarify. > - Page 12, first paragraph (RZ: It would be probably more appropriate > to rename to this section to > "Service Request/Response Synchronization" vs. "TED Sync" in a > subsequent section. It may be more productive here in describing > service request/reponse sync of PCC-PCE and PCE-PCE > as part of the architectural discussion, rather than illustrating more > detailed > procedures since these procedures could be discussed in a detailed spec > document in which it may transform to something different.) Not entirely sure to see the section that you're referring to ? > > - page 13, 2nd paragrah: > "No assumption is made at this stage about whether the PCC-PCE and > PCE-PCE communication protocols are identical." > > (RZ: but I think it would be architectrually more scalable if they are > same, so are such comments are warranted here (same protocols for both > PCC-PCE/PCE-PCE...) in an arch doc ? > Thanks for your input - (With WG chair hat), this a WG item which will be discussed in the WG and has not been determined, thus this generic statement. Note that this does not have implication on the overall architecture. > - Section 6.8: (RZ: since this is an arch doc, does it imply that > implementation of either scheme would meet the arch framework > established here ?) > The PCE architecture ID indeed describes two possible types of PCE, namely "statefull" and "stateless" Note that this ID is "Informational" (see RFC2026): > - A general comment: there are a lot of very good, analytical > discussions in the document presenting different cases. It would be > good I think if the authors could provide some guidance in drawing up > some architecture recommendations after comparing/analyzing some of > these cases or simply say all cases presented in some of these > sections are considered valid architectural options ? > The latter is what we indeed target. I'm sure other more specific IDs will be proposed with applicability statement. Thanks a lot for your comments. JP. > Regards, > Raymond > > > > > > --Apple-Mail-4--578001081 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Raymond, Thanks for your comments - see in line, On Oct 12, 2004, at 5:10 PM, raymond zhang wrote: Hi Adrian, JP, Jerry, I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I think this document has very well stated the architectural objectives and need for a separate WG for this area. Also please find some minor comments below: - section 3. Definitions " Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The PCE entity can be located within an application" (RZ: I'd suggest some rewording here: The PCE entity is an application process that can be located on a network node or component, on an out-of- network server, etc.) Good suggestion, changes done. - Page 4, first paragraph: 1) Path computation is applicable in both intra-domain, inter-domain, and inter-layer contexts. Inter-domain path computation may involve the correlation of topology and routing information between domains. Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or multiple (RZ:"inter-layer contexts" is mentioned at the beginning of this paragraph so it would be good to explain this a bit as did for inter-domain) Text added: "Inter-layer path computation refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at such layers." - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... ok - Page 6, 2nd paragraph: (RZ: From SP's perspective, it is not a difficult thing to migrate a legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane supporting TE ext. So I dont seem to see a strong case for this...) We do agree but we wanted to mention this case for the sake of exhaustiveness. That said, this could happen in some cases with "small" edge devices not supporting the TE extensions for which TE LSPs would be required. That said, again, not a strong and usual case. - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on one hand this scenario does not relay on loose hops, yet on the other hand PCE based solution provides loose hops in the computed paths ?) Good catch, the text is indeed ambiguous - New Text: "This scenario suggests a solution that does not involve doing computation on the ingress router, and that does not rely on static loose hops configuration in which case optimal paths could hardly be achieved. A distinct PCE-based solution can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops." - Page 7, section 5.1. 5.1. Composite PCE "Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests are received by the node and converted into signaling requests" (RZ:it would be good to clarify between service requests to the PCE or inter- PCE requests and service requests to signal a TE-LSP request) ... Some text added to clarify. - Page 12, first paragraph (RZ: It would be probably more appropriate to rename to this section to "Service Request/Response Synchronization" vs. "TED Sync" in a subsequent section. It may be more productive here in describing service request/reponse sync of PCC-PCE and PCE-PCE as part of the architectural discussion, rather than illustrating more detailed procedures since these procedures could be discussed in a detailed spec document in which it may transform to something different.) Not entirely sure to see the section that you're referring to ? - page 13, 2nd paragrah: "No assumption is made at this stage about whether the PCC-PCE and PCE-PCE communication protocols are identical." (RZ: but I think it would be architectrually more scalable if they are same, so are such comments are warranted here (same protocols for both PCC-PCE/PCE-PCE...) in an arch doc ? Thanks for your input - (With WG chair hat), this a WG item which will be discussed in the WG and has not been determined, thus this generic statement. Note that this does not have implication on the overall architecture. - Section 6.8: (RZ: since this is an arch doc, does it imply that implementation of either scheme would meet the arch framework established here ?) The PCE architecture ID indeed describes two possible types of PCE, namely "statefull" and "stateless" Note that this ID is "Informational" (see RFC2026): - A general comment: there are a lot of very good, analytical discussions in the document presenting different cases. It would be good I think if the authors could provide some guidance in drawing up some architecture recommendations after comparing/analyzing some of these cases or simply say all cases presented in some of these sections are considered valid architectural options ? The latter is what we indeed target. I'm sure other more specific IDs will be proposed with applicability statement. Thanks a lot for your comments. JP. Regards, Raymond --Apple-Mail-4--578001081-- --===============1737026602== 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 --===============1737026602==-- From pce-bounces@ietf.org Fri Jan 28 22:53: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 WAA19528; Fri, 28 Jan 2005 22:53:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CujxX-0001lv-C0; Fri, 28 Jan 2005 23:11:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cujeo-0002fw-TO; Fri, 28 Jan 2005 22:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CujZn-0001TJ-Rg for pce@megatron.ietf.org; Fri, 28 Jan 2005 22:47:12 -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 WAA19207 for ; Fri, 28 Jan 2005 22:47:09 -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 1CujrG-0001ex-Cu for pce@ietf.org; Fri, 28 Jan 2005 23:05:14 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2005 20:56:07 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j0T3kbl2029716; Fri, 28 Jan 2005 19:46:38 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-92.cisco.com [10.86.240.92]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA09246; Fri, 28 Jan 2005 19:46:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Fri, 28 Jan 2005 22:46:46 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [Pce] Formation of a 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: , Content-Type: multipart/mixed; boundary="===============1677411385==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 --===============1677411385== Content-Type: multipart/alternative; boundary=Apple-Mail-72--185812059 --Apple-Mail-72--185812059 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Dear list members, With the objective of achieving some of our aggressive WG Milestones,=20= a design team has been formed, made of the following members: =A0Jean-Louis Le Roux (France Telecom) =A0Raymond Zhang (Infonet) =A0Durga Gangisetti (MCI) =A0Kenji Kumaki (KDDI) =A0Eiji Oki (NTT) =A0Jerry Ash (AT&T) =A0Igor Bryskin =A0Arthi Ayyangar (Juniper) =A0Dean Cheng (Cisco) =A0Alia Atlas (Avici) The design team is chartered to work on the following WG charter item: =A0 "Specification of a new communication protocol for use between a PCC=20 and a PCE, and between PCEs. A single protocol will be selected from=20 among candidates that include the existing protocols defined in other=20 WGs." =A0 The two main related Milestones are: =A0 Apr 05: Submit first draft of the PCE communication protocol=20 requirements Jul 05: Submit first draft of the PCE communication protocol=20 specification =A0 As usual, the work produced by the Design team is not exclusive and by=20= no means precludes any other individual to write other drafts.=20 Furthermore, as usual, comments to the produced drafts are highly=20 encouraged and additional contributors may join these drafts. We hope that once the drafts have reached a basic state of readiness we=20= will be able to move them within the working group at which point they=20= will be "owned" by the whole Working Group. Although it looks unrealistic to produce any IDs before the next IETF,=20= we would encourage some preliminary discussions (especially on the=20 requirements) during the next PCE WG meeting (presentation of a few=20 slides would be an option). =A0 JP and Adrian. --Apple-Mail-72--185812059 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear list members, With the objective of achieving some of our aggressive WG Milestones, a design team has been formed, made of the following members: =A0Jean-Louis Le Roux (France Telecom)=20 =A0Raymond Zhang (Infonet)=20 =A0Durga Gangisetti (MCI)=20 =A0Kenji Kumaki (KDDI)=20 =A0Eiji Oki (NTT)=20 =A0Jerry Ash (AT&T) =A0Igor Bryskin =A0Arthi Ayyangar (Juniper) =A0Dean Cheng (Cisco)=20 =A0Alia Atlas (Avici)=20 The design team is chartered to work on the following WG charter item: =A0 "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." =A0 The two main related Milestones are: =A0 Apr 05: Submit first draft of the PCE communication protocol requirements=20 Jul 05: Submit first draft of the PCE communication protocol specification=20 =A0 As usual, the work produced by the Design team is not exclusive and by no means precludes any other individual to write other drafts. Furthermore, as usual, comments to the produced drafts are highly encouraged and additional contributors may join these drafts. We hope that once the drafts have reached a basic state of readiness we will be able to move them within the working group at which point they will be "owned" by the whole Working Group. Although it looks unrealistic to produce any IDs before the next IETF, we would encourage some preliminary discussions (especially on the requirements) during the next PCE WG meeting (presentation of a few slides would be an option). =A0 JP and Adrian. --Apple-Mail-72--185812059-- --===============1677411385== 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 --===============1677411385==--