From mailman-bounces@ietf.org Fri Oct 1 05:40:04 2004 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 FAA10850 for ; Fri, 1 Oct 2004 05:40:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDK1x-0002qo-8u for pce-archive@ietf.org; Fri, 01 Oct 2004 05:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJPU-0003l1-QP for pce-archive@ietf.org; Fri, 01 Oct 2004 05:09:04 -0400 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: Fri, 01 Oct 2004 05:01:46 -0400 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 Sat Oct 2 04:29:36 2004 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 EAA03681; Sat, 2 Oct 2004 04:29:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDfPU-0004bH-JN; Sat, 02 Oct 2004 04:38:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDfEF-0001qp-D4; Sat, 02 Oct 2004 04:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDfBq-0007Dj-Ia for pce@megatron.ietf.org; Sat, 02 Oct 2004 04:24:26 -0400 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 EAA03409 for ; Sat, 2 Oct 2004 04:24:24 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDfKH-0004S6-O0 for pce@ietf.org; Sat, 02 Oct 2004 04:33:21 -0400 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 i928O5AT002596; Sat, 2 Oct 2004 17:24:05 +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 i928O4pA000048; Sat, 2 Oct 2004 17:24:04 +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 i928O4fL000045; Sat, 2 Oct 2004 17:24:04 +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 i928O4Kb016431; Sat, 2 Oct 2004 17:24:04 +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 i928O39C016418; Sat, 2 Oct 2004 17:24:03 +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 i928O3Sr010865; Sat, 2 Oct 2004 17:24:03 +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 i928O285020581; Sat, 2 Oct 2004 17:24:03 +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 i928O23e020578; Sat, 2 Oct 2004 17:24:02 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id RAA15989; Sat, 2 Oct 2004 17:24:02 +0900 (JST) Date: Sat, 02 Oct 2004 17:23:59 +0900 From: Eiji Oki To: JP Vasseur Subject: Re: [Pce] Fwd: Internet Draft for Publication In-Reply-To: <9CF1708C-0E42-11D9-BF82-000D93330B14@cisco.com> References: <9CF1708C-0E42-11D9-BF82-000D93330B14@cisco.com> Message-Id: <20041002172336.A208.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: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Hi JP, Ash, and Adrian, The architecture draft well clarifies what PCE is. I have several comments on the draft as follows. 1. LSP information in TED. It would be useful to clarify information in TED. I understand that section 1 describes the definition of TED and that TED is made by using IGP-TE or by other means. Information in TED includes not only contents that can be built from the distribution of IGP-TE, but LSP information as described in section 6.8. However, LSP information, which is not able to be collected by IGP, is not clarified in the draft. I suggest that contents of LSP information, such as LSP routes, the reserved bandwidth, and measured traffic volume passing through the LSP, be clarified. There are two reasons to add the LSP information. One is because the LSP information is required to perform re-optimization for MPLS LSPs. LSP re-optimization is described in Sections 4.4 and 7. I suggest that LSP information including measured traffic volume and LSP routes should be added in TED for LSP re-optimization. Otherwise, LSP re-optimization is not effectively performed according to traffic fluctuation. The other reason is because LSP information is needed to reconfigure virtual network topology (VNT). Lower-region LSPs such as optical paths form a network topology, which is used for routing of higher-region traffic such as IP traffic. The network topology formed by lower-region LSPs is called a virtual network topology (VNT). I also suggest that more description be added on how LSP information might be collected and how this information could be synchronized with the conventional TED. TED information comes from different sources such as OSPF-TE, NetFlow, SNMP, GTEP, XML etc. or TED information is obtained by making another new protocls or by extending IGP, PCC-PCE communication protocol. Therefore, there is an issue whether TED information is managed with a single database or multiple database. Several methods for TED synchronization can be considered. a) Different TED database. One database often accesses the other database for TED synchronization. b) The same database. The database often is updated when LSP information is changed. Method b would be better in terms of accuracy of TED synchronization. In terms of node processing load, more discussions are needed. 2. TED synchronization As described above, TED synchronization is important. I suggest that "TED synchronization: speed with which synchronization is achieved, and the impact of the synchronization process on the data flows in the network." be added as evaluation metric in section 7. Thank you. Eiji On Fri, 24 Sep 2004 11:58:44 -0400 JP Vasseur wrote: > Hi, > > One of the main action point required by Alex after the PCE BOF held in > San Diego was to produce a PCE architecture document whose aim was to > describe various possible PCE architectures and their components, > provides application examples, and clarify the scope of the > applicability of such path computation techniques. > > In particular, PCE-based path computation would not replace existing > methods but could be used in some environments and for specific > applications. > > In order to move forward, comments to this draft are very welcome. > > Adrian and I also received various emails mentioning that other PCE > related IDs were on their way, so please authors, try to publish them > prior to the next IETF so as to have enough time for comments and > discussion. > > JP. > > > Begin forwarded message: > > > From: grash@hello.mt.att.com > > Date: September 24, 2004 11:28:43 AM EDT > > To: internet-drafts@ietf.org > > Cc: adrian@olddog.co.uk, gash@att.com, grash@hello.mt.att.com, > > jpv@cisco.com > > Subject: Internet Draft for Publication > > > > > > To: Internet Drafts Editor > > > > Please publish the attached Internet Draft: > > > > draft-ash-pce-architecture-00.txt> > > > > Please announce the draft to the CCAMP working group. > > > > The attached file is in ASCII text. > > > > Thank you very much, > > Jerry Ash > > ----------------------------------------------------------------------- > > ----- > > Gerald R. (Jerry) Ash > > AT&T Labs > > Room MT D5-2A01 > > 200 Laurel Avenue > > Middletown, NJ 07748-4801 > > U.S.A. > > Telephone 732-420-4578 > > Fax 732-368-8659 > > E-mail gash@att.com > > ----------------------------------------------------------------------- > > ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Oct 6 09:43:40 2004 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 JAA25702; Wed, 6 Oct 2004 09:43:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCEW-0003DH-AH; Wed, 06 Oct 2004 09:53:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFC00-0008D5-8z; Wed, 06 Oct 2004 09:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBwZ-0007ZU-5h for pce@megatron.ietf.org; Wed, 06 Oct 2004 09:34:59 -0400 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 JAA24760 for ; Wed, 6 Oct 2004 09:34:56 -0400 (EDT) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFC60-0002Zm-Sp for pce@ietf.org; Wed, 06 Oct 2004 09:44:48 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i96DY3Af017619 for ; Wed, 6 Oct 2004 08:34:23 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.1.006) id 414DAE590036648E; Wed, 6 Oct 2004 09:34:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.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] Fwd: Internet Draft for Publication Date: Wed, 6 Oct 2004 08:34:20 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE29D@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Fwd: Internet Draft for Publication Thread-Index: AcSoWTFuBXB7WcKGSoOTcexbQ/9zeQDR5EzQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Eiji Oki" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Hi Eiji, Thanks for your comments: > The architecture draft well clarifies what PCE is. > I have several comments on the draft as follows.=20 >=20 > 1. LSP information in TED.=20 >=20 > It would be useful to clarify information in TED.=20 >=20 > I understand that section 1 describes the definition of TED=20 > and that TED is made by using IGP-TE or by other means.=20 > Information in TED includes not only contents that can be built=20 > from the distribution of IGP-TE, but LSP information as described in > section 6.8. However, LSP information, which is not able to=20 > be collected by IGP, is not clarified in the draft. LSP information from sources other than the IGP is discussed in Section 6.7. The scope of such information could be large. Do you have suggestions as to which information should be clarified? =20 > I suggest that contents of LSP information, such as LSP routes, the > reserved bandwidth, and measured traffic volume passing=20 > through the LSP, be clarified.=20 >=20 > There are two reasons to add the LSP information. One is because the LSP > information is required to perform re-optimization for MPLS > LSPs. LSP re-optimization is described in Sections 4.4 and 7. I suggest > that LSP information including measured traffic volume and LSP routes > should be added in TED for LSP re-optimization. Otherwise,=20 > LSP re-optimization is not effectively performed according to traffic > fluctuation. >=20 > The other reason is because LSP information is needed to reconfigure > virtual network topology (VNT). Lower-region LSPs such as optical paths > form a network topology, which is used for routing of higher-region > traffic such as IP traffic. The network topology formed by lower-region > LSPs is called a virtual network topology (VNT). Sounds reasonable in general. However, several LSP attributes are listed in Section 6.6 -- what additional attributes, if any, are needed? =20 > I also suggest that more description be added on how LSP information > might be collected and how this information could be synchronized with > the conventional TED. Collection of LSP information is discussed in several places and synchronization is discussed in Section 6.7 -- anything specific to suggest be added? > TED information comes from different sources such as OSPF-TE, NetFlow,=20 > SNMP, GTEP, XML etc. or TED information is obtained by making another > new protocols or by extending IGP, PCC-PCE communication protocol. > Therefore, there is an issue whether TED information is > managed with a single database or multiple database. Several methods for > TED synchronization can be considered.=20 > =20 > a) Different TED database. One database often accesses the other=20 > database for TED synchronization.=20 > b) The same database. The database often is updated when LSP=20 > information is changed.=20 >=20 > Method b would be better in terms of accuracy of TED synchronization. > In terms of node processing load, more discussions are needed. The tradeoffs of a) and b) are discussed in Section 6.7 on synchronization, and elsewhere in the document. Distributed and centralized PCE architecture alternatives are identified and allowed within the architecture -- no judgment is made on which is preferred. Do you have any specific additions you would like to suggest (if so in which Section)? =20 > 2. TED synchronization >=20 > As described above, TED synchronization is important.=20 > I suggest that "TED synchronization: speed with which synchronization is > achieved, and the impact of the synchronization process on the data > flows in the network." be added as evaluation metric in section 7.=20 OK. These would augment the last item in Section 7 regarding synchronization: "- Ability to maintain accurate synchronization between TED and network topology and resource states." Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Oct 7 19:08:57 2004 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 TAA08350; Thu, 7 Oct 2004 19:08:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhXP-0003Y5-Ld; Thu, 07 Oct 2004 19:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhGt-0003K9-WB; Thu, 07 Oct 2004 19:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFhF8-0002Gy-RC for pce@megatron.ietf.org; Thu, 07 Oct 2004 19:00:14 -0400 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 TAA07440 for ; Thu, 7 Oct 2004 19:00:11 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhOv-0002y8-Hy for pce@ietf.org; Thu, 07 Oct 2004 19:10:22 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 00:58:15 +0200 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] RE: Internet Draft Date: Fri, 8 Oct 2004 00:58:12 +0200 Message-ID: Thread-Topic: [Pce] RE: Internet Draft Thread-Index: AcSiT2U1CVJLSdMwQTaPO+LEh3sLYAAKCO7AApFR8LA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Ash, Gerald R \(Jerry\), ALABS" , X-OriginalArrivalTime: 07 Oct 2004 22:58:15.0780 (UTC) FILETIME=[2122A240:01C4ACC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Hi Jerry, Adrian, Jean-Philippe, and all, Thanks for this architecture draft that is really relevant, and will = help structuring the PCE standardization effort. It catches quite well all motivations and requirements addressed by SPs = during SD meeting, and clarifies the different use cases. One more comment: As regards the interactions with the routing plane, = the draft currently focuses on the IGP. It would be good to mention, in = next revision, the possible interactions with BGP (for inter-AS path = computation). Regards, JL >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de Ash, Gerald=20 >R (Jerry), ALABS >Envoy=E9 : vendredi 24 septembre 2004 22:50 >=C0 : pce@ietf.org >Objet : [Pce] RE: Internet Draft > > >All, > >The I-D is now available at=20 >http://www.ietf.org/internet-drafts/draft->ash-pce-architecture-00.txt. > >Please read and comment. > >Thanks, >Jerry > >________________________________ > >From: JP Vasseur [mailto:jvasseur@cisco.com]=20 >Sent: Friday, September 24, 2004 11:59 AM >To: pce@ietf.org >Cc: Adrian Farrel; Ash, Gerald R (Jerry), ALABS >Subject: Fwd: Internet Draft for Publication=20 > > >Hi,=20 > >One of the main action point required by Alex after the PCE=20 >BOF held in San Diego was to produce a PCE architecture=20 >document whose aim was to describe various possible PCE=20 >architectures and their components, provide application=20 >examples, and clarify the scope of the applicability of such=20 >path computation techniques.=20 > >In particular, PCE-based path computation would not replace=20 >existing methods but could be used in some environments and=20 >for specific applications.=20 > >In order to move forward, comments to this draft are very welcome.=20 > >Adrian and I also received various emails mentioning that=20 >other PCE related IDs were on their way, so please authors,=20 >try to publish them prior to the next IETF so as to have=20 >enough time for comments and discussion.=20 > >JP=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 Thu Oct 7 21:39:39 2004 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 VAA24351; Thu, 7 Oct 2004 21:39:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFjtG-0005AD-Oe; Thu, 07 Oct 2004 21:49:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjiG-0001Ur-P2; Thu, 07 Oct 2004 21:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjgW-0001BS-4i for pce@megatron.ietf.org; Thu, 07 Oct 2004 21:36:40 -0400 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 VAA24234 for ; Thu, 7 Oct 2004 21:36:37 -0400 (EDT) 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 1CFjqJ-0004yy-R2 for pce@ietf.org; Thu, 07 Oct 2004 21:46:49 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2004 18:41:23 -0700 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 i981a3wp008620; Thu, 7 Oct 2004 18:36:03 -0700 (PDT) Received: from [66.189.47.89] (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA28487; Thu, 7 Oct 2004 18:36:04 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6B21D1A8-18CA-11D9-840C-000D93330B14@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: RE : [Pce] RE: Internet Draft Date: Thu, 7 Oct 2004 21:36:04 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Hi Jean-Louis, On Oct 7, 2004, at 6:58 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Jerry, Adrian, Jean-Philippe, and all, > > Thanks for this architecture draft that is really relevant, and will =20= > help structuring the PCE > standardization effort. > It catches quite well all motivations and requirements addressed by =20= > SPs during SD meeting, > and clarifies the different use cases. > Thanks for your comment Jean-Louis, this was an important action items =20= legitimately requested by Alex. > One more comment: As regards the interactions with the routing plane, =20= > the draft currently focuses on the IGP. It would be good to mention, =20= > in next revision, the possible interactions with BGP (for inter-AS =20 > path computation). > Good point indeed, this will be added to the next revision for the =20 inter-AS case. JP. > Regards, > > JL > >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] De la part de Ash, Gerald >> R (Jerry), ALABS >> Envoy=E9 : vendredi 24 septembre 2004 22:50 >> =C0 : pce@ietf.org >> Objet : [Pce] RE: Internet Draft >> >> >> All, >> >> The I-D is now available at >> http://www.ietf.org/internet-drafts/draft->ash-pce-architecture=20 >> -00.txt. >> >> Please read and comment. >> >> Thanks, >> Jerry >> >> ________________________________ >> >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Friday, September 24, 2004 11:59 AM >> To: pce@ietf.org >> Cc: Adrian Farrel; Ash, Gerald R (Jerry), ALABS >> Subject: Fwd: Internet Draft for Publication >> >> >> Hi, >> >> One of the main action point required by Alex after the PCE >> BOF held in San Diego was to produce a PCE architecture >> document whose aim was to describe various possible PCE >> architectures and their components, provide application >> examples, and clarify the scope of the applicability of such >> path computation techniques. >> >> In particular, PCE-based path computation would not replace >> existing methods but could be used in some environments and >> for specific applications. >> >> In order to move forward, comments to this draft are very welcome. >> >> Adrian and I also received various emails mentioning that >> other PCE related IDs were on their way, so please authors, >> try to publish them prior to the next IETF so as to have >> enough time for comments and discussion. >> >> JP >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 8 00:25:36 2004 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 AAA05419; Fri, 8 Oct 2004 00:25:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmTt-0005Nz-Q7; Fri, 08 Oct 2004 00:35:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmCu-0008Gx-Ey; Fri, 08 Oct 2004 00:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmAw-0007Ud-Lx for pce@megatron.ietf.org; Fri, 08 Oct 2004 00:16:14 -0400 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 AAA04696 for ; Fri, 8 Oct 2004 00:16:10 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmKa-0005Db-Vr for pce@ietf.org; Fri, 08 Oct 2004 00:26:24 -0400 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 i984FZw1008764; Fri, 8 Oct 2004 13:15:35 +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 i984FZNN018372; Fri, 8 Oct 2004 13:15:35 +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 i984FYrT018359; Fri, 8 Oct 2004 13:15:34 +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 i984FYlf020092; Fri, 8 Oct 2004 13:15:34 +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 i984FYAp020089; Fri, 8 Oct 2004 13:15:34 +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 i984FX9L021856; Fri, 8 Oct 2004 13:15:33 +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 i984FXJt026809; Fri, 8 Oct 2004 13:15:33 +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 i984FX6O026806; Fri, 8 Oct 2004 13:15:33 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA29105; Fri, 8 Oct 2004 13:15:31 +0900 (JST) Date: Fri, 08 Oct 2004 13:15:29 +0900 From: Eiji Oki To: gash@att.com Subject: Re: [Pce] Fwd: Internet Draft for Publication In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE29D@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA060CE29D@KCCLUST06EVS1.ugd.att.com> Message-Id: <20041008131426.22E5.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: 0.0 (/) 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 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: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi Jerry, Thank you for your comments. Please see inlines. > > The architecture draft well clarifies what PCE is. > > I have several comments on the draft as follows. > > > > 1. LSP information in TED. > > > > It would be useful to clarify information in TED. > > > > I understand that section 1 describes the definition of TED > > and that TED is made by using IGP-TE or by other means. > > Information in TED includes not only contents that can be built > > from the distribution of IGP-TE, but LSP information as described in > > section 6.8. However, LSP information, which is not able to > > be collected by IGP, is not clarified in the draft. > > LSP information from sources other than the IGP is discussed in Section > 6.7. The scope of such information could be large. Do you have > suggestions as to which information should be clarified? I think that it would be better to include LSP routes, the reserved bandwidth, and measured traffic volume passing through the LSP, which are not included in IGP-TE information. > > > I suggest that contents of LSP information, such as LSP routes, the > > reserved bandwidth, and measured traffic volume passing > > through the LSP, be clarified. > > > > There are two reasons to add the LSP information. One is because the > LSP > > information is required to perform re-optimization for MPLS > > LSPs. LSP re-optimization is described in Sections 4.4 and 7. I > suggest > > that LSP information including measured traffic volume and LSP routes > > should be added in TED for LSP re-optimization. Otherwise, > > LSP re-optimization is not effectively performed according to traffic > > fluctuation. > > > > The other reason is because LSP information is needed to reconfigure > > virtual network topology (VNT). Lower-region LSPs such as optical > paths > > form a network topology, which is used for routing of higher-region > > traffic such as IP traffic. The network topology formed by > lower-region > > LSPs is called a virtual network topology (VNT). > > Sounds reasonable in general. However, several LSP attributes are > listed in Section 6.6 -- what additional attributes, if any, are needed? > Yes, several attributes are listed. However, it seems to be fixed values that are determined when an LSP is established. I suggest that changeable values according to traffic situation, LSP routes and measured traffic volume passing through the LSP. > > I also suggest that more description be added on how LSP information > > might be collected and how this information could be synchronized with > > the conventional TED. > > Collection of LSP information is discussed in several places and > synchronization is discussed in Section 6.7 -- anything specific to > suggest be added? > > > TED information comes from different sources such as OSPF-TE, > NetFlow, > > SNMP, GTEP, XML etc. or TED information is obtained by making another > > new protocols or by extending IGP, PCC-PCE communication protocol. > > Therefore, there is an issue whether TED information is > > managed with a single database or multiple database. Several methods > for > > TED synchronization can be considered. > > > > a) Different TED database. One database often accesses the other > > database for TED synchronization. > > b) The same database. The database often is updated when LSP > > information is changed. > > > > Method b would be better in terms of accuracy of TED synchronization. > > In terms of node processing load, more discussions are needed. > > The tradeoffs of a) and b) are discussed in Section 6.7 on > synchronization, and elsewhere in the document. Distributed and > centralized PCE architecture alternatives are identified and allowed > within the architecture -- no judgment is made on which is preferred. Yes, I agree with you. > Do you have any specific additions you would like to suggest (if so in > which Section)? > > > 2. TED synchronization > > > > As described above, TED synchronization is important. > > I suggest that "TED synchronization: speed with which synchronization > is > > achieved, and the impact of the synchronization process on the data > > flows in the network." be added as evaluation metric in section 7. > > OK. These would augment the last item in Section 7 regarding > synchronization: > "- Ability to maintain accurate synchronization between TED and network > topology and resource states." I would like to mean "quick" synchronization in evaluation metric. Thank you. Eiji _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 8 08:19:11 2004 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 IAA18829; Fri, 8 Oct 2004 08:19:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtsE-0005OX-Vl; Fri, 08 Oct 2004 08:29:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFtgW-0007bf-Cu; Fri, 08 Oct 2004 08:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFtZj-0006UG-7U for pce@megatron.ietf.org; Fri, 08 Oct 2004 08:10:19 -0400 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 IAA18132 for ; Fri, 8 Oct 2004 08:10:18 -0400 (EDT) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtjd-0005F3-8m for pce@ietf.org; Fri, 08 Oct 2004 08:20:33 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i98C99e9023184 for ; Fri, 8 Oct 2004 08:09:47 -0400 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.1.006) id 414DAE59003E115B; Fri, 8 Oct 2004 08:09:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.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] Fwd: Internet Draft for Publication Date: Fri, 8 Oct 2004 07:09:46 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE2A4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Fwd: Internet Draft for Publication Thread-Index: AcSs7YhX+tvGof2tSx6xm9rQRGvGZgAQEQ4g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Eiji Oki" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Hi Eiji, > > > I understand that section 1 describes the definition of TED=20 > > > and that TED is made by using IGP-TE or by other means.=20 > > > Information in TED includes not only contents that can be built=20 > > > from the distribution of IGP-TE, but LSP information as described in > > > section 6.8. However, LSP information, which is not able to=20 > > > be collected by IGP, is not clarified in the draft. > > LSP information from sources other than the IGP is discussed in Section > > 6.7. The scope of such information could be large. Do you have > > suggestions as to which information should be clarified? =20 > I think that it would be better to include LSP routes,=20 > the reserved bandwidth, and measured traffic volume passing=20 > through the LSP, which are not included in IGP-TE information. OK, we'll include in the next update. > > > TED synchronization is important. I suggest that "TED=20 > > > synchronization: speed with which synchronization is > > > achieved, and the impact of the synchronization process=20 > > > on the data flows in the network." be added as=20 > > > evaluation metric in section 7.=20 > > OK. These would augment the last item in Section 7 regarding > > synchronization: > > "- Ability to maintain accurate synchronization between TED=20 > > and network topology and resource states." > I would like to mean "quick" synchronization in evaluation metric. Agreed, we'll add your suggested evaluation metrics in the next update: - speed with which synchronization is achieved - impact of the synchronization process on the data flows in the network Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 8 18:02:43 2004 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 SAA21981; Fri, 8 Oct 2004 18:02:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2z2-00069H-MR; Fri, 08 Oct 2004 18:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2jh-0002yg-8Y; Fri, 08 Oct 2004 17:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1wJ-0007X0-An; Fri, 08 Oct 2004 17:06:11 -0400 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 RAA16100; Fri, 8 Oct 2004 17:06:09 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG26I-0004OV-AI; Fri, 08 Oct 2004 17:16:30 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Oct 2004 17:05:40 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i98L5aED015523; Fri, 8 Oct 2004 17:05:36 -0400 (EDT) From: "Zafar Ali" To: Date: Fri, 8 Oct 2004 17:05:35 -0400 Message-ID: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 X-Mailman-Approved-At: Fri, 08 Oct 2004 17:57:11 -0400 Cc: ccamp@ops.ietf.org, mpls@ietf.org, jpv@cisco.com Subject: [Pce] Path Computation Element (PCE) Architecture and mailing list, 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="===============0529533204==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c This is a multi-part message in MIME format. --===============0529533204== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4AD59.08795340" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Jerry, JP, et al,=20 =20 Thanks for putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), = I found it very useful in scoping PCE WG and applicability of PCE in MPLS/ GMPLS TE networks. In the following I have a few questions/ comments = about this ID.=20 =20 I would also like to request about what would be a tentative agenda for = PCE BOF Part II in DC? I think the discussion in SD went very well in favor = of PCE WG, pending this architecture ID. What is the present plan of = record?=20 =20 - What did you meant by "the level of robustness of the path resources", = in PCC-PCE communication? I am expecting that the client can also specify = an exclude list, include list (this is in addition of SRLG to include/ exclude). =20 =20 - Can you please elaborate more on advantages of Stateful PCE and what = are the pits fall of using Stateful PCE in a distributed PCE environment. = You have information about Out-of-band TED synchronization but I am thinking there is some complexity involved in such mechanism and stateful PCE in = a distributed PCE setup. More description on the applicability of Stateful = PCE & Out-of-band TED synchronization would be useful to better scope core = vs.. advanced features of PCE.=20 =20 - When PCE is distributed, are there any considerations in path = computation (minimum guidelines, like constraints based shortest path based on the specified optimization criteria, optimization criteria does not change = for the same setup when multiple PCE are involved in path computation, etc.) = to make Path Computations in a distributed PCE scheme, that you think we = need to add to the text of this document.=20 =20 - When a number of disjoint paths are required, we need a mechanism to specify if near disjoint Paths are acceptable (but this is need not to = be in architecture doc). =20 =20 The rest of the document look very good to me.=20 =20 Regards... Zafar =20 ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi = Adrian, Jerry,=20 JP, et al,
 
Thanks for=20 putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.t= xt),=20 I found it very useful in scoping PCE WG and applicability of PCE in = MPLS/ GMPLS=20 TE networks. In the following I have a few questions/ comments = about this=20 ID.
 
I = would also like to=20 request about what would be a tentative agenda for PCE BOF Part II in = DC? I=20 think the discussion in SD went very well in favor of PCE WG, pending = this=20 architecture ID. What is the present plan of record? =
 
- What = did you meant=20 by "the level of robustness of the path resources", in PCC-PCE = communication? I=20 am expecting that the client can also specify an exclude list, include = list=20 (this is in addition of SRLG to include/ exclude).=20  
 
- Can = you please=20 elaborate more on advantages of Stateful PCE and what are the pits fall = of using=20 Stateful PCE in a distributed PCE environment. You have information = about=20 Out-of-band TED synchronization but I am thinking there is some = complexity=20 involved in such mechanism and stateful PCE in a distributed PCE setup. = More=20 description on the applicability of Stateful PCE & Out-of-band TED=20 synchronization would be useful to better scope core vs.. advanced = features of=20 PCE.
 
- When = PCE is=20 distributed, are there any considerations in path computation (minimum=20 guidelines, like constraints based shortest path based on the specified=20 optimization criteria, optimization criteria does not change for the = same setup=20 when multiple PCE are involved in path computation, etc.) to make Path=20 Computations in a distributed PCE scheme, that you think we need to add = to the=20 text of this document.
 
- When = a number of=20 disjoint paths are required, we need a mechanism to specify if near = disjoint Paths are acceptable (but this is need not to be in = architecture=20 doc).  
 
The = rest of the=20 document look very good to me.
 
Regards... = Zafar
 
------=_NextPart_000_0008_01C4AD59.08795340-- --===============0529533204== 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 --===============0529533204==-- From pce-bounces@ietf.org Fri Oct 8 18:35:04 2004 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 SAA25614; Fri, 8 Oct 2004 18:35:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3UM-0006oK-KF; Fri, 08 Oct 2004 18:45:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3GJ-0004VB-FL; Fri, 08 Oct 2004 18:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Dd-0003IW-Dj for pce@megatron.ietf.org; Fri, 08 Oct 2004 18:28:09 -0400 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 SAA25153 for ; Fri, 8 Oct 2004 18:28:07 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3Nd-0006fw-GI for pce@ietf.org; Fri, 08 Oct 2004 18:38:29 -0400 Received: from du-069-0166.access.clara.net ([217.158.132.166] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CG3Db-000Cpx-Dw for pce@ietf.org; Fri, 08 Oct 2004 23:28:08 +0100 Message-ID: <023301c4ad86$24061da0$21849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 8 Oct 2004 23:28:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Subject: [Pce] Fw: Path Computation Element (PCE) Architecture and mailing list, 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Forwarded mail from Zafar Ali. The mail list server is not functioning optimally! Adrian ----- Original Message ----- From: "Zafar Ali" To: Cc: "'Adrian Farrel'" ; "'Ash, Gerald R (Jerry), ALABS'" ; ; ; ; Sent: Friday, October 08, 2004 10:05 PM Subject: Path Computation Element (PCE) Architecture and mailing list, Hi Adrian, Jerry, JP, et al, Thanks for putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I found it very useful in scoping PCE WG and applicability of PCE in MPLS/ GMPLS TE networks. In the following I have a few questions/ comments about this ID. I would also like to request about what would be a tentative agenda for PCE BOF Part II in DC? I think the discussion in SD went very well in favor of PCE WG, pending this architecture ID. What is the present plan of record? - What did you meant by "the level of robustness of the path resources", in PCC-PCE communication? I am expecting that the client can also specify an exclude list, include list (this is in addition of SRLG to include/ exclude). - Can you please elaborate more on advantages of Stateful PCE and what are the pits fall of using Stateful PCE in a distributed PCE environment. You have information about Out-of-band TED synchronization but I am thinking there is some complexity involved in such mechanism and stateful PCE in a distributed PCE setup. More description on the applicability of Stateful PCE & Out-of-band TED synchronization would be useful to better scope core vs.. advanced features of PCE. - When PCE is distributed, are there any considerations in path computation (minimum guidelines, like constraints based shortest path based on the specified optimization criteria, optimization criteria does not change for the same setup when multiple PCE are involved in path computation, etc.) to make Path Computations in a distributed PCE scheme, that you think we need to add to the text of this document. - When a number of disjoint paths are required, we need a mechanism to specify if near disjoint Paths are acceptable (but this is need not to be in architecture doc). The rest of the document look very good to me. Regards... Zafar _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 8 18:41:53 2004 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 SAA25863; Fri, 8 Oct 2004 18:41:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3ax-0006u4-G3; Fri, 08 Oct 2004 18:52:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Mh-0005u0-2t; Fri, 08 Oct 2004 18:37:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3GP-0004a7-49 for pce@megatron.ietf.org; Fri, 08 Oct 2004 18:31:02 -0400 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 SAA25346 for ; Fri, 8 Oct 2004 18:30:58 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3QO-0006jp-JB for pce@ietf.org; Fri, 08 Oct 2004 18:41:21 -0400 Received: from du-069-0166.access.clara.net ([217.158.132.166] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CG3GK-000D6b-D1; Fri, 08 Oct 2004 23:30:58 +0100 Message-ID: <023f01c4ad86$87e2d7f0$21849ed9@Puppy> From: "Adrian Farrel" To: "Zafar Ali" , References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> Date: Fri, 8 Oct 2004 23:31:11 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: jpv@cisco.com Subject: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, 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: , Content-Type: multipart/mixed; boundary="===============1819739162==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 This is a multi-part message in MIME format. --===============1819739162== Content-Type: multipart/alternative; boundary="----=_NextPart_000_023C_01C4AD8E.E52401C0" This is a multi-part message in MIME format. ------=_NextPart_000_023C_01C4AD8E.E52401C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, [Recipients trimmed to leave out the MPLS and CCAMP mailing lists.] > Thanks for putting the PCE Architecture document > = (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), > I found it very useful in scoping PCE WG and applicability of PCE in=20 > MPLS/GMPLS TE networks. In the following I have a few questions/ > comments about this ID.=20 =20 > I would also like to request about what would be a tentative agenda > for PCE BOF Part II in DC? I think the discussion in SD went very=20 > well in favor of PCE WG, pending this architecture ID. What is the > present plan of record?=20 Yup, we have requested a BOF for Washington DC and hopefully this=20 will appear on the meta-agenda soon. In order to request a BOF you must supply the intended meeting agenda, and we have done. I will=20 send separate mails to the list to cover the agenda and the proposed charter. (Thanks for triggering me to do this!) > - What did you meant by "the level of robustness of the path > resources", in PCC-PCE communication? I am expecting that=20 > the client can also specify an exclude list, include list=20 > (this is in addition of SRLG to include/exclude). =20 This is in section 6.6. Exclusions are covered by the bullet point: - resources, resource affinities and shared resource link=20 groups (SRLGs) to use/avoid The point you are asking about: - the level of robustness of the path resources covers a qualatative assessment of the vulnerability or fragility of the = resources that may be used. For example, one might grade resources based = on empirical evidence (mean time between failures), on known risks = (there is major building work going on near this conduit), or on = prejudice (vendor X's software is always crashing). A PCC could request = that only robust resources be used, or allow any resource. Of course, this information does not comprise part of the TE information = advertise by IGPs. It must come from somewhere else. Note that the likelihood of being preempted is also somewhat computable = based on past experience and current network conditions. > - Can you please elaborate more on advantages of Stateful > PCE and what are the pits fall of using Stateful PCE in > a distributed PCE environment. You have information about > Out-of-band TED synchronization but I am thinking there=20 > is some complexity involved in such mechanism and stateful > PCE in a distributed PCE setup. More description on the=20 > applicability of Stateful PCE & Out-of-band TED=20 > synchronization would be useful to better scope core vs.. > advanced features of PCE.=20 =20 Good points. We need to flesh this out a little. Eiji Oki has been = raising similar questions because he sees a strong benefit in knowing = what LSPs exist in the system and where they run. A useful application would be placing a high priority LSP in a crowded = network such that it preempted as few other LSPs as possible (note that = preempting 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 the = Virtual Network Topolgy (see the MRN draft). It is helpful to understand = which other LSPs exist in the network in order to decide how to manage = the FAs that exist or need to be set up. However, as you note, the maintenance of such a stateful database is = non-trivial. Actually, that isn't quite true! If there is a single PCE = for the whole network, stateful PCE is almost a simple matter of = remembering all of the LSPs that you have computed - if you could = guarantee that the LSPs were actually set up, and know when they were = torn down... As the number of PCEs increases you might go through a stage where the = PCEs synchronize state by communicating with each other. But, when LSPs = are set up using computation performed all over the network, the problem = becomes larger and more complex. This is clearly a need to understand the cost-benefit analysis for this = type of proposal. if the need is great enough a solution will be found = whatever the cost. However, if the solution is a huge drain on the = network and the function doesn't buy much... So this is a good area for further discussion. > - When PCE is distributed, are there any considerations > in path computation (minimum guidelines, like constraints > based shortest path based on the specified optimization=20 > criteria, optimization criteria does not change for the > same setup when multiple PCE are involved in path=20 > computation, etc.) to make Path Computations in a=20 > distributed PCE scheme, that you think we need to add to > the text of this document.=20 I'm not clear what you asking. If you mean "is there any notable difference in service to the PCC?", = then there are three cases to consider. 1. Cooperative mode is used.=20 In this case we have the text (section 5.4) Note that a PCC cannot see the difference between centralized computation, and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more=20 than one PCE. This is intended to imply that the PCC gets the same service. 2. PCC must make a choice between distributed PCEs It is clearly important that the PCC knows the properties of the available PCEs so that it can make an informed choice. However, there is also an option that, provided the PCC expresses its requirements correctly, its PCE will pass a request to another PCE to make sure that the desired service is available. 3. Will different PCCs get the same service? Yes and no. Really the question boils down to quesiton 2. If my ramblings don't answer your question, can I suggest that you = supply some text for inclusion in the draft. The architecture is as much = your draft as anyone else's! > - When a number of disjoint paths are required, we need a=20 > mechanism to specify if near disjoint Paths are acceptable > (but this is need not to be in architecture doc). =20 Agree on both counts. There are a large number of types and grades of = dijointedness. =20 > The rest of the document look very good to me.=20 Very kind of you to say so! Regards, Adrian ------=_NextPart_000_023C_01C4AD8E.E52401C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Zafar,

[Recipients trimmed = to leave out=20 the MPLS and CCAMP mailing lists.]

> Thanks for putting the = PCE=20 Architecture document
>=20 (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt),<= BR>>=20 I found it very useful in scoping PCE WG and applicability of PCE in =
>=20 MPLS/GMPLS TE networks. In the following I have a few questions/
> = comments about this ID.
 
> I would also like to request = about=20 what would be a tentative agenda
> for PCE BOF Part II in DC? I = think the=20 discussion in SD went very
> well in favor of PCE WG, pending = this=20 architecture ID. What is the
> present plan of record? =

Yup, we=20 have requested a BOF for Washington DC and hopefully this
will = appear on the=20 meta-agenda soon. In order to request a BOF you
must supply the = intended=20 meeting agenda, and we have done. I will
send separate mails to the list to = cover the=20 agenda and the proposed
charter. (Thanks for triggering me to = do=20 this!)
 
 
 
> - What did you meant by "the = level of=20 robustness of the path
>   resources", in = PCC-PCE=20 communication? I am expecting that
>   the client can also = specify an=20 exclude list, include list
>   (this is in addition = of SRLG to=20 include/exclude).  
 
This is in section 6.6.
 
Exclusions are covered by the bullet=20 point:
   - resources, resource = affinities and=20 shared resource link
     groups = (SRLGs) to=20 use/avoid
 
The point you are asking = about:
   - the level of = robustness of the=20 path resources
covers a qualatative assessment of = the=20 vulnerability or fragility of the resources that may be used. For = example, one=20 might grade resources based on empirical evidence (mean time between = failures),=20 on known risks (there is major building work going on near this=20 conduit), or on prejudice (vendor X's software is always crashing). = A PCC=20 could request that only robust resources be used, or allow any=20 resource.
 
Of course, this information does not = comprise=20 part of the TE information advertise by IGPs. It must come from = somewhere=20 else.
 
Note that the likelihood of being = preempted is=20 also somewhat computable based on past experience and current network=20 conditions.


> - Can you please elaborate more on advantages of = Stateful
>   PCE and what are the pits fall of using = Stateful PCE=20 in
>   a distributed PCE environment. You have = information=20 about
>   Out-of-band TED synchronization but I am thinking = there=20
>   is some complexity involved in such mechanism and=20 stateful
>   PCE in a distributed PCE setup. More description = on the=20
>   applicability of Stateful PCE & = Out-of-band TED=20
>   synchronization would be useful to better scope = core=20 vs..
>   advanced features of PCE.
 
Good points. We need to flesh this out a little. Eiji Oki has been = raising=20 similar questions because he sees a strong benefit in knowing what LSPs = exist in=20 the system and where they run.
 
A useful application would be placing a high priority LSP in a = crowded=20 network such that it preempted as few other LSPs as possible (note that=20 preempting on the minimum number of links might not result in the = smallest=20 number of LSPs being disrupted).
 
Another application concerns the construction and maintenance of = the=20 Virtual Network Topolgy (see the MRN draft). It is helpful to understand = which=20 other LSPs exist in the network in order to decide how to manage the FAs = that=20 exist or need to be set up.
 
However, as you note, the maintenance of such a stateful database = is=20 non-trivial. Actually, that isn't quite true! If there is a single PCE = for the=20 whole network, stateful PCE is almost a simple matter of remembering all = of the=20 LSPs that you have computed - if you could guarantee that the LSPs were = actually=20 set up, and know when they were torn down...
 
As the number of PCEs increases you might go through a stage where = the PCEs=20 synchronize state by communicating with each other. But, when LSPs are = set up=20 using computation performed all over the network, the problem becomes = larger and=20 more complex.
 
This is clearly a need to understand the cost-benefit analysis for = this=20 type of proposal. if the need is great enough a solution will be found = whatever=20 the cost. However, if the solution is a huge drain on the network and = the=20 function doesn't buy much...
 
So this is a good area for further discussion.
 

> - When PCE is distributed, are there any = considerations
>   in path computation (minimum guidelines, like=20 constraints
>   based shortest path based on the specified = optimization=20
>   criteria, optimization criteria does not change = for=20 the
>   same setup when multiple PCE are involved in path =
>   computation, etc.) to make Path Computations in a =
>   distributed PCE scheme, that you think we need to = add=20 to
>   the text of this document.
 
I'm not clear what you asking.
 
If you mean "is there any notable difference in service to the = PCC?", then=20 there are three cases to consider.
 
1. Cooperative mode is used.
In this case we have the text (section 5.4)
  Note that a PCC cannot see the difference between=20 centralized
  computation, and multiple PCE path computation = with=20 inter-PCE
  communication. That is, the PCC network node or = component=20 that
  requests the computation makes a single request and = receives=20 a
  full or partial path in response, but the response is=20 actually
  achieved through the coordinated, cooperative efforts = of more=20
  than one PCE.
This is intended to imply that the PCC gets = the=20 same service.
 
2. PCC must make a choice between distributed PCEs
It is clearly important that the PCC knows the properties of = the
available PCEs so that it can make an informed choice. = However,
there is also an option that, provided the PCC expresses its
requirements correctly, its PCE will pass a request to = another
PCE to make sure that the desired service is available.
 
3. Will different PCCs get the same service?
Yes and no. Really the question boils down to quesiton 2.
 
 
If my ramblings don't answer your question, can I suggest that you = supply=20 some text for inclusion in the draft. The architecture is as much your = draft as=20 anyone else's!


> - When a number of disjoint paths are required, we = need a=20
>   mechanism to specify if near disjoint Paths are=20 acceptable
>   (but this is need not to be in architecture = doc). =20
 
Agree on both counts. There are a large number of types and = grades of=20 dijointedness.
 
> The rest of the document look very good = to me.=20
 
Very kind of you to say so!

Regards,
Adrian 
------=_NextPart_000_023C_01C4AD8E.E52401C0-- --===============1819739162== 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 --===============1819739162==-- From pce-bounces@ietf.org Fri Oct 8 18:43:05 2004 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 SAA25930; Fri, 8 Oct 2004 18:43:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3c7-0006v1-Ev; Fri, 08 Oct 2004 18:53:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Mx-0005v5-G8; Fri, 08 Oct 2004 18:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3HH-0004fU-1U for pce@megatron.ietf.org; Fri, 08 Oct 2004 18:31:55 -0400 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 SAA25405 for ; Fri, 8 Oct 2004 18:31:52 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3RG-0006kQ-8Y for pce@ietf.org; Fri, 08 Oct 2004 18:42:15 -0400 Received: from du-069-0166.access.clara.net ([217.158.132.166] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CG3HE-000DFJ-Eh for pce@ietf.org; Fri, 08 Oct 2004 23:31:53 +0100 Message-ID: <024001c4ad86$aa6ab7c0$21849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 8 Oct 2004 23:32:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Pce] Agenda for PCE BOF in Washington DC 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi, We have asked for another BOF in Washington and Alex has given an Ack. The agenda we want to work with is as follows. It will be published on the IETF Web pages. 1) Introduction, admin, statement of objectives of this second PCE BOF 2) Quick summary of the conclusion of the first BOF held in San Diego 3) Problem space: recap of the PCE architecture ID 4) Summary of existing and updated drafts a. draft-farrel-ccamp-interdomain-framework-00.txt b. draft-vasseur-ccamp-inter-area-as-te-comp-00.txt c. draft-vasseur-mpls-computation-rsvp d. draft-oki-ccamp-gtep-00.txt 5) New drafts published since IETF-60 a. draft-ogino-pce-recovery-pc-model-00.txt b. draft-mescal draft-mescal-pcp-proto-00.txt (?) c. draft-mescal-pce-fwk-00.txt (?) 6) Discussion of the proposed architecture 7) Discussion about the need for a WG 8) Proposed charter (see below) 9) Summary and conclusions The main meat of the meeting will be section 6 onwards. So please review the architecture draft and send your comments to the list in advance of the meeting. Also please have a look at the proposed draft charter (separate email or on the Web page with the agenda) and let us know what you think (again, preferably on the mailing list). Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 8 18:43:22 2004 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 SAA25960; Fri, 8 Oct 2004 18:43:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3cP-0006vH-BB; Fri, 08 Oct 2004 18:53:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Mx-0005vA-NF; Fri, 08 Oct 2004 18:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3Ha-0004h3-Qx for pce@megatron.ietf.org; Fri, 08 Oct 2004 18:32:14 -0400 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 SAA25441 for ; Fri, 8 Oct 2004 18:32:12 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3Ra-0006lC-QW for pce@ietf.org; Fri, 08 Oct 2004 18:42:35 -0400 Received: from du-069-0166.access.clara.net ([217.158.132.166] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CG3HY-000DGt-Fe for pce@ietf.org; Fri, 08 Oct 2004 23:32:13 +0100 Message-ID: <024101c4ad86$b685a010$21849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 8 Oct 2004 23:32:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [Pce] Proposed Charter for a PCE WG 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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi, The main purposes of the PCE BOF in Washington DC will be to discuss the PCE architecture, and the need for and scope of a PCE WG. Hence the proposed charter is particularly important. JP and I have put together the following as a starting point, and we would very much appreciate your comments on the mailing list in advance of the meeting. Specific milestones are pending agreement on the major work areas. Thanks, Adrian ============ Proposed Charter WG items: - Functional specification of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s). This includes the case of intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for both Point to Point, Point to Multipoint and Multipoint to Multipoint TE LSPs. - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) extensions required by PCE-based path computation techniques. Specification of routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks. The proposed extensions will done in conjunction with the WGs in charge of the specification of those protocols. - Specification of new protocols or modifications to existing protocols to facilitate communication between LSRs and PCEs, and between a PCE and other PCEs. - Definition of protocol-independent metrics defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements defined by the WG. The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and OIF where appropriate. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Oct 9 13:49:12 2004 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 NAA28806; Sat, 9 Oct 2004 13:49:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLVP-0002ZC-Cj; Sat, 09 Oct 2004 13:59:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLF2-0000Pk-9y; Sat, 09 Oct 2004 13:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGIUI-00048C-Gy; Sat, 09 Oct 2004 10:46:22 -0400 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 KAA18187; Sat, 9 Oct 2004 10:46:20 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGIeO-0007eR-9f; Sat, 09 Oct 2004 10:56:51 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id 487522E76B; Sat, 9 Oct 2004 10:45:47 -0400 (EDT) Received: from 70.177.176.176 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 9 Oct 2004 10:45:47 -0400 (EDT) Message-ID: <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> In-Reply-To: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT) To: "Zafar Ali" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 09 Oct 2004 13:42:46 -0400 Cc: ccamp@ops.ietf.org, pce@ietf.org, Gerald , mpls@ietf.org, jpv@cisco.com, 'Ash@movaz.com Subject: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, 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: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 8bit Hi guys, I think this is a vey sound document. I have a suggestion though. It would be extreamely useful if a PCE could advertise its capabilities such as: a) set of constraints that it can account for (diversity, SRLGs, optical impairements, wavelenght continuity, etc.) b) number of switching capability layers (and which); c) number of path selection criterias (and which); d) whether it is a stateless path calculator or can send updates about better paths that might be available in future; e) whether it can compute P2MP trees (and which types); f) whether it can ensure the resource sharing between backup tunnels; g) etc. This information would help a lot for a potential PCC that dynamically learns about PCEs available on the network to decide which of them to use. Igor > Hi Adrian, Jerry, JP, et al, > > Thanks for putting the PCE Architecture document > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I > found it very useful in scoping PCE WG and applicability of PCE in MPLS/ > GMPLS TE networks. In the following I have a few questions/ comments about > this ID. > > I would also like to request about what would be a tentative agenda for > PCE > BOF Part II in DC? I think the discussion in SD went very well in favor of > PCE WG, pending this architecture ID. What is the present plan of record? > > - What did you meant by "the level of robustness of the path resources", > in > PCC-PCE communication? I am expecting that the client can also specify an > exclude list, include list (this is in addition of SRLG to include/ > exclude). > > - Can you please elaborate more on advantages of Stateful PCE and what are > the pits fall of using Stateful PCE in a distributed PCE environment. You > have information about Out-of-band TED synchronization but I am thinking > there is some complexity involved in such mechanism and stateful PCE in a > distributed PCE setup. More description on the applicability of Stateful > PCE > & Out-of-band TED synchronization would be useful to better scope core > vs.. > advanced features of PCE. > > - When PCE is distributed, are there any considerations in path > computation > (minimum guidelines, like constraints based shortest path based on the > specified optimization criteria, optimization criteria does not change for > the same setup when multiple PCE are involved in path computation, etc.) > to > make Path Computations in a distributed PCE scheme, that you think we need > to add to the text of this document. > > - When a number of disjoint paths are required, we need a mechanism to > specify if near disjoint Paths are acceptable (but this is need not to be > in > architecture doc). > > The rest of the document look very good to me. > > Regards... Zafar > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Oct 9 13:55:11 2004 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 NAA29044; Sat, 9 Oct 2004 13:55:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLbC-0002g0-EF; Sat, 09 Oct 2004 14:05:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLMw-00025n-KE; Sat, 09 Oct 2004 13:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLLz-0001gy-KZ for pce@megatron.ietf.org; Sat, 09 Oct 2004 13:49:59 -0400 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 NAA28889 for ; Sat, 9 Oct 2004 13:49:58 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLW9-0002b0-Bp for pce@ietf.org; Sat, 09 Oct 2004 14:00:29 -0400 Received: from du-069-0289.access.clara.net ([217.158.145.35] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CGLLw-0003EZ-EV for pce@ietf.org; Sat, 09 Oct 2004 18:49:57 +0100 Message-ID: <02c401c4ae28$71e00c50$21849ed9@Puppy> From: "Adrian Farrel" To: Date: Sat, 9 Oct 2004 18:50:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Subject: [Pce] Fw: Path Computation Element (PCE) Architecture and mailing list, 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Forwarding email for non-member. ----- Original Message ----- From: To: "Zafar Ali" Cc: ; "'Adrian Farrel'" ; <'Ash@movaz.com>; "Gerald" ; "ALABS'" ; ; ; ; Sent: Saturday, October 09, 2004 3:45 PM Subject: Re: Path Computation Element (PCE) Architecture and mailing list, > Hi guys, > > I think this is a vey sound document. I have a suggestion though. > > It would be extreamely useful if a PCE could advertise its capabilities > such as: > > a) set of constraints that it can account for (diversity, SRLGs, optical > impairements, wavelenght continuity, etc.) > > b) number of switching capability layers (and which); > > c) number of path selection criterias (and which); > > d) whether it is a stateless path calculator or can send updates about > better paths that might be available in future; > > e) whether it can compute P2MP trees (and which types); > > f) whether it can ensure the resource sharing between backup tunnels; > > g) etc. > > This information would help a lot for a potential PCC that dynamically > learns about PCEs available on the network to decide which of them to use. > > Igor > > > > Hi Adrian, Jerry, JP, et al, > > > > Thanks for putting the PCE Architecture document > > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I > > found it very useful in scoping PCE WG and applicability of PCE in MPLS/ > > GMPLS TE networks. In the following I have a few questions/ comments about > > this ID. > > > > I would also like to request about what would be a tentative agenda for > > PCE > > BOF Part II in DC? I think the discussion in SD went very well in favor of > > PCE WG, pending this architecture ID. What is the present plan of record? > > > > - What did you meant by "the level of robustness of the path resources", > > in > > PCC-PCE communication? I am expecting that the client can also specify an > > exclude list, include list (this is in addition of SRLG to include/ > > exclude). > > > > - Can you please elaborate more on advantages of Stateful PCE and what are > > the pits fall of using Stateful PCE in a distributed PCE environment. You > > have information about Out-of-band TED synchronization but I am thinking > > there is some complexity involved in such mechanism and stateful PCE in a > > distributed PCE setup. More description on the applicability of Stateful > > PCE > > & Out-of-band TED synchronization would be useful to better scope core > > vs.. > > advanced features of PCE. > > > > - When PCE is distributed, are there any considerations in path > > computation > > (minimum guidelines, like constraints based shortest path based on the > > specified optimization criteria, optimization criteria does not change for > > the same setup when multiple PCE are involved in path computation, etc.) > > to > > make Path Computations in a distributed PCE scheme, that you think we need > > to add to the text of this document. > > > > - When a number of disjoint paths are required, we need a mechanism to > > specify if near disjoint Paths are acceptable (but this is need not to be > > in > > architecture doc). > > > > The rest of the document look very good to me. > > > > Regards... Zafar > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Oct 9 14:03:09 2004 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 OAA29319; Sat, 9 Oct 2004 14:03:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLiu-0002ms-KF; Sat, 09 Oct 2004 14:13:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLUd-0003sg-Qd; Sat, 09 Oct 2004 13:58:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLRZ-0002wA-Qk for pce@megatron.ietf.org; Sat, 09 Oct 2004 13:55:46 -0400 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 NAA29068 for ; Sat, 9 Oct 2004 13:55:44 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLbj-0002gq-Ni for pce@ietf.org; Sat, 09 Oct 2004 14:06:16 -0400 Received: from du-069-0289.access.clara.net ([217.158.145.35] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CGLRX-0005Kr-Ew; Sat, 09 Oct 2004 18:55:44 +0100 Message-ID: <02cf01c4ae29$408c3880$21849ed9@Puppy> From: "Adrian Farrel" To: References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> Date: Sat, 9 Oct 2004 18:55:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit [Pruned recipients] Hi Igor, > I think this is a vey sound document. I have a suggestion though. Thanks, and thanks. > It would be extreamely useful if a PCE could advertise its capabilities > such as: > > a) set of constraints that it can account for (diversity, SRLGs, optical > impairements, wavelenght continuity, etc.) > > b) number of switching capability layers (and which); > > c) number of path selection criterias (and which); > > d) whether it is a stateless path calculator or can send updates about > better paths that might be available in future; > > e) whether it can compute P2MP trees (and which types); > > f) whether it can ensure the resource sharing between backup tunnels; > > g) etc. > > This information would help a lot for a potential PCC that dynamically > learns about PCEs available on the network to decide which of them to use. You're right. This should go in section 6.4. In addition, it seems to me that a PCC might ask a PCE to perform a particular type of service and receive a response that says, "Sorry, I can't do that, these are the things I can do. Here is the address of a PCE that may be able to better fulfil your request." We need to be careful not to get too far into the possible solutions at this stage, but I think the point you raise is important for the architecture. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Oct 10 11:58:10 2004 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 LAA20564; Sun, 10 Oct 2004 11:58:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGgFj-0001Tl-HK; Sun, 10 Oct 2004 12:08:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGg4B-000867-4z; Sun, 10 Oct 2004 11:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGg3j-0007uA-Ik for pce@megatron.ietf.org; Sun, 10 Oct 2004 11:56:31 -0400 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 LAA20511 for ; Sun, 10 Oct 2004 11:56:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGgE4-0001SB-K3 for pce@ietf.org; Sun, 10 Oct 2004 12:07:13 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2004 12:15:23 -0400 X-BrightmailFiltered: true Received: from zaliw2k01 (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9AFtsYX004615; Sun, 10 Oct 2004 11:55:55 -0400 (EDT) From: "Zafar Ali" To: "'Adrian Farrel'" , Date: Sun, 10 Oct 2004 11:55:53 -0400 Message-ID: <000001c4aee1$a0f45be0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <023f01c4ad86$87e2d7f0$21849ed9@Puppy> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.9 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: jpv@cisco.com Subject: [Pce] RE: Path Computation Element (PCE) Architecture and mailing list, 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="===============1591381293==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: e05124dbe0e171b371ff9d88326a1ab7 This is a multi-part message in MIME format. --===============1591381293== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C4AEC0.19E5C920" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C4AEC0.19E5C920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Adrian,=20 =20 Thanks for your detailed reply. Please see in-line for some follow-ups. =20 Thanks =20 Regards... Zafar -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, October 08, 2004 6:31 PM To: Zafar Ali; pce@ietf.org Cc: 'Ash, Gerald R (Jerry), ALABS'; jpv@cisco.com; zinin@psg.com Subject: Re: Path Computation Element (PCE) Architecture and mailing = list,=20 Hi Zafar, [Recipients trimmed to leave out the MPLS and CCAMP mailing lists.] > Thanks for putting the PCE Architecture document > = (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), > I found it very useful in scoping PCE WG and applicability of PCE in=20 > MPLS/GMPLS TE networks. In the following I have a few questions/ > comments about this ID.=20 =20 > I would also like to request about what would be a tentative agenda > for PCE BOF Part II in DC? I think the discussion in SD went very=20 > well in favor of PCE WG, pending this architecture ID. What is the > present plan of record?=20 Yup, we have requested a BOF for Washington DC and hopefully this=20 will appear on the meta-agenda soon. In order to request a BOF you must supply the intended meeting agenda, and we have done. I will=20 send separate mails to the list to cover the agenda and the proposed charter. (Thanks for triggering me to do this!) =20 Great!=20 =20 > - What did you meant by "the level of robustness of the path > resources", in PCC-PCE communication? I am expecting that=20 > the client can also specify an exclude list, include list=20 > (this is in addition of SRLG to include/exclude). =20 =20 This is in section 6.6. =20 Exclusions are covered by the bullet point: - resources, resource affinities and shared resource link=20 groups (SRLGs) to use/avoid =20 The point you are asking about: - the level of robustness of the path resources covers a qualatative assessment of the vulnerability or fragility of the resources that may be used. For example, one might grade resources based = on empirical evidence (mean time between failures), on known risks (there = is major building work going on near this conduit), or on prejudice (vendor = X's software is always crashing). A PCC could request that only robust = resources be used, or allow any resource.=20 =20 Of course, this information does not comprise part of the TE information advertise by IGPs. It must come from somewhere else.=20 =20 =20 Note that the likelihood of being preempted is also somewhat computable based on past experience and current network conditions. > - Can you please elaborate more on advantages of Stateful > PCE and what are the pits fall of using Stateful PCE in > a distributed PCE environment. You have information about > Out-of-band TED synchronization but I am thinking there=20 > is some complexity involved in such mechanism and stateful > PCE in a distributed PCE setup. More description on the=20 > applicability of Stateful PCE & Out-of-band TED=20 > synchronization would be useful to better scope core vs.. > advanced features of PCE.=20 =20 Good points. We need to flesh this out a little. Eiji Oki has been = raising similar questions because he sees a strong benefit in knowing what LSPs exist in the system and where they run. =20 A useful application would be placing a high priority LSP in a crowded network such that it preempted as few other LSPs as possible (note that preempting on the minimum number of links might not result in the = smallest number of LSPs being disrupted). =20 Another application concerns the construction and maintenance of the = Virtual Network Topolgy (see the MRN draft). It is helpful to understand which = other LSPs exist in the network in order to decide how to manage the FAs that exist or need to be set up. =20 However, as you note, the maintenance of such a stateful database is non-trivial. Actually, that isn't quite true! If there is a single PCE = for the whole network, stateful PCE is almost a simple matter of remembering = all of the LSPs that you have computed - if you could guarantee that the = LSPs were actually set up, and know when they were torn down... =20 As the number of PCEs increases you might go through a stage where the = PCEs synchronize state by communicating with each other. But, when LSPs are = set up using computation performed all over the network, the problem becomes larger and more complex. =20 This is clearly a need to understand the cost-benefit analysis for this = type of proposal. if the need is great enough a solution will be found = whatever the cost. However, if the solution is a huge drain on the network and = the function doesn't buy much...=20 =20 Like I mention, and you agree, that the synchronization of "Path information" in a distribute d PCE is much complex and prone to race conditions , scalability concerns, etc. Even if we know detailed information of "ALL" the paths at "ALL" priorities and in "ALL layers (MRN)", taken such information into account for computation of a new = path appears highly polynomial to me. =20 =20 In summary, I would like to know how do you plan to pursue this = cost-benefit tradeoff analysis? Do you plan to have some description along these = lines in the next version of the Architecture Document?, etc. =20 So this is a good area for further discussion. =20 > - When PCE is distributed, are there any considerations > in path computation (minimum guidelines, like constraints > based shortest path based on the specified optimization=20 > criteria, optimization criteria does not change for the > same setup when multiple PCE are involved in path=20 > computation, etc.) to make Path Computations in a=20 > distributed PCE scheme, that you think we need to add to > the text of this document.=20 =20 I'm not clear what you asking.=20 =20 I will discuss more on this off-line with you. =20 =20 If you mean "is there any notable difference in service to the PCC?", = then there are three cases to consider. =20 1. Cooperative mode is used.=20 In this case we have the text (section 5.4) Note that a PCC cannot see the difference between centralized computation, and multiple PCE path computation with inter-PCE communication. That is, the PCC network node or component that requests the computation makes a single request and receives a full or partial path in response, but the response is actually achieved through the coordinated, cooperative efforts of more=20 than one PCE. This is intended to imply that the PCC gets the same service. =20 2. PCC must make a choice between distributed PCEs It is clearly important that the PCC knows the properties of the available PCEs so that it can make an informed choice. However, there is also an option that, provided the PCC expresses its requirements correctly, its PCE will pass a request to another PCE to make sure that the desired service is available. =20 3. Will different PCCs get the same service? Yes and no. Really the question boils down to quesiton 2. =20 =20 If my ramblings don't answer your question, can I suggest that you = supply some text for inclusion in the draft. The architecture is as much your = draft as anyone else's!=20 =20 > - When a number of disjoint paths are required, we need a=20 > mechanism to specify if near disjoint Paths are acceptable > (but this is need not to be in architecture doc). =20 =20 Agree on both counts. There are a large number of types and grades of dijointedness. =20 > The rest of the document look very good to me.=20 =20 Very kind of you to say so! Regards, Adrian=20 ------=_NextPart_000_0001_01C4AEC0.19E5C920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dear=20 Adrian,
 
Thanks=20 for your detailed reply. Please see in-line for some=20 follow-ups.
 
Thanks
 
Regards... = Zafar
-----Original Message-----
From: = Adrian Farrel=20 [mailto:adrian@olddog.co.uk]
Sent: Friday, October 08, 2004 = 6:31=20 PM
To: Zafar Ali; pce@ietf.org
Cc: 'Ash, Gerald R = (Jerry),=20 ALABS'; jpv@cisco.com; zinin@psg.com
Subject: Re: Path = Computation=20 Element (PCE) Architecture and mailing list,

Hi Zafar,

[Recipients = trimmed to leave=20 out the MPLS and CCAMP mailing lists.]

> Thanks for putting = the PCE=20 Architecture document
>=20 = (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt),<= BR>>=20 I found it very useful in scoping PCE WG and applicability of PCE in =
>=20 MPLS/GMPLS TE networks. In the following I have a few = questions/
>=20 comments about this ID.
 
> I would also like to = request about=20 what would be a tentative agenda
> for PCE BOF Part II in DC? I = think=20 the discussion in SD went very
> well in favor of PCE WG, = pending this=20 architecture ID. What is the
> present plan of record? =

Yup, we=20 have requested a BOF for Washington DC and hopefully this
will = appear on=20 the meta-agenda soon. In order to request a BOF you
must supply the = intended meeting agenda, and we have done. I will
send separate mails to the list to = cover the=20 agenda and the proposed
charter. (Thanks for triggering me = to do=20 this!)
 
Great!
 
> - What did you meant by "the = level of=20 robustness of the path
>   resources", in = PCC-PCE=20 communication? I am expecting that
>   the client can = also specify an=20 exclude list, include list
>   (this is in = addition of SRLG=20 to include/exclude).  
 
This is in section = 6.6.
 
Exclusions are covered by the = bullet=20 point:
   - resources, resource = affinities=20 and shared resource link
     groups = (SRLGs) to=20 use/avoid
 
The point you are asking = about:
   - the level of = robustness of the=20 path resources
covers a qualatative = assessment of the=20 vulnerability or fragility of the resources that may be used. For = example, one=20 might grade resources based on empirical evidence (mean time between=20 failures), on known risks (there is major building work going on near = this=20 conduit), or on prejudice (vendor X's software is always = crashing). A PCC=20 could request that only robust resources be used, or allow any = resource. 
 
Of course, this information = does not=20 comprise part of the TE information advertise by IGPs. It must = come from=20 somewhere else. 
 
=
 
Note that the likelihood of = being=20 preempted is also somewhat computable based on past experience and = current=20 network conditions.


> - Can you please elaborate more on advantages of=20 Stateful
>   PCE and what are the pits = fall of=20 using Stateful PCE in
>   a distributed PCE environment. = You have=20 information about
>   Out-of-band TED synchronization = but I am=20 thinking there
>   is some complexity involved in = such=20 mechanism and stateful
>   PCE in a distributed PCE setup. = More=20 description on the
>   applicability of Stateful = PCE &=20 Out-of-band TED
>   synchronization would be useful = to better=20 scope core vs..
>   advanced features of PCE.=20
 
Good points. We need to flesh this out a little. = Eiji Oki=20 has been raising similar questions because he sees a strong benefit in = knowing=20 what LSPs exist in the system and where they run.
 
A useful application would be placing a high = priority LSP in=20 a crowded network such that it preempted as few other LSPs as possible = (note=20 that preempting on the minimum number of links might not result in the = smallest number of LSPs being disrupted).
 
Another application concerns the construction and=20 maintenance of the Virtual Network Topolgy (see the MRN draft). It is = helpful=20 to understand which other LSPs exist in the network in order to decide = how to=20 manage the FAs that exist or need to be set up.
 
However, as you note, the maintenance of such a = stateful=20 database is non-trivial. Actually, that isn't quite true! If there is = a single=20 PCE for the whole network, stateful PCE is almost a simple matter of=20 remembering all of the LSPs that you have computed - if you could = guarantee=20 that the LSPs were actually set up, and know when they were torn=20 down...
 
As the number of PCEs increases you might go = through a stage=20 where the PCEs synchronize state by communicating with each other. = But, when=20 LSPs are set up using computation performed all over the network, the = problem=20 becomes larger and more complex.
 
This is clearly a need to understand the = cost-benefit=20 analysis for this type of proposal. if the need is great enough a = solution=20 will be found whatever the cost. However, if the solution is a huge = drain on=20 the network and the function doesn't buy much... 
 
Like I mention, and = you agree, that=20 the synchronization of "Path information" in a distribute d  PCE is much complex and = prone to=20 race conditions , scalability=20 concerns, etc.  Even if we = know=20 detailed information of "ALL" the paths at "ALL" priorities and in = "ALL=20 layers (MRN)", taken such information into account for computation of a = new=20 path appears highly polynomial to=20 me.  
 
In summary, I would like to know how do you plan to = pursue=20 this cost-benefit tradeoff analysis? Do you plan to have some = description=20 along these lines in the next version of the Architecture Document?, = etc.=20  
So this is a good area for further = discussion.
 

> - When PCE is = distributed, are=20 there any considerations
>   in path computation (minimum = guidelines,=20 like constraints
>   based shortest path based on the = specified=20 optimization
>   criteria, optimization criteria = does not=20 change for the
>   same setup when multiple PCE are = involved=20 in path
>   computation, etc.) to make Path=20 Computations in a
>   distributed PCE scheme, that you = think we=20 need to add to
>   the text of this document. =
 
I'm not clear what you asking. 
 
I will discuss more on this off-line with you.=20  
 
If you mean "is there any notable difference in = service to=20 the PCC?", then there are three cases to consider.
 
1. Cooperative mode is used.
In this case we have the text (section = 5.4)
  Note that a PCC cannot see the difference = between=20 centralized
  computation, and multiple PCE path computation = with=20 inter-PCE
  communication. That is, the PCC network node or = component=20 that
  requests the computation makes a = single request=20 and receives a
  full or partial path in response, but = the=20 response is actually
  achieved through the coordinated, = cooperative=20 efforts of more
  than one PCE.
This is intended to imply = that the=20 PCC gets the same service.
 
2. PCC must make a choice between distributed=20 PCEs
It is clearly important that the PCC knows the = properties of=20 the
available PCEs so that it can make an informed = choice.=20 However,
there is also an option that, provided the PCC = expresses=20 its
requirements correctly, its PCE will pass a = request to=20 another
PCE to make sure that the desired service is=20 available.
 
3. Will different PCCs get the same = service?
Yes and no. Really the question boils down to = quesiton=20 2.
 
 
If my ramblings don't answer your question, can I = suggest=20 that you supply some text for inclusion in the draft. The architecture = is as=20 much your draft as anyone else's! 
  


> - When a=20 number of disjoint paths are required, we need a
>   mechanism to specify if near = disjoint Paths=20 are acceptable
>   (but this is need not to be in = architecture=20 doc). 
 
Agree on both counts. There are a large number = of types=20 and grades of dijointedness.
 
> The rest of the = document look=20 very good to me.
 
Very kind of you to say so!

Regards,
Adrian 
------=_NextPart_000_0001_01C4AEC0.19E5C920-- --===============1591381293== 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 --===============1591381293==-- From pce-bounces@ietf.org Mon Oct 11 10:03:06 2004 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 KAA07715; Mon, 11 Oct 2004 10:03:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0w5-000071-FS; Mon, 11 Oct 2004 10:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0kR-0006Vf-FG; Mon, 11 Oct 2004 10:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0jf-000699-PV for pce@megatron.ietf.org; Mon, 11 Oct 2004 10:01:11 -0400 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 KAA07591 for ; Mon, 11 Oct 2004 10:01:09 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0uD-0008W5-Fg for pce@ietf.org; Mon, 11 Oct 2004 10:12:05 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id D7D251521C; Mon, 11 Oct 2004 10:00:39 -0400 (EDT) Message-ID: <008901c4af9a$b140e0e0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> Date: Mon, 11 Oct 2004 10:00:40 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit See in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: Cc: Sent: Saturday, October 09, 2004 1:55 PM Subject: Re: Path Computation Element (PCE) Architecture and mailing list, > [Pruned recipients] > > Hi Igor, > > > I think this is a vey sound document. I have a suggestion though. > > Thanks, and thanks. > > > It would be extreamely useful if a PCE could advertise its capabilities > > such as: > > > > a) set of constraints that it can account for (diversity, SRLGs, optical > > impairements, wavelenght continuity, etc.) > > > > b) number of switching capability layers (and which); > > > > c) number of path selection criterias (and which); > > > > d) whether it is a stateless path calculator or can send updates about > > better paths that might be available in future; > > > > e) whether it can compute P2MP trees (and which types); > > > > f) whether it can ensure the resource sharing between backup tunnels; > > > > g) etc. > > > > This information would help a lot for a potential PCC that dynamically > > learns about PCEs available on the network to decide which of them to use. > > You're right. This should go in section 6.4. > > In addition, it seems to me that a PCC might ask a PCE to perform a particular type of > service and receive a response that says, "Sorry, I can't do that, these are the things I > can do. Here is the address of a PCE that may be able to better fulfil your request." IB>> It won't be necessary if PCE advertises its capabilities separately. What you are suggesting will make the PCC-PCE protocol heavier without giving actual benefits. But you are right, it is too early at this stage to discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE signalling protocols will be by far the biggest challenge, and we must not complicate it unnecessarily. Igor > > We need to be careful not to get too far into the possible solutions at this stage, but I > think the point you raise is important for the architecture. > > Thanks, > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Oct 11 20:00:58 2004 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 UAA11901; Mon, 11 Oct 2004 20:00:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAGk-0008Ri-Mw; Mon, 11 Oct 2004 20:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9xD-00024A-6R; Mon, 11 Oct 2004 19:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9ph-00088N-RI; Mon, 11 Oct 2004 19:44:02 -0400 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 TAA11098; Mon, 11 Oct 2004 19:43:58 -0400 (EDT) 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 1CHA0K-0008BU-K2; Mon, 11 Oct 2004 19:55:01 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2004 16:52:07 -0700 X-BrightmailFiltered: true 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 i9BNhQOE011814; Mon, 11 Oct 2004 16:43:27 -0700 (PDT) Received: from [68.184.43.50] (che-vpn-cluster-1-213.cisco.com [10.86.240.213]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA12666; Mon, 11 Oct 2004 16:43:24 -0700 (PDT) In-Reply-To: <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5822B2DE-1BDF-11D9-B106-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Mon, 11 Oct 2004 19:43:25 -0400 To: ibryskin@movaz.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org, Gerald , Zafar Ali , jpv@cisco.com, 'Ash@movaz.com 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: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Hi Igor, On Oct 9, 2004, at 10:45 AM, ibryskin@movaz.com wrote: > Hi guys, > > I think this is a vey sound document. I have a suggestion though. > > It would be extreamely useful if a PCE could advertise its capabilities > such as: > > a) set of constraints that it can account for (diversity, SRLGs, > optical > impairements, wavelenght continuity, etc.) > > b) number of switching capability layers (and which); > > c) number of path selection criterias (and which); > > d) whether it is a stateless path calculator or can send updates about > better paths that might be available in future; > > e) whether it can compute P2MP trees (and which types); > > f) whether it can ensure the resource sharing between backup tunnels; > > g) etc. > > This information would help a lot for a potential PCC that dynamically > learns about PCEs available on the network to decide which of them to > use. > I cannot agree more ! See the two PCE cap related drafts: draft-vasseur-ospf--te-caps (and isis) Such draft would probably ends up being discussed here, should we end up creating a WG. JP. > Igor > > >> Hi Adrian, Jerry, JP, et al, >> >> Thanks for putting the PCE Architecture document >> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture >> -00.txt), I >> found it very useful in scoping PCE WG and applicability of PCE in >> MPLS/ >> GMPLS TE networks. In the following I have a few questions/ comments >> about >> this ID. >> >> I would also like to request about what would be a tentative agenda >> for >> PCE >> BOF Part II in DC? I think the discussion in SD went very well in >> favor of >> PCE WG, pending this architecture ID. What is the present plan of >> record? >> >> - What did you meant by "the level of robustness of the path >> resources", >> in >> PCC-PCE communication? I am expecting that the client can also >> specify an >> exclude list, include list (this is in addition of SRLG to include/ >> exclude). >> >> - Can you please elaborate more on advantages of Stateful PCE and >> what are >> the pits fall of using Stateful PCE in a distributed PCE environment. >> You >> have information about Out-of-band TED synchronization but I am >> thinking >> there is some complexity involved in such mechanism and stateful PCE >> in a >> distributed PCE setup. More description on the applicability of >> Stateful >> PCE >> & Out-of-band TED synchronization would be useful to better scope core >> vs.. >> advanced features of PCE. >> >> - When PCE is distributed, are there any considerations in path >> computation >> (minimum guidelines, like constraints based shortest path based on the >> specified optimization criteria, optimization criteria does not >> change for >> the same setup when multiple PCE are involved in path computation, >> etc.) >> to >> make Path Computations in a distributed PCE scheme, that you think we >> need >> to add to the text of this document. >> >> - When a number of disjoint paths are required, we need a mechanism to >> specify if near disjoint Paths are acceptable (but this is need not >> to be >> in >> architecture doc). >> >> The rest of the document look very good to me. >> >> Regards... Zafar >> >> > > > _______________________________________________ > 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 Mon Oct 11 20:21:54 2004 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 UAA13270; Mon, 11 Oct 2004 20:21:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAb0-0000KE-MT; Mon, 11 Oct 2004 20:32:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHAK3-0000yZ-2R; Mon, 11 Oct 2004 20:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHABD-0007CY-Qd for pce@megatron.ietf.org; Mon, 11 Oct 2004 20:06:16 -0400 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 UAA12292 for ; Mon, 11 Oct 2004 20:06:14 -0400 (EDT) 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 1CHALq-0008Va-Ui for pce@ietf.org; Mon, 11 Oct 2004 20:17:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2004 17:11:46 -0700 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 i9C05fOE022786; Mon, 11 Oct 2004 17:05:42 -0700 (PDT) Received: from [68.184.43.50] (che-vpn-cluster-1-213.cisco.com [10.86.240.213]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA15771; Mon, 11 Oct 2004 17:05:40 -0700 (PDT) In-Reply-To: <008901c4af9a$b140e0e0$7a1810ac@movaz.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> <008901c4af9a$b140e0e0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74368DBF-1BE2-11D9-B106-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Mon, 11 Oct 2004 20:05:41 -0400 To: "Igor Bryskin" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Igor, On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote: > See in-line. > > Igor > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: > Sent: Saturday, October 09, 2004 1:55 PM > Subject: Re: Path Computation Element (PCE) Architecture and mailing > list, > > >> [Pruned recipients] >> >> Hi Igor, >> >>> I think this is a vey sound document. I have a suggestion though. >> >> Thanks, and thanks. >> >>> It would be extreamely useful if a PCE could advertise its >>> capabilities >>> such as: >>> >>> a) set of constraints that it can account for (diversity, SRLGs, >>> optical >>> impairements, wavelenght continuity, etc.) >>> >>> b) number of switching capability layers (and which); >>> >>> c) number of path selection criterias (and which); >>> >>> d) whether it is a stateless path calculator or can send updates >>> about >>> better paths that might be available in future; >>> >>> e) whether it can compute P2MP trees (and which types); >>> >>> f) whether it can ensure the resource sharing between backup tunnels; >>> >>> g) etc. >>> >>> This information would help a lot for a potential PCC that >>> dynamically >>> learns about PCEs available on the network to decide which of them to > use. >> >> You're right. This should go in section 6.4. >> >> In addition, it seems to me that a PCC might ask a PCE to perform a > particular type of >> service and receive a response that says, "Sorry, I can't do that, >> these > are the things I >> can do. Here is the address of a PCE that may be able to better fulfil > your request." > > IB>> It won't be necessary if PCE advertises its capabilities > separately. > What you are suggesting will make the PCC-PCE protocol heavier without > giving actual benefits. But you are right, it is too early at this > stage to > discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE > signalling protocols will be by far the biggest challenge, and we must > not > complicate it unnecessarily. > See my previous answer, I'm also a strong advocate for advertising PCE cap, such advertisement will be required anyway for the PCE discovery especially in multi-domain environments. Thanks for your feed-backs. Cheers JP. > Igor > >> >> We need to be careful not to get too far into the possible solutions >> at > this stage, but I >> think the point you raise is important for the architecture. >> >> 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 Tue Oct 12 11:28:01 2004 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 LAA00742; Tue, 12 Oct 2004 11:28:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOk2-0007jV-E0; Tue, 12 Oct 2004 11:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOLR-0006bz-GA; Tue, 12 Oct 2004 11:13:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOH4-0005Bz-Fw for pce@megatron.ietf.org; Tue, 12 Oct 2004 11:09:14 -0400 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 LAA28732 for ; Tue, 12 Oct 2004 11:09:12 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHORn-0007IQ-He for pce@ietf.org; Tue, 12 Oct 2004 11:20:22 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 9010A167E; Tue, 12 Oct 2004 11:08:38 -0400 (EDT) Message-ID: <009a01c4b06d$5a6b45c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> <008901c4af9a$b140e0e0$7a1810ac@movaz.com> <74368DBF-1BE2-11D9-B106-000D93330B14@cisco.com> Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Tue, 12 Oct 2004 11:08:38 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Hey JP, Looks like we are in a wild agreement. Igor ----- Original Message ----- From: "JP Vasseur" To: "Igor Bryskin" Cc: "Adrian Farrel" ; Sent: Monday, October 11, 2004 8:05 PM Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, > Hi Igor, > > On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote: > > > See in-line. > > > > Igor > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: > > Cc: > > Sent: Saturday, October 09, 2004 1:55 PM > > Subject: Re: Path Computation Element (PCE) Architecture and mailing > > list, > > > > > >> [Pruned recipients] > >> > >> Hi Igor, > >> > >>> I think this is a vey sound document. I have a suggestion though. > >> > >> Thanks, and thanks. > >> > >>> It would be extreamely useful if a PCE could advertise its > >>> capabilities > >>> such as: > >>> > >>> a) set of constraints that it can account for (diversity, SRLGs, > >>> optical > >>> impairements, wavelenght continuity, etc.) > >>> > >>> b) number of switching capability layers (and which); > >>> > >>> c) number of path selection criterias (and which); > >>> > >>> d) whether it is a stateless path calculator or can send updates > >>> about > >>> better paths that might be available in future; > >>> > >>> e) whether it can compute P2MP trees (and which types); > >>> > >>> f) whether it can ensure the resource sharing between backup tunnels; > >>> > >>> g) etc. > >>> > >>> This information would help a lot for a potential PCC that > >>> dynamically > >>> learns about PCEs available on the network to decide which of them to > > use. > >> > >> You're right. This should go in section 6.4. > >> > >> In addition, it seems to me that a PCC might ask a PCE to perform a > > particular type of > >> service and receive a response that says, "Sorry, I can't do that, > >> these > > are the things I > >> can do. Here is the address of a PCE that may be able to better fulfil > > your request." > > > > IB>> It won't be necessary if PCE advertises its capabilities > > separately. > > What you are suggesting will make the PCC-PCE protocol heavier without > > giving actual benefits. But you are right, it is too early at this > > stage to > > discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE > > signalling protocols will be by far the biggest challenge, and we must > > not > > complicate it unnecessarily. > > > > See my previous answer, I'm also a strong advocate for advertising PCE > cap, such advertisement will be required anyway for the PCE discovery > especially in multi-domain environments. > > Thanks for your feed-backs. > > Cheers > > JP. > > > Igor > > > >> > >> We need to be careful not to get too far into the possible solutions > >> at > > this stage, but I > >> think the point you raise is important for the architecture. > >> > >> 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 Tue Oct 12 12:55:07 2004 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 MAA08705; Tue, 12 Oct 2004 12:55:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQ6L-00029J-Ri; Tue, 12 Oct 2004 13:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPsQ-0006RM-Kb; Tue, 12 Oct 2004 12:51:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPdB-0002h7-C1 for pce@megatron.ietf.org; Tue, 12 Oct 2004 12:36:09 -0400 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 MAA06678 for ; Tue, 12 Oct 2004 12:36:07 -0400 (EDT) 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 1CHPnP-0001aQ-1V for pce@ietf.org; Tue, 12 Oct 2004 12:46:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2004 09:43:49 -0700 X-BrightmailFiltered: true 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 i9CGZ0OE025947; Tue, 12 Oct 2004 09:35:01 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-181.cisco.com [10.86.162.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA15947; Tue, 12 Oct 2004 09:34:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20041012123236.05b6bd18@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Oct 2004 12:34:28 -0400 To: "Igor Bryskin" From: Jean Philippe Vasseur Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, In-Reply-To: <009a01c4b06d$5a6b45c0$7a1810ac@movaz.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> <008901c4af9a$b140e0e0$7a1810ac@movaz.com> <74368DBF-1BE2-11D9-B106-000D93330B14@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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: dbb8771284c7a36189745aa720dc20ab Hi Igor, At 11:08 AM 10/12/2004 -0400, Igor Bryskin wrote: >Hey JP, > >Looks like we are in a wild agreement. Perfect - let's continue the discussion on how to extend draft-vasseur-ospf-te-caps-00.txt and draft-vasseur-isis-te-caps-00.txt to cope with GMPLS specific parameters. Your input is very welcome. Cheers. JP. >Igor > >----- Original Message ----- >From: "JP Vasseur" >To: "Igor Bryskin" >Cc: "Adrian Farrel" ; >Sent: Monday, October 11, 2004 8:05 PM >Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and >mailing list, > > > > Hi Igor, > > > > On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote: > > > > > See in-line. > > > > > > Igor > > > > > > ----- Original Message ----- > > > From: "Adrian Farrel" > > > To: > > > Cc: > > > Sent: Saturday, October 09, 2004 1:55 PM > > > Subject: Re: Path Computation Element (PCE) Architecture and mailing > > > list, > > > > > > > > >> [Pruned recipients] > > >> > > >> Hi Igor, > > >> > > >>> I think this is a vey sound document. I have a suggestion though. > > >> > > >> Thanks, and thanks. > > >> > > >>> It would be extreamely useful if a PCE could advertise its > > >>> capabilities > > >>> such as: > > >>> > > >>> a) set of constraints that it can account for (diversity, SRLGs, > > >>> optical > > >>> impairements, wavelenght continuity, etc.) > > >>> > > >>> b) number of switching capability layers (and which); > > >>> > > >>> c) number of path selection criterias (and which); > > >>> > > >>> d) whether it is a stateless path calculator or can send updates > > >>> about > > >>> better paths that might be available in future; > > >>> > > >>> e) whether it can compute P2MP trees (and which types); > > >>> > > >>> f) whether it can ensure the resource sharing between backup tunnels; > > >>> > > >>> g) etc. > > >>> > > >>> This information would help a lot for a potential PCC that > > >>> dynamically > > >>> learns about PCEs available on the network to decide which of them to > > > use. > > >> > > >> You're right. This should go in section 6.4. > > >> > > >> In addition, it seems to me that a PCC might ask a PCE to perform a > > > particular type of > > >> service and receive a response that says, "Sorry, I can't do that, > > >> these > > > are the things I > > >> can do. Here is the address of a PCE that may be able to better fulfil > > > your request." > > > > > > IB>> It won't be necessary if PCE advertises its capabilities > > > separately. > > > What you are suggesting will make the PCC-PCE protocol heavier without > > > giving actual benefits. But you are right, it is too early at this > > > stage to > > > discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE > > > signalling protocols will be by far the biggest challenge, and we must > > > not > > > complicate it unnecessarily. > > > > > > > See my previous answer, I'm also a strong advocate for advertising PCE > > cap, such advertisement will be required anyway for the PCE discovery > > especially in multi-domain environments. > > > > Thanks for your feed-backs. > > > > Cheers > > > > JP. > > > > > Igor > > > > > >> > > >> We need to be careful not to get too far into the possible solutions > > >> at > > > this stage, but I > > >> think the point you raise is important for the architecture. > > >> > > >> 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 Tue Oct 12 15:37:34 2004 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 PAA23522; Tue, 12 Oct 2004 15:37:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSdZ-0005cv-HQ; Tue, 12 Oct 2004 15:48:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSHT-0005bZ-CV; Tue, 12 Oct 2004 15:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSG6-0004nA-D6 for pce@megatron.ietf.org; Tue, 12 Oct 2004 15:24:30 -0400 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 PAA22085 for ; Tue, 12 Oct 2004 15:24:29 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSQj-0005I7-2f for pce@ietf.org; Tue, 12 Oct 2004 15:35:40 -0400 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 i9CJNub9017509; Wed, 13 Oct 2004 04:23:56 +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 i9CJNt5t026505; Wed, 13 Oct 2004 04:23:55 +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 i9CJNtg4026500; Wed, 13 Oct 2004 04:23:55 +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 i9CJNsbG006069; Wed, 13 Oct 2004 04:23:54 +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 i9CJNs0O006064; Wed, 13 Oct 2004 04:23:54 +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 i9CJNsYA007802; Wed, 13 Oct 2004 04:23:54 +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 i9CJNror002359; Wed, 13 Oct 2004 04:23:53 +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 i9CJNrxD002355; Wed, 13 Oct 2004 04:23:53 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id EAA25558; Wed, 13 Oct 2004 04:23:53 +0900 (JST) Date: Wed, 13 Oct 2004 04:23:50 +0900 From: Eiji Oki To: gash@att.com Subject: Re: [Pce] Fwd: Internet Draft for Publication In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE2A4@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA060CE2A4@KCCLUST06EVS1.ugd.att.com> Message-Id: <20041013041402.CC3E.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: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi Jeery, > > > > > I understand that section 1 describes the definition of TED > > > > and that TED is made by using IGP-TE or by other means. > > > > Information in TED includes not only contents that can be built > > > > from the distribution of IGP-TE, but LSP information as described > in > > > > section 6.8. However, LSP information, which is not able to > > > > be collected by IGP, is not clarified in the draft. > > > > LSP information from sources other than the IGP is discussed in > Section > > > 6.7. The scope of such information could be large. Do you have > > > suggestions as to which information should be clarified? > > > I think that it would be better to include LSP routes, > > the reserved bandwidth, and measured traffic volume passing > > through the LSP, which are not included in IGP-TE information. > > OK, we'll include in the next update. > In the next update, it would be also good to describe the applicabilities for the usage of the above information. > > > > TED synchronization is important. I suggest that "TED > > > > synchronization: speed with which synchronization is > > > > achieved, and the impact of the synchronization process > > > > on the data flows in the network." be added as > > > > evaluation metric in section 7. > > > > OK. These would augment the last item in Section 7 regarding > > > synchronization: > > > "- Ability to maintain accurate synchronization between TED > > > and network topology and resource states." > > > I would like to mean "quick" synchronization in evaluation metric. > > Agreed, we'll add your suggested evaluation metrics in the next update: > - speed with which synchronization is achieved > - impact of the synchronization process on the data flows in the network > Thank you. Eiji _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Oct 12 19:04:34 2004 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 TAA25685; Tue, 12 Oct 2004 19:04:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVrm-00065a-D0; Tue, 12 Oct 2004 19:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHVan-0007XC-K2; Tue, 12 Oct 2004 18:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTvn-0007vi-Td; Tue, 12 Oct 2004 17:11:39 -0400 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 RAA11040; Tue, 12 Oct 2004 17:11:38 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHU6M-0002NG-KI; Tue, 12 Oct 2004 17:22:50 -0400 Received: from zhangr2.sa.infonet.com (sfjl161.us.info.net [204.79.139.161] (may be forged)) by sa.infonet.com with ESMTP id i9CLBKOA023203; Tue, 12 Oct 2004 21:11:20 GMT Message-Id: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 12 Oct 2004 14:10:02 -0700 To: Adrian Farrel , , From: raymond zhang In-Reply-To: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Tue, 12 Oct 2004 18:58:03 -0400 Cc: ccamp@ops.ietf.org, mpls@ietf.org, 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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.) - 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) - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... - 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...) - 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 ?) - 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) ... - 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.) - 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 ? - 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 ?) - 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 ? Regards, Raymond _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Oct 13 06:48:07 2004 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 GAA11066; Wed, 13 Oct 2004 06:48:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHgqs-0001Vy-EA; Wed, 13 Oct 2004 06:59:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHgex-0007FU-1B; Wed, 13 Oct 2004 06:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHgaU-000693-JE for pce@megatron.ietf.org; Wed, 13 Oct 2004 06:42:30 -0400 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 GAA10618 for ; Wed, 13 Oct 2004 06:42:25 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHglK-0001Qd-OW for pce@ietf.org; Wed, 13 Oct 2004 06:53:44 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9DAgK0f022995 for ; Wed, 13 Oct 2004 05:42:21 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id <4M3D07LC>; Wed, 13 Oct 2004 16:12:19 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D20B4917AD@ii0015exch002u.iprc.lucent.com> From: "Kulkarni, Hrishikesh (Hrishikesh)" To: pce@ietf.org Date: Wed, 13 Oct 2004 16:11:40 +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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Pce] PCE and ForCES WG difference 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: 7d33c50f3756db14428398e2bdedd581 Hi all, I was going through Forwarding and Control Element Separation (ForCES) Framework http://www.ietf.org/rfc/rfc3746.txt which provides a framework to separate the control (routing) and the forwarder functionality. How is this working group goals or architecture suggestions different from the one being suggested by PCE? is one of them a subset of the other? thanks rishi. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Oct 13 07:43:10 2004 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 HAA17052; Wed, 13 Oct 2004 07:43:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhi4-0002jO-FE; Wed, 13 Oct 2004 07:54:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhLj-0003OR-Ey; Wed, 13 Oct 2004 07:31:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhGy-0001q3-7o for pce@megatron.ietf.org; Wed, 13 Oct 2004 07:26:24 -0400 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 HAA15355 for ; Wed, 13 Oct 2004 07:26:20 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhRo-0002Iu-K3 for pce@ietf.org; Wed, 13 Oct 2004 07:37:37 -0400 Received: from du-069-0079.access.clara.net ([217.158.132.79] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.34) id 1CHhGp-000DPk-AB; Wed, 13 Oct 2004 12:26:15 +0100 Message-ID: <05da01c4b117$82410580$21849ed9@Puppy> From: "Adrian Farrel" To: "Kulkarni, Hrishikesh \(Hrishikesh\)" , References: <6733C768256DEC42A72BAFEFA9CF06D20B4917AD@ii0015exch002u.iprc.lucent.com> Subject: Re: [Pce] PCE and ForCES WG difference Date: Wed, 13 Oct 2004 12:26:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hi Rishi, This is a good question which probably applies equally to ForCES and GSMP. If you were to draw a simplistic picture of the ForCES or GSMP model it would show a clear separation of the control and data planes. The programming protocol (e.g. NetLink or GSMP) operates between the control element and the data element to achieve programming in the data plane. PCE, on the other hand, is a facilitator for the control plane. Thus the PCC is a control element and makes requests of the PCE which is also functionally a control element. There is no new interaction with the data plane in this model. In fact, PCE could be used in the ForCES model, the GSMP model, or the MPLS/GMPLS model where the data and control plane elements are co-resident in an LSR. Does this answer your question? Thanks, Adrian ----- Original Message ----- From: "Kulkarni, Hrishikesh (Hrishikesh)" To: Sent: Wednesday, October 13, 2004 11:41 AM Subject: [Pce] PCE and ForCES WG difference > Hi all, > > I was going through Forwarding and Control Element Separation (ForCES) > Framework http://www.ietf.org/rfc/rfc3746.txt > > which provides a framework to separate the control (routing) and the > forwarder functionality. > > How is this working group goals or architecture suggestions different from > the one being > suggested by PCE? > > is one of them a subset of the other? > > thanks > rishi. > > _______________________________________________ > 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 Oct 13 09:48:15 2004 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 JAA27526; Wed, 13 Oct 2004 09:48:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjfC-0005TV-Kd; Wed, 13 Oct 2004 09:59:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjRL-0005Ye-VF; Wed, 13 Oct 2004 09:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjPC-0004ln-J1 for pce@megatron.ietf.org; Wed, 13 Oct 2004 09:43:02 -0400 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 JAA27197 for ; Wed, 13 Oct 2004 09:42:57 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHja4-0005Nd-AR for pce@ietf.org; Wed, 13 Oct 2004 09:54:16 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9DDgqkR005259 for ; Wed, 13 Oct 2004 08:42:53 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id <4M31ABG9>; Wed, 13 Oct 2004 19:12:51 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D20B4917B1@ii0015exch002u.iprc.lucent.com> From: "Kulkarni, Hrishikesh (Hrishikesh)" To: "'Adrian Farrel'" , pce@ietf.org Subject: RE: [Pce] PCE and ForCES WG difference Date: Wed, 13 Oct 2004 19:12:41 +0530 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: 73734d43604d52d23b3eba644a169745 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: 386e0819b1192672467565a524848168 Hi Adrian, Thanks for the clarification. I have question regarding section 4.5 So the outcome of the path computation done by the PCE needs to communicated to the forwarding plane (please allow me to assume "forwarding plane " as "network element which doesnt have control plane or routing plane"). Does PCE proposes to provide a protocol for this exchange of info? isnt this protocol which is addressed in GSMP or forces? rishi > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, October 13, 2004 4:57 PM > To: Kulkarni, Hrishikesh (Hrishikesh); pce@ietf.org > Subject: Re: [Pce] PCE and ForCES WG difference > > > Hi Rishi, > > This is a good question which probably applies equally to > ForCES and GSMP. > > If you were to draw a simplistic picture of the ForCES or > GSMP model it would show a clear > separation of the control and data planes. The programming > protocol (e.g. NetLink or GSMP) > operates between the control element and the data element to > achieve programming in the > data plane. > > PCE, on the other hand, is a facilitator for the control > plane. Thus the PCC is a control > element and makes requests of the PCE which is also > functionally a control element. There > is no new interaction with the data plane in this model. > > In fact, PCE could be used in the ForCES model, the GSMP > model, or the MPLS/GMPLS model > where the data and control plane elements are co-resident in an LSR. > > Does this answer your question? > > Thanks, > Adrian > > ----- Original Message ----- > From: "Kulkarni, Hrishikesh (Hrishikesh)" > To: > Sent: Wednesday, October 13, 2004 11:41 AM > Subject: [Pce] PCE and ForCES WG difference > > > > Hi all, > > > > I was going through Forwarding and Control Element > Separation (ForCES) > > Framework http://www.ietf.org/rfc/rfc3746.txt > > > > which provides a framework to separate the control (routing) and the > > forwarder functionality. > > > > How is this working group goals or architecture suggestions > different from > > the one being > > suggested by PCE? > > > > is one of them a subset of the other? > > > > thanks > > rishi. > > > > _______________________________________________ > > 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 Oct 13 16:40:23 2004 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 QAA04343; Wed, 13 Oct 2004 16:40:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHq67-0005lC-6s; Wed, 13 Oct 2004 16:51:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpoi-00015s-LW; Wed, 13 Oct 2004 16:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpdj-0004yx-J7 for pce@megatron.ietf.org; Wed, 13 Oct 2004 16:22:27 -0400 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 QAA03180 for ; Wed, 13 Oct 2004 16:22:26 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpoi-0005Va-6d for pce@ietf.org; Wed, 13 Oct 2004 16:33:49 -0400 Received: from du-069-0217.access.clara.net ([217.158.132.217] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CHpde-000KjO-DV; Wed, 13 Oct 2004 21:22:23 +0100 Message-ID: <069801c4b162$672b5160$21849ed9@Puppy> From: "Adrian Farrel" To: "Kulkarni, Hrishikesh \(Hrishikesh\)" References: <6733C768256DEC42A72BAFEFA9CF06D20B4917B1@ii0015exch002u.iprc.lucent.com> Subject: Re: [Pce] PCE and ForCES WG difference Date: Wed, 13 Oct 2004 21:15:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi again, > I have question regarding section 4.5 > > So the outcome of the path computation done by the PCE needs to communicated > > to the forwarding plane (please allow me to assume "forwarding plane " as > "network element which doesnt have control plane or routing plane"). > Does PCE proposes to provide a protocol for this exchange of info? > isnt this protocol which is addressed in GSMP or forces? Two answers: My understanding is that GSMP and ForCES are intended to supply communication between the control and forwarding planes. In the case described in section 4.5 there is no control plane so these mechanisms do not come into play. As section 4.5 says, it is describing a situation where 'legacy' equipment is currently controlled by the management plane and "all cross-connections are made from the management plane." No change to this mode of operation is intended - that is, although PCE may be used to compute a path, the path is installed through the use of the management plane. You could, I suppose, regard the PCC in this case as being an element of the management plane. I think it is helpful that you have raised this point and we will try to clarify that no change in the mode of operation is intended. And specifically that no matter how PCE is used, there is no change to how the data plane is programmed. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Oct 14 13:13:13 2004 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 NAA08515; Thu, 14 Oct 2004 13:13:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI9LP-00074g-8T; Thu, 14 Oct 2004 13:24:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI94a-0000l0-4T; Thu, 14 Oct 2004 13:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8x4-0007QA-26 for pce@megatron.ietf.org; Thu, 14 Oct 2004 12:59:42 -0400 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 MAA07266 for ; Thu, 14 Oct 2004 12:59:38 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI98G-0006k2-2Z for pce@ietf.org; Thu, 14 Oct 2004 13:11:16 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 18:58:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Oct 2004 18:58:51 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B019D42F@ftrdmel3.rd.francetelecom.fr> Thread-Topic: draft-boucadair-pcp-interas-00.txt Thread-Index: AcSyDxTPtaB15hCfReShJvD8yoQUeg== From: "BOUCADAIR Mohamed RD-CORE-CAE" To: X-OriginalArrivalTime: 14 Oct 2004 16:58:51.0718 (UTC) FILETIME=[14D82660:01C4B20F] X-Spam-Score: 0.9 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Pce] draft-boucadair-pcp-interas-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: , Content-Type: multipart/mixed; boundary="===============2053839798==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. --===============2053839798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B20F.14BBFAF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B20F.14BBFAF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Inter-AS PCE Communication protocol Author(s) : M. Boucadair, P. Morand Filename : draft-boucadair-pcp-interas-00.txt Pages : 22 Date : 2004-10-13 =09 This draft describes a new protocol allowing communication between=20 two Path Computation Elements (PCEs) located in different domains in=20 order to compute inter-domain paths satisfying a set of QoS=20 constraints. This protocol could also be used for intra-domain=20 purposes. A URL for this Internet-Draft is: To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit = =20 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-boucadair-pcp-interas-00.txt". A list of Internet-Drafts directories can be found in =20 or Internet-Drafts can also be obtained by e-mail. ------_=_NextPart_001_01C4B20F.14BBFAF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-boucadair-pcp-interas-00.txt

A New Internet-Draft is available = from the on-line Internet-Drafts directories.


        Title   =         : Inter-AS PCE Communication = protocol
        = Author(s)       : M. Boucadair, P. = Morand
        = Filename        : = draft-boucadair-pcp-interas-00.txt
        Pages   =         : 22
        Date    =         : 2004-10-13
       
This draft describes a new protocol allowing communication between
   two Path Computation Elements (PCEs) located in different = domains in
   order  to  compute  inter-domain  = paths  satisfying  a  set  of  QoS
   constraints. This protocol could also be used for = intra-domain
   purposes.

A URL for this Internet-Draft is:
<http://www.ietf.org/internet-drafts/draft-boucadair-pcp-interas-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-boucadair-pcp-interas-00.txt".

A list of Internet-Drafts directories can be found in
<http://www.ietf.org/shadow.html<= /A>>
or  <ftp://ftp.ietf.org/iet= f/1shadow-sites.txt>


Internet-Drafts can also be obtained = by e-mail.

------_=_NextPart_001_01C4B20F.14BBFAF8-- --===============2053839798== 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 --===============2053839798==-- From pce-bounces@ietf.org Thu Oct 14 17:27:10 2004 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 RAA08073; Thu, 14 Oct 2004 17:27:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDJC-0006O9-1s; Thu, 14 Oct 2004 17:38:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CID3I-0007yQ-Sh; Thu, 14 Oct 2004 17:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICy3-0004Rw-J0 for pce@megatron.ietf.org; Thu, 14 Oct 2004 17:16:59 -0400 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 RAA06494 for ; Thu, 14 Oct 2004 17:16:56 -0400 (EDT) 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 1CID9H-0005sQ-Rf for pce@ietf.org; Thu, 14 Oct 2004 17:28:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2004 14:23:28 -0700 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 i9ELGmk2013110; Thu, 14 Oct 2004 14:16:49 -0700 (PDT) Received: from [68.189.240.215] (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA24777; Thu, 14 Oct 2004 14:16:49 -0700 (PDT) In-Reply-To: <6CF039C5B32037498B02251E11CDE6B019D42F@ftrdmel3.rd.francetelecom.fr> References: <6CF039C5B32037498B02251E11CDE6B019D42F@ftrdmel3.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <5CD7364E-1E26-11D9-9D9F-000D93330B14@cisco.com> From: JP Vasseur Subject: Re: [Pce] draft-boucadair-pcp-interas-00.txt Date: Thu, 14 Oct 2004 17:16:49 -0400 To: "BOUCADAIR Mohamed RD-CORE-CAE" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.8 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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="===============1575834240==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 --===============1575834240== Content-Type: multipart/alternative; boundary=Apple-Mail-16--777674297 --Apple-Mail-16--777674297 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Hi Mohamed, Thanks for your draft - Note that at this point, we do not have a WG. =20= We will run a second BOF in Washington. Comment whether your draft address an item of the proposed charter. JP. On Oct 14, 2004, at 12:58 PM, BOUCADAIR Mohamed RD-CORE-CAE wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : Inter-AS = PCE Communication protocol > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : M. Boucadair, P. = Morand > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-boucadair-pcp-interas-00.txt > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : 22 > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : = 2004-10-13 > =A0=A0=A0=A0=A0=A0=A0 > This draft describes a new protocol allowing communication between > =A0=A0 two Path Computation Elements (PCEs) located in different = domains =20 > in > =A0=A0 order=A0 to=A0 compute=A0 inter-domain=A0 paths=A0 satisfying=A0= a=A0 set=A0 of=A0 =20 > QoS > =A0=A0 constraints. This protocol could also be used for intra-domain > =A0=A0 purposes. > > A URL for this Internet-Draft is: > -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 =20= > of the message.=A0 > You can also visit=A0 =20 > > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > =A0=A0=A0=A0=A0=A0=A0 "get draft-boucadair-pcp-interas-00.txt". > > A list of Internet-Drafts directories can be found in > > or=A0 > > > Internet-Drafts can also be obtained by e-mail. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-16--777674297 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mohamed,=20 Thanks for your draft - Note that at this point, we do not have a WG. We will run a second BOF in Washington. Comment whether your draft address an item of the proposed charter. JP. On Oct 14, 2004, at 12:58 PM, BOUCADAIR Mohamed RD-CORE-CAE wrote: Courier NewA New Internet-Draft is available from the on-line Internet-Drafts = directories. Courier New =A0=A0=A0=A0=A0=A0=A0 = Title=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : Inter-AS PCE Communication protocol Courier New =A0=A0=A0=A0=A0=A0=A0 = Author(s)=A0=A0=A0=A0=A0=A0 : M. Boucadair, P. Morand Courier New =A0=A0=A0=A0=A0=A0=A0 = Filename=A0=A0=A0=A0=A0=A0=A0 : draft-boucadair-pcp-interas-00.txt Courier New =A0=A0=A0=A0=A0=A0=A0 = Pages=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : 22 Courier New =A0=A0=A0=A0=A0=A0=A0 = Date=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : 2004-10-13 Courier New = =A0=A0=A0=A0=A0=A0=A0 Courier New This draft describes a new protocol allowing communication between Courier New =A0=A0 two Path = Computation Elements (PCEs) located in different domains in Courier New =A0=A0 order=A0 to=A0 = compute=A0 inter-domain=A0 paths=A0 satisfying=A0 a=A0 set=A0 of=A0 = QoS Courier New =A0=A0 constraints. This protocol could also be used for intra-domain Courier New =A0=A0 = purposes. Courier New A URL for this Internet-Draft is: Courier = New0000,0000,FFFF<<000= 0,0000,EEEEhttp://www.ietf.org/internet-drafts/draft-boucadair-pcp= -interas-00.txt0000,0000,FFFF> Courier NewTo remove yourself from the I-D Announcement list, send a message to Courier New i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=A0 Courier New You can also visit=A0 = Courier = New0000,0000,FFFF<<000= 0,0000,EEEEhttps://www1.ietf.org/mailman/listinfo/I-D-announce0000,0000,FFFF> Courier New to change your subscription settings. Courier New Internet-Drafts are also available by anonymous FTP. Login with the username Courier New "anonymous" and a password of your e-mail address. After logging in, Courier New type "cd internet-drafts" and then Courier New =A0=A0=A0=A0=A0=A0=A0 "get draft-boucadair-pcp-interas-00.txt". Courier New A list of Internet-Drafts directories can be found in Courier = New0000,0000,FFFF<<000= 0,0000,EEEEhttp://www.ietf.org/shadow.html00= 00,0000,FFFF> Courier New or=A0 = Courier = New0000,0000,FFFF<<000= 0,0000,EEEEftp://ftp.ietf.org/ietf/1shadow-sites.txt0000,0000,FFFF> Courier NewInternet-Drafts can also be obtained by e-mail. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce = --Apple-Mail-16--777674297-- --===============1575834240== 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 --===============1575834240==-- From pce-bounces@ietf.org Thu Oct 14 17:29:01 2004 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 RAA08239; Thu, 14 Oct 2004 17:29:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDKy-0006RL-Ky; Thu, 14 Oct 2004 17:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CID6n-0000pY-Ez; Thu, 14 Oct 2004 17:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICzi-0005Qb-G2 for pce@megatron.ietf.org; Thu, 14 Oct 2004 17:18:42 -0400 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 RAA06900 for ; Thu, 14 Oct 2004 17:18:39 -0400 (EDT) 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 1CIDAx-0005zt-2A for pce@ietf.org; Thu, 14 Oct 2004 17:30:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2004 14:24:46 -0700 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 i9ELI7OE022211; Thu, 14 Oct 2004 14:18:08 -0700 (PDT) Received: from [68.189.240.215] (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA27462; Thu, 14 Oct 2004 14:18:07 -0700 (PDT) In-Reply-To: <009a01c4b06d$5a6b45c0$7a1810ac@movaz.com> References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> <008901c4af9a$b140e0e0$7a1810ac@movaz.com> <74368DBF-1BE2-11D9-B106-000D93330B14@cisco.com> <009a01c4b06d$5a6b45c0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B7F68D4-1E26-11D9-9D9F-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Thu, 14 Oct 2004 17:18:08 -0400 To: "Igor Bryskin" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Hi Igor, On Oct 12, 2004, at 11:08 AM, Igor Bryskin wrote: > Hey JP, > > Looks like we are in a wild agreement. > Indeed, feel free to propose GMPLS PCE-cap that should be carried by the IGP extensions. JP. > Igor > > ----- Original Message ----- > From: "JP Vasseur" > To: "Igor Bryskin" > Cc: "Adrian Farrel" ; > Sent: Monday, October 11, 2004 8:05 PM > Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and > mailing list, > > >> Hi Igor, >> >> On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote: >> >>> See in-line. >>> >>> Igor >>> >>> ----- Original Message ----- >>> From: "Adrian Farrel" >>> To: >>> Cc: >>> Sent: Saturday, October 09, 2004 1:55 PM >>> Subject: Re: Path Computation Element (PCE) Architecture and mailing >>> list, >>> >>> >>>> [Pruned recipients] >>>> >>>> Hi Igor, >>>> >>>>> I think this is a vey sound document. I have a suggestion though. >>>> >>>> Thanks, and thanks. >>>> >>>>> It would be extreamely useful if a PCE could advertise its >>>>> capabilities >>>>> such as: >>>>> >>>>> a) set of constraints that it can account for (diversity, SRLGs, >>>>> optical >>>>> impairements, wavelenght continuity, etc.) >>>>> >>>>> b) number of switching capability layers (and which); >>>>> >>>>> c) number of path selection criterias (and which); >>>>> >>>>> d) whether it is a stateless path calculator or can send updates >>>>> about >>>>> better paths that might be available in future; >>>>> >>>>> e) whether it can compute P2MP trees (and which types); >>>>> >>>>> f) whether it can ensure the resource sharing between backup >>>>> tunnels; >>>>> >>>>> g) etc. >>>>> >>>>> This information would help a lot for a potential PCC that >>>>> dynamically >>>>> learns about PCEs available on the network to decide which of them >>>>> to >>> use. >>>> >>>> You're right. This should go in section 6.4. >>>> >>>> In addition, it seems to me that a PCC might ask a PCE to perform a >>> particular type of >>>> service and receive a response that says, "Sorry, I can't do that, >>>> these >>> are the things I >>>> can do. Here is the address of a PCE that may be able to better >>>> fulfil >>> your request." >>> >>> IB>> It won't be necessary if PCE advertises its capabilities >>> separately. >>> What you are suggesting will make the PCC-PCE protocol heavier >>> without >>> giving actual benefits. But you are right, it is too early at this >>> stage to >>> discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE >>> signalling protocols will be by far the biggest challenge, and we >>> must >>> not >>> complicate it unnecessarily. >>> >> >> See my previous answer, I'm also a strong advocate for advertising PCE >> cap, such advertisement will be required anyway for the PCE discovery >> especially in multi-domain environments. >> >> Thanks for your feed-backs. >> >> Cheers >> >> JP. >> >>> Igor >>> >>>> >>>> We need to be careful not to get too far into the possible solutions >>>> at >>> this stage, but I >>>> think the point you raise is important for the architecture. >>>> >>>> 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 Thu Oct 14 17:52:13 2004 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 RAA10644; Thu, 14 Oct 2004 17:52:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDhR-00072E-EA; Thu, 14 Oct 2004 18:03:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDVJ-0005Pw-RD; Thu, 14 Oct 2004 17:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDOV-0004QO-Ql for pce@megatron.ietf.org; Thu, 14 Oct 2004 17:44:19 -0400 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 RAA09971 for ; Thu, 14 Oct 2004 17:44:17 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDZk-0006oy-Cp for pce@ietf.org; Thu, 14 Oct 2004 17:55:56 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 23:40:54 +0200 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] Proposed Charter for a PCE WG Date: Thu, 14 Oct 2004 23:40:52 +0200 Message-ID: Thread-Topic: [Pce] Proposed Charter for a PCE WG Thread-Index: AcStiDstyCKqbg5aQOyrJ3cy/ovLIwErUKAw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Adrian Farrel" , X-OriginalArrivalTime: 14 Oct 2004 21:40:54.0213 (UTC) FILETIME=[7B6FF750:01C4B236] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Hi Adrian and all, This proposed charter sounds good Just two points: -Could it be possible to explicitely include PCE-based backup path = computation within the charter ? Either include it in the first item or = in a dedicated item -It would be good to explicitely mention GMPLS aspects as part of the = charter Regards, JL >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel >Envoy=E9 : samedi 9 octobre 2004 00:33 >=C0 : pce@ietf.org >Objet : [Pce] Proposed Charter for a PCE WG > > >Hi, > >The main purposes of the PCE BOF in Washington DC will be to=20 >discuss the PCE architecture, and the need for and scope of a=20 >PCE WG. Hence the proposed charter is particularly important. > >JP and I have put together the following as a starting point,=20 >and we would very much appreciate your comments on the mailing=20 >list in advance of the meeting. Specific milestones are=20 >pending agreement on the major work areas. > >Thanks, >Adrian >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Proposed Charter > >WG items: >- Functional specification of Generalized Traffic Engineered LSP path > computation techniques involving Path Computation Element(s). This > includes the case of intra IGP area, inter IGP area, inter-AS and > inter-provider TE LSPs path computation for both Point to Point, > Point to Multipoint and Multipoint to Multipoint TE LSPs. >- Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) > extensions required by PCE-based path computation techniques. > Specification of routing extensions in support of PCE discovery > techniques within an IGP area and across multiple IGP areas, ASes > and Provider networks. The proposed extensions will done in > conjunction with the WGs in charge of the specification of those > protocols. >- Specification of new protocols or modifications to existing > protocols to facilitate communication between LSRs and PCEs, and > between a PCE and other PCEs. >- Definition of protocol-independent metrics defining path quality > measurement criteria, algorithm complexity and scalability criteria > related to path computation techniques. >- Specification of requirements and protocol extensions related to the > policy, security and confidentiality aspects of PCE-based path > computation techniques involving PCEs of multiple Providers. >- Definition of MIBs and management procedures related to the new > protocols, protocol extensions and operational elements defined > by the WG. > >The WG will work closely with the following other WGs: CCAMP,=20 >MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and=20 >OIF where appropriate. > > >_______________________________________________ >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 Thu Oct 14 18:34:59 2004 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 SAA15421; Thu, 14 Oct 2004 18:34:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIEMp-0007w3-RT; Thu, 14 Oct 2004 18:46:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIE9C-0003ih-Lo; Thu, 14 Oct 2004 18:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIE6d-000320-Iq for pce@megatron.ietf.org; Thu, 14 Oct 2004 18:29:55 -0400 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 SAA14966 for ; Thu, 14 Oct 2004 18:29:52 -0400 (EDT) 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 1CIEHi-0007pz-7p for pce@ietf.org; Thu, 14 Oct 2004 18:41:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2004 15:35:50 -0700 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 i9EMTAOE011207; Thu, 14 Oct 2004 15:29:10 -0700 (PDT) Received: from [68.189.240.215] (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA01506; Thu, 14 Oct 2004 15:29:10 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <7815707E-1E30-11D9-9D9F-000D93330B14@cisco.com> From: JP Vasseur Subject: Re: RE : [Pce] Proposed Charter for a PCE WG Date: Thu, 14 Oct 2004 18:29:10 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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="===============1484483910==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c --===============1484483910== Content-Type: multipart/alternative; boundary=Apple-Mail-19--773333623 --Apple-Mail-19--773333623 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jean-Louis, On Oct 14, 2004, at 5:40 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Adrian and all, > > This proposed charter sounds good > Thanks. > Just two points: > > -Could it be possible to explicitely include PCE-based backup path=20 > computation within the charter ? Either include it in the first item=20= > or in a dedicated item > Agree, we should list as a specific item since the problems to handled=20= may be specific to this problem space. We will update the proposed charter accordingly. > -It would be good to explicitely mention GMPLS aspects as part of the=20= > charter > - Functional specification of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s). so this covers GMPLS, since indeed PCE-based computation is a good=20 candidate for Generalized LSP path computation considering the=20 complexity of multi-constraints algorithms, a quite common case in=20 GMPLS environments. Thanks for your feed-backs. JP. > Regards, > > JL > >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel >> Envoy=E9 : samedi 9 octobre 2004 00:33 >> =C0 : pce@ietf.org >> Objet : [Pce] Proposed Charter for a PCE WG >> >> >> Hi, >> >> The main purposes of the PCE BOF in Washington DC will be to >> discuss the PCE architecture, and the need for and scope of a >> PCE WG. Hence the proposed charter is particularly important. >> >> JP and I have put together the following as a starting point, >> and we would very much appreciate your comments on the mailing >> list in advance of the meeting. Specific milestones are >> pending agreement on the major work areas. >> >> Thanks, >> Adrian >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Proposed Charter >> >> WG items: >> - Functional specification of Generalized Traffic Engineered LSP path >> computation techniques involving Path Computation Element(s). This >> includes the case of intra IGP area, inter IGP area, inter-AS and >> inter-provider TE LSPs path computation for both Point to Point, >> Point to Multipoint and Multipoint to Multipoint TE LSPs. >> - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) >> extensions required by PCE-based path computation techniques. >> Specification of routing extensions in support of PCE discovery >> techniques within an IGP area and across multiple IGP areas, ASes >> and Provider networks. The proposed extensions will done in >> conjunction with the WGs in charge of the specification of those >> protocols. >> - Specification of new protocols or modifications to existing >> protocols to facilitate communication between LSRs and PCEs, and >> between a PCE and other PCEs. >> - Definition of protocol-independent metrics defining path quality >> measurement criteria, algorithm complexity and scalability criteria >> related to path computation techniques. >> - Specification of requirements and protocol extensions related to = the >> policy, security and confidentiality aspects of PCE-based path >> computation techniques involving PCEs of multiple Providers. >> - Definition of MIBs and management procedures related to the new >> protocols, protocol extensions and operational elements defined >> by the WG. >> >> The WG will work closely with the following other WGs: CCAMP, >> MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and >> OIF where appropriate. >> >> >> _______________________________________________ >> 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 > --Apple-Mail-19--773333623 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jean-Louis, On Oct 14, 2004, at 5:40 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: Hi Adrian and all, This proposed charter sounds good Thanks. Just two points: -Could it be possible to explicitely include PCE-based backup path computation within the charter ? Either include it in the first item or in a dedicated item Agree, we should list as a specific item since the problems to handled may be specific to this problem space. We will update the proposed charter accordingly. -It would be good to explicitely mention GMPLS aspects as part of the charter - Functional specification of 8080,0000,0000Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s). so this covers GMPLS, since indeed PCE-based computation is a good candidate for Generalized LSP path computation considering the complexity of multi-constraints algorithms, a quite common case in GMPLS environments. Thanks for your feed-backs. JP. Regards, JL -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel Envoy=E9 : samedi 9 octobre 2004 00:33 =C0 : pce@ietf.org Objet : [Pce] Proposed Charter for a PCE WG Hi, The main purposes of the PCE BOF in Washington DC will be to=20 discuss the PCE architecture, and the need for and scope of a=20 PCE WG. Hence the proposed charter is particularly important. JP and I have put together the following as a starting point,=20 and we would very much appreciate your comments on the mailing=20 list in advance of the meeting. Specific milestones are=20 pending agreement on the major work areas. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed Charter WG items: - Functional specification of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s). This includes the case of intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for both Point to Point, Point to Multipoint and Multipoint to Multipoint TE LSPs. - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) extensions required by PCE-based path computation techniques. Specification of routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks. The proposed extensions will done in conjunction with the WGs in charge of the specification of those protocols. - Specification of new protocols or modifications to existing protocols to facilitate communication between LSRs and PCEs, and between a PCE and other PCEs. - Definition of protocol-independent metrics defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements defined by the WG. The WG will work closely with the following other WGs: CCAMP,=20 MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and=20 OIF where appropriate. _______________________________________________ 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 = --Apple-Mail-19--773333623-- --===============1484483910== 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 --===============1484483910==-- From pce-bounces@ietf.org Thu Oct 14 18:44:28 2004 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 SAA15984; Thu, 14 Oct 2004 18:44:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIEW0-00086v-Hx; Thu, 14 Oct 2004 18:56:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIEK3-0005XW-N3; Thu, 14 Oct 2004 18:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIEIC-0005HL-5a for pce@megatron.ietf.org; Thu, 14 Oct 2004 18:41:52 -0400 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 SAA15878 for ; Thu, 14 Oct 2004 18:41:49 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIETP-00083v-TZ for pce@ietf.org; Thu, 14 Oct 2004 18:53:29 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 7B90F16AE6; Thu, 14 Oct 2004 18:41:13 -0400 (EDT) Message-ID: <013401c4b23e$e8d16510$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Jean Philippe Vasseur" References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> <02cf01c4ae29$408c3880$21849ed9@Puppy> <008901c4af9a$b140e0e0$7a1810ac@movaz.com> <74368DBF-1BE2-11D9-B106-000D93330B14@cisco.com> <4.3.2.7.2.20041012123236.05b6bd18@wells.cisco.com> Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Thu, 14 Oct 2004 18:41:13 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit JP, Here is my comments on the document. 1. For some reason you define PCC as any head-end LSR. IMO PCC is any LSR that requires remote path computation service. It could be any transit LSR (e.g. to compute FRR backup tunnel); 2. The following capability bits are missing: S: =1 - PCE keeps states for all PCE requests and may send updates later if better path(s) become available. =0 - PCE is stateless path calculator; R:=1 -PCE is capable of computing paths crossing multiple switching layers (regions) =0 - PCE can compute path only within a single switching layer; X:= 1 - handles exclusions (links, nodes) Y:= 1- handles inclusions, i.e. it is possible to specify ordered list(s) of links/nodes (strictly or loosely) that will appear in the selected path(s) 3. Diversity There should be TLV(s) specifying whether PCE can compute: SRLG diverse, node diverse, link diverse, best diverse paths 4. Link level constraints There should be TLVs specifying sub-TLVs of a TE LINK TLV that could be used as constraints 5. Path level constraints This would be most difficult thing to describe: max path end-to-end length, delay/jitter, wavelength contnuity, etc. For now I suggest a separate TLV per each constraint. Igor ----- Original Message ----- From: "Jean Philippe Vasseur" To: "Igor Bryskin" Cc: "Adrian Farrel" ; Sent: Tuesday, October 12, 2004 12:34 PM Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, > Hi Igor, > > At 11:08 AM 10/12/2004 -0400, Igor Bryskin wrote: > >Hey JP, > > > >Looks like we are in a wild agreement. > > Perfect - let's continue the discussion on how to extend > draft-vasseur-ospf-te-caps-00.txt and draft-vasseur-isis-te-caps-00.txt to > cope with GMPLS specific parameters. Your input is very welcome. > > Cheers. > > JP. > > >Igor > > > >----- Original Message ----- > >From: "JP Vasseur" > >To: "Igor Bryskin" > >Cc: "Adrian Farrel" ; > >Sent: Monday, October 11, 2004 8:05 PM > >Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and > >mailing list, > > > > > > > Hi Igor, > > > > > > On Oct 11, 2004, at 10:00 AM, Igor Bryskin wrote: > > > > > > > See in-line. > > > > > > > > Igor > > > > > > > > ----- Original Message ----- > > > > From: "Adrian Farrel" > > > > To: > > > > Cc: > > > > Sent: Saturday, October 09, 2004 1:55 PM > > > > Subject: Re: Path Computation Element (PCE) Architecture and mailing > > > > list, > > > > > > > > > > > >> [Pruned recipients] > > > >> > > > >> Hi Igor, > > > >> > > > >>> I think this is a vey sound document. I have a suggestion though. > > > >> > > > >> Thanks, and thanks. > > > >> > > > >>> It would be extreamely useful if a PCE could advertise its > > > >>> capabilities > > > >>> such as: > > > >>> > > > >>> a) set of constraints that it can account for (diversity, SRLGs, > > > >>> optical > > > >>> impairements, wavelenght continuity, etc.) > > > >>> > > > >>> b) number of switching capability layers (and which); > > > >>> > > > >>> c) number of path selection criterias (and which); > > > >>> > > > >>> d) whether it is a stateless path calculator or can send updates > > > >>> about > > > >>> better paths that might be available in future; > > > >>> > > > >>> e) whether it can compute P2MP trees (and which types); > > > >>> > > > >>> f) whether it can ensure the resource sharing between backup tunnels; > > > >>> > > > >>> g) etc. > > > >>> > > > >>> This information would help a lot for a potential PCC that > > > >>> dynamically > > > >>> learns about PCEs available on the network to decide which of them to > > > > use. > > > >> > > > >> You're right. This should go in section 6.4. > > > >> > > > >> In addition, it seems to me that a PCC might ask a PCE to perform a > > > > particular type of > > > >> service and receive a response that says, "Sorry, I can't do that, > > > >> these > > > > are the things I > > > >> can do. Here is the address of a PCE that may be able to better fulfil > > > > your request." > > > > > > > > IB>> It won't be necessary if PCE advertises its capabilities > > > > separately. > > > > What you are suggesting will make the PCC-PCE protocol heavier without > > > > giving actual benefits. But you are right, it is too early at this > > > > stage to > > > > discuss the solution yet. I believe, though, that PCC-PCE and PCE-PCE > > > > signalling protocols will be by far the biggest challenge, and we must > > > > not > > > > complicate it unnecessarily. > > > > > > > > > > See my previous answer, I'm also a strong advocate for advertising PCE > > > cap, such advertisement will be required anyway for the PCE discovery > > > especially in multi-domain environments. > > > > > > Thanks for your feed-backs. > > > > > > Cheers > > > > > > JP. > > > > > > > Igor > > > > > > > >> > > > >> We need to be careful not to get too far into the possible solutions > > > >> at > > > > this stage, but I > > > >> think the point you raise is important for the architecture. > > > >> > > > >> 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 Fri Oct 15 01:04:32 2004 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 BAA08833; Fri, 15 Oct 2004 01:04:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIKRn-0005o8-Sw; Fri, 15 Oct 2004 01:16:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIKF1-0000c4-VA; Fri, 15 Oct 2004 01:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIKAh-0000Ku-L8 for pce@megatron.ietf.org; Fri, 15 Oct 2004 00:58:31 -0400 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 AAA08439 for ; Fri, 15 Oct 2004 00:58:28 -0400 (EDT) Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIKLz-0005hI-CO for pce@ietf.org; Fri, 15 Oct 2004 01:10:12 -0400 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1004.kddi.com with ESMTP id i9F4vdi19304; Fri, 15 Oct 2004 13:57:39 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com with ESMTP id i9F4vdb27932; Fri, 15 Oct 2004 13:57:39 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.146]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041015045738.CVSR1043.usjk1009.kddi.com@[127.0.0.1]>; Fri, 15 Oct 2004 13:57:38 +0900 Date: Fri, 15 Oct 2004 13:57:30 +0900 From: Kenji Kumaki To: Adrian Farrel , JP Vasseur Subject: Re: [Pce] Proposed Charter for a PCE WG In-Reply-To: <024101c4ad86$b685a010$21849ed9@Puppy> References: <024101c4ad86$b685a010$21849ed9@Puppy> Message-Id: <20041015135722.0264.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.08 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi JP and Adrian, I agree with this proposed charter. Is PCE-based path computation in Multi-layer network environment within this charter? Regards, Kenji On Fri, 8 Oct 2004 23:32:32 +0100 "Adrian Farrel" wrote: > Hi, > > The main purposes of the PCE BOF in Washington DC will be to discuss the PCE architecture, > and the need for and scope of a PCE WG. Hence the proposed charter is particularly > important. > > JP and I have put together the following as a starting point, and we would very much > appreciate your comments on the mailing list in advance of the meeting. Specific > milestones are pending agreement on the major work areas. > > Thanks, > Adrian > ============ > Proposed Charter > > WG items: > - Functional specification of Generalized Traffic Engineered LSP path > computation techniques involving Path Computation Element(s). This > includes the case of intra IGP area, inter IGP area, inter-AS and > inter-provider TE LSPs path computation for both Point to Point, > Point to Multipoint and Multipoint to Multipoint TE LSPs. > - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) > extensions required by PCE-based path computation techniques. > Specification of routing extensions in support of PCE discovery > techniques within an IGP area and across multiple IGP areas, ASes > and Provider networks. The proposed extensions will done in > conjunction with the WGs in charge of the specification of those > protocols. > - Specification of new protocols or modifications to existing > protocols to facilitate communication between LSRs and PCEs, and > between a PCE and other PCEs. > - Definition of protocol-independent metrics defining path quality > measurement criteria, algorithm complexity and scalability criteria > related to path computation techniques. > - Specification of requirements and protocol extensions related to the > policy, security and confidentiality aspects of PCE-based path > computation techniques involving PCEs of multiple Providers. > - Definition of MIBs and management procedures related to the new > protocols, protocol extensions and operational elements defined > by the WG. > > The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will > also cooperate with the ITU-T and OIF where appropriate. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce -- Kenji Kumaki _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 15 02:14:42 2004 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 CAA23252; Fri, 15 Oct 2004 02:14:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CILXk-0006q2-Rt; Fri, 15 Oct 2004 02:26:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CILJx-0003vD-Mk; Fri, 15 Oct 2004 02:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CILJg-0003ig-Qe for pce@megatron.ietf.org; Fri, 15 Oct 2004 02:11:53 -0400 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 CAA20850 for ; Fri, 15 Oct 2004 02:11:51 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CILUp-0006nG-3X for pce@ietf.org; Fri, 15 Oct 2004 02:23:34 -0400 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 i9F6BUFL028032; Fri, 15 Oct 2004 15:11:33 +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 i9F6BUWc021338; Fri, 15 Oct 2004 15:11:30 +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 i9F6BTln021332; Fri, 15 Oct 2004 15:11:30 +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 i9F6BTkK007538; Fri, 15 Oct 2004 15:11:29 +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 i9F6BTI3007529; Fri, 15 Oct 2004 15:11:29 +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 i9F6BT7b028636; Fri, 15 Oct 2004 15:11:29 +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 i9F6BS3w013496; Fri, 15 Oct 2004 15:11:28 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9F6BSr5013493; Fri, 15 Oct 2004 15:11:28 +0900 (JST) Received: from lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id PAA05006; Fri, 15 Oct 2004 15:11:28 +0900 (JST) Message-ID: <416F6A0D.3000109@lab.ntt.co.jp> Date: Fri, 15 Oct 2004 15:11:25 +0900 From: Kohei Shiomoto Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Kenji Kumaki Subject: Re: [Pce] Proposed Charter for a PCE WG References: <024101c4ad86$b685a010$21849ed9@Puppy> <20041015135722.0264.KE-KUMAKI@kddi.com> In-Reply-To: <20041015135722.0264.KE-KUMAKI@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Hi Kenji It is a good point. I would suggest that the list of scenarios for the functional specification of PCE techniques should also include inter-region (that is, between GMPLS switching regions) and inter-layer (that is, between layers of a multi-layer network). Thanks, -- Kohei Shiomoto Kenji Kumaki wrote: >Hi JP and Adrian, > >I agree with this proposed charter. > >Is PCE-based path computation in Multi-layer network environment within >this charter? > >Regards, >Kenji > >On Fri, 8 Oct 2004 23:32:32 +0100 >"Adrian Farrel" wrote: > > > >>Hi, >> >>The main purposes of the PCE BOF in Washington DC will be to discuss the PCE architecture, >>and the need for and scope of a PCE WG. Hence the proposed charter is particularly >>important. >> >>JP and I have put together the following as a starting point, and we would very much >>appreciate your comments on the mailing list in advance of the meeting. Specific >>milestones are pending agreement on the major work areas. >> >>Thanks, >>Adrian >>============ >>Proposed Charter >> >>WG items: >>- Functional specification of Generalized Traffic Engineered LSP path >> computation techniques involving Path Computation Element(s). This >> includes the case of intra IGP area, inter IGP area, inter-AS and >> inter-provider TE LSPs path computation for both Point to Point, >> Point to Multipoint and Multipoint to Multipoint TE LSPs. >>- Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) >> extensions required by PCE-based path computation techniques. >> Specification of routing extensions in support of PCE discovery >> techniques within an IGP area and across multiple IGP areas, ASes >> and Provider networks. The proposed extensions will done in >> conjunction with the WGs in charge of the specification of those >> protocols. >>- Specification of new protocols or modifications to existing >> protocols to facilitate communication between LSRs and PCEs, and >> between a PCE and other PCEs. >>- Definition of protocol-independent metrics defining path quality >> measurement criteria, algorithm complexity and scalability criteria >> related to path computation techniques. >>- Specification of requirements and protocol extensions related to the >> policy, security and confidentiality aspects of PCE-based path >> computation techniques involving PCEs of multiple Providers. >>- Definition of MIBs and management procedures related to the new >> protocols, protocol extensions and operational elements defined >> by the WG. >> >>The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will >>also cooperate with the ITU-T and OIF where appropriate. >> >> >>_______________________________________________ >>Pce mailing list >>Pce@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/pce >> >> > > > -- Kohei Shiomoto, Ph.D NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 4549 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 15 04:41:58 2004 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 EAA05712; Fri, 15 Oct 2004 04:41:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINqJ-000125-G2; Fri, 15 Oct 2004 04:53:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CINcr-0007xO-DE; Fri, 15 Oct 2004 04:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CINWW-00075G-I0 for pce@megatron.ietf.org; Fri, 15 Oct 2004 04:33:19 -0400 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 EAA04982 for ; Fri, 15 Oct 2004 04:33:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINho-0000qr-3P for pce@ietf.org; Fri, 15 Oct 2004 04:44:59 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CINWR-000LcW-Sa; Fri, 15 Oct 2004 08:33:12 +0000 Message-ID: <416F8B47.9040306@psg.com> Date: Fri, 15 Oct 2004 10:33:11 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Proposed Charter for a PCE WG References: <024101c4ad86$b685a010$21849ed9@Puppy> In-Reply-To: <024101c4ad86$b685a010$21849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit hi adrian, jp, thanks for putting this together, several comments here below: > Proposed Charter > > WG items: > - Functional specification of Generalized Traffic Engineered LSP path > computation techniques involving Path Computation Element(s). This > includes the case of intra IGP area, inter IGP area, inter-AS and > inter-provider TE LSPs path computation for both Point to Point, > Point to Multipoint and Multipoint to Multipoint TE LSPs. -> when you say "both" to what does it apply in the above sentence ? -> this item uses a terminology related to the partitioning of the network in terms of routing instead of PCE responsibility scope - so should i consider this as part of the work to disambuiguate the situation ? -> is it expected as part of this item to deliver the functionality for "segment" computation for a given path p2p, p2mp or mp2mp LSP ? as this is not explicitly indicated > - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) > extensions required by PCE-based path computation techniques. -> would you clarify the implication of RSVP-TE in path computation "techniques" ? as there are no resource reservation expected here if the intent is to say "result of computation should be usable by signaling protocols used to setup the LSP along the computed path" i think this would better translate implication of RSVP-TE > Specification of routing extensions in support of PCE discovery > techniques within an IGP area and across multiple IGP areas, ASes > and Provider networks. The proposed extensions will done in > conjunction with the WGs in charge of the specification of those > protocols. -> there should be an explicit item detailing what are the potential PCE discovery techniques are/or involved mechanisms b/f discussing for routing extensions (as routing is not the only means to achieve this anyway) -> which WG wrt to RSVP-TE as mentioned here above (note: OSPF, ISIS and BGP have an associate WG) - RSVP(-TE) does not or do we assume implicitly it is the CCAMP WG ? > - Specification of new protocols or modifications to existing > protocols to facilitate communication between LSRs and PCEs, and > between a PCE and other PCEs. -> the term LSR is imho not accuarate enough - also referring to the discussion wrt to FORCES - i think there is the need to introduce the term PC Requestor, Client or equivalent (instead of LSR) to avoid further confusion and ensure genericity > - Definition of protocol-independent metrics defining path quality > measurement criteria, algorithm complexity and scalability criteria > related to path computation techniques. > > - Specification of requirements and protocol extensions related to the > policy, security and confidentiality aspects of PCE-based path > computation techniques involving PCEs of multiple Providers. -> why only multiple providers would be involved in this item ? why not PCEs of multiple administrative entities ? > - Definition of MIBs and management procedures related to the new > protocols, protocol extensions and operational elements defined > by the WG. > > The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will > also cooperate with the ITU-T and OIF where appropriate. -> as BGP is part of the protocols in the loop, IDR should also be listed as part of the above list of WGs _______________________________________________ > 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 Oct 15 08:41:34 2004 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 IAA23803; Fri, 15 Oct 2004 08:41:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIRaD-0006Bb-5P; Fri, 15 Oct 2004 08:53:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIRMP-00038d-U8; Fri, 15 Oct 2004 08:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIRL9-0002hP-Fm for pce@megatron.ietf.org; Fri, 15 Oct 2004 08:37:47 -0400 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 IAA23502 for ; Fri, 15 Oct 2004 08:37:45 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIRWV-00065J-Vd for pce@ietf.org; Fri, 15 Oct 2004 08:49:32 -0400 Received: from du-069-0342.access.clara.net ([217.158.145.88] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.34) id 1CIRL2-0001xa-Bs; Fri, 15 Oct 2004 13:37:41 +0100 Message-ID: <083a01c4b2b3$cfc6f830$21849ed9@Puppy> From: "Adrian Farrel" To: , References: <024101c4ad86$b685a010$21849ed9@Puppy> <416F8B47.9040306@psg.com> Subject: Re: [Pce] Proposed Charter for a PCE WG Date: Fri, 15 Oct 2004 13:33:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for your comments... > > - Functional specification of Generalized Traffic Engineered LSP path > > computation techniques involving Path Computation Element(s). This > > includes the case of intra IGP area, inter IGP area, inter-AS and > > inter-provider TE LSPs path computation for both Point to Point, > > Point to Multipoint and Multipoint to Multipoint TE LSPs. > > -> when you say "both" to what does it apply in the above sentence ? It refers to JP's inability to speak English, and my laziness when reviewing the draft :-) "both" should read "each of" and applies to P2P, P2MP and MP2MP LSPs. > -> this item uses a terminology related to the partitioning of the > network in terms of routing instead of PCE responsibility scope - > so should I consider this as part of the work to disambuiguate the > situation ? Agreed. We are struggling to avoid a circular definition because PCE is clearly responsible for computing paths in the set of nodes for which PCE is responsible for computing paths. The set of possible computational domains is not intended to be exhaustive, but perhaps we should try to generalize the description by using "computational domain", and describing intra and inter-domain computation. > -> is it expected as part of this item to deliver the functionality > for "segment" computation for a given path p2p, p2mp or mp2mp LSP ? > as this is not explicitly indicated Unclear whether you mean segment as in a stitchable segment, or segment as in a protection segment (or both). In any case, yes this is intended to be included. I am not sure whether the charter at this stage should attempt to list each detailed item, or whether it should list a task to discover and document the detailed items. > > - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) > > extensions required by PCE-based path computation techniques. > > -> would you clarify the implication of RSVP-TE in path computation > "techniques" ? as there are no resource reservation expected here > > if the intent is to say "result of computation should be usable by > signaling protocols used to setup the LSP along the computed path" > i think this would better translate implication of RSVP-TE In my mind I have the ability to signal (to, for example, an ASBR) the identity of a PCE and the key of a computed path so that the ASBR can retrieve the next segment of a precomputed path that has not be signalled across the first AS because of confidentiality concerns. This would require a signaling extension to support a PCE-based path computation technique. > > Specification of routing extensions in support of PCE discovery > > techniques within an IGP area and across multiple IGP areas, ASes > > and Provider networks. The proposed extensions will done in > > conjunction with the WGs in charge of the specification of those > > protocols. > > -> there should be an explicit item detailing what are the potential > PCE discovery techniques are/or involved mechanisms b/f discussing > for routing extensions (as routing is not the only means to achieve > this anyway) I agree. We have got ahead of ourselves. This item might read better as: Specification of techniques in support of PCE discovery within and across IGP areas, ASes and Provider networks. Where such techniques result in the extensions of existing protocols, this work will be done in conjunction with the appropriate WGs. > -> which WG wrt to RSVP-TE as mentioned here above (note: OSPF, ISIS > and BGP have an associate WG) - RSVP(-TE) does not or do we assume > implicitly it is the CCAMP WG ? TBD (and pending discovery that that work is needed) > > - Specification of new protocols or modifications to existing > > protocols to facilitate communication between LSRs and PCEs, and > > between a PCE and other PCEs. > > -> the term LSR is imho not accuarate enough - also referring to the > discussion wrt to FORCES - i think there is the need to introduce > the term PC Requestor, Client or equivalent (instead of LSR) to > avoid further confusion and ensure genericity Yes. We have PCC, and should use that term. > > - Specification of requirements and protocol extensions related to the > > policy, security and confidentiality aspects of PCE-based path > > computation techniques involving PCEs of multiple Providers. > > -> why only multiple providers would be involved in this item ? why not > PCEs of multiple administrative entities ? Agreed. > > The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will > > also cooperate with the ITU-T and OIF where appropriate. > > -> as BGP is part of the protocols in the loop, IDR should also be > listed as part of the above list of WGs Agreed. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Oct 15 10:40:55 2004 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 KAA08392; Fri, 15 Oct 2004 10:40:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITRj-0000se-4n; Fri, 15 Oct 2004 10:52:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIT7L-0006jU-Id; Fri, 15 Oct 2004 10:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIT0g-0004wa-Rt for pce@megatron.ietf.org; Fri, 15 Oct 2004 10:24:48 -0400 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 KAA05405 for ; Fri, 15 Oct 2004 10:24:44 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITC3-0000J4-W8 for pce@ietf.org; Fri, 15 Oct 2004 10:36:32 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 89AD6C558; Fri, 15 Oct 2004 10:24:14 -0400 (EDT) Message-ID: <009501c4b2c2$a6ed5df0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "JP Vasseur" , "LE ROUX Jean-Louis RD-CORE-LAN" References: <7815707E-1E30-11D9-9D9F-000D93330B14@cisco.com> Subject: Re: RE : [Pce] Proposed Charter for a PCE WG Date: Fri, 15 Oct 2004 10:24:16 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 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="===============1788549223==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 This is a multi-part message in MIME format. --===============1788549223== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C4B2A1.1FA7B5A0" This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C4B2A1.1FA7B5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, - Specification of routing (OSPF, ISIS, BGP) and = signaling (RSVP-TE) extensions required by PCE-based path = computation techniques. Specification of routing extensions in support = of PCE discovery techniques within an IGP area and across = multiple IGP areas, ASes and Provider networks. The proposed extensions = will done in conjunction with the WGs in charge of the = specification of those protocols. I don't understand the part about signaling (RSVP-TE) extensions = required by PCE-based path computation techniques. I hope this is about = things like signaling of constraints during LSP setup and not about = PCC-PCE and PCE-PCE signaling. I would also like to add to the charter the framework and the = architecture of the distributed path computation involving multiple PCEs Igor ----- Original Message -----=20 From: JP Vasseur=20 To: LE ROUX Jean-Louis RD-CORE-LAN=20 Cc: pce@ietf.org=20 Sent: Thursday, October 14, 2004 6:29 PM Subject: Re: RE : [Pce] Proposed Charter for a PCE WG Hi Jean-Louis, On Oct 14, 2004, at 5:40 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: Hi Adrian and all, This proposed charter sounds good Thanks. Just two points: -Could it be possible to explicitely include PCE-based backup path = computation within the charter ? Either include it in the first item or = in a dedicated item Agree, we should list as a specific item since the problems to handled = may be specific to this problem space. We will update the proposed charter accordingly. -It would be good to explicitely mention GMPLS aspects as part of = the charter - Functional specification of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s). so this covers GMPLS, since indeed PCE-based computation is a good = candidate for Generalized LSP path computation considering the = complexity of multi-constraints algorithms, a quite common case in GMPLS = environments. Thanks for your feed-backs. JP. Regards, JL -----Message d'origine----- De : pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel Envoy=E9 : samedi 9 octobre 2004 00:33 =C0 : pce@ietf.org Objet : [Pce] Proposed Charter for a PCE WG Hi, The main purposes of the PCE BOF in Washington DC will be to=20 discuss the PCE architecture, and the need for and scope of a=20 PCE WG. Hence the proposed charter is particularly important. JP and I have put together the following as a starting point,=20 and we would very much appreciate your comments on the mailing=20 list in advance of the meeting. Specific milestones are=20 pending agreement on the major work areas. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed Charter WG items: - Functional specification of Generalized Traffic Engineered LSP = path computation techniques involving Path Computation Element(s). This includes the case of intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for both Point to Point, Point to Multipoint and Multipoint to Multipoint TE LSPs. - Specification of routing (OSPF, ISIS, BGP) and signaling = (RSVP-TE) extensions required by PCE-based path computation techniques. Specification of routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks. The proposed extensions will done in conjunction with the WGs in charge of the specification of those protocols. - Specification of new protocols or modifications to existing protocols to facilitate communication between LSRs and PCEs, and between a PCE and other PCEs. - Definition of protocol-independent metrics defining path quality measurement criteria, algorithm complexity and scalability = criteria related to path computation techniques. - Specification of requirements and protocol extensions related to = the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements defined by the WG. The WG will work closely with the following other WGs: CCAMP,=20 MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and=20 OIF where appropriate. _______________________________________________ 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 -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0092_01C4B2A1.1FA7B5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
          &nbs= p;         =20 - Specification of routing (OSPF, ISIS, BGP) and signaling=20 (RSVP-TE)
          =             &= nbsp;=20 extensions required by PCE-based path computation=20 techniques.
         &nbs= p;            = ; =20 Specification of routing extensions in support of PCE=20 discovery
          =             &= nbsp;=20 techniques within an IGP area and across multiple IGP areas,=20 ASes
           = ;           =20 and Provider networks. The proposed extensions will done=20 in
           &= nbsp;          =20 conjunction with the WGs in charge of the specification of=20 those
          &nbs= p;           =20 protocols.
 
I don't=20 understand the part about signaling (RSVP-TE) extensions required by = PCE-based=20 path computation techniques. I hope this is about things like signaling = of=20 constraints during LSP setup and not about PCC-PCE and PCE-PCE=20 signaling.
 
I would also=20 like to add to the charter the framework and the architecture of the = distributed=20 path computation involving multiple PCEs
 
Igor
----- Original Message -----
From:=20 JP = Vasseur=20
To: LE ROUX Jean-Louis=20 RD-CORE-LAN
Sent: Thursday, October 14, = 2004 6:29=20 PM
Subject: Re: RE : [Pce] = Proposed Charter=20 for a PCE WG

Hi Jean-Louis,

On Oct 14, 2004, at 5:40 PM, LE = ROUX=20 Jean-Louis RD-CORE-LAN wrote:

Hi Adrian and all,

This proposed charter sounds=20 good


Thanks.

Just two points:

-Could it be possible to = explicitely=20 include PCE-based backup path computation within the charter ? = Either=20 include it in the first item or in a dedicated=20 item


Agree, we should list as a specific item = since=20 the problems to handled may be specific to this problem = space.

We will=20 update the proposed charter accordingly.

-It would be good to explicitely mention GMPLS aspects as = part=20 of the charter


- Functional specification of = Generalized Traffic Engineered = LSP=20 path
computation techniques involving Path Computation=20 Element(s).

so this covers GMPLS, since indeed PCE-based = computation is=20 a good candidate for Generalized LSP path computation considering the=20 complexity of multi-constraints algorithms, a quite common case in = GMPLS=20 environments.

Thanks for your feed-backs.

JP.

Regards,

JL

-----Message d'origine-----
De : = pce-bounces@lists.ietf.org=20
[mailto:pce-bounces@lists.ietf.org] De la part de Adrian=20 Farrel
Envoy=E9 : samedi 9 octobre 2004 00:33
=C0 :=20 pce@ietf.org
Objet : [Pce] Proposed Charter for a PCE=20 WG


Hi,

The main purposes of the PCE BOF in = Washington DC=20 will be to
discuss the PCE architecture, and the need for and = scope of=20 a
PCE WG. Hence the proposed charter is particularly=20 important.

JP and I have put together the following as a = starting=20 point,
and we would very much appreciate your comments on the = mailing=20
list in advance of the meeting. Specific milestones are =
pending=20 agreement on the major work=20 = areas.

Thanks,
Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DProposed=20 Charter

WG items:
- Functional specification of = Generalized=20 Traffic Engineered LSP path
computation techniques involving = Path=20 Computation Element(s). This
includes the case of intra IGP = area, inter=20 IGP area, inter-AS and
inter-provider TE LSPs path computation = for both=20 Point to Point,
Point to Multipoint and Multipoint to = Multipoint TE=20 LSPs.
- Specification of routing (OSPF, ISIS, BGP) and = signaling=20 (RSVP-TE)
extensions required by PCE-based path computation=20 techniques.
Specification of routing extensions in support of = PCE=20 discovery
techniques within an IGP area and across multiple IGP = areas,=20 ASes
and Provider networks. The proposed extensions will done=20 in
conjunction with the WGs in charge of the specification of=20 those
protocols.
- Specification of new protocols or = modifications=20 to existing
protocols to facilitate communication between LSRs = and=20 PCEs, and
between a PCE and other PCEs.
- Definition of=20 protocol-independent metrics defining path quality
measurement=20 criteria, algorithm complexity and scalability criteria
related = to path=20 computation techniques.
- Specification of requirements and = protocol=20 extensions related to the
policy, security and confidentiality = aspects=20 of PCE-based path
computation techniques involving PCEs of = multiple=20 Providers.
- Definition of MIBs and management procedures = related to=20 the new
protocols, protocol extensions and operational elements = defined
by the WG.

The WG will work closely with the = following=20 other WGs: CCAMP,
MPLS, ISIS, OSPF; and will also cooperate = with the=20 ITU-T and
OIF where=20 = appropriate.


_______________________________________________Pce=20 mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>

_______________________________________________Pce=20 mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0092_01C4B2A1.1FA7B5A0-- --===============1788549223== 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 --===============1788549223==-- From pce-bounces@ietf.org Fri Oct 15 15:52:44 2004 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 PAA04271; Fri, 15 Oct 2004 15:52:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYJV-0008D2-Ru; Fri, 15 Oct 2004 16:04:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXxe-0005QG-8H; Fri, 15 Oct 2004 15:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXqQ-0001Gr-1f for pce@megatron.ietf.org; Fri, 15 Oct 2004 15:34:30 -0400 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 PAA02518 for ; Fri, 15 Oct 2004 15:34:27 -0400 (EDT) Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIY1p-0007bm-E3 for pce@ietf.org; Fri, 15 Oct 2004 15:46:18 -0400 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id i9FJYG4V016122; Fri, 15 Oct 2004 21:34:16 +0200 (MET DST) From: Olivier Bonaventure To: pce@ietf.org Content-Type: text/plain Message-Id: <1097868857.7579.39.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 15 Oct 2004 21:34:17 +0200 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Steve Uhlig Subject: [Pce] Submission of draft-pelsser-bgp-pce-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.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Dear All, We submitted the following draft for consideration at the next PCE BOF. Authors : C. Pelsser, S. Uhlig, O. Bonaventure Title : Limitations induced by BGP on the computation of interdomain LSPs Filename: draft-pelsser-bgp-pce-00.txt Abstract: Path Computation Elements have been proposed to aid the establishment of interdomain Label Switched Paths. We propose to colocate the PCE with a route reflector and show that the performance of such a PCE depends on the quality of the interdomain routes that it collects. The draft will be announced soon by IETF. In the meantime, you can download it from : http://totem.info.ucl.ac.be/publications/papers-elec-versions/draft-pelsser-bgp-pce-00.txt Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Oct 16 10:54:15 2004 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 KAA25407; Sat, 16 Oct 2004 10:54:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIq8P-0007vh-6G; Sat, 16 Oct 2004 11:06:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIpvk-0003eS-9U; Sat, 16 Oct 2004 10:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIptN-00032L-7K for pce@megatron.ietf.org; Sat, 16 Oct 2004 10:50:47 -0400 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 KAA25305 for ; Sat, 16 Oct 2004 10:50:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIq4x-0007sh-VT for pce@ietf.org; Sat, 16 Oct 2004 11:02:44 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIptK-000MMM-8I; Sat, 16 Oct 2004 14:50:42 +0000 Message-ID: <4171353F.5020806@psg.com> Date: Sat, 16 Oct 2004 16:50:39 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Proposed Charter for a PCE WG References: <024101c4ad86$b685a010$21849ed9@Puppy> <416F8B47.9040306@psg.com> <083a01c4b2b3$cfc6f830$21849ed9@Puppy> In-Reply-To: <083a01c4b2b3$cfc6f830$21849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: 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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit hi adrian - thanks for the responses - see in-line: >>>- Functional specification of Generalized Traffic Engineered LSP path >>> computation techniques involving Path Computation Element(s). This >>> includes the case of intra IGP area, inter IGP area, inter-AS and >>> inter-provider TE LSPs path computation for both Point to Point, >>> Point to Multipoint and Multipoint to Multipoint TE LSPs. >> >>-> when you say "both" to what does it apply in the above sentence ? > > It refers to JP's inability to speak English, and my laziness when reviewing the draft :-) > > "both" should read "each of" and applies to P2P, P2MP and MP2MP LSPs. ok - >>-> this item uses a terminology related to the partitioning of the >> network in terms of routing instead of PCE responsibility scope - >> so should I consider this as part of the work to disambuiguate the >> situation ? > > Agreed. We are struggling to avoid a circular definition because PCE is clearly > responsible for computing paths in the set of nodes for which PCE is responsible for > computing paths. The set of possible computational domains is not intended to be > exhaustive, but perhaps we should try to generalize the description by using > "computational domain", and describing intra and inter-domain computation. ok - i think by generalizing the description by using "computational domain" it would definitelly clarify the situation >>-> is it expected as part of this item to deliver the functionality >> for "segment" computation for a given path p2p, p2mp or mp2mp LSP ? >> as this is not explicitly indicated > > Unclear whether you mean segment as in a stitchable segment, or segment as in a protection > segment (or both). In any case, yes this is intended to be included. it was meant to cover the former (but in fact this case includes the latter because the computation of protecting segment taking into account protected segment path properties is a particular case of constraint) should even have better referred to this as intermediate segment computation - the reason is to avoid focusing only on full end-to-end path computation (from sender to receiver) that is a particular case > I am not sure whether the charter at this stage should attempt to list each detailed item, > or whether it should list a task to discover and document the detailed items. you are right here that the definition of a taxonomy and classification of each of the detailed items is the initial and primary objective to be achieved >>>- Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) >>> extensions required by PCE-based path computation techniques. >> >>-> would you clarify the implication of RSVP-TE in path computation >> "techniques" ? as there are no resource reservation expected here >> >> if the intent is to say "result of computation should be usable by >> signaling protocols used to setup the LSP along the computed path" >> i think this would better translate implication of RSVP-TE > > In my mind I have the ability to signal (to, for example, an ASBR) the identity of a PCE > and the key of a computed path so that the ASBR can retrieve the next segment of a > precomputed path that has not be signalled across the first AS because of confidentiality > concerns. This would require a signaling extension to support a PCE-based path computation > technique. so the idea here would be to use the signaling to trigger the inclusion from a PCE along the LSP path of a computed segment but for which details are not known to the initiator of the request ? this would translate to an extension of the so-called constrain-passing model where you have an additional constraint in terms of computation element as long as the method is integrated as part of signaling information exchange for resource reservation purpose towards the LSP destination >>> Specification of routing extensions in support of PCE discovery >>> techniques within an IGP area and across multiple IGP areas, ASes >>> and Provider networks. The proposed extensions will done in >>> conjunction with the WGs in charge of the specification of those >>> protocols. >> >>-> there should be an explicit item detailing what are the potential >> PCE discovery techniques are/or involved mechanisms b/f discussing >> for routing extensions (as routing is not the only means to achieve >> this anyway) > > I agree. We have got ahead of ourselves. This item might read better as: > Specification of techniques in support of PCE discovery within and > across IGP areas, ASes and Provider networks. Where such > techniques result in the extensions of existing protocols, this work > will be done in conjunction with the appropriate WGs. ok - it clarifies >>-> which WG wrt to RSVP-TE as mentioned here above (note: OSPF, ISIS >> and BGP have an associate WG) - RSVP(-TE) does not or do we assume >> implicitly it is the CCAMP WG ? > > TBD (and pending discovery that that work is needed) ok - i see that this important question which is not "PCE-specific" at the end is also likely to >>>- Specification of new protocols or modifications to existing >>> protocols to facilitate communication between LSRs and PCEs, and >>> between a PCE and other PCEs. >> >>-> the term LSR is imho not accuarate enough - also referring to the >> discussion wrt to FORCES - i think there is the need to introduce >> the term PC Requestor, Client or equivalent (instead of LSR) to >> avoid further confusion and ensure genericity > > Yes. We have PCC, and should use that term. ok - >>>- Specification of requirements and protocol extensions related to the >>> policy, security and confidentiality aspects of PCE-based path >>> computation techniques involving PCEs of multiple Providers. >> >>-> why only multiple providers would be involved in this item ? why not >> PCEs of multiple administrative entities ? > > Agreed. ok - >>>The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and >>> will also cooperate with the ITU-T and OIF where appropriate. >> >>-> as BGP is part of the protocols in the loop, IDR should also be >> listed as part of the above list of WGs > > Agreed. ok - thanks, - dimitri. > Thanks, > Adrian > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Oct 18 04:28:52 2004 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 EAA27097; Mon, 18 Oct 2004 04:28:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJT4t-00038E-Tu; Mon, 18 Oct 2004 04:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJSrT-0001dP-VV; Mon, 18 Oct 2004 04:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJSqN-0001VO-F4 for pce@megatron.ietf.org; Mon, 18 Oct 2004 04:26:15 -0400 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 EAA26945 for ; Mon, 18 Oct 2004 04:26:13 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJT2K-000352-FG for pce@ietf.org; Mon, 18 Oct 2004 04:38:36 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 10:25:10 +0200 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: RE : [Pce] Proposed Charter for a PCE WG Date: Mon, 18 Oct 2004 10:25:09 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B019D430@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [Pce] Proposed Charter for a PCE WG Thread-Index: AcStiDstyCKqbg5aQOyrJ3cy/ovLIwErUKAwAK1mzRA= From: "BOUCADAIR Mohamed RD-CORE-CAE" To: "Adrian Farrel" , X-OriginalArrivalTime: 18 Oct 2004 08:25:10.0428 (UTC) FILETIME=[FB9385C0:01C4B4EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Hi all, The proposed charter sounds good.. See some comments inlign. Cheers, Med >-----Message d'origine----- >De : pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel >Envoy=E9 : samedi 9 octobre 2004 00:33 >=C0 : pce@ietf.org >Objet : [Pce] Proposed Charter for a PCE WG > > >Hi, > >The main purposes of the PCE BOF in Washington DC will be to=20 >discuss the PCE architecture, and the need for and scope of a=20 >PCE WG. Hence the proposed charter is particularly important. > >JP and I have put together the following as a starting point,=20 >and we would very much appreciate your comments on the mailing=20 >list in advance of the meeting. Specific milestones are=20 >pending agreement on the major work areas. > >Thanks, >Adrian >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Proposed Charter > >WG items: >- Functional specification of Generalized Traffic Engineered LSP path > computation techniques involving Path Computation Element(s). This > includes the case of intra IGP area, inter IGP area, inter-AS and > inter-provider TE LSPs path computation for both Point to Point, > Point to Multipoint and Multipoint to Multipoint TE LSPs. >- Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) > extensions required by PCE-based path computation techniques. > Specification of routing extensions in support of PCE discovery > techniques within an IGP area and across multiple IGP areas, ASes > and Provider networks. The proposed extensions will done in > conjunction with the WGs in charge of the specification of those > protocols. Do we need RSVP-TE extensions? What do we mean by "PCE Discovery"? Is it discovery of a "service" or a = "network element". >- Specification of new protocols or modifications to existing > protocols to facilitate communication between LSRs and PCEs, and > between a PCE and other PCEs. Yes. >- Definition of protocol-independent metrics defining path quality > measurement criteria, algorithm complexity and scalability criteria > related to path computation techniques. >- Specification of requirements and protocol extensions related to the > policy, security and confidentiality aspects of PCE-based path > computation techniques involving PCEs of multiple Providers. This is a critical point that should be addressed whithin the PCE wg. >- Definition of MIBs and management procedures related to the new > protocols, protocol extensions and operational elements defined > by the WG. > >The WG will work closely with the following other WGs: CCAMP,=20 >MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and=20 >OIF where appropriate. > > >_______________________________________________ >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 Mon Oct 18 04:45:35 2004 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 EAA27960; Mon, 18 Oct 2004 04:45:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJTL4-0003PN-CN; Mon, 18 Oct 2004 04:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJT7s-0002mN-8N; Mon, 18 Oct 2004 04:44:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJT3D-0002Ni-BP for pce@megatron.ietf.org; Mon, 18 Oct 2004 04:39:32 -0400 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 EAA27662 for ; Mon, 18 Oct 2004 04:39:29 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJTF9-0003J0-OX for pce@ietf.org; Mon, 18 Oct 2004 04:51:53 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 10:39:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Oct 2004 10:39:27 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B019D433@ftrdmel3.rd.francetelecom.fr> Thread-Topic: draft-boucadair-pce-interas-00.txt Thread-Index: AcS07fpFfw4bN2NRT1qg1NTzYAOw3Q== From: "BOUCADAIR Mohamed RD-CORE-CAE" To: X-OriginalArrivalTime: 18 Oct 2004 08:39:27.0915 (UTC) FILETIME=[FAADA7B0:01C4B4ED] X-Spam-Score: 0.9 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Pce] draft-boucadair-pce-interas-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: , Content-Type: multipart/mixed; boundary="===============0069440029==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. --===============0069440029== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B4ED.FA6DB5A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B4ED.FA6DB5A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : A Solution for providing inter-AS MPLS-based QoS tunnels Author(s) : M. Boucadair, P. Morand Filename : draft-boucadair-pce-interas-00.txt Pages : 16 Date : 2004-10-15 =09 This draft describes a solution for providing inter-AS MPLS-based=20 Quality of Service (QoS) tunnels. This solution makes use of Path=20 Computation Elements (PCE) as a means to compute inter-domain = constraint-based paths. Service considerations and agreements between = two Service Providers implementing this solution are also described. A URL for this Internet-Draft is: To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit = =20 to change your subscription settings. ------_=_NextPart_001_01C4B4ED.FA6DB5A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-boucadair-pce-interas-00.txt

A New Internet-Draft is available = from the on-line Internet-Drafts directories.


        Title   =         : A Solution for providing = inter-AS MPLS-based QoS tunnels
        = Author(s)       : M. Boucadair, P. = Morand
        = Filename        : = draft-boucadair-pce-interas-00.txt
        Pages   =         : 16
        Date    =         : 2004-10-15
       
This draft describes a solution for providing inter-AS MPLS-based
   Quality of Service (QoS) tunnels. This solution makes use = of Path
   Computation  Elements  (PCE)  as  = a  means  to  compute  inter-domain
   constraint-based paths. Service considerations and = agreements between
   two Service Providers implementing this solution are also = described.

A URL for this Internet-Draft is:
<http://www.ietf.org/internet-drafts/draft-boucadair-pce-interas-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.

------_=_NextPart_001_01C4B4ED.FA6DB5A6-- --===============0069440029== 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 --===============0069440029==-- From pce-bounces@ietf.org Mon Oct 18 16:42:06 2004 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 QAA21261; Mon, 18 Oct 2004 16:42:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeWX-00013Y-Ra; Mon, 18 Oct 2004 16:54:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJe2p-0003fK-0M; Mon, 18 Oct 2004 16:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdh2-0007o1-SJ for pce@megatron.ietf.org; Mon, 18 Oct 2004 16:01:21 -0400 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 QAA18308 for ; Mon, 18 Oct 2004 16:01:14 -0400 (EDT) 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 1CJdt0-000098-Nt for pce@ietf.org; Mon, 18 Oct 2004 16:13:44 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2004 13:18:03 +0000 X-BrightmailFiltered: true 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 i9IK0aYJ014074; Mon, 18 Oct 2004 13:00:37 -0700 (PDT) Received: from [68.189.249.204] (che-vpn-cluster-1-47.cisco.com [10.86.240.47]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA17333; Mon, 18 Oct 2004 13:00:39 -0700 (PDT) In-Reply-To: <6CF039C5B32037498B02251E11CDE6B019D430@ftrdmel3.rd.francetelecom.fr> References: <6CF039C5B32037498B02251E11CDE6B019D430@ftrdmel3.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <62DC3054-2140-11D9-8BA5-000D93330B14@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: RE : [Pce] Proposed Charter for a PCE WG Date: Mon, 18 Oct 2004 16:00:40 -0400 To: "BOUCADAIR Mohamed RD-CORE-CAE" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Hi Mohamed, Thanks for your comments on the proposed charter - see in line, On Oct 18, 2004, at 4:25 AM, BOUCADAIR Mohamed RD-CORE-CAE wrote: > Hi all, > > The proposed charter sounds good.. > See some comments inlign. > > Cheers, > Med > >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel >> Envoy=E9 : samedi 9 octobre 2004 00:33 >> =C0 : pce@ietf.org >> Objet : [Pce] Proposed Charter for a PCE WG >> >> >> Hi, >> >> The main purposes of the PCE BOF in Washington DC will be to >> discuss the PCE architecture, and the need for and scope of a >> PCE WG. Hence the proposed charter is particularly important. >> >> JP and I have put together the following as a starting point, >> and we would very much appreciate your comments on the mailing >> list in advance of the meeting. Specific milestones are >> pending agreement on the major work areas. >> >> Thanks, >> Adrian >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Proposed Charter >> >> WG items: >> - Functional specification of Generalized Traffic Engineered LSP path >> computation techniques involving Path Computation Element(s). This >> includes the case of intra IGP area, inter IGP area, inter-AS and >> inter-provider TE LSPs path computation for both Point to Point, >> Point to Multipoint and Multipoint to Multipoint TE LSPs. >> - Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE) >> extensions required by PCE-based path computation techniques. >> Specification of routing extensions in support of PCE discovery >> techniques within an IGP area and across multiple IGP areas, ASes >> and Provider networks. The proposed extensions will done in >> conjunction with the WGs in charge of the specification of those >> protocols. > > Do we need RSVP-TE extensions? > This may be needed. Note that we do not refer to the use of RSVP for=20 the PCC-PCE or PCE-PCE (which is one proposal among others) but to some=20= potential RSVP-TE extensions required when the path has been computed=20 by means of a PCE. > What do we mean by "PCE Discovery"? Is it discovery of a "service" or=20= > a "network element". > The discovery that a network entity has the capability to act as a PCE. >> - Specification of new protocols or modifications to existing >> protocols to facilitate communication between LSRs and PCEs, and >> between a PCE and other PCEs. > > Yes. > >> - Definition of protocol-independent metrics defining path quality >> measurement criteria, algorithm complexity and scalability criteria >> related to path computation techniques. > > >> - Specification of requirements and protocol extensions related to = the >> policy, security and confidentiality aspects of PCE-based path >> computation techniques involving PCEs of multiple Providers. > > This is a critical point that should be addressed whithin the PCE wg. > >> - Definition of MIBs and management procedures related to the new >> protocols, protocol extensions and operational elements defined >> by the WG. >> >> The WG will work closely with the following other WGs: CCAMP, >> MPLS, ISIS, OSPF; and will also cooperate with the ITU-T and >> OIF where appropriate. >> Thanks. JP. >> >> _______________________________________________ >> 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 > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Oct 19 04:32:33 2004 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 EAA01011; Tue, 19 Oct 2004 04:32:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJpcC-0007LI-HA; Tue, 19 Oct 2004 04:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJp41-0006ll-7n; Tue, 19 Oct 2004 04:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJofp-0003QG-Qt for pce@megatron.ietf.org; Tue, 19 Oct 2004 03:44:50 -0400 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 DAA27363 for ; Tue, 19 Oct 2004 03:44:43 -0400 (EDT) Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJort-0006Os-TD for pce@ietf.org; Tue, 19 Oct 2004 03:57:18 -0400 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id i9J7iU7P006159; Tue, 19 Oct 2004 09:44:31 +0200 (MET DST) Subject: Re: [Pce] Proposed Charter for a PCE WG From: Olivier Bonaventure To: Adrian Farrel In-Reply-To: <024101c4ad86$b685a010$21849ed9@Puppy> References: <024101c4ad86$b685a010$21849ed9@Puppy> Content-Type: text/plain Message-Id: <1098171870.7579.531.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 19 Oct 2004 09:44:31 +0200 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Adrian and JP, > > The main purposes of the PCE BOF in Washington DC will be to discuss the PCE architecture, > and the need for and scope of a PCE WG. Hence the proposed charter is particularly > important. I think that the problem addressed by the PCE BOF is important and justifies a WG. The proposed charter is ambitious as it covers a wide range of problems. Do you have ideas on the expected timing for each work item ? >The WG will work closely with the following other WGs: CCAMP, MPLS, >ISIS, OSPF; and will >also cooperate with the ITU-T and OIF where appropriate. How do you envision the cooperation with the other IETF WGs ? PCE proposes requirements and waits for answer from responsible WG or PCE defines requirements and proposes solution which is jointly approved by PCE and the responsible WG ? Best regards, Olivier _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Oct 19 20:59:43 2004 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 UAA10785; Tue, 19 Oct 2004 20:59:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK51e-0001jr-Nz; Tue, 19 Oct 2004 21:12:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3dO-0006Aw-4G; Tue, 19 Oct 2004 19:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJss2-0007xF-0U for pce@megatron.ietf.org; Tue, 19 Oct 2004 08:13:42 -0400 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 IAA15855 for ; Tue, 19 Oct 2004 08:13:35 -0400 (EDT) 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 1CJt46-00030z-00 for pce@ietf.org; Tue, 19 Oct 2004 08:26:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2004 05:20:32 -0700 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 i9JCCsk2014500; Tue, 19 Oct 2004 05:12:55 -0700 (PDT) Received: from [68.189.249.204] (che-vpn-cluster-1-118.cisco.com [10.86.240.118]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA22096; Tue, 19 Oct 2004 05:12:54 -0700 (PDT) In-Reply-To: <1098171870.7579.531.camel@pcobo> References: <024101c4ad86$b685a010$21849ed9@Puppy> <1098171870.7579.531.camel@pcobo> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34C00594-21C8-11D9-AAF8-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Proposed Charter for a PCE WG Date: Tue, 19 Oct 2004 08:12:54 -0400 To: Olivier Bonaventure X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Hi Oliver, On Oct 19, 2004, at 3:44 AM, Olivier Bonaventure wrote: > Adrian and JP, >> >> The main purposes of the PCE BOF in Washington DC will be to discuss >> the PCE architecture, >> and the need for and scope of a PCE WG. Hence the proposed charter is >> particularly >> important. > > I think that the problem addressed by the PCE BOF is important and > justifies a WG. The proposed charter is ambitious as it covers a wide > range of problems. > Thanks. > Do you have ideas on the expected timing for each work item ? > We're currently working on the milestone, should a WG be formed, and we will share it with the list. >> The WG will work closely with the following other WGs: CCAMP, MPLS, >> ISIS, OSPF; and will >> also cooperate with the ITU-T and OIF where appropriate. > > How do you envision the cooperation with the other IETF WGs ? Yes, this will be listed in the proposed WG charter. > PCE proposes requirements and waits for answer from responsible WG or > PCE defines requirements and proposes solution which is jointly > approved > by PCE and the responsible WG ? > The later. Thanks. JP. > Best regards, > > > Olivier > > > _______________________________________________ > 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 Oct 20 09:46:06 2004 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 JAA03588; Wed, 20 Oct 2004 09:46:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGzP-0000td-2e; Wed, 20 Oct 2004 09:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGGH-0005nE-H6; Wed, 20 Oct 2004 09:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFao-0005vV-1K for pce@megatron.ietf.org; Wed, 20 Oct 2004 08:29:26 -0400 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 IAA27288 for ; Wed, 20 Oct 2004 08:29:19 -0400 (EDT) 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 1CKFn7-0007hm-5A for pce@ietf.org; Wed, 20 Oct 2004 08:42:10 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2004 05:36:29 -0700 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 i9KCSjOE021821 for ; Wed, 20 Oct 2004 05:28:46 -0700 (PDT) Received: from [66.189.89.146] (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA02093 for ; Wed, 20 Oct 2004 05:28:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: quoted-printable Message-Id: <962D0794-2293-11D9-951C-000D93330B14@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: pce@ietf.org From: JP Vasseur Date: Wed, 20 Oct 2004 08:28:45 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [Pce] Please provide your input on CCAMP 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Dear list members, The CCAMP working group is examining the PCE architecture with a view=20 to determining whether it addresses any of the issues in the=20 inter-domain problem space that CCAMP is chartered to work on. If you=20 have opinions on this, could you please send them to the CCAMP mailing=20= list. This is an important step to moce forward. Cheers. JP and Adrian. =A0= _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Oct 21 07:39:50 2004 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 HAA05519; Thu, 21 Oct 2004 07:39:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbUw-0005PI-US; Thu, 21 Oct 2004 07:52:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKULt-000883-JV; Thu, 21 Oct 2004 00:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKI6-0002dP-S6 for pce@megatron.ietf.org; Wed, 20 Oct 2004 13:30:26 -0400 Received: from icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29593 for ; Wed, 20 Oct 2004 13:30:15 -0400 (EDT) Received: from mail.icu.ac.kr (localhost [127.0.0.1]) by icu.ac.kr (8.12.10/8.12.8) with ESMTP id i9KHLWj7015432 for ; Thu, 21 Oct 2004 02:21:33 +0900 (KST) Received: (from kebi@localhost) by mail.icu.ac.kr (8.12.10/8.12.8/Submit) id i9KHLUc6015424 for pce@lists.ietf.org; Thu, 21 Oct 2004 02:21:31 +0900 (KST) Date: Thu, 21 Oct 2004 02:21:31 +0900 (KST) Message-Id: <200410201721.i9KHLUc6015424@mail.icu.ac.kr> X-Authentication-Warning: mail.icu.ac.kr: kebi set sender to dip@icu.ac.kr using -f From: "Dipnarayan Guha" User-Host: 210.107.137.122 In-Reply-To: dip@icu.ac.kr To: pce@ietf.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: dip.154211098292890872 X-Priority: 3 MIME-Version: 1.0 Subject: [Pce] New draft 1 for PCE BOF for 61st. IETF X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dip@icu.ac.kr List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716018964==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Multi-Message. --===============0716018964== Content-type: multipart/alternative; boundary="kebi210.107.137.122.154211098292890795" Multi-Message. --kebi210.107.137.122.154211098292890795 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello All,
 
We have submitted the following draft for the upcoming PCE BOF in the 61st. IETF meet at Washington DC. Here are the details:
 
Title : Path Computation Element Metric Protocol (PCEMP)

Author(s) : Jun Kyun Choi, Dipnarayan Guha and Jin Ho Hahm

Filename : draft-choi-pce-metric-protocol-00.txt

 
[Abstract]

   In this draft, we propose an analysis of a Path Computation
   Element Metric Protocol (PCEMP) that acts as a generic computation
   model for path based metrics in large multi-domain or multi-layer
   networks. The mechanism that is described in this draft is generic
   and can serve as an application path computation framework for any
   Path Computation Element (PCE)
 
   This draft proposes to elucidate protocol independent metrics
   defining path quality measurement criteria, algorithm complexity
   and scalability criteria related to path computation techniques
   through the PCEMP and is in line with the PCE WG Charter.
 
The corresponding draft can be found at:
 
 
 
Your comments are most welcome.
 
Thanks, Dip
--kebi210.107.137.122.154211098292890795 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello All,

 

We have submitted the following draft for the upcoming PCE BOF in the 61st. IETF meet at Washington DC. Here are the details:

 

Title : Path Computation Element Metric Protocol (PCEMP)


Author(s) : Jun Kyun Choi, Dipnarayan Guha and Jin Ho Hahm


Filename : draft-choi-pce-metric-protocol-00.txt


 

[Abstract]


   In this draft, we propose an analysis of a Path Computation
   Element Metric Protocol (PCEMP) that acts as a generic computation
   model for path based metrics in large multi-domain or multi-layer
   networks. The mechanism that is described in this draft is generic
   and can serve as an application path computation framework for any
   Path Computation Element (PCE)

 

   This draft proposes to elucidate protocol independent metrics
   defining path quality measurement criteria, algorithm complexity
   and scalability criteria related to path computation techniques
   through the PCEMP and is in line with the PCE WG Charter.

 

The corresponding draft can be found at:

 


 

 

Your comments are most welcome.

 

Thanks, Dip
  --kebi210.107.137.122.154211098292890795-- --===============0716018964== 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 --===============0716018964==-- From pce-bounces@ietf.org Thu Oct 21 07:41:06 2004 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 HAA05887; Thu, 21 Oct 2004 07:41:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbWD-0005Sa-OA; Thu, 21 Oct 2004 07:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUMH-0008Vs-7N; Thu, 21 Oct 2004 00:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKNE-0006IT-2g for pce@megatron.ietf.org; Wed, 20 Oct 2004 13:35:44 -0400 Received: from icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00493 for ; Wed, 20 Oct 2004 13:35:30 -0400 (EDT) Received: from mail.icu.ac.kr (localhost [127.0.0.1]) by icu.ac.kr (8.12.10/8.12.8) with ESMTP id i9KHQsj7017914 for ; Thu, 21 Oct 2004 02:26:55 +0900 (KST) Received: (from kebi@localhost) by mail.icu.ac.kr (8.12.10/8.12.8/Submit) id i9KHQs9O017903 for pce@lists.ietf.org; Thu, 21 Oct 2004 02:26:54 +0900 (KST) Date: Thu, 21 Oct 2004 02:26:54 +0900 (KST) Message-Id: <200410201726.i9KHQs9O017903@mail.icu.ac.kr> X-Authentication-Warning: mail.icu.ac.kr: kebi set sender to dip@icu.ac.kr using -f From: "Dipnarayan Guha" User-Host: 210.107.137.122 In-Reply-To: dip@icu.ac.kr To: pce@ietf.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: dip.179001098293214185 X-Priority: 3 MIME-Version: 1.0 Subject: [Pce] Submission of draft 2 for PCE BOF in 61st. IETF X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dip@icu.ac.kr List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1752670784==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Multi-Message. --===============1752670784== Content-type: multipart/alternative; boundary="kebi210.107.137.122.179001098293214111" Multi-Message. --kebi210.107.137.122.179001098293214111 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello All,
 
This is the second draft which we have submitted for the upcoming PCE BOF which we think can strengthen the agenda of the new PCE WG Charter. It covers the aspects of L1 VPN architecture using PCE techniques and concepts, and can serve as an example of how the PCE WG can work in close collaboration with ITU-T on relevant areas.
 
Title : Framework of PCEMP based Layer 1 Virtual Private Network

Author(s) : Jun Kyun Choi, Dipnarayan Guha, Seng Kyoun Jo, Young Hwa Kim and Byung Ho Yae

Filename : draft-choi-pce-l1vpn-framework-00.txt

[Abstract]
   
   When path computation is done in the management systems for Layer 1
   Virtual Private Networks (L1 VPNs), it would be important that
   resource information is synchronized between the management systems
   and the Provider Edge /Provider (PE/P). This draft looks at such a
   scenario from the viewpoint of the Path Computation Element Metric
   Protocol (PCEMP) that acts a generic computation model for path
   based metrics in large multi-domain or multi-layer networks.
   This draft proposes to show how a L1 VPN framework may be included
   within the scope of Path Computation Element architectures and is
   derived primarily from the motivation of per VPN peer service
   solutions using PCE techniques. PCEMP metrics defining path quality
   measurement criteria, algorithm complexity and scalability criteria
   for L1 VPNs is in line with the functional specifications of
   Generalized Traffic Engineered LSP path computation techniques
   involving Path Computation Element(s) of the PCE WG Charter.

Details can be found at:
 
 
Thanks again, Dip
--kebi210.107.137.122.179001098293214111 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello All,

 

This is the second draft which we have submitted for the upcoming PCE BOF which we think can strengthen the agenda of the new PCE WG Charter. It covers the aspects of L1 VPN architecture using PCE techniques and concepts, and can serve as an example of how the PCE WG can work in close collaboration with ITU-T on relevant areas.

 

Title : Framework of PCEMP based Layer 1 Virtual Private Network


Author(s) : Jun Kyun Choi, Dipnarayan Guha, Seng Kyoun Jo, Young Hwa Kim and Byung Ho Yae


Filename : draft-choi-pce-l1vpn-framework-00.txt


[Abstract]
   
   When path computation is done in the management systems for Layer 1
   Virtual Private Networks (L1 VPNs), it would be important that
   resource information is synchronized between the management systems
   and the Provider Edge /Provider (PE/P). This draft looks at such a
   scenario from the viewpoint of the Path Computation Element Metric
   Protocol (PCEMP) that acts a generic computation model for path
   based metrics in large multi-domain or multi-layer networks.

   This draft proposes to show how a L1 VPN framework may be included
   within the scope of Path Computation Element architectures and is
   derived primarily from the motivation of per VPN peer service
   solutions using PCE techniques. PCEMP metrics defining path quality
   measurement criteria, algorithm complexity and scalability criteria
   for L1 VPNs is in line with the functional specifications of
   Generalized Traffic Engineered LSP path computation techniques
   involving Path Computation Element(s) of the PCE WG Charter.


Details can be found at:

 


 

Thanks again, Dip
  --kebi210.107.137.122.179001098293214111-- --===============1752670784== 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 --===============1752670784==-- From pce-bounces@ietf.org Thu Oct 21 07:41:38 2004 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 HAA05956; Thu, 21 Oct 2004 07:41:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbWj-0005U3-A5; Thu, 21 Oct 2004 07:54:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUMM-00008y-Dk; Thu, 21 Oct 2004 00:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKQ5-0006OP-GO for pce@megatron.ietf.org; Wed, 20 Oct 2004 13:38:41 -0400 Received: from icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00835 for ; Wed, 20 Oct 2004 13:38:33 -0400 (EDT) Received: from mail.icu.ac.kr (localhost [127.0.0.1]) by icu.ac.kr (8.12.10/8.12.8) with ESMTP id i9KHTsj7019164 for ; Thu, 21 Oct 2004 02:29:54 +0900 (KST) Received: (from kebi@localhost) by mail.icu.ac.kr (8.12.10/8.12.8/Submit) id i9KHTsaQ019159 for pce@lists.ietf.org; Thu, 21 Oct 2004 02:29:54 +0900 (KST) Date: Thu, 21 Oct 2004 02:29:54 +0900 (KST) Message-Id: <200410201729.i9KHTsaQ019159@mail.icu.ac.kr> X-Authentication-Warning: mail.icu.ac.kr: kebi set sender to dip@icu.ac.kr using -f From: "Dipnarayan Guha" User-Host: 210.107.137.122 In-Reply-To: dip@icu.ac.kr To: pce@ietf.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: dip.191541098293393957 X-Priority: 3 MIME-Version: 1.0 Subject: [Pce] Submission of draft 3 for PCE BOF in 61st. IETF meet X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dip@icu.ac.kr List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2085868656==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Multi-Message. --===============2085868656== Content-type: multipart/alternative; boundary="kebi210.107.137.122.191541098293393881" Multi-Message. --kebi210.107.137.122.191541098293393881 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello all once again,
 
Here is the third draft for the PCE BOF.
 
Title : Fast IPv6 PCE peer Advertisement using PCEMP

Author(s) : Jun Kyun Choi and Dipnarayan Guha

Filename :  draft-choi-pcemp-ipv6-00.txt

[Abstract]
   
   In this draft, we propose a guideline for an improved version of
   router handling procedures in RFC 2461 that allow for improved
   default router acquisition performance when an active IP host moves
   from one subnet to the other using the Path Computation Element
   Metric Protocol (PCEMP). Router handling procedures can be improved
   by a soft configuration of PCEMP support in the context of
   real-time data driven strategy on individual PCE nodes.
   This draft is an informational draft that shows a guideline to
   specifications of modifying existing protocols to facilitate
   communication between LSRs and PCEs, and between a PCE and other
   PCEs. This can also be a guideline for mobile PCE nodes changing
   respective PCEDAs and thus needing fast advertisements to the
   corresponding LSRs and other PCE peers using IPv6 schemes.
 
More details available at:
 
 
Thanks again, Dip
--kebi210.107.137.122.191541098293393881 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit
Hello all once again,

 

Here is the third draft for the PCE BOF.

 

Title : Fast IPv6 PCE peer Advertisement using PCEMP


Author(s) : Jun Kyun Choi and Dipnarayan Guha


Filename :  draft-choi-pcemp-ipv6-00.txt


[Abstract]

   
   In this draft, we propose a guideline for an improved version of
   router handling procedures in RFC 2461 that allow for improved
   default router acquisition performance when an active IP host moves
   from one subnet to the other using the Path Computation Element
   Metric Protocol (PCEMP). Router handling procedures can be improved
   by a soft configuration of PCEMP support in the context of
   real-time data driven strategy on individual PCE nodes.

   This draft is an informational draft that shows a guideline to
   specifications of modifying existing protocols to facilitate
   communication between LSRs and PCEs, and between a PCE and other
   PCEs. This can also be a guideline for mobile PCE nodes changing
   respective PCEDAs and thus needing fast advertisements to the
   corresponding LSRs and other PCE peers using IPv6 schemes.

 

More details available at:

 


 

Thanks again, Dip
  --kebi210.107.137.122.191541098293393881-- --===============2085868656== 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 --===============2085868656==-- From pce-bounces@ietf.org Thu Oct 21 08:13:06 2004 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 IAA12898; Thu, 21 Oct 2004 08:13:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc1B-0007MC-1c; Thu, 21 Oct 2004 08:26:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKav4-0001zp-Kb; Thu, 21 Oct 2004 07:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKO7T-0007sF-3b for pce@megatron.ietf.org; Wed, 20 Oct 2004 17:35:43 -0400 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 RAA29660 for ; Wed, 20 Oct 2004 17:35:35 -0400 (EDT) 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 1CKOJr-0006am-D5 for pce@ietf.org; Wed, 20 Oct 2004 17:48:32 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2004 14:45:18 -0700 X-BrightmailFiltered: true 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 i9KLYcYJ023490; Wed, 20 Oct 2004 14:34:38 -0700 (PDT) Received: from [66.189.89.146] (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA25458; Wed, 20 Oct 2004 14:35:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 20 Oct 2004 17:35:03 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Pce] Proposed PCE WG Charter and relevant drafts 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Dear list, First of all, thanks for your comments on the proposed WG charter. Adrian and I are currently working on an updated version which will be posted to the list soon so as to be discussed during the second PCE BOF in Washington. An important aspect that we would like to point out relates to the scope of this potential WG. As you know, the scope is limited to the use of PCE-based TRAFFIC ENGINEERING TE LSP path computation, We saw various drafts published recently whose applicability might not be limited to MPLS TE LSP (intra and inter-domain). Could you please clarify whether the intended applicability of those draft is limited to TE LSP (in which case they would fall under the scope of the potential PCE WG) or maybe extended to other types of path computation ? JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Oct 21 08:19:12 2004 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 IAA13780; Thu, 21 Oct 2004 08:19:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc75-0007Xm-C8; Thu, 21 Oct 2004 08:32:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaxi-000793-29; Thu, 21 Oct 2004 07:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKPZd-0007jm-65 for pce@megatron.ietf.org; Wed, 20 Oct 2004 19:08:53 -0400 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 TAA11900 for ; Wed, 20 Oct 2004 19:08:44 -0400 (EDT) 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 1CKPm2-0001Kc-2U for pce@ietf.org; Wed, 20 Oct 2004 19:21:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2004 16:16:02 -0700 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 i9KN8DOE023921 for ; Wed, 20 Oct 2004 16:08:13 -0700 (PDT) Received: from [66.189.89.146] (che-vpn-cluster-2-154.cisco.com [10.86.242.154]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA10728 for ; Wed, 20 Oct 2004 16:08:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Wed, 20 Oct 2004 19:08:14 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Pce] Fwd: Proposed PCE WG Charter and relevant drafts 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="===============1963399612==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --===============1963399612== Content-Type: multipart/alternative; boundary=Apple-Mail-3--252590025 --Apple-Mail-3--252590025 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: JP Vasseur > Date: October 20, 2004 5:35:03 PM EDT > To: pce@ietf.org > Cc: Adrian Farrel , Alex Zinin > Subject: Proposed PCE WG Charter and relevant drafts > > Dear list, > > First of all, thanks for your comments on the proposed WG charter. > Adrian and I are currently working on an updated version which will be > posted to the list soon so as to be discussed during the second PCE > BOF in Washington. > > An important aspect that we would like to point out relates to the > scope of this potential WG. As you know, the scope is limited to the > use of PCE-based TRAFFIC ENGINEERING TE LSP path computation, We saw > various drafts published recently whose applicability might not be > limited to MPLS TE LSP (intra and inter-domain). Could you please > clarify whether the intended applicability of those draft is limited > to TE LSP (in which case they would fall under the scope of the > potential PCE WG) or maybe extended to other types of path computation > ? > > JP. > --Apple-Mail-3--252590025 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Begin forwarded message: Helvetica0000,0000,0000From: HelveticaJP Vasseur < 0000,0000,0000Date: October 20, 2004 5:35:03 PM EDT 0000,0000,0000To: pce@ietf.org 0000,0000,0000Cc: Adrian Farrel <, Alex Zinin < 0000,0000,0000Subject: Proposed PCE WG Charter and relevant drafts Dear list, First of all, thanks for your comments on the proposed WG charter. Adrian and I are currently working on an updated version which will be posted to the list soon so as to be discussed during the second PCE BOF in Washington. An important aspect that we would like to point out relates to the scope of this potential WG. As you know, the scope is limited to the use of PCE-based TRAFFIC ENGINEERING TE LSP path computation, We saw various drafts published recently whose applicability might not be limited to MPLS TE LSP (intra and inter-domain). Could you please clarify whether the intended applicability of those draft is limited to TE LSP (in which case they would fall under the scope of the potential PCE WG) or maybe extended to other types of path computation ? JP. --Apple-Mail-3--252590025-- --===============1963399612== 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 --===============1963399612==-- From pce-bounces@ietf.org Fri Oct 22 15:42:34 2004 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 PAA03477; Fri, 22 Oct 2004 15:42:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Vw-00059Y-Qc; Fri, 22 Oct 2004 15:55:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5AX-0002p9-4t; Fri, 22 Oct 2004 15:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL57h-0000QO-Qu for pce@megatron.ietf.org; Fri, 22 Oct 2004 15:30:49 -0400 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 PAA02649 for ; Fri, 22 Oct 2004 15:30:46 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5KN-0004v3-7x for pce@ietf.org; Fri, 22 Oct 2004 15:44:06 -0400 Received: from zhangr2.sa.infonet.com (sfjl161.us.info.net [204.79.139.161] (may be forged)) by sa.infonet.com with ESMTP id i9MJURJS026817; Fri, 22 Oct 2004 19:30:28 GMT Message-Id: <6.0.3.0.2.20041021192940.02ca8ff8@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 21 Oct 2004 19:44:24 -0700 To: "Adrian Farrel" , ccamp@ops.ietf.org From: raymond zhang In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: pce@ietf.org Subject: [Pce] Re: Your input: Use of PCE in Inter-domain 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi, A PCE-based solution, as documented in "draft-ash-pce-architecture-00.txt" provides an acceptable solution to address # of requirements in dynamically establishing optimized inter-domain TE LSPs which would otherwise become unmanageable as the interconnect density increases in both # of interconnections per provider pair and # of provider interconnects. Regards, Raymond At 12:11 PM 10/19/2004, Adrian Farrel wrote: >Folks, >The chairs and ADs would like your input on >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in >the context of our inter-domain traffic engineering work. >This draft documents an architecture for Path Computation Elements (PCE) >and is currently being discussed on the pce mailing list >(https://www1.ietf.org/mailman/listinfo/pce) >What we would like CCAMP to do is give us your opinion on whether PCE is >addresing an inter-domain problem that needs to be addressed, and if so >whether the architecture provides an acceptable way to resolve the problem. >Answers to the mailing list in advance of the meeting in Washington would >be appreciated. >Thanks, >Adrian and Kireeti > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Oct 25 13:06:59 2004 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 NAA14483; Mon, 25 Oct 2004 13:06:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Wf-00032u-Fi; Mon, 25 Oct 2004 13:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM87e-0003dA-Nm; Mon, 25 Oct 2004 12:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM843-0002x9-TK for pce@megatron.ietf.org; Mon, 25 Oct 2004 12:51:26 -0400 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 MAA13279 for ; Mon, 25 Oct 2004 12:51:20 -0400 (EDT) Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8HW-0002gt-Pg for pce@ietf.org; Mon, 25 Oct 2004 13:05:20 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0I65009PTFV6LE@firewall.mci.com> for pce@ietf.org; Mon, 25 Oct 2004 16:45:06 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I6500901FV42G@pmismtp05.mcilink.com>; Mon, 25 Oct 2004 16:45:06 +0000 (GMT) Received: from ws344v8066292 ([153.39.146.163]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I65008CWFV5K6@pmismtp05.mcilink.com>; Mon, 25 Oct 2004 16:45:05 +0000 (GMT) Date: Mon, 25 Oct 2004 12:45:05 -0400 From: "Parantap.Lahiri" Subject: RE: [Pce] Re: Your input: Use of PCE in Inter-domain In-reply-to: <6.0.3.0.2.20041021192940.02ca8ff8@sa.infonet.com> To: "'Adrian Farrel'" , ccamp@ops.ietf.org Message-id: <004701c4bab1$fad642a0$a3922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Hi Adrian and Kireeti, I think the PCE based solution is a reasonable way of approaching this problem. It might be a good idea to take it up in a PCE WG. -Parantap=20 -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of raymond zhang Sent: Thursday, October 21, 2004 10:44 PM To: Adrian Farrel; ccamp@ops.ietf.org Cc: pce@ietf.org Subject: [Pce] Re: Your input: Use of PCE in Inter-domain Hi, A PCE-based solution, as documented in = "draft-ash-pce-architecture-00.txt"=20 provides an acceptable solution to address # of requirements in = dynamically=20 establishing optimized inter-domain TE LSPs which would otherwise become = unmanageable as the interconnect density increases in both # of=20 interconnections per provider pair and # of provider interconnects. Regards, Raymond At 12:11 PM 10/19/2004, Adrian Farrel wrote: >Folks, >The chairs and ADs would like your input on=20 >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt = in=20 >the context of our inter-domain traffic engineering work. >This draft documents an architecture for Path Computation Elements = (PCE)=20 >and is currently being discussed on the pce mailing list=20 >(https://www1.ietf.org/mailman/listinfo/pce) >What we would like CCAMP to do is give us your opinion on whether PCE = is=20 >addresing an inter-domain problem that needs to be addressed, and if so = >whether the architecture provides an acceptable way to resolve the = problem. >Answers to the mailing list in advance of the meeting in Washington = would=20 >be appreciated. >Thanks, >Adrian and Kireeti > > > _______________________________________________ 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 Oct 26 04:56:40 2004 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 EAA13327; Tue, 26 Oct 2004 04:56:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNLr-0006Mq-Qh; Tue, 26 Oct 2004 05:10:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMN3k-0005x9-Mu; Tue, 26 Oct 2004 04:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMv9-00047R-Ne for pce@megatron.ietf.org; Tue, 26 Oct 2004 04:43:11 -0400 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 EAA11510 for ; Tue, 26 Oct 2004 04:43:09 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMN8k-0005wT-VW for pce@ietf.org; Tue, 26 Oct 2004 04:57:16 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 10:41:53 +0200 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 Subject: RE: [Pce] Proposed PCE WG Charter and relevant drafts Date: Tue, 26 Oct 2004 10:41:52 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B019D448@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [Pce] Proposed PCE WG Charter and relevant drafts Thread-Index: AcS3Z1aPJKQgbMGxTWm36a5j4zXs9gDztzKw From: "BOUCADAIR Mohamed RD-CORE-CAE" To: "JP Vasseur" , X-OriginalArrivalTime: 26 Oct 2004 08:41:53.0527 (UTC) FILETIME=[A4C64870:01C4BB37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Hi Jean Philippe and all, We have submitted three drafts that focus on the computation of inter-provider QoS constrained LSP paths. Service considerations are taken into account in order to allow such scenarios in an inter-provider environment. We believe that the PCE approach is a viable track to offer QoS sensitive services (e.g. VoIP). These drafts are: http://www.ietf.org/internet-drafts/draft-boucadair-pce-discovery-00.txt http://www.ietf.org/internet-drafts/draft-boucadair-pce-interas-00.txt http://www.ietf.org/internet-drafts/draft-boucadair-pcp-interas-00.txt I suggest that this issue to be covered also by the work of the future PCE WG.=20 Med -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org]De la part de JP Vasseur Envoye : mercredi 20 octobre 2004 23:35 A : pce@ietf.org Objet : [Pce] Proposed PCE WG Charter and relevant drafts Dear list, First of all, thanks for your comments on the proposed WG charter.=20 Adrian and I are currently working on an updated version which will be=20 posted to the list soon so as to be discussed during the second PCE BOF=20 in Washington. An important aspect that we would like to point out relates to the=20 scope of this potential WG. As you know, the scope is limited to the=20 use of PCE-based TRAFFIC ENGINEERING TE LSP path computation, We saw=20 various drafts published recently whose applicability might not be=20 limited to MPLS TE LSP (intra and inter-domain). Could you please=20 clarify whether the intended applicability of those draft is limited to=20 TE LSP (in which case they would fall under the scope of the potential=20 PCE WG) or maybe extended to other types of path computation ? JP. _______________________________________________ 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 Oct 26 18:54:54 2004 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 SAA19208; Tue, 26 Oct 2004 18:54:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMaRA-0007mP-SQ; Tue, 26 Oct 2004 19:09:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYp3-0000bV-Oq; Tue, 26 Oct 2004 17:25:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMY3T-00077N-92 for pce@megatron.ietf.org; Tue, 26 Oct 2004 16:36:31 -0400 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 QAA14526 for ; Tue, 26 Oct 2004 16:36:28 -0400 (EDT) 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 1CMYHB-0005Jd-Uz for pce@ietf.org; Tue, 26 Oct 2004 16:50:42 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2004 13:47:16 -0700 X-BrightmailFiltered: true 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 i9QKZvk2008836; Tue, 26 Oct 2004 13:35:57 -0700 (PDT) Received: from [66.189.93.121] (che-vpn-cluster-1-36.cisco.com [10.86.240.36]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA22170; Tue, 26 Oct 2004 13:35:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Tue, 26 Oct 2004 16:35:55 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Bill Fenner Subject: [Pce] New Proposed PCE WG Charter 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="===============0097143598==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 --===============0097143598== Content-Type: multipart/alternative; boundary=Apple-Mail-36-256671566 --Apple-Mail-36-256671566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Dear list members, First of all, thanks for various comments that we received from various=20= sources. Adrian and I have updated the proposed WG Charter, which=20 reflects those comments/suggestions. Obviously, further comments and=20 feed-backs are very welcome: having a proposed WG charter we all agree=20= on before our second BPF would be a good step. Proposed PCE Working Charter and Milestones WG items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP=20 path computation techniques involving Path Computation Element(s). This=20= includes the case of intra and inter-domain (where a domain might be a=20= specific layer, an IGP area or an Autonomous System) TE LSPs path=20 computation and applies to Point to Point and Point to Multipoint TE=20 LSPs. Such path computation techniques include primary, protection and=20= recovery paths as well as load balancing techniques. - Specification of PCE-based architectures including centralized,=20 distributed and cooperative models. - Specification of routing (OSPF, ISIS, BGP) and LSP signaling=20 (RSVP-TE) extensions required by PCE-based path computation techniques. - Specification of techniques in support of PCE discovery within and=20 across domains. Where such techniques result in the extensions of=20 existing protocols, this work will be done in conjunction with the=20 appropriate WGs. - Specification of new protocols or modifications to existing protocols=20= to facilitate communication between PCC (Path Computation Client) and=20 PCE(s), and between PCEs. - Definition of protocol-independent metrics defining path quality=20 measurement criteria and scalability criteria related to path=20 computation techniques. - Specification of requirements and protocol extensions related to the=20= policy, security and confidentiality aspects of PCE-based path=20 computation techniques involving PCEs of multiple administrative=20 entities. - Definition of MIBs and management procedures related to the new=20 protocols, protocol extensions and operational elements defined by the=20= WG. The WG will work closely with the following other WGs: CCAMP, MPLS,=20 ISIS, OSPF and IDR; and will also cooperate with the ITU-T and OIF=20 where appropriate. Proposed WG Goals and initial Milestones (date to be determined) Requirement drafts (multiple drafts may be expected coming various=20 other WGs and submitted to be PCE WG) Finalize the PCE architecture document(s) =A0=A0 Identify and document a limited set of candidate solutions for PCC-PCE=20= and PCE-PCE signaling. Among candidate solutions to be considered are=20 the existing signaling protocols defined in other WGs. Identify protocol extensions for PCE discovery Thanks. JP and Adrian. --Apple-Mail-36-256671566 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear list members, First of all, thanks for various comments that we received from various sources. Adrian and I have updated the proposed WG Charter, which reflects those comments/suggestions. Obviously, further comments and feed-backs are very welcome: having a proposed WG charter we all agree on before our second BPF would be a good step. Proposed PCE Working Charter and = Milestones WG items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation techniques involving Path Computation Element(s). This includes the case of intra and inter-domain (where a domain might be a specific layer, an IGP area or an Autonomous System) TE LSPs path computation and applies to Point to Point and Point to Multipoint TE LSPs. Such path computation techniques include primary, protection and recovery paths as well as load balancing techniques. - Specification of PCE-based architectures including centralized, distributed and cooperative models. - Specification of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required by PCE-based path computation techniques.=20 - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols, this work will be done in conjunction with the appropriate WGs. - Specification of new protocols or modifications to existing protocols to facilitate communication between PCC (Path Computation Client) and PCE(s), and between PCEs. - Definition of protocol-independent metrics defining path quality measurement criteria and scalability criteria related to path computation techniques. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple administrative entities. - Definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements defined by the WG. The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF and IDR; and will also cooperate with the ITU-T and OIF where appropriate. Proposed WG Goals and initial Milestones (date to be determined) Requirement drafts (multiple drafts may be expected coming various other WGs and submitted to be PCE WG) Finalize the PCE architecture document(s) =A0=A0 Identify and document a limited set of candidate solutions for PCC-PCE and PCE-PCE signaling. Among candidate solutions to be considered are the existing signaling protocols defined in other WGs. Identify protocol extensions for PCE discovery Thanks. JP and Adrian. = --Apple-Mail-36-256671566-- --===============0097143598== 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 --===============0097143598==-- From pce-bounces@ietf.org Thu Oct 28 09:51:07 2004 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 JAA13234; Thu, 28 Oct 2004 09:51:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAuJ-0001Xf-2j; Thu, 28 Oct 2004 10:05:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAXS-0006Ym-1X; Thu, 28 Oct 2004 09:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNARI-0005Iz-TH for pce@megatron.ietf.org; Thu, 28 Oct 2004 09:35:40 -0400 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 JAA11936 for ; Thu, 28 Oct 2004 09:35:36 -0400 (EDT) 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 1CNAfJ-00018N-JT for pce@ietf.org; Thu, 28 Oct 2004 09:50:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 06:44:20 -0700 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 i9SDYxk2005678; Thu, 28 Oct 2004 06:35:00 -0700 (PDT) Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-206.cisco.com [10.86.162.206]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA04206; Thu, 28 Oct 2004 06:35:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20041028093249.059a50a0@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 09:34:27 -0400 To: pce@ietf.org From: Jean Philippe Vasseur Mime-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: bill Fenner Subject: [Pce] Second BOF schedule 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="===============1643320433==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 --===============1643320433== Content-Type: multipart/alternative; boundary="=====================_657934199==_.ALT" --=====================_657934199==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Just to inform that the schedule for our second PCE BOF meeting has been determined: WEDNESDAY, November 10, 2004 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APPsimpleSIP for Instant Messaging and Presence Leveraging Extensions WG INTeapExtensible Authentication Protocol WG OPSv6opsIPv6 Operations WG * RTGidrInter-Domain Routing WG TSVnfsv4Network File System Version 4 WG 1130-1300 Break 1300-1500 Afternoon Sessions I APPgeoprivGeographic Location/Privacy WG GENnewtrkNew IETF Standards Track WG INTdnsextDNS Extensions WG INTnemoNetwork Mobility WG OPSopsareaOperations & Management Open Area Meeting RTGmanetMobile Ad-hoc Networks WG SECpkixPublic-Key Infrastructure (X.509) WG TSVsipSession Initiation Protocol WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APPwebdavWWW Distributed Authoring and Versioning WG INT6lowpanIPv6 over Low-power WPAN BOF IRTFmoboptsIP Mobility Optimizations RG OPSmulti6Site Multhoming in IPv6 WG RTGpcePath Computation Element BOF SECkrbwgKerberos WG TSVtsvwgTransport Area Working Group Adrian and I will shortly send you a proposed agenda. JP. --=====================_657934199==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

Just to inform that the schedule for our second PCE BOF meeting has been determined:

WEDNESDAY, November 10, 2004
0800-1800 IETF Registration -
0800-0900 Continental Breakfast -
0900-1130 Morning Sessions
APPsimpleSIP for Instant Messaging and Presence Leveraging Extensions WG
INTeapExtensible Authentication Protocol WG
OPSv6opsIPv6 Operations WG *
RTGidrInter-Domain Routing WG
TSVnfsv4Network File System Version 4 WG
1130-1300 Break
1300-1500 Afternoon Sessions I
APPgeoprivGeographic Location/Privacy WG
GENnewtrkNew IETF Standards Track WG
INTdnsextDNS Extensions WG
INTnemoNetwork Mobility WG
OPSopsareaOperations & Management Open Area Meeting
RTGmanetMobile Ad-hoc Networks WG
SECpkixPublic-Key Infrastructure (X.509) WG
TSVsipSession Initiation Protocol WG
1500-1530 Break (Refreshments provided) -
1530-1730 Afternoon Sessions II
APPwebdavWWW Distributed Authoring and Versioning WG
INT6lowpanIPv6 over Low-power WPAN BOF
IRTFmoboptsIP Mobility Optimizations RG
OPSmulti6Site Multhoming in IPv6 WG
RTGpcePath Computation Element BOF
SECkrbwgKerberos WG
TSVtsvwgTransport Area Working Group

Adrian and I will shortly send you a proposed agenda.

JP. --=====================_657934199==_.ALT-- --===============1643320433== 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 --===============1643320433==-- From pce-bounces@ietf.org Fri Oct 29 11:09:29 2004 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 LAA07952; Fri, 29 Oct 2004 11:09:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNYbw-00016k-9B; Fri, 29 Oct 2004 11:24:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYDM-0003am-C4; Fri, 29 Oct 2004 10:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLk0H-00045L-MF for pce@megatron.ietf.org; Sun, 24 Oct 2004 11:09:53 -0400 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 LAA05616 for ; Sun, 24 Oct 2004 11:09:51 -0400 (EDT) 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 1CLkDL-0007gG-NY for pce@ietf.org; Sun, 24 Oct 2004 11:23:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2004 08:20:02 -0700 X-BrightmailFiltered: true 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 i9OF91YJ009491; Sun, 24 Oct 2004 08:09:02 -0700 (PDT) Received: from [66.189.89.64] (che-vpn-cluster-1-134.cisco.com [10.86.240.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA25782; Sun, 24 Oct 2004 08:09:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: pce@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-5-64257225 From: JP Vasseur Date: Sun, 24 Oct 2004 11:09:01 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 62b5971f410f8a9411789cf7221d7b70 X-Mailman-Approved-At: Fri, 29 Oct 2004 10:58:50 -0400 Subject: [Pce] Fwd: Submission of Individual Draft - PCE BOF 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: e697ed3465ad27d848ef8a3a747fe199 --Apple-Mail-5-64257225 Content-Type: multipart/alternative; boundary=Apple-Mail-6-64257225 --Apple-Mail-6-64257225 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable FYI although we will not have time during the next PCE BOF to spend=20 that much time on drafts since the primer focus will the the proposed=20 charter. Feel free to comment this ID on the list. JP. Begin forwarded message: > From: "Dipnarayan Guha" > Date: October 24, 2004 10:47:48 AM EDT > To: internet-drafts@ietf.org, adrian@olddog.co.uk, jpv@cisco.com,=20 > gash@att.com > Cc: jkchoi@icu.ac.kr, dip@icu.ac.kr, jhhahm@etri.re.kr > Subject: Submission of Individual Draft - PCE BOF > Reply-To: dip@icu.ac.kr > > Hello There! > > > > > We would like to submit an Internet Draft for the upcoming PCE BOF=20 > session at the 61st. IETF. > > > =A0 > > > > Title : Fast End-to-End Restoration Mechanism with SRLG using=20 > Centralized Control > > > > Author(s) : Jun Kyun Choi, Dipnarayan Guha and Jin Ho Hahm > > > > Filename :=A0=A0draft-choi-pce-e2e-centralized-restoration-srlg-01.txt > > > > > [Abstract] > > > > =A0=A0=A0 > =A0=A0 This draft describes the concept of the Shared Link Risk Group > =A0=A0 (SRLG) based logical ring configuration and recovery method = using > =A0=A0 ring SRLG for the purpose of PCE-based backup path = computation.=A0 > =A0=A0 In this restoration architecture, backup paths can be easily > =A0=A0 established through the end-to-end path which follows from the > =A0=A0 logical ring configuration. It guarantees the establishment of > =A0=A0 backup path disjoint from the working path at all levels. To = take > =A0=A0 advantage of bandwidth considerations and fast restoration > =A0=A0 mechanisms, a centralized Controller is used to provide > =A0=A0 dedicated protection to Optical Transport Networks using the > =A0=A0 SRLG concept. > =A0=A0 > > > =A0=A0 > =A0=A0 A robust and efficient signaling protocol, PCEMP, is used to > =A0=A0 distribute the mapping table from the Controller (PCE node) to = the > =A0=A0 nodes in the optical transport network and for informing a = failure > =A0=A0 from a node to the corresponding Controller. > > > =A0 > > > =A0 > > > =A0=A0 This draft is in conjunction to explore the possibility of > =A0=A0 explicitly including PCE-based backup path computation > =A0=A0 within the scope of the PCE WG Charter > =A0=A0 > =A0 > > > > Thanks A Lot, > > > > =A0 > Dip > > --Apple-Mail-6-64257225 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI although we will not have time during the next PCE BOF to spend that much time on drafts since the primer focus will the the proposed charter. Feel free to comment this ID on the list. JP. Begin forwarded message: = Helvetica0000,0000= ,0000From: = Helvetica= "Dipnarayan Guha" < 0000,0000,0000Date: October 24, 2004 10:47:48 AM EDT 0000,0000,0000To: internet-drafts@ietf.org, adrian@olddog.co.uk, jpv@cisco.com, gash@att.com 0000,0000,0000Cc: jkchoi@icu.ac.kr, dip@icu.ac.kr, jhhahm@etri.re.kr 0000,0000,0000Subject: Submission of Individual Draft - PCE BOF 0000,0000,0000Reply-To: dip@icu.ac.kr Hello There! We would like to submit an Internet Draft for the upcoming PCE BOF session at the 61st. IETF. =A0 Title : Fast End-to-End Restoration Mechanism with SRLG using Centralized Control Author(s) : Jun Kyun Choi, Dipnarayan Guha and Jin Ho Hahm Filename :=A0=A0draft-choi-pce-e2e-centralized-restoration-srlg-01.txt [Abstract] =A0=A0=A0 =A0=A0 This draft describes the concept of the Shared Link Risk Group=20 =A0=A0 (SRLG) based logical ring configuration and recovery method using=20= =A0=A0 ring SRLG for the purpose of PCE-based backup path computation.=A0 =A0=A0 In this restoration architecture, backup paths can be easily=20 =A0=A0 established through the end-to-end path which follows from the=20 =A0=A0 logical ring configuration. It guarantees the establishment of=20 =A0=A0 backup path disjoint from the working path at all levels. To take =A0=A0 advantage of bandwidth considerations and fast restoration =A0=A0 mechanisms, a centralized Controller is used to provide =A0=A0 dedicated protection to Optical Transport Networks using the=20 =A0=A0 SRLG concept. =A0=A0 =A0=A0=20 =A0=A0 A robust and efficient signaling protocol, PCEMP, is used to=20 =A0=A0 distribute the mapping table from the Controller (PCE node) to = the=20 =A0=A0 nodes in the optical transport network and for informing a = failure=20 =A0=A0 from a node to the corresponding Controller. =A0 =A0 =A0=A0 This draft is in conjunction to explore the possibility of=20 =A0=A0 explicitly including PCE-based backup path computation =A0=A0 within the scope of the PCE WG Charter =A0=A0=20 =A0 Thanks A Lot, =A0 Dip 7070,8080,AAAA = --Apple-Mail-6-64257225-- --Apple-Mail-5-64257225 Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="dip.gif" Content-Disposition: inline; filename=dip.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw== --Apple-Mail-5-64257225 Content-Type: multipart/alternative; boundary=Apple-Mail-7-64257226 --Apple-Mail-7-64257226 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable > =A0= --Apple-Mail-7-64257226 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0= --Apple-Mail-7-64257226-- --Apple-Mail-5-64257225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0666; name="draft-choi-pce-e2e-centralized-restoration-srlg-01.txt" Content-Disposition: attachment; filename=draft-choi-pce-e2e-centralized-restoration-srlg-01.txt Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =0D Network Working Group Jun Kyun Choi = (ICU)=0D Internet Draft Dipnarayan Guha = (ICU)=0D Category: Informational Jin Ho Hahm = (ETRI)=0D Expiration Date: April 2005 October = 2004=0D =0D =0D =0D Fast End-to-End Restoration Mechanism with SRLG using Centralized = Control=0D =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt=0D= =0D =0D =0D Status of this Memo=0D =0D This document is an Internet-Draft and is in full conformance with=0D all provisions of Section 10 of RFC2026.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six=0D months and may be updated, replaced, or obsoleted by other documents=0D= at any time. It is inappropriate to use Internet-Drafts as=0D reference material or to cite them other than as "work in progress."=0D= =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/ietf/1id-abstracts.txt=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html.=0D =0D By submitting this Internet-Draft, we certify that any applicable =0D patent or other IPR claims of which we are aware have been =0D disclosed, and any of which we become aware will be disclosed, =0D in accordance with RFC 3668.=0D =0D =0D Abstract=0D =0D =0D This draft describes the concept of the Shared Link Risk Group =0D (SRLG) based logical ring configuration and recovery method using =0D ring SRLG for the purpose of PCE-based backup path computation. =0D In this restoration architecture, backup paths can be easily =0D established through the end-to-end path which follows from the =0D logical ring configuration. It guarantees the establishment of =0D backup path disjoint from the working path at all levels. To take =0D advantage of bandwidth considerations and fast restoration =0D mechanisms, a centralized Controller is used to provide =0D dedicated protection to Optical Transport Networks using the =0D SRLG concept.=0D =0D =0D J K Choi, D Guha Informational [Page 1]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D A robust and efficient signaling protocol, PCEMP, is used to =0D distribute the mapping table from the Controller (PCE node) to the =0D= nodes in the optical transport network and for informing a failure =0D= from a node to the corresponding Controller. =0D =0D This draft is in conjunction to explore the possibility of =0D explicitly including PCE-based backup path computation =0D within the scope of the PCE WG Charter=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D J K Choi, D Guha Informational [Page 2]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D Table of Contents=0D =0D 1 Terminology ................................................. 3=0D= 2 Introduction ................................................ 4=0D= 3 Network Architecture for centralized control using SRLG ..... 6=0D= 3.1 Introduction to the centralized Controller .............. 7=0D= 3.2 Network structure ....................................... 7=0D= 3.3 Control structure ....................................... 8=0D= 3.4 Control plane hierarchy architecture for SRLG based =0D protection and PCE based recovery ........................... 8=0D= 4 Logical ring configuration based on SRLG .................... 9=0D= 4.1 Logical ring with SRLG .................................. 9=0D= 4.2 Segment wise logical ring using the centralized =0D Controller in the PCE node .................................. 10=0D= 4.3 Resource allocation with SRLG by the Controller ......... 11=0D= 5 Integrated Layer survivability and recovery mechanisms ...... 12=0D= 5.1 PCE-based Protection and Recovery Mechanisms ............ 12=0D= 5.2 Protocol based Ring Recovery mechanisms using the =0D Controller in the PCE node .................................. 13=0D= 6 Key features of PCEMP ....................................... 14=0D= 6.1 Other features of PCEMP ................................. 14=0D= 6.2 Protocol level hierarchy architecture on the control =0D plane ....................................................... 16=0D= 6.3 Role of CC and SPC ..................................... 17=0D= 7 Conclusion .................................................. 18=0D= 8 Security Considerations ..................................... 19=0D= 9 IANA Considerations ......................................... 19=0D= 10 Acknowledgements ............................................ 19=0D= 11 Intellectual Property Considerations ........................ 19=0D= 12 Normative References ........................................ 20=0D= 13 Informational References .................................... 20=0D= 14 Authors' Addresses .......................................... 22=0D= 15 Full Copyright Statement .................................... 22=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D J K Choi, D Guha Informational [Page 3]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D 1. Terminology=0D =0D This memo makes use of the following terms: =0D =0D 1. Path Computation Element (PCE): an entity that is responsible =0D= for computing/finding inter/intra domain LSPs. This entity can =0D= simultaneously act as a client and a server. Several PCEs can =0D= be deployed in a given Autonomous System (AS). = =0D =0D 2. Path Computation Element node (PCE Node): a network processing =0D= unit comprising of a PCE unit. This can be embedded in a router=0D= or a switch. =0D =0D 3. Domain: Denotes an Autonomous system (AS) within the scope of=0D this draft.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D J K Choi, D Guha Informational [Page 4]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D 2. Introduction=0D =0D With the rapid growth of the Internet, the advance of wavelength =0D division multiplexing (WDM) technology, and the integration of =0D various communication technologies, the communication network is =0D evolving to include huge bandwidth-intensive network applications. =0D= Survivability refers to the ability of the network to transfer the =0D= interrupted service onto spare network capacity to circumvent a =0D point of failure in the network and it is a critical requirement =0D for IP over WDM networks. In a WDM network, a link failure, fiber =0D cut, node down may be due to human error or natural disasters =0D leading to the loss of large amount of data and multiple failures =0D of all the optical paths that traverse the fiber. So, we have to =0D develop appropriate recovery architecture and strategies that =0D minimize the data loss when a failure on a path occurs in WDM =0D based GMPLS (Generalized Multi-Protocol Label Switching) networks =0D that will offer fast recovery, with speeds comparable to SONET, =0D and versatile survivable functions. =0D =0D Recovery techniques are broadly classified by computation timing =0D as pre-computed and dynamic and by their type of rerouting as =0D link-based, partial path-based and path-based. In dynamic =0D techniques, a search for backup path is initiated upon occurrence =0D of a failure. A backup path is computed based on availability of =0D resource at that time of failure. While dynamic techniques provide =0D= better resource utilization, they suffer from long delays to search =0D= and reroute the traffic on to the backup path and there is no =0D guarantee that the connection can be restored upon failure. Dynamic =0D= techniques provide a best-effort type of service. In protection =0D techniques the primary and backup routes are computed and resources =0D= are reserved for backup paths before the connection is established. =0D= Upon occurrence of a failure the backup path is established and =0D traffic is immediately routed on to the backup path. A pre-computed =0D= method avoids long delays in setting up backup paths upon failure. =0D= The pre-computed techniques also provide guarantee that a connection =0D= can be restored in the event of failure. According to range of =0D rerouting, the recovery techniques are classified into link-based, =0D= segment-wised based and path-based recovery. Link-based techniques =0D= reroute disrupted traffic around the failed link. This approach =0D requires the ability to identify a failed link at both ends. It =0D also makes recovery more difficult in the event of a node failure. =0D= Furthermore, it limits the choice of backup path and thus may use =0D more capacity, while path-base techniques replace the whole path =0D between the two endpoints of a demand. The path-based techniques =0D have better resource utilization while span-based techniques have =0D better recovery time. Therefore, we focus on the path-based =0D recovery, called end-to-end recovery. =0D =0D =0D =0D J K Choi, D Guha Informational [Page 5]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D Most backbone networks have a mesh physical topology. However, the =0D= mesh-based schemes have some shortcomings. They are not as fast in =0D= failure recovery as ring-based schemes and complicated working path =0D= and backup path routing arrangements are used to achieve optimality, =0D= and the optimization procedures used for mesh-based schemes are =0D very computationally intensive that are virtually impossible to =0D solve for very large networks. SONET networks are, for the most =0D part, protected in the form of rings. The rings are interconnected =0D= in order to provide overall network connectivity and protection. It =0D= is possible to design a fast and simple recovery strategy for ring =0D= network so ring protection switching is well established and robust =0D= in these days. Therefore, we need the ring concept in the mesh =0D optical network. =0D =0D This draft describes the Ring configuration based on SRLG =0D information and the approach of using a centralized Controller that =0D= enables fast restoration in optical transport networks. Using the =0D centralized Controller guarantees the establishment of a disjoint =0D end-to-end restoration path from failed working paths, and helps in =0D= achieving near real-time end-to-end restoration in optical =0D transport networks.=0D =0D This forms the basis of including PCE-based backup path computation =0D= within the scope of the PCE WG Charter.=0D =0D =0D 3. Network Architecture for centralized Control using SRLG=0D =0D =0D __________________Control/Management = Network__________________________ =0D / = \ =0D / +--+ PCEMP +--+ PCEMP = +--+ \ =0D / | |-------------------| |--------------------------| = | \=0D / +--+Centralized +--+Centralized = +--+Centralized \=0D \ /|| Controller /|| Controller / || = Controller / =0D \ / | \ (PCE node) / | \ (PCE node) / | = \ /=0D \___|_|__\_________________|_|__\______________________|__ = |__\__________/ =0D | | | | | \ | | = \=0D / | \ / | | / | = |=0D Control / | \-- PCEMP ---- / | \ ------ PCEMP--- / | = \=0D Channel / | \ / | \ / | = \=0D _______/____|_____ \___ _____/____|______\_____ ______|______ = |______\_____ =0D \ +--+ | +--+ | \ +--+ | +--+ | \ +--+ | = +--+ |=0D \ | |OXC | | | | \ | | | OXC| | | \ | |OXC | = | | |=0D \ +--+ | +--+ / \ +--+ | +--+ / \ +--+ | = +--+ / =0D \ \ | / / \ \ | / / \ \ | = / / =0D \ \ | / / \ \ | Xfail/ \ Data-> \ | = / / =0D \ \ | / / \ \ \ / / \Channel \ | = / / =0D \ +--+ / \ +--+ / \ = +--+ / =0D \ | | / \ | | / \ | = | / =0D \ +--+ / \ +--+ / Optical \ = +--+ / =0D \ / \ / Transport \ = /=0D \____/ \_____/ Network = \________/ =0D =0D =0D Figure 1. Network Architecture for Centralized Control using SRLG =0D= =0D Generalized Multi-protocol Label Switching (GMPLS) enables service =0D= providers to build networks with the flexibility of IP, the =0D reliability of SONET/SDH and the scalability of optics at costs =0D to offer services at extremely competitive prices. GMPLS supports =0D= a concept of common control of packet, TDM, wavelength and fiber =0D services, and is a key enabler of the new network architecture =0D model. =0D =0D =0D J K Choi, D Guha Informational [Page 6]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D 3.1 Introduction to the centralized Controller:=0D =0D This draft addresses the coordination of the IP and optical =0D network survivability based on a consolidated network element, =0D the controller and a truly integrated control plane. This =0D centralized Controller in the PCE node enables an integrated =0D network architecture where each network layer can freely exchange =0D= topology and resource information. This allows network performance =0D= to be globally optimized across all layers. In addition, a single =0D= control plane and the central controller that manages all network =0D= layers greatly simplify network management tasks.=0D =0D =0D As far as control and management types are concerned, they can be =0D= classified into three categories: centralized, distributed and =0D hybrid control/management. Each control and management type has =0D its' own advantages and disadvantages, but typical telecommunication = =0D networks and automatic switched optical networks (ASON) defined =0D in ITU-T follows a centralized control/management architecture in =0D= which the control plane is separate from the data plane. In this =0D draft, for path establishment and protection, we consider the =0D control plane to be separated logically from the data plane. =0D Separate Controllers or control/management networks comprising of a =0D= series of Controllers could be connected to each other by through =0D= signaling channels and appropriate control message exchanges. If =0D the domains of the control/management networks increase, a =0D hierarchical control/management structure could be applied. This =0D can be fully realized in the centralized Controller through logical =0D= functional blocks. We do not restrict the interconnection =0D architecture of the optical transport networks such as overlay =0D model, peer model and augmented model. There is a channel =0D interface between the Controller and any node in the optical =0D transport network, and this can be realized using a number of =0D methods, like Simple Network Management Protocol (SNMP), General =0D Switch Management Protocol (GSMP) etc. In this architecture, the =0D Controller is responsible for path calculation and recovery. Some =0D= of the recovery functions are also assigned to nodes in the =0D optical network for the purpose of control and load balancing. =0D The Controller thus forms the building block of a PCE node for =0D the purpose of PCE based backup path computation.=0D =0D 3.2 Network Structure:=0D =0D In this draft, we develop the network architecture with a =0D hierarchical structure following the existing network management =0D architecture. We focus on the backbone part of networks where =0D link capacity is at least OC-48 (2.5 Gb/s). Each network node is =0D assumed to have OXC and IP router capabilities in the same =0D hardware setup, which results in the support of multiple traffic =0D types at the same location. The traffic manager in each optical =0D network node also manages multiple traffic types. Each node can =0D communicate directly with the centralized Controller to report =0D its status. As mentioned in Section 3.1, this could be achieved =0D via a network management standard, such as SNMP or GSMP. The =0D Controller takes care of network nodes within the same =0D administrative domain. It also has the responsibility of =0D centralizing domain network management service and integrating =0D the management of the transport network in its respective domain. =0D= This structure permits scalability, as well as internetworking =0D of different administrative domains.=0D =0D =0D =0D J K Choi, D Guha Informational [Page 7]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D 3.3 Control Structure:=0D =0D Network elements within each domain communicate with one another =0D via a common control plane. We assume a dedicated out-of-band =0D control channel between two adjacent nodes, and between each node =0D= and the centralized Controller. The common control plane can be =0D implemented based on the GMPLS standard. The Resource Reservation =0D= Protocol (RSVP) and Constraint-Based Routing Label Distribution =0D Protocol (CR-LDP) extensions to GMPLS can provide traffic =0D engineering in this unified network architecture. Moreover, =0D neighbor discovery and link state update can employ routing =0D protocol Link State Advertisements (LSA), such as the Intermediate =0D= System to Intermediate System (IS-IS) and Open Shortest Path =0D First (OSPF) extensions to GMPLS. =0D =0D 3.4 Control Plane hierarchy architecture for SRLG Protection and =0D Recovery:=0D =0D In the integrated control plane proposed here, three levels of =0D functional control hierarchy are mapped into one centralized =0D Controller node and implemented as a single unit. The functional =0D blocks involved in the controller node are: the network processor =0D= (the network management system with extended functionalities), the =0D= domain processor (the network element management system with =0D extended functionalities), and the node processor. In the first =0D level, the network processor acts as an interface between users =0D and all sub-network domains. Its main functionality is to oversee =0D= the provisioning of new connections across multiple sub-networks =0D and to maintain the network-wide topological view. The domain =0D processor supervises tasks within a sub-network domain, such as =0D service provisioning and network status monitoring. It handles =0D requests for connection setup and teardown, and computes =0D explicit paths that meet the SLA of each request. The network =0D monitor observes the overall network health and detects failure =0D and repair events. The databases maintained by the domain =0D processor include the domain topology, the domain link state =0D database gathered via the LSA protocol within its domain, and =0D the domain connection database which keeps track of all =0D established connections in the domain. The node processor =0D manages specific functionalities that can be done in a =0D distributed manner at each node, such as overload handling, =0D failure recovery, and status monitoring. It also detects sudden =0D link overloads, conducts a countermeasure and provides rapid =0D protection and restoration capability in times of failure. The =0D databases maintained by the node processor are the local link =0D state and the local connection databases. The local link state =0D is obtained automatically via the neighbor discovery protocol, =0D while the list of local connections is obtained from all =0D connections that traverse the node.=0D =0D =0D =0D J K Choi, D Guha Informational [Page 8]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D =0D The structure of the topology database may contain the combined =0D IP and optical layer topology in a unified form. The link state =0D database contains information not only about link connectivity, =0D but also about the shared-risk link group (SRLG) it belongs to, =0D the resources available on that link, the link protection type, =0D and the link status. This extra information is defined in the =0D LSA extensions to the GMPLS. =0D =0D =0D 4. Logical ring configuration based on SRLG=0D =0D In this part, we describe some of the logical ring configuration =0D methods for optical networks and the functions of the centralized =0D= Controller in providing real-time protection and recovery. =0D Ring-based schemes are essentially some extensions of self-healing =0D= ring in the mesh topology, and the study of logical ring in mesh =0D network has been developed. =0D =0D 4.1 Logical Ring with SRLG:=0D =0D Shared Risk Link Groups (SRLGs) allow the definition of resources =0D= or groups of resources that share the same risk of failure [6]. =0D The knowledge of SRLGs may be used to compute diverse paths that =0D can be used for protection in optical networks. The concept of =0D SRLG has been used to compute a path that is disjoint from a set =0D of links sharing the same risk. When two or more links share the =0D same risk, it may be the case that when a link fails, the others =0D fail at the same time. Proper planning needs to be done for the =0D network to recover from failures due to these risks. The risks =0D are generally represented by SRLGs. The SRLG concept generates =0D another dimension to the existing constraint-based path =0D computation methods traditionally used in hierarchical networks. =0D =0D Existing logical ring architectures for recovery do not consider =0D the SRLG information for survivability of working paths and =0D backup paths and is generally configured based on topology =0D information and network characteristics. If the link from the =0D first ingress node is broken, the network cannot provide LSP SRLG =0D= disjointness. This is a rather strong bottleneck to support =0D survivability of connections with different bandwidth =0D requirements and QoS constraints. The existing logical ring =0D configuration does not take account into the probability of =0D resource failure and risk of the link. Therefore, the disjoint =0D path may, in some cases, have some problems in being computed =0D and hence the probability of backup path failure increases =0D though the backup path may exist. We need to consider the =0D possibility of failure of the logical ring configuration at the =0D connection setup stage. =0D =0D We propose the network architecture as the concept of the =0D logical ring with the SRLG for reliable transmission in =0D pre-configuration stage using the centralized Controller concept. =0D= The proposed network with ring-SRLG is the set of SRLGs with =0D contribution weights per link to avoid backup path failure and =0D =0D =0D =0D J K Choi, D Guha Informational [Page 9]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D guarantee the survivability of traffic. The controller manages =0D the entire domain network, as discussed in Section 3.4. The =0D description follows a logical ring configuration with SRLG for =0D the purpose of restoration in mesh networks. In this architecture, =0D= backup paths can be easily established end-to-end using the =0D logical ring configuration. It guarantees the establishment of a =0D backup path that is disjoint from a primary path that is set up. =0D The logical ring with ring-SRLG has both a primary path and a =0D backup path in same ring with one ring-SRLG. Ring-SRLG must =0D support two-way-connectivity, which supports the logical ring =0D architecture in OXC based mesh network and helps in protection =0D and recovery using the centralized Controller concept. Based on =0D a given SRLG table, which is configured at each node by the =0D centralized Controller, one can make rings between a source node =0D and a destination node and many intermediate nodes between the two. =0D= =0D =0D To extend network scalability, a distributed domain management =0D system must be used, which is determined by the centralized =0D Controller. In order to configure the SRLG-based logical ring, a =0D control unit handling algorithm may be set up in the centralized =0D Controller which then configures the SRLG-based logical ring as =0D well as GMPLS signaling for LSP setups. Our restoration signaling =0D= on the SRLG-based logical ring can allow dynamic network =0D configuration instead of static configuration by operators or =0D management systems. The use of signaling with SRLG via the =0D centralized Controller vastly reduces the complexity of network =0D configuration. =0D =0D 4.2 Segment wise logical ring using the centralized Controller:=0D =0D As a network becomes large, the possibility of the size of the=0D ring pattern also became large. So, applying ring does not =0D promote efficiency in terms of end-to-end delay and recovery time. =0D= In this section we propose the method, called segment-wised ring =0D [7] that can be effectively applied to real networks without =0D those problems. Additionally, it can support fast recovery and =0D can care for partially multiple simultaneous failures. =0D =0D The main concept of segment-wised ring is to partition a large =0D network into several small networks to configure ring to each =0D small network. This is one of the major functionalities of the =0D =0D =0D J K Choi, D Guha Informational [Page 10]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D =0D centralized Controller, which effectively partitions the =0D addressed domain using the three functional blocks, the Network =0D Processor, Domain Processor and Node Processor. Sub-networks are =0D chosen according to network provisioning such as physical layer =0D conditioning, call demands or QoS demands, which may arise from =0D the user. The following shows segment wise logical ring =0D architecture, with the centralized Controller managing the =0D different sub-networks:=0D =0D =0D Subnetwork 1 Subnetwork 2 Subnetwork 3=0D +-----------------+--------------+------------------+=0D | +--+ | +--+ | +--+ | =0D | |PCE| | |PCE| | |PCE| |=0D | //+--+\\ | /+--+\ | //+--+\\ |=0D | // \\ | / \ | // \\ |=0D | // \\ | / \ | // \\ |=0D | +--+ +---+ +---+ +--+ |=0D | |ON| |ON | |ON | |ON| |=0D | +--+ +---+ +---+ +--+ |=0D | \ / | \\ // | \ / |=0D | \ / | \\ // | \ / |=0D | \ / | \\ // | \ / |=0D | +--+ | +--+ | +--+ |=0D | |ON| | |ON| | |ON| |=0D | +--+ | +--+ | +--+ |=0D +-----------------+--------------+------------------+=0D =0D // : Working path / : backup path=0D =0D Figure 2. Segment-wise ring architecture=0D =0D =0D 4.3 Resource allocation with SRLG by the Controller:=0D =0D The source node can pre-compute the ring configuration based on =0D SRLG information during the primary path setup that it receives =0D from the centralized Controller. The network architecture with =0D the concept of logical ring with SRLG for reliable transmission =0D is established via pre-configuration. =0D =0D To discuss about the survivability of logical topology, we =0D consider that the logical topology is redundant (two-connectivity); =0D= the logical topology remains connected when a physical link goes =0D down. The ingress nodes should have the SRLG history and Ring-SRLG =0D= combined with logical ring. This can be received from the =0D centralized Controller, as described in Section 3.2 and 3.4. The =0D controller can pre-compute the ring architecture before a failure =0D= =0D =0D J K Choi, D Guha Informational [Page 11]=0D =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D based on network topology information and SRLG contribution =0D weight factors and also configure the ring architecture after =0D failure by allocating resources via signaling for backup purposes. =0D= This information is also conveyed to the individual ingress nodes =0D= in the domain.=0D =0D 5. Integrated Layer Survivability and Recovery Mechanisms:=0D =0D In this section we discuss of the integrated layer protection =0D mechanisms appropriate for the central Controller.=0D =0D 5.1 Protection and Recovery Mechanisms: =0D =0D A request of LSP establishment from a client network is handled =0D by the Domain Processor of the centralized Controller, as =0D described in Section 3.4. This is mapped by the Controller to the =0D= optical transport network and conveyed to the corresponding nodes. =0D= When the Controller receives the request, it will try to compute =0D a logical ring encompassing the ingress and the egress node based =0D= on the requested traffic parameters and the SRLG properties. =0D =0D There can be two cases what the Controller can do, based on the =0D number of connection setup requests and the number of already =0D established connections in a domain. It can either distribute the =0D= LSP mapping information to the participating nodes in the optical =0D= transport domain and clear the domain link state database and=0D domain connection database, or provide the mapping links to the =0D participating nodes. =0D =0D i) Distribution of direct mapping information to nodes in the =0D optical network:=0D =0D In this method, the role of Controller is to find a logical ring, =0D= to distribute the mapping table and SRLG information between a =0D primary path and a backup path to the nodes in the optical network, =0D= and to trigger the establishment of a backup path once a failure =0D occurs. Each node is responsible for maintaining the mapping table =0D= and establishment of primary and backup path by using signaling =0D messages. When a node detects a failure, it reports the failure to =0D= its corresponding domain Controller. If an end-to-end path =0D protection is used, the Controller triggers the changeover from =0D the primary path to the backup path to the ingress nodes. If the =0D backup path is already established, the ingress node simply =0D changes the direction of the traffic flow from the primary path =0D =0D =0D =0D J K Choi, D Guha Informational [Page 12]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D to the backup path. However, if there is not an established backup =0D= path, the ingress node tries to set up a backup path in the =0D network when it receives the trigger from the Controller. Since =0D the ingress node has been maintaining the route object for the =0D backup path received from the Controller, the path setup message =0D from the ingress node will propagate via a route that is disjoint =0D= with the primary path. =0D =0D ii) Distribution of mapping information link to nodes in the =0D optical network:=0D =0D In this method, the nodes in the optical transport network performs =0D= failure detection and switching operation based on the pointers =0D provided by the forwarding table given by the corresponding domain =0D= processor. The Controller performs the roles of finding a logical =0D= ring as well as signaling to establish a primary and backup path. =0D= When a failure is reported from a node in the optical network to =0D the corresponding Controller, the Controller should look up its' =0D internal table in the domain link state and domain connection =0D databases that maintains the backup path mapped to the failed =0D primary path. By using the Backup Route Object [7], the =0D Controller tries to establish the backup path. Once it is done, =0D the setup message of the backup path will be sent from the =0D Controller managing the ingress node domain to the Controller =0D managing the egress node domain. When the backup path is =0D established through the logical ring configuration, each =0D Controller on the path should send the forwarding table to the =0D corresponding node to configure its' forwarding databases. =0D =0D =0D 5.2 Protocol based Ring Recovery Mechanisms using the Controller in =0D the PCE node: =0D =0D ITU-T G.otnpro.2 [9] provides protection switching by using =0D logical ring concept. However, it does not take account into the =0D probability of resource failure and risk of the link according to =0D= a lack of true diverse fiber routes. We may need to consider the =0D possibility of failure of the logical ring configuration at the =0D connection setup stage. =0D =0D The APS protocol (ITU-T G.otnpro.2) can be used between the =0D Controller and the optical network nodes in the ring topology. =0D It is ideal to overcome the bottleneck of the usual 50 ms =0D communications delay between Controller and nodes in the optical =0D transport network. =0D =0D =0D J K Choi, D Guha Informational [Page 13]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D A robust and efficient signaling protocol should be used to =0D distribute the mapping table from the Controller to the nodes in =0D the optical transport network and for informing a failure from a =0D node to the corresponding Controller. Signaling for restoration =0D is also needed along the primary path and the backup path at the =0D time of connection setup. GMPLS mechanisms are similar to those =0D used for setting up primary paths and backup paths. In order to =0D support our mechanism, GSMP or APS may be extended or a totally =0D new protocol could be proposed. =0D =0D PCEMP, suggested in [10] can be a suitable protocol =0D mechanism for this purpose. =0D =0D =0D 6. Key features of PCEMP =0D =0D This section summarizes the key features of the PCEMP protocol. =0D PCEMP is a generic domain routing and path computation protocol =0D that runs on any PCE unit that is capable of computing a path =0D based on an ordered graph. PCEMP uses data vector techniques for =0D path computation. Individual link state advertisements (LSAs) are =0D= mapped onto the computation units directly at TE-LSP setup time. =0D Each PCE unit maintains this mapping information through the =0D controller unit and the mapping synchronization of the Link State =0D= Databases (LSDBs) are performed using PCEMP finite state machines. =0D= =46rom this central controller sub-units, each PCE constructs a =0D routing table by calculating a shortest data vector tree, the =0D root being the calculating PCE node itself.=0D =0D 6.1 Other features of PCEMP=0D =0D The other features of the PCEMP protocol are:=0D =0D 1. Central Controller (CC). The central controller acts as the =0D originator of the network's local information environment. The =0D controller also acts in the global scenario of inter domain PCEs =0D and inter layer networks. It serves as the key functional point =0D of the data vector driven algorithm for all PCE information and =0D link state synchronizations by co-ordinating LSP advertisements =0D from other PCEs and LSRs (All PCE peers). =0D =0D =0D J K Choi, D Guha Informational [Page 14]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D 2. Soft PCE Controller (SPC). A Soft PCE Controller is an entity =0D designed primarily for protection and fast route establishment in =0D= conjunction with the Central Controller. The SPC's primary =0D functionality is to provide a robust and real-time path =0D computation adjacency without crossover delays for the data driven =0D= algorithm mechanism. Also, this enables the LSP state and path =0D computation state retention in case of nodal faults and hardware =0D failures. =0D =0D 3. Support for peer adjacency through non-participating interior =0D nodes. PCEMP treats these nodes opaquely and is able to maintain =0D the PCE adjacencies over inter-domains and inter-layer networks. =0D The protocol is generic and can be easily carried over existing =0D routing mechanisms over non-supporting network clouds. There is no =0D= necessity for any additional configuration updates for PCEs =0D attached to such networks for initial discovery as the data driven =0D= mechanism is flow based. =0D =0D 4. PCE domain areas (PCEDA). PCEMP allows the formation of =0D distinct PCE domain areas in a specific domain for end-to-end peer =0D= participations. This is useful for several reasons. This is in line =0D= with the protocol architecture that provides a granularity of data =0D= protection within an autonomous system and isolation of data to =0D local branches of the tree. This is also helpful for the design of =0D= the PCE units using soft memory techniques and reduces the =0D algorithm operation costs.=0D =0D 5. Data driven mapping of external routing information. In PCEMP, =0D= each external route is imported into the PCE domain area in =0D separate data driven computation strategies. This reduces the =0D amount of instantaneous re-computation of routing traffic data. =0D It also enables partial controller database updates when there is =0D= a partial external route change. =0D =0D 6. Three level functional control hierarchy. PCEMP has a three =0D level controller hierarchy, intra-PCE-domain, inter-PCE-domain =0D and external-PCE-domain. This is discussed in the context of the =0D Centralized Controller. =0D =0D =0D =0D J K Choi, D Guha Informational [Page 15]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D 7. Virtual link mapping. This is done via the real-time =0D configuration of logical local links based on the data-driven =0D strategy of the algorithm. The mechanism is thus made topology =0D independent and generic. =0D =0D 8. Soft Computation Memory (SCM). This is a novel feature in terms =0D= of path computation in the CC and SPC. It helps split the tree =0D into a combination of sparse subtrees for fast computation. SCM =0D can be used to assign metrics of path computation as well as =0D compute data-driven flow based mappings in the PCE.=0D =0D 9. Data-driven routing metric. In PCEMP, the computation metrics =0D are assigned to the outbound router interfaces and the soft =0D memory cycles in the PCE controller unit. The cost of a path is =0D then the weighted sum of the path's component interfaces and the =0D soft memory cycles. The routing and external path metrics can be =0D assigned externally. =0D =0D 10. Flow-based routing. Separate sets of paths can be computed for=0D= each type of service. This is done by assigning flow-based metrics =0D= to each outgoing router interface.=0D =0D =0D 6.2 Protocol level hierarchy architecture on the control plane =0D =0D In an integrated control plane, three levels of functional control =0D= hierarchy are mapped into one PCE node in the core of the Network =0D= Processing engine and implemented as a single unit. PCEMP thus =0D has a three level controller hierarchy, intra-PCE-domain, =0D inter-PCE-domain and external-PCE-domain. =0D =0D The functional blocks involved in the PCE node are: the network =0D processor (the network management system with extended =0D functionalities), the domain processor (the network element =0D management system with extended functionalities), and the node =0D processor. These are invoked by the PCEMP state machines and =0D comprise the fundamental protocol level hierarchies on the control =0D= plane. In the first level, the network processor acts as an =0D interface between users and all sub-network domains. Its' main =0D functionality is to oversee the provisioning of new connections =0D across multiple sub-networks and to maintain the network-wide =0D topological view by reducing the computational domains to PCEDAs. =0D= The domain processor supervises tasks within a sub-network =0D domain, such as service provisioning and network status =0D monitoring. It handles requests for connection setup and =0D teardown, and computes explicit paths that meet the SLA of each =0D request. The network monitor observes the overall network health =0D =0D =0D J K Choi, D Guha Informational [Page 16]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D and detects failure and repair events. The databases maintained =0D by the domain processor include the domain topology, the domain =0D link state database gathered via the LSA protocol within its =0D domain, and the domain connection database which keeps track of =0D all established connections in the domain. The node processor =0D manages specific functionalities that can be done in a distributed =0D= manner at each node, such as overload handling, failure recovery, =0D= and status monitoring. It also detects sudden link overloads, =0D conducts a countermeasure and provides rapid protection and =0D restoration capability in times of failure. The databases =0D maintained by the node processor are the local link state and the =0D= local connection databases. The local link state is obtained =0D automatically via the neighbor discovery protocol, while the list =0D= of local connections is obtained from all connections that =0D traverse the node. These are implemented using soft memory =0D concepts and synchronized using PCEMP. =0D =0D For the purpose of establishing a guaranteed a disjoint backup =0D path and fast restoration techniques in the participating PCEDAs, =0D= it is essential that the large scale data processing in the CC and =0D= SPC have minimum overhead and processing delay. The CC manages the =0D= entire domain network, as discussed before. In this architecture, =0D= backup paths can be easily established end-to-end using the logical =0D= configuration in the SPCs using PCEMP. Based on the data driven =0D routing metric table, which is configured at each PCE node by the =0D= CC, one can make a robust real-time path between a source node and =0D= a destination node and many intermediate nodes between the two. =0D This is done using soft decision PCEMP algorithms [10].=0D =0D 6.3 Role of CC and SPC=0D =0D The CC is responsible for handling data vectors and synchronization =0D= of different link states. The SPC acts a fast path computation =0D mechanism in case of crossover and faults. This conjunction makes =0D= the PCE unit's functioning much more efficient. =0D =0D This has the same implications as the LSA protocol used for peer=0D advertisement and topology discovery. A significant improvement by=0D= using PCEMP is that the number of routers that can be attached =0D to a single PCEDA is quite arbitrary. As traffic increases, the SPC =0D= eases the stringency of backup path computation and the CC-SPC =0D combination guarantees a disjoint alternate path calculation with =0D= the minimum crossover time. =0D =0D This follows from the previous section 6.2. =0D =0D =0D J K Choi, D Guha Informational [Page 17]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D =0D +--------+ +--------+ +--------+ +--------+ +--------+ =0D= | PCE | | PCE | | PCE | | PCE | | PCE | =0D= | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | =0D= | |PCEMP|| | |PCEMP|| | |PCEMP|| | |PCEMP|| | |PCEMP|| =0D= | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | =0D= | || |=3D=3D=3D=3D| || |=3D=3D=3D=3D| || |=3D=3D=3D=3D| = || |=3D=3D=3D=3D| || | =0D | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | =0D= | |PCEMP|| | |PCEMP|| | |PCEMP|| | |PCEMP|| | |PCEMP|| =0D= | +----+ | | +----+ | | +----+ | | +----+ | | +----+ | =0D= +--------+ +--------+ +--------+ +--------+ +--------+ =0D= | ^ =0D PCEMP PCEMP Control plane =0D --------------------V----------- |----------------------------------- =0D= Data plane = =0D +--------+ +--------+ +--------+ +--------+ +-------- + =0D= | Sender |--->| N1 |--->| N2 |--->| N3 |--->| Receiver| =0D= | App | | | | | | | | App | =0D= +--------+ +--------+ +--------+ +--------+ +---------+ =0D= =0D Appp =3D Application N1, N2, N3 =3D node =0D =3D=3D=3D=3D =3D Signaling Messages ---> =3D Data flow = Messages =0D =0D Figure 3. PCE based backup path computation architecture =0D =0D Figure 3 shows a simple PCE based backup computation architecture=0D =0D =0D 7. Conclusion=0D =0D Network survivability is a critical requirement in high-speed =0D networks. So, recovery mechanisms that can provide fast recovery =0D and efficient capacity are needed. Our proposed network =0D architecture using the centralized Controller considered high =0D survivability of backup path, called ring-SRLG that has grouped =0D traffic driven logical rings and shared resources in GMPLS based =0D networks. Ring-SRLG with the centralized Controller can guarantee =0D= the survivability of backup paths with constraints to the other =0D logical ring configuration. Our proposed backup paths can be =0D easily established through the end-to-end path, which follows the =0D= logical ring configuration. It guarantees the establishment of =0D backup path disjoint from the working path. =0D =0D We have shown that our proposed integrated provisioning, which =0D combines protection efforts from both IP and optical layers, is =0D favorable over the traditional provisioning approach. The =0D integrated protection effort achieves efficient resource =0D allocation in terms of total bandwidth reservation, bandwidth =0D utilization, and connection blocking probability. The level of =0D improvement largely depends on the type of pre-configured =0D underlying lightpath protection. While we expect that the choice =0D of lightpath protection should depend on the nature of service =0D requests, we leave it up to the service provider to make this =0D choice. The scheme takes advantage of information sharing across =0D =0D =0D J K Choi, D Guha Informational [Page 18]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D network layers which is facilitated by GMPLS. The proposed scheme =0D= uses GMPLS capabilities to provide end-to-end survivability =0D against network failures. This integrated provisioning scheme can =0D= deliver rapid service provisioning dynamically on demand. The=0D consolidated effort simplifies the provisioning process and =0D reduces network management complexity by eliminating the =0D cumbersome coordination of provisioning in separate network layers. =0D= =0D PCEMP along with the PCE framework can be an efficent mechanism=0D for this purpose of fast backup path computation.=0D =0D =0D 8. Security Considerations=0D =0D The impact of the use of the PCEMP architecture is relatively =0D much secure as the PCEDA are computed and distributed internal to =0D= the PCE unit. An increase in inter-domain information flows and =0D the facilitation of inter-domain path establishment through PCEMP =0D= does not increase the existing vulnerability to security attacks. =0D= It should be remembered that PCEMP works by an invoked logic =0D scheme local to each participating PCE unit, and the protocol =0D invoke is brought into play only when there is a significant =0D change in the data profile within the time of goodness of fit.=0D =0D However, it is expected that the PCE solutions will address =0D security issues mentioned in [Ash] in details using authentication =0D= and security techniques. =0D =0D =0D 9. IANA Considerations=0D =0D This document makes no requests for IANA action.=0D =0D 10. Acknowledgements=0D =0D This work was supported in part by the Korea Science and =0D Engineering Foundation (KOSEF) through the Ministry of Science and =0D= Technology (MOST) and the Institute of Information Technology =0D Assessment (IITA) through the Ministry of Information and =0D Communications (MIC), Republic of Korea.=0D =0D 11. Intellectual Property Considerations=0D =0D The IETF takes no position regarding the validity or scope of any=0D Intellectual Property Rights or other rights that might be claimed =0D= to pertain to the implementation or use of the technology =0D described in this document or the extent to which any license under =0D= =0D =0D J K Choi, D Guha Informational [Page 19]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D such rights might or might not be available; nor does it represent =0D= that it has made any independent effort to identify any such rights. = =0D Information on the procedures with respect to rights in RFC =0D documents can be found in BCP 78 and BCP 79.=0D =0D Copies of IPR disclosures made to the IETF Secretariat and any=0D assurances of licenses to be made available, or the result of an =0D attempt made to obtain a general license or permission for the use =0D= of such proprietary rights by implementers or users of this =0D specification can be obtained from the IETF on-line IPR repository =0D= at http://www.ietf.org/ipr.=0D =0D The IETF invites any interested party to bring to its attention any=0D= copyrights, patents or patent applications, or other proprietary =0D rights that may cover technology that may be required to implement =0D= this standard. Please address the information to the IETF at=0D ietf-ipr@ietf.org.=0D =0D =0D 12. Normative References=0D =0D =0D [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate =0D Requirement Levels", BCP 14, RFC 2119, March 1997.=0D =0D [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, =0D RFC 3667, February 2004.=0D =0D [RFC3668] Bradner, S., "Intellectual Property Rights in IETF =0D Technology", BCP 79, RFC 3668, February 2004.=0D =0D =0D 13. Informational References=0D =0D [1] Mannie, E. et al., "Generalized Multi-Protocol Label Switching =0D= Architecture", Internet Draft, =0D draft-ietf-ccamp-gmpls-architecture-07.txt, November 2003. =0D =0D [2] Papadimitriou, D. and Mannie, E. (Editors), "Analysis of =0D Generalized Multi-Protocol Label Switching (GMPLS) based Recovery =0D= Mechanisms (Including Protection and Restoration)", Internet Draft, =0D= draft-ietf-ccamp-gmpls-recovery-analysis-03.txt, October 2004.=0D =0D [3] Mannie, E. and Papadimitriou, D. (Editors), "Recovery =0D (Protection and Restoration) Terminology for Generalized =0D Multi-Protocol Label Switching (GMPLS)", Internet Draft, =0D draft-ietf-ccamp-gmpls-recovery-terminology-04.txt, October 2004.=0D =0D [4] Lang, P. and Rajagopalan, B. (Editors), "Generalized =0D Multi-Protocol Label Switching (GMPLS) Recovery Functional =0D Specification", Internet Draft, =0D draft-ietf-ccamp-gmpls-recovery-functional-02.txt, October 2004. =0D =0D =0D =0D J K Choi, D Guha Informational [Page 20]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D [5] Papadimitriou, D. et al., "Shared Risk Link Groups Inference =0D and Processing", Internet Draft, =0D draft-papadimitriou-ccamp-srlg-processing-02.txt, December 2003=0D =0D [6] Czezowski, P. et al., "Optical Network Failure Recovery =0D Requirements", Internet Draft, =0D draft-czezowski-optical-recovery-reqs-01.txt, December 2003.=0D =0D [7] Choi, J.K. et al., "Signaling Extension for the End-to-End =0D Restoration with SRLG", Internet Draft, =0D draft-choi-ccamp-e2e-restoration-srlg-01.txt, August 2004=0D =0D [8] Lang, J.P., Rekhter, Y., Papadimitriou, D., "RSVP-TE Extensions =0D= in support of End-to-End GMPLS-based Recovery", Internet Draft, =0D draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt, August 2004. =0D= =0D [9] ITU-T SG15 G.otnpro.2 Work In Progress=0D =0D [10] Choi, J.K., Guha, D. et al., "Path Computation Element Metric =0D= Protocol (PCEMP)", draft-choi-pce-metric-protocol-00.txt, =0D October 2004 (work in progress)=0D =0D [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and =0D J. McManus, "Requirements for Traffic Engineering over MPLS", =0D RFC 2702, September 1999.=0D =0D [RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP =0D Tunnels", RFC 3209, December 2001.=0D =0D [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label =0D Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic =0D= Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.=0D =0D [INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for =0D= Support of Inter-Area and Inter-AS MPLS Traffic Engineering", =0D draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in =0D= progress).=0D =0D [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic =0D= Engineering requirements", = draft-ietf-tewg-interas-mpls-te-req-06.txt, =0D January 2004 (work in progress).=0D =0D =0D J K Choi, D Guha Informational [Page 21]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004=0D =0D =0D [MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for=0D= Multi-Region = Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt,=0D February 2004 (work in progress).=0D =0D [Ash] Farrel, A., Vasseur, JP., and Ash, J., "Path Computation =0D Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, =0D September 2004 (work in progress)=0D =0D =0D 14. Authors' Addresses=0D =0D Jun Kyun Choi=0D Information and Communications University (ICU)=0D 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea=0D Phone: +82-42-866-6122=0D Email: jkchoi@icu.ac.kr=0D =0D Dipnarayan Guha=0D Information and Communications University (ICU)=0D 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea=0D Phone: +82-42-866-6282=0D Email: dip@icu.ac.kr=0D =0D Jin Ho Hahm =0D Electronics and Telecommunications Research Institute (ETRI) =0D 161 Gajeong-Dong, Yuseong-gu, Daejeon, 305-350, Republic of Korea =0D= Phone: +82-42-860-6048 =0D E-mail: jhhahm@etri.re.kr =0D =0D =0D 15. Full Copyright Statement=0D =0D Copyright (C) The Internet Society (2004). All Rights Reserved. =0D This document is subject to the rights, licenses and restrictions =0D contained in BCP 78 and except as set forth therein, the authors =0D retain all their rights.=0D =0D This document and translations of it MAY be copied and furnished to =0D= others, and derivative works that comment on or otherwise explain it =0D= or assist in its implementation MAY be prepared, copied, published =0D= and distributed, in whole or in part, without restriction of any = kind, =0D provided that the above copyright notice and this paragraph are =0D included on all such copies and derivative works. However, this =0D document itself MAY not be modified in any way, such as by removing =0D= the copyright notice or references to the Internet Society or other =0D= Internet organizations, except as needed for the purpose of =0D developing Internet standards in which case the procedures for =0D copyrights defined in the Internet Standards process MUST be = followed, =0D or as required to translate it into languages other than English. =0D =0D The limited permissions granted above are perpetual and will not be =0D= revoked by the Internet Society or its successors or assigns. =0D =0D This document and the information contained herein is provided on an =0D= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING =0D= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING =0D= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION =0D HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF =0D MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0D =0D =0D =0D J K Choi, D Guha Informational [Page 22]=0D= =0D Internet Draft =0D draft-choi-pce-e2e-centralized-restoration-srlg-01.txt October 2004= --Apple-Mail-5-64257225 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 --Apple-Mail-5-64257225-- From pce-bounces@ietf.org Sun Oct 31 08:52:55 2004 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 IAA27545; Sun, 31 Oct 2004 08:52:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COGNM-00055j-0X; Sun, 31 Oct 2004 09:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFw4-0006Ha-KG; Sun, 31 Oct 2004 08:39:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFqd-0005eK-I1 for pce@megatron.ietf.org; Sun, 31 Oct 2004 08:34: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 IAA26552 for ; Sun, 31 Oct 2004 08:34:17 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COG5I-0004lo-SK for pce@ietf.org; Sun, 31 Oct 2004 08:49:30 -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 i9VDY96X012808 for ; Sun, 31 Oct 2004 22:34:09 +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 i9VDY8b6007886 for ; Sun, 31 Oct 2004 22:34:08 +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 i9VDY8DH007882 for ; Sun, 31 Oct 2004 22:34:08 +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 i9VDY8V2026973 for ; Sun, 31 Oct 2004 22:34:08 +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 i9VDY7R4026970 for ; Sun, 31 Oct 2004 22:34:07 +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 i9VDY7jw025247 for ; Sun, 31 Oct 2004 22:34:07 +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 i9VDY6e9029406 for ; Sun, 31 Oct 2004 22:34:07 +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 i9VDY6Ti029403 for ; Sun, 31 Oct 2004 22:34:06 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA10269 for ; Sun, 31 Oct 2004 22:34:06 +0900 (JST) Date: Sun, 31 Oct 2004 22:34:02 +0900 From: Eiji Oki To: pce@ietf.org Message-Id: <20041031222528.C8D5.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: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Pce] draft-oki-ccamp-gtep-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi all, I upudated our draft of "draft-oki-ccamp-gtep-01.txt", which I expect to discuss in the meeting of PCE BOF. Title : Generalized Traffic Engineering Protocol Author(s) : E. Oki, et al. Filename : draft-oki-ccamp-gtep-01.txt Pages : 26 Date : 2004-10-29 This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between a Path Computation Element (PCE) and a GMPLS controller (GMPLS CNTL). A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols such as routing and signaling protocols and controls a GMPLS node. PCE provides a function of traffic engineer-ing, which calculates LSP routes and judges whether a new lower-layer LSP should be established and whether an existing lower-layer LSP should be released. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-ccamp-gtep-01.txt Any comments and suggestions are highly appreciated. Thank you. Eiji _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Oct 31 08:54:46 2004 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 IAA27715; Sun, 31 Oct 2004 08:54:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COGP9-000580-AW; Sun, 31 Oct 2004 09:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFyS-0006ex-VS; Sun, 31 Oct 2004 08:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFss-000639-Ej for pce@megatron.ietf.org; Sun, 31 Oct 2004 08:36:38 -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 IAA26682 for ; Sun, 31 Oct 2004 08:36:37 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COG7Z-0004oR-Ng for pce@ietf.org; Sun, 31 Oct 2004 08:51:50 -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 i9VDaZFP013070 for ; Sun, 31 Oct 2004 22:36:35 +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 i9VDaZKE009065 for ; Sun, 31 Oct 2004 22:36:35 +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 i9VDaYeg009060 for ; Sun, 31 Oct 2004 22:36:34 +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 i9VDaYOs027807 for ; Sun, 31 Oct 2004 22:36:34 +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 i9VDaXVP027802 for ; Sun, 31 Oct 2004 22:36:33 +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 i9VDaX3d025533 for ; Sun, 31 Oct 2004 22:36:33 +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 i9VDaWVn029816 for ; Sun, 31 Oct 2004 22:36:33 +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 i9VDaWO6029813 for ; Sun, 31 Oct 2004 22:36:32 +0900 (JST) Received: from [127.0.0.1] by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA10382 for ; Sun, 31 Oct 2004 22:36:32 +0900 (JST) Date: Sun, 31 Oct 2004 22:36:28 +0900 From: Eiji Oki To: pce@ietf.org Message-Id: <20041031223408.C8D8.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: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Pce] draft-oki-pce-gmpls-req-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi all, I upudated our draft of "draft-oki-pce-gmpls-req-01.txt", which I expect to discuss in the meeting of PCE BOF. Title : Requirements for Path Computation Element in GMPLS and IP/MPLS Networks Author(s) : E. Oki, et al. Filename : draft-oki-pce-gmpls-req-01.txt Pages : 25 Date : 2004-10-29 Path Computation Element (PCE) provides functions of traffic engineering in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal virtual network topology reconfiguration control, and jugdes on whether a new lower-region LSP should be established when a higher-region LSP is requested. PCE also handles interworking between GMPLS and IP/MPLS net- works, both of which will coexist at some point during the migration process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-gmpls-req-01.txt Any comments and suggestions are highly appreciated. Thank you. Eiji _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce