From mailman-bounces@ietf.org Mon Nov 1 05:27: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 FAA12491 for ; Mon, 1 Nov 2004 05:27:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZeS-0003fh-1B for pce-archive@ietf.org; Mon, 01 Nov 2004 05:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ56-0007AK-5n for pce-archive@ietf.org; Mon, 01 Nov 2004 05:06:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pce-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:02:35 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for pce-archive@ietf.org: List Password // URL ---- -------- pce@lists.ietf.org geebfe https://www1.ietf.org/mailman/options/pce/pce-archive%40ietf.org From pce-bounces@ietf.org Mon Nov 1 20:47: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 UAA01891; Mon, 1 Nov 2004 20:47:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COo0v-0003L4-I7; Mon, 01 Nov 2004 21:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnUT-000814-6h; Mon, 01 Nov 2004 20:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnOM-0003qp-2Y for pce@megatron.ietf.org; Mon, 01 Nov 2004 20:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29665 for ; Mon, 1 Nov 2004 20:23:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COndM-0002nA-Vp for pce@ietf.org; Mon, 01 Nov 2004 20:38:53 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COnOK-000621-2l; Tue, 02 Nov 2004 01:23:20 +0000 Date: Mon, 1 Nov 2004 17:23:19 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <12010515119.20041101172319@psg.com> To: Jean Philippe Vasseur In-Reply-To: <4.3.2.7.2.20041028093249.059a50a0@wells.cisco.com> References: <4.3.2.7.2.20041028093249.059a50a0@wells.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: bill Fenner , pce@ietf.org Subject: [Pce] Re: Second BOF schedule X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Ammm... this is still draft agenda though... -- Alex http://www.psg.com/~zinin Thursday, October 28, 2004, 5:34:27 AM, Jean Philippe Vasseur wrote: > 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. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Nov 4 14:16:30 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 OAA23514; Thu, 4 Nov 2004 14:16:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnLZ-0004QH-E3; Thu, 04 Nov 2004 14:32:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmxA-0008HD-SG; Thu, 04 Nov 2004 14:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmpj-000789-SS for pce@megatron.ietf.org; Thu, 04 Nov 2004 13:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22176 for ; Thu, 4 Nov 2004 13:59:42 -0500 (EST) Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPn5K-00042G-09 for pce@ietf.org; Thu, 04 Nov 2004 14:15:50 -0500 Received: from cnri-7-127.cnri.reston.va.us ([132.151.7.127] helo=action2.cnri.reston.va.us) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1CPmpi-0007cS-Bn for pce@ietf.org; Thu, 04 Nov 2004 13:59:42 -0500 Message-Id: <5.0.0.25.2.20041104135743.00aed9c8@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 04 Nov 2004 13:59:41 -0500 To: pce@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.6 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Pce] TEST MESSAGE - PLEASE INGORE/DELETE 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: 30ac594df0e66ffa5a93eb4c48bcb014 This is a test message to test the PCE mailing list. Please Ignore/Delete this message. -Greg Cunningham _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Fri Nov 5 03:44: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 DAA16673; Fri, 5 Nov 2004 03:44:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzxy-0004xf-If; Fri, 05 Nov 2004 04:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzhP-00080g-Vi; Fri, 05 Nov 2004 03:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzap-0006fv-PK for pce@megatron.ietf.org; Fri, 05 Nov 2004 03:37:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16287 for ; Fri, 5 Nov 2004 03:37:10 -0500 (EST) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzqW-0004p8-7V for pce@ietf.org; Fri, 05 Nov 2004 03:53:25 -0500 Received: from du-069-0388.access.clara.net ([217.158.145.134] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1CPzam-0009Hg-Do for pce@ietf.org; Fri, 05 Nov 2004 08:37:08 +0000 Message-ID: <002601c4c312$b93914d0$86919ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 5 Nov 2004 08:35:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Subject: [Pce] Mailing list archives fixed 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Thanks to the Secretariat. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Nov 7 12:21: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 MAA06115; Sun, 7 Nov 2004 12:21:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqkA-0007Zl-VZ; Sun, 07 Nov 2004 12:22:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqfh-00068Q-2f; Sun, 07 Nov 2004 12:17:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqTB-0003Cs-CH for pce@megatron.ietf.org; Sun, 07 Nov 2004 12:04:49 -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 MAA04888 for ; Sun, 7 Nov 2004 12:04:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqTX-0007Eq-E8 for pce@ietf.org; Sun, 07 Nov 2004 12:05:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2004 09:17:40 -0800 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 iA7H4Aom010529; Sun, 7 Nov 2004 09:04:10 -0800 (PST) Received: from [66.189.44.146] (che-vpn-cluster-1-218.cisco.com [10.86.240.218]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA10981; Sun, 7 Nov 2004 09:04:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B587F72-30DF-11D9-8062-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sun, 7 Nov 2004 12:04:11 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [Pce] Updated 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: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, I just posted the revised proposed PCE WG charter (http://rtg.ietf.org/bof/pce/) and Milestones which incorporates comments/suggestion from several of you and has been modified based on Alex's input. This is of course a draft which will be further discussed during the BOF. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Nov 7 21:00:45 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 VAA22614; Sun, 7 Nov 2004 21:00:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQyq8-0002Vn-Sq; Sun, 07 Nov 2004 21:01:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQyoi-0005TK-0k; Sun, 07 Nov 2004 20:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQyit-0004Yn-7X for pce@megatron.ietf.org; Sun, 07 Nov 2004 20:53:35 -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 UAA22149 for ; Sun, 7 Nov 2004 20:53:32 -0500 (EST) Received: from fujitsu2.fujitsu.com ([192.240.0.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQyj9-0002Ly-PF for pce@ietf.org; Sun, 07 Nov 2004 20:54:03 -0500 Received: from fujitsu2.fujitsu.com (localhost [127.0.0.1]) by fujitsu2.fujitsu.com (8.12.10/8.12.9) with ESMTP id iA81qoNq016709 for ; Sun, 7 Nov 2004 17:52:51 -0800 (PST) Received: from fnanic.fujitsu.com ([133.164.253.2]) by fujitsu2.fujitsu.com (8.12.10/8.12.9) with ESMTP id iA81qo2K016641; Sun, 7 Nov 2004 17:52:50 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fnanic.fujitsu.com (8.12.11/8.12.11) with ESMTP id iA81qg2k006170; Sun, 7 Nov 2004 17:52:42 -0800 (PST) Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id iA81qfx00400; Sun, 7 Nov 2004 17:52:41 -0800 (PST) From: "Richard Rabbat" To: "'JP Vasseur'" , "'Adrian Farrel'" , Subject: RE: [Pce] New Proposed PCE WG Charter Date: Sun, 7 Nov 2004 20:51:04 -0800 Message-ID: <000301c4c54e$8e3d4ec0$6e878182@PHOENIX> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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="===============0043680198==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca This is a multi-part message in MIME format. --===============0043680198== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C4C50B.801A0EC0" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C4C50B.801A0EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, Adrian, =20 In the updated proposed charter, you say: - Definition of protocol-independent metrics defining path quality measurement criteria and scalability criteria related to path = computation techniques. =20 Could you clarify what protocol(s) these metrics would be independent = of? =20 I'm also confused about the sentence. Could you please clarify what you = mean by:=20 -Definition of ... metrics defining ... criteria. =20 Thanks, =20 Richard. -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, October 26, 2004 1:36 PM To: pce@ietf.org Cc: Bill Fenner Subject: [Pce] New Proposed PCE WG Charter 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) =20 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. ------=_NextPart_000_0004_01C4C50B.801A0EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi JP,=20 Adrian,
 
In=20 the updated proposed charter, you say:
- Definition of = protocol-independent metrics=20 defining path quality measurement criteria and scalability criteria = related to=20 path computation techniques.
 
Could=20 you clarify what protocol(s) these metrics would be independent=20 of?
 
I'm=20 also confused about the sentence. Could you please clarify what you mean = by:=20
-Definition of ... metrics defining ... = criteria.
 
Thanks,
 
Richard.

-----Original=20 Message-----
From: pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP=20 Vasseur
Sent: Tuesday, October 26, 2004 1:36 PM
To:=20 pce@ietf.org
Cc: Bill Fenner
Subject: [Pce] New = Proposed PCE=20 WG Charter

Dear=20 list members,

First of all, thanks for various comments that we = received from various sources. Adrian and I have updated the proposed = WG=20 Charter, which reflects those comments/suggestions. Obviously, further = comments and feed-backs are very welcome: having a proposed WG charter = we all=20 agree on before our second BPF would be a good=20 step.

Proposed PCE Working Charter and = Milestones

WG items:

- Functional = specification of MPLS and GMPLS Traffic Engineered LSP path = computation=20 techniques involving Path Computation Element(s). This includes the = case of=20 intra and inter-domain (where a domain might be a specific layer, an = IGP area=20 or an Autonomous System) TE LSPs path computation and applies to Point = to=20 Point and Point to Multipoint TE LSPs. Such path computation = techniques=20 include primary, protection and recovery paths as well as load = balancing=20 techniques.

- Specification of PCE-based architectures = including=20 centralized, distributed and cooperative models.

- = Specification of=20 routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions = required by=20 PCE-based path computation techniques.

- Specification of = techniques=20 in support of PCE discovery within and across domains. Where such = techniques=20 result in the extensions of existing protocols, this work will be done = in=20 conjunction with the appropriate WGs.

- Specification of new = protocols=20 or modifications to existing protocols to facilitate communication = between PCC=20 (Path Computation Client) and PCE(s), and between PCEs.

- = Definition of=20 protocol-independent metrics defining path quality measurement = criteria and=20 scalability criteria related to path computation techniques.

-=20 Specification of requirements and protocol extensions related to the = policy,=20 security and confidentiality aspects of PCE-based path computation = techniques=20 involving PCEs of multiple administrative entities.

- = Definition of=20 MIBs and management procedures related to the new protocols, protocol=20 extensions and operational elements defined by the WG.

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


Proposed WG Goals and initial Milestones (date = to be=20 determined)

Requirement drafts (multiple drafts may be expected = coming=20 various other WGs and submitted to be PCE WG)

Finalize the PCE=20 architecture document(s)
  
Identify and document a = limited=20 set of candidate solutions for PCC-PCE and PCE-PCE signaling. Among = candidate=20 solutions to be considered are the existing signaling protocols = defined in=20 other WGs.


Identify protocol extensions for PCE=20 discovery

Thanks.

JP and=20 Adrian.
------=_NextPart_000_0004_01C4C50B.801A0EC0-- --===============0043680198== 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 --===============0043680198==-- From pce-bounces@ietf.org Mon Nov 8 15:17: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 PAA25157; Mon, 8 Nov 2004 15:17:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFy3-0004LR-KU; Mon, 08 Nov 2004 15:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFkn-0005S8-JM; Mon, 08 Nov 2004 15:04:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFUp-00061O-QL for pce@megatron.ietf.org; Mon, 08 Nov 2004 14:48:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20253 for ; Mon, 8 Nov 2004 14:48:09 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFVQ-0003PD-Lk for pce@ietf.org; Mon, 08 Nov 2004 14:48:49 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2004 11:47:53 -0800 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 iA8JlGnC020837; Mon, 8 Nov 2004 11:47:17 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (rtp-vpn1-111.cisco.com [10.82.224.111]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10697; Mon, 8 Nov 2004 11:47:31 -0800 (PST) Message-Id: <4.3.2.7.2.20041108133801.034c5e08@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 14:47:27 -0500 To: "Richard Rabbat" From: Jean Philippe Vasseur Subject: RE: [Pce] New Proposed PCE WG Charter In-Reply-To: <000301c4c54e$8e3d4ec0$6e878182@PHOENIX> References: Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 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="===============0864763881==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a --===============0864763881== Content-Type: multipart/alternative; boundary="=====================_617434734==_.ALT" --=====================_617434734==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Richard, At 08:51 PM 11/7/2004 -0800, Richard Rabbat wrote: >Hi JP, Adrian, > >In the updated proposed charter, you say: >- Definition of protocol-independent metrics defining path quality >measurement criteria and scalability criteria related to path computation >techniques. > >Could you clarify what protocol(s) these metrics would be independent of? > >I'm also confused about the sentence. Could you please clarify what you >mean by: >-Definition of ... metrics defining ... criteria. > The aim of this potential WG item was to define some metrics so as to be able to qualify a proposed PCE-based computation technique: - the quality of a computed path (ex: degree of optimality, ...) - the scalability of the solution (ex: computation time, signalling overhead, ability to handle burst of requests, ... ) - .... Hope that this clarifies. Thanks for your comment. JP. >Thanks, > >Richard. > >-----Original Message----- >From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On >Behalf Of JP Vasseur >Sent: Tuesday, October 26, 2004 1:36 PM >To: pce@ietf.org >Cc: Bill Fenner >Subject: [Pce] New Proposed PCE WG Charter >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. > >- 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) > >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. > > --=====================_617434734==_.ALT Content-Type: text/html; charset="us-ascii" Hi Richard,

At 08:51 PM 11/7/2004 -0800, Richard Rabbat wrote:
Hi JP, Adrian,
 
In the updated proposed charter, you say:
- Definition of protocol-independent metrics defining path quality measurement criteria and scalability criteria related to path computation techniques.
 
Could you clarify what protocol(s) these metrics would be independent of?
 
I'm also confused about the sentence. Could you please clarify what you mean by:
-Definition of ... metrics defining ... criteria.
 

The aim of this potential WG item was to define some metrics so as to be able to qualify a proposed PCE-based computation technique:
        - the quality of a computed path (ex: degree of optimality, ...)
        - the scalability of the solution (ex: computation time, signalling overhead, ability to handle burst of requests, ... )
        - ....

Hope that this clarifies.

Thanks for your comment.

JP.

Thanks,
 
Richard.

-----Original Message-----
From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP Vasseur
Sent: Tuesday, October 26, 2004 1:36 PM
To: pce@ietf.org
Cc: Bill Fenner
Subject: [Pce] New Proposed PCE WG Charter
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.

<?smaller>Proposed PCE Working Charter and Milestones<?/smaller><?smaller>

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.

- 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)
 
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.

<?/smaller>
--=====================_617434734==_.ALT-- --===============0864763881== 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 --===============0864763881==-- From pce-bounces@ietf.org Tue Nov 9 10:32: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 KAA09628; Tue, 9 Nov 2004 10:32:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRY06-0006Yi-3r; Tue, 09 Nov 2004 10:33:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXiH-0004yf-Nd; Tue, 09 Nov 2004 10:15:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXdF-0002PL-N2 for pce@megatron.ietf.org; Tue, 09 Nov 2004 10:10:05 -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 KAA06343 for ; Tue, 9 Nov 2004 10:10:03 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXe0-0005xs-AZ for pce@ietf.org; Tue, 09 Nov 2004 10:10:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2004 07:21:10 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA9F9QnC009037; Tue, 9 Nov 2004 07:09:27 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-2-132.cisco.com [10.86.242.132]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA15846; Tue, 9 Nov 2004 07:09:29 -0800 (PST) Message-Id: <4.3.2.7.2.20041109094222.00ca2d00@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Nov 2004 10:09:29 -0500 To: pce@ietf.org From: Jean Philippe Vasseur Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Bill Fenner Subject: [Pce] Slides posted for the BOF tomorrow 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="===============0380646046==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --===============0380646046== Content-Type: multipart/alternative; boundary="=====================_687151311==_.ALT" --=====================_687151311==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Just to let you know that slides have been posted for our second BOF tomorrow (http://rtg.ietf.org/bof/pce) Proposed agenda: 1) Introduction, admin, statement of objectives of this second BOF (5 minutes) Adrian/JP 2) Quick summary of the conclusion of the first BOF held in San Diego (5 minutes) JP 3) Problem space: recap of the PCE architecture ID draft-ash-pce-architecture-00.txt (15 minutes) Jerry 4) Summary of existing and updated drafts (5 minutes) Adrian 5) New drafts published since IETF-60 (15 minutes) JP and authors 6) Discussion (and possibly conclusion!) about the need for a WG (15 minutes) 7) Proposed charter (45 minutes) 8) Summary and conclusions (15 minutes) Chairs and ADs KEY ITEMS are: 3) since this was one of the main request/outcome from Alex during the first BOF and the basis on the potential WG work. 6) + 7) + 8) A friendly reminder to the presenters of 5) ... 1mn per draft. No presentation but just a quick overview of your ID and how/why they would fit in the proposed PCE WG charter ! See you tomorrow. JP. --=====================_687151311==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

Just to let you know that slides have been posted for our second BOF tomorrow (http://rtg.ietf.org/bof/pce)

Proposed agenda:
1) Introduction, admin, statement of objectives of this second BOF (5 minutes) Adrian/JP
2) Quick summary of the conclusion of the first BOF held in San Diego
(5 minutes) JP
3) Problem space: recap of the PCE architecture ID
draft-ash-pce-architecture-00.txt (15 minutes) Jerry
4) Summary of existing and updated drafts (5 minutes) Adrian
5) New drafts published since IETF-60 (15 minutes) JP and authors
6) Discussion (and possibly conclusion!) about the need for a WG (15 minutes)
7) Proposed charter (45 minutes)
8) Summary and conclusions (15 minutes) Chairs and ADs

KEY ITEMS are:
3) since this was one of the main request/outcome from Alex during the first BOF and the basis on the potential WG work.
6) + 7) + 8)

A friendly reminder to the presenters of 5) ... 1mn per draft. No presentation but just a quick overview of your ID and how/why they would fit in the proposed PCE WG charter !

See you tomorrow.

JP. --=====================_687151311==_.ALT-- --===============0380646046== 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 --===============0380646046==-- From pce-bounces@ietf.org Wed Nov 10 14:09:08 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 OAA14407; Wed, 10 Nov 2004 14:09:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxrA-0002E2-8K; Wed, 10 Nov 2004 14:10:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxdW-0007xL-SS; Wed, 10 Nov 2004 13:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxaC-0006xk-2Y for pce@megatron.ietf.org; Wed, 10 Nov 2004 13:52:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12427 for ; Wed, 10 Nov 2004 13:52:38 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxbB-0001hy-P9 for pce@ietf.org; Wed, 10 Nov 2004 13:53:43 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 11:03:58 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAAIq5cp027133; Wed, 10 Nov 2004 10:52:05 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (rtp-vpn2-322.cisco.com [10.82.241.66]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA28155; Wed, 10 Nov 2004 10:52:02 -0800 (PST) Message-Id: <4.3.2.7.2.20041110134915.03476da0@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Nov 2004 13:52:00 -0500 To: pce@ietf.org From: Jean Philippe Vasseur Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Bill Fenner Subject: [Pce] New set of slides for the BOF this afternoon 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi, Based on useful suggestion from our ADs, we've made some adjustments on the agenda and consequently the set of slides to be used during the BOF. New slides are available at : http://rtg.ietf.org/bof/pce/pce-bof-2.ppt JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Mon Nov 15 00:38: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 AAA12667; Mon, 15 Nov 2004 00:38:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTZb3-0007ta-G3; Mon, 15 Nov 2004 00:40:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTZVB-0004M5-FB; Mon, 15 Nov 2004 00:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTZSE-00045w-E6 for pce@megatron.ietf.org; Mon, 15 Nov 2004 00:31:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12253 for ; Mon, 15 Nov 2004 00:31:03 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CTZU9-0007n3-LB for pce@ietf.org; Mon, 15 Nov 2004 00:33:06 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111500305524384 for ; Mon, 15 Nov 2004 00:30:55 -0500 Received: from Puppy ([10.67.86.151]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 00:30:55 -0500 Message-ID: <004c01c4cad4$61040f30$9756430a@Puppy> From: "Adrian Farrel" To: Date: Mon, 15 Nov 2004 05:31:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 15 Nov 2004 05:30:55.0524 (UTC) FILETIME=[4788C640:01C4CAD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 847361531d5cb2b89126844012e81b58 Content-Transfer-Encoding: 7bit Subject: [Pce] PCE BOF - Draft minutes X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 Content-Transfer-Encoding: 7bit Thanks to Richard Rabbat, Jonathan Saddler and Andy Malis. Comments to the PCE list or to me/JP privately. Thanks, Adrian ===== Path Computation Element BOF (pce) Wednesday, November 10 at 1530-1730 CHAIR: JP Vasseur (jvasseur@cisco.com) Adrian Farrel (adrian@olddog.co.uk) Minute takers Richard Rabbat, Jonathan Sadler and Andrew Malis Slides and charter available on the Routing Area web site. http://rtg.ietf.org 1) Introduction, admin, statement of objectives of this second BOF (5 minutes) Adrian/JP Adrian: In the interest of getting to the charter, slides are on the web site. Went over the agenda. No questions were raised. At the mic, please limit yourselves to clarifications. JP: Scope of the Potential PCE WG Specify a set of mechanism for PCE-based path computation of MPLS Traffic Engineered LSPs in the context of a specific application. There is no intent to come up with a new Inter-domain routing protocol. The scope is very clear and is for TE LSPs Based on discussions with SPs, are we trying to come up with a mesh of 1000 LSPs? Answer is no. So we start by trying to find techniques to compute limited number of TE LSPs. We will have 2 or 3 ASes. For the same SP, 4 or 5 ASes likely. JP: Objectives of this BOF - Jerry will go over proposed architecture - Recap different perceived requirements - Agree a proposed charter for a working group 2) Quick summary of the conclusion of the first BOF held in San Diego (5 minutes) JP JP: - Clear statements of requirements from many providers (Infonet, KDDI, AT&T, FT, NTT, MCI) - To be able to compute shortest path in multiple domains - Diverse path computation (intra and inter domain) - Dealing with multiple (complex) constraints - If you have to try to solve a problem with multiple constraints, it is NP-complete. So off-line computation is necessary. - Asked to write an architecture I-D. - Common theme at SD PCE BOF was need for (G)MPLS TE LSP path computation - Need to develop a draft charter - We want to narrow the scope of work Adrian: - Kireeti asks that MPLS be changed to say GMPLS in all instances - Agreement that this work needs to cover MPLS-TE and GMPLS - Asked questions on the CCAMP ML. - Is this an appropriate technology to solve inter-domain TE? - Does it look like it may solve a problem that CCAMP is charted to work on? - Answers were positive, especially from SPs - CCAMP will commit to help provide requirements to a future PCE WG for the inter-domain TE problem space - Comments made on the CCAMP list were that the architecture needs polishing. Comments are good and were expected 3) Problem space: recap of the PCE architecture ID draft-ash-pce-architecture-00.txt (15 minutes) Jerry Ash Jerry Ash: - Main architects are JP, Adrian and Jerry - Good amount of discussion. Will summarize issues discussed on list Terminology: What is a path computation element (PCE) - entity (component, application or network node) capable of computing a network path based on network graph & computational constraints - e.g., PCE computes path of a TE LSP by using TED & bandwidth/other constraints What is path computation client (PCC)? - any client application requesting a path computation by the PCE What is a domain? - any collection of network elements within a common sphere of address management or path computational responsibility - e.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs across multiple SP networks What is single PCE path computation? - single PCE computes a path in a domain Defining multiple PCE path computation: - multiple PCEs compute a path in a domain Defining centralized computation model: - all paths in a domain computed by a single, centralized PCE Defining distributed computation model: - computation of paths in a domain shared among multiple PCEs Assumptions that are made: - PCE may or may not be located at head-end - e.g. nodes on path contribute to path computation (e.g., loose hops) making them PCEs - Path computation may be made by PCE physically distinct from the computed path - The path computed by PCE may be: - complete: full explicit path of strict hops - partial: mix of strict & loose hops (may be an abstract node such as an AS) PCE path computation can be used in conjunction with other path computation models - e.g., inter-AS TE LSP may be computed using PCE in some domains but not others We make no assumptions made about PCE implementation - e.g., could be implemented on a router, LSR, dedicated network server, etc. PCE function is independent of the forwarding capability of the node on which it is implemented The motivation for this are: - inter-area/AS optimal path computation (node has partial visibility) - computation of inter-area/AS diverse path (node has partial visibility) - CPU-intensive path computation/global optimization - backup path computation for bandwidth protection with backup capacity optimization - multi-layer networks e.g. TDM network provides connectivity for client-layer (IP, MPLS, L2, etc.) - absence of TED or use of non-TE-enabled IGP - where the node is outside routing domain (e.g., CE to PE path computation) - where the network element lacks control plan or routing capability Jerry then presented the composite PCE architecture. It is embedded in the router. It could also be external to be queried for a path. It could also be a headend LSR, where you query along the way. We can have multiple PCEs with inter-pce communication. It looks like it's computed by one PCE. He listed some considerations discussed in the draft: - Synchronization - non-synchronized (e.g., PCE makes multiple individual path computations to generate set of paths) - synchronized (e.g., single PCE invokes computations by other PCEs before supplying result to PCC - PCE discovery & load balancing - Detecting PCE liveness - PCC-PCE & PCE-PCE communication - PCE TED synchronization - Stateful vs. stateless PCEs - We need to monitor the state of the PCE A major issue is that of policy & confidentiality - we must preserve confidentiality across multiple SPs - we must ensure confidentiality & security of PCC-PCE & PCE-PCE messages For security & confidentiality: On the PCC-PCE communication - Snooping not a significant issue but requires authentication - might want to encrypt - Spoofing is a very serious issue as it would allow for traffic intercept - must offer strong authentication - protocol is P2P so this is relatively easy - DoS important because of 'centralized' nature of PCE PCE-PCE communication - same as for PCC-PCE, but add confidentiality Confidentiality (protection of domain topology information) - Policy and confidentiality issues must be handled in the information returned by the PCE - Could be done through the use loose routes - PCE encrypts ERO segments - decrypt on entry to domain - Replace ERO segment with cookie, keeping confidentiality. JP: Manageability is probably also something that should be added Jerry: PCE Evaluation Metrics - optimality - scalability - load sharing - multiple path computation - reoptimization - path computation time - network stability - synchronization - between TED & network topology/resource states - speed of TED synchronization - impact of synchronization on data flows There's been a good amount of discussion on the list. He listed them as shown on the slide - PCE should advertise its capabilities (constraints that can be handled, etc.) - PCE request should handle near-disjoint as well as mandatory disjoint - TED can include info from sources other than IGP - Evaluation metrics should include TED sync speed, and impact on data flows - Architecture should elaborate on advantages of stateful PCE and pitfalls of stateful PCE in a distributed PCE environment We've already spoken about TED synchronization speed & impact on the data flows JP: Please give comments about 1st cut at PCE architecture Mark Handley: Which part of the architecture are we talking about standardizing? Adrian: Please wait for the charter discussion as the charter lists this Dimitri Papadimitriou: The name "entity" broadens the scope instead of focusing Appears that we are standardizing an entity, not a protocol. So what is expected to be standardize here? LSR behavior internally is not standardized. Adrian: You are saying if we co-locate a PCE with an LSR there is nothing to do Dimitri: Right ???? (MCI): Please clarify what can be done through dynamic stuff and what can be done statically Hani ???: Does the architecture allow for PCEs to initiate rerouting in the network? JP: Stateful PCE may allow such behavior 4) Summary of existing/future drafts (5 minutes) Adrian/JP JP: We'll go very quickly through the drafts - Techniques for establishing and controlling (G)MPLS LSPs in multi-domain networks - Presents PCE as a possible approach - Procedural and operational considerations for PCE in inter-domain TE - Use of PCE for MPLS Fast Reroute - GMPLS considerations for PCE (multi-region, MPLS/GMPLS) - Generalized Traffic Engineering Protocol - Proposal for communications between LSRs and PCE based on GTEP - Use of ring-based SRLG for back-up path computation Since the last IETF, we had something like 8 new drafts. This shows interest in the area. No time to go over them. Please go to the slides on the web site. Let's go to the key questions. Clear requirements have been expressed by many Service Providers during the last BOF in San Diego, on the mailing list, - Is there agreement on this point? - No dissent was expressed. Can we say that this work belongs to the IETF (under the IETF scope of expertise)? - Scope is limited to (G)MPLS-TE LSPs Alex Zinin: Are there are any comments on JPs question? Mark Handley: Still haven't figured out what we're doing (standardizing). We can't answer this question. JP: The charter slide does provide more definition, but has not been presented yet. So ordering of slides was probably suboptimal. We'll go back to your point during the discussion of the charter. Is there enough interest on this architecture? - No answer Adrian: Let's move on to the charter 5) Proposed charter (15 minutes) The charter is on the slides and separately on the web site. JP: (Picking out key points) The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. The Working Group will determine requirements for extensions to existing routing and signaling protocols in support of such functions as PCE discovery and the secure and confidential signaling of inter- domain paths. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The goal is what kind of protocol we should end up with. We came up with an architecture but it is not the objective to standardize the architecture. Signalling extensions is for a reply/response protocol, not for other changes. Note that the communications protocol between PCC and PCE is not signaling and should not be referred to as signaling. Currently there are 6 proposals on the table for the protocol. New protocols, and existing protocols. Adrian: We'll not standardize all of them. We will have just one protocol. JP: In some cases, it might not be completely desirable to have automatic discovery of PCE to communicate with and otherwise, fall back to policy or static configuration Routing extensions are for auto discovery of PCE. Loa Andersson: On this slide, I can't parse the 2nd paragraph. It doesn't come to conclusion. What do you want to cooperate with other WGs about? JP: It means that we may need to extend OSPF Loa: On the previous slide, there is a very general comment about extending/using routing protocols. Do you include PNNI? I want to exclude LDP. JP: We need to be more explicit Adrian: You're not going to ask us to list all the exclusions? Loa: No, a list of inclusions would be good enough JP: When we come up with new protocols, we come up with protocol- independent metrics to evaluate the protocol. You want to hide internal topology when you provide path computation If you return a loose hop, when you signal the LSP, you may not preserve path diversity We will need extensions to RSVP Need security Arthi Ayyangar: Are extensions for policy, security and confidentiality specifically for diverse path computation? JP: No general requirement. Mark Handley: You talk about specifying techniques. We don't standardize techniques. We do protocols. Don't do protocols or techniques when you don't need to have interop. JP: In some techniques, you have 2 ABRs that are acting as PCEs, you may need communication between PCEs and agreed techniques. Algorithms are not specified but inputs/outputs need to be specified. George Swallow: You should not specify an algorithm but the outcome of the algorithm Choi: Some of the NEs don't have signaling / traffic engineering capabilities Adrian: You're describing a situation where legacy (optical) equipment does not have a control plane, and PCE is able to choose a route in the network on behalf of that equipment. I understand. Kireeti Kompella: Show the interactions and tell what is going to be standardized. You need multiple PCEs for reliability. If I'm a PCC, I discover the PCE, ask it for a path, get it back from it. If I run the PCE as a distributed computation, that's something we don't need to have standardized. Use of distributed or centralized computation should be an implementation detail -- not a standardized item. Please draw a picture to show what is going to be worked on. Adrian: Clearly, it is none of our business to specify what they do when they implement. Distributed computation is within scope. If in multi-AS with PCE to PCE communication, is that distributed computation, and shouldn't it be standardized? Kireeti: The behavior of a PCE should be standardized, but the way that the PCE is used to develop an end-to-end route is not necessarily something that should be standardized. If I take a problem and hierarchically decompose it, then we do need to standardize this. If I'm the one holding the database, another is doing the computation, no need to standardize. JP: What we try to mention is in the PCE id Anna C: If we do have distributed computation do we need to standardize the inter-PCE communication method? Adrian: Somewhat Richard Rabbat: Distributed algorithm (not hierarchical decomposition) is an implantation decision, so it shouldn't be standardized. Alex Zinin: Please continue through the milestones. Adrian: List is where we will start rather than a complete set JP: 1st submit a requirements draft. Kireeti, how about CCAMP? Kireeti: Previously other groups do the requirements and CCAMP does the work; this is the other way around. This discusses inter-area/domain/region work. The other part of the problem is protection. We've been working on both of these so CCAMP will have some requirements. You also need to take input from other WG. JP: How about MPLS working group for P2MP requirements? George: Not quite there yet for P2MP; getting the base thing done so can't specify PCE requirements yet. Doing the unicast case is a good start. Adrian: Not an attempt to force other WGs to do significant work or to deliver requirements. Rather a statement that PCE does not develop requirements. Dimitri: Previous MPLS work was on signalling/routing protocols, not behaviors. PCE work should still not be about behaviors even though computational complexity is increasing. Kireeti: One of the things in the charter I read was mp2mp LSPs. This makes me shiver. Adrian: That was an early version of the charter. It's gone now. JP: Submit requirements draft. We need to start with requirements. Submit draft describing the PCE arch Try to flesh out PCE architecture I-D. Need to define more precisely to explain what we mean by distributed computation. Submit draft specifying communications protocol requirements between PCC and PCe and PCEs. Submit draft of a SINGLE communication protocol for use between a PCC and a PCE and between PCEs. Submit an applicability draft Nice to have an applicability draft describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions. Kireeti: Do we need a MIB? Adrian: If we have a protocol, we must have a MIB. Not immediately obvious that we need one, but that's the rules. Kireeti: Agree that we need management, I'm just wondering if we need a MIB. Adrian: Until the IESG changes the rules, we need a MIB. Richard Rabbat: Does this include Load balancing between PCEs? JP: MPLS PCE Load balancing draft has been created already, need to have GMPLS extensions Richard: Doesn't this mean that PCE needs to provide information on its Computation power, etc? Does that cause confidentiality problem? JP: There are ways around this... Kireeti: We should walk before we run, but I would like to see in the charter the use of PCE for Optical VPNs. Alex: This is the 2nd BOF. We don't normally have more than 2 BOFs. You need to take into consideration whether there is enough interest in this work and whether we have a good idea, whether we have good candidates for this work. Are there any questions on the key questions? There are two questions: Is there a need for a WG? Who believes the WG should be chartered? Many hands raised Are there any people that don't believe there is a need for a WG? No hands raised Hmm. Not all hands raised for those two questions. Who isn't thinking? Some hands Ok. Seems to be consensus in the room. I will take it to the IESG for consideration and we will work on the proposed BOF charter Keep discussion going on PCE mailing list. Find the mailing list for PCE on the routing area web pages. All discussions on PCE will happen on that list. Thanks for coming JP: Thanks. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Nov 17 08:09: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 IAA26613; Wed, 17 Nov 2004 08:09:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPbS-0000bu-OV; Wed, 17 Nov 2004 08:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPXz-00055t-6V; Wed, 17 Nov 2004 08:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPSA-0003W3-6E for pce@megatron.ietf.org; Wed, 17 Nov 2004 08:02:30 -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 IAA25258 for ; Wed, 17 Nov 2004 08:02:28 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPUY-0000IE-LH for pce@ietf.org; Wed, 17 Nov 2004 08:05:00 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 14:00:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Nov 2004 14:00:10 +0100 Message-ID: Thread-Topic: contribution to charter item Thread-Index: AcTMpV6srmFYZj9gQfeJq1wfwNHicA== From: "STEPHAN Emile RD-CORE-LAN" To: X-OriginalArrivalTime: 17 Nov 2004 13:00:11.0260 (UTC) FILETIME=[5F3B2BC0:01C4CCA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Pce] contribution to charter item 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="===============0823928395==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. --===============0823928395== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CCA5.5F25636E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4CCA5.5F25636E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear JP, Adrian and all There is an important item in the PCE WG charter, which is the definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements. I am interested to contribute to this WG item. Please let me know when you will start this activity. Regards Emile ------_=_NextPart_001_01C4CCA5.5F25636E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable contribution to charter item

Dear = JP, = Adrian and = all

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

I am = interested to contribute to this WG = item.

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

Regards

Emile

------_=_NextPart_001_01C4CCA5.5F25636E-- --===============0823928395== 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 --===============0823928395==-- From pce-bounces@ietf.org Wed Nov 17 08:35: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 IAA28589; Wed, 17 Nov 2004 08:35:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUQ0f-00018m-Mp; Wed, 17 Nov 2004 08:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPrd-0000Q2-It; Wed, 17 Nov 2004 08:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPmC-0007xT-RR for pce@megatron.ietf.org; Wed, 17 Nov 2004 08:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27745 for ; Wed, 17 Nov 2004 08:23:11 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPoZ-0000tX-Qq for pce@ietf.org; Wed, 17 Nov 2004 08:25:43 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2004 05:22:43 -0800 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 iAHDMYPJ017411; Wed, 17 Nov 2004 05:22:34 -0800 (PST) Received: from [68.116.197.250] (che-vpn-cluster-1-99.cisco.com [10.86.240.99]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA28048; Wed, 17 Nov 2004 05:22:33 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: JP Vasseur Subject: Re: [Pce] contribution to charter item Date: Wed, 17 Nov 2004 08:22:38 -0500 To: "STEPHAN Emile RD-CORE-LAN" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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="===============0233460276==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --===============0233460276== Content-Type: multipart/alternative; boundary=Apple-Mail-7--16008986 --Apple-Mail-7--16008986 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Emile, On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote: > Dear JP, Adrian and all > > There is an important item in the PCE WG charter, which is the > definition of MIBs and management procedures related to the new > protocols, protocol extensions and operational elements. > > I am interested to contribute to this WG item. > You are indeed very welcome. > Please let me know when you will start this activity. > Although we need to wait for the IESG approval for the PCE WG to be official, you are very welcome to start any draft and discuss it on this list. Any other volunteer to work on this item ? JP. > Regards > > Emile > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-7--16008986 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Emile, On Nov 17, 2004, at 8:00 AM, STEPHAN Emile RD-CORE-LAN wrote: Dear JP, Adrian and all There is an important item in the PCE WG charter, which is the definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements. I am interested to contribute to this WG item. You are indeed very welcome. Please let me know when you will start this activity. Although we need to wait for the IESG approval for the PCE WG to be official, you are very welcome to start any draft and discuss it on this list. Any other volunteer to work on this item ? JP. Regards Emile _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-7--16008986-- --===============0233460276== 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 --===============0233460276==-- From pce-bounces@ietf.org Wed Nov 17 11:48: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 LAA18026; Wed, 17 Nov 2004 11:48:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUT0u-0005rW-2O; Wed, 17 Nov 2004 11:50:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSwq-00054e-Vr; Wed, 17 Nov 2004 11:46:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSkP-0001om-VJ for pce@megatron.ietf.org; Wed, 17 Nov 2004 11:33:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16239 for ; Wed, 17 Nov 2004 11:33:31 -0500 (EST) 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 1CUSmr-0005Lv-FK for pce@ietf.org; Wed, 17 Nov 2004 11:36:05 -0500 Received: from info.ucl.ac.be (dufy [130.104.230.51]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id iAHGXD32026794; Wed, 17 Nov 2004 17:33:13 +0100 (MET) Message-ID: <419B7CD4.20301@info.ucl.ac.be> Date: Wed, 17 Nov 2004 17:31:16 +0100 From: Cristel Pelsser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "LE ROUX Jean-Louis RD-CORE-LAN" , pce@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Pce] comments on draft-leroux-pce-backup-comp-frwk-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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi Jean-Louis and all, Here are some comments on draft-leroux-pce-backup-comp-frwk-00.txt 1. Could you replace the occurences of PCS by PCE 2. In the draft, you consider two cases. Either there is a single PCE that computes all the bypass tunnels paths or each LSR behaves as a PCE and computes the paths for the bypass tunnels protecting its own failure or the failure of one of its links. What about the case where not all nodes have the PCE capability but there are mutliple PCEs for request balancing and resilience purposes? Maybe you could say that in this case there needs to be synchronisation between the PCEs or a way to determine which PCE is responsible for the protection of a given facility. 3. Paragraph 3 of section 6.3.1 is not clear. What approach do you propose to determine the backup-bandwidth pool? If you take the same pool as for the primary LSPs then you need to update this primary-bandwidth pool when a new bypass tunnel is established depending on the resources that it protects. 4. Paragraph 1 of section 6.3.1.2, replace "to tell" by "to distinguish" in sentence: "... additional signaling extensions need to be implemented to enable an LSR to tell a primary LSP from a bypass LSP ..." 5. What happens if the PCE elected to compute the bypass tunnels paths for a given facility fails? For example: if the PCE elected to compute paths for a SRLG fails, it looses all the information about the bypass tunnels established to protect the SRLG. Thus it looses the information concerning the resources allocated to these bypass tunnels. How can this PCE compute subsequent bypass tunnels paths protecting the SRLG? Best regards, Cristel -- ''' (0 0) +-------oOO----(_)---------------+ | Cristel Pelsser | | http://www.info.ucl.ac.be/~cpe | +--------------------oOO---------+ |__|__| || || ooO Ooo _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Nov 17 12:47: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 MAA24030; Wed, 17 Nov 2004 12:47:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTwp-0007WK-42; Wed, 17 Nov 2004 12:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTp2-0002dH-QU; Wed, 17 Nov 2004 12: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 1CUTeM-0000S4-FF for pce@megatron.ietf.org; Wed, 17 Nov 2004 12:31:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22538 for ; Wed, 17 Nov 2004 12:31:19 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTgo-00076X-Cp for pce@ietf.org; Wed, 17 Nov 2004 12:33:54 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:30:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2004 18:30:55 +0100 Message-ID: Thread-Topic: comments on draft-leroux-pce-backup-comp-frwk-00.txt Thread-Index: AcTMwyo4vD+mXn2xS0aVNiVhLkUO5QAAPh/Q From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Cristel Pelsser" , X-OriginalArrivalTime: 17 Nov 2004 17:30:56.0889 (UTC) FILETIME=[32616E90:01C4CCCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Subject: [Pce] RE : comments on draft-leroux-pce-backup-comp-frwk-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: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Hi Cristel, Thanks a lot for these really valuable comments. Please see inline, JL >-----Message d'origine----- >De : Cristel Pelsser [mailto:cpe@info.ucl.ac.be]=20 >Envoy=E9 : mercredi 17 novembre 2004 17:31 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org >Objet : comments on draft-leroux-pce-backup-comp-frwk-00.txt > > >Hi Jean-Louis and all, > >Here are some comments on draft-leroux-pce-backup-comp-frwk-00.txt > >1. Could you replace the occurences of PCS by PCE Right, I though I had removed all PCS occurences, but it seems that=20 there is some "resistance" in the SDLG section... Anyway, we will kill them. > >2. In the draft, you consider two cases. Either there is a=20 >single PCE that computes all the bypass tunnels paths or each=20 >LSR behaves as a PCE and computes the paths for the bypass=20 >tunnels protecting its own failure or the failure of one of=20 >its links. What about the case where not all nodes have the=20 >PCE capability but there are mutliple PCEs for request=20 >balancing and resilience purposes? Maybe you could say that in=20 >this case there needs to be synchronisation between the PCEs=20 >or a way to determine which PCE is responsible for the=20 >protection of a given facility. You raised a good point. Basically the set of bypass tunnels protecting a given facility (link, = node SRLG or SDLG) must be computed by the same PCE, and as you mention = there must be a way to determine which PCE is responsible for the = protection of a given facility. We will fix that for the next revision. > >3. Paragraph 3 of section 6.3.1 is not clear. What approach do=20 >you propose to determine the backup-bandwidth pool? If you=20 >take the same pool as for the primary LSPs then you need to=20 >update this primary-bandwidth pool when a new bypass tunnel is=20 >established depending on the resources that it protects. In this section we address the case where both primary and backup LSPs=20 are computed by the same PCE. That is the PCE is aware of all primary = and backup LSPs. In such case, we just have to tell the PCE the amount of link bandwidth = it can use for backup and there is actually no need to explicitely define a backup pool.=20 Does that make sense ? > >4. Paragraph 1 of section 6.3.1.2, replace "to tell" by "to=20 >distinguish" in sentence: "... additional signaling extensions=20 >need to be implemented to enable an LSR to tell a primary LSP=20 >from a bypass LSP ..." OK, will update > >5. What happens if the PCE elected to compute the bypass=20 >tunnels paths for a given facility fails? For example: if the=20 >PCE elected to compute paths for a SRLG fails, it looses all=20 >the information about the bypass tunnels established to=20 >protect the SRLG. Thus it looses the information concerning=20 >the resources allocated to these bypass tunnels. How can this=20 >PCE compute subsequent bypass tunnels paths protecting the SRLG? Actually after a PCE restart, all PLRs will have to re-send a PC request = to the PCE, potentially indicating the previous computed path (kind of PCE graceful = restart approach) We will clarify that in next revision. Again thanks a lot for these useful comments Regards, JL > >Best regards, > >Cristel > >--=20 > ''' > (0 0) > +-------oOO----(_)---------------+ > | Cristel Pelsser | > | http://www.info.ucl.ac.be/~cpe | > +--------------------oOO---------+ > |__|__| > || || > ooO Ooo > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Nov 18 11: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 LAA10170; Thu, 18 Nov 2004 11:41:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUpOP-0005ZJ-LI; Thu, 18 Nov 2004 11:44:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpEl-0004Tz-AK; Thu, 18 Nov 2004 11:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpBi-0003Dq-Io for pce@megatron.ietf.org; Thu, 18 Nov 2004 11:31:14 -0500 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 LAA08731 for ; Thu, 18 Nov 2004 11:31:10 -0500 (EST) Received: from mail.icu.ac.kr (localhost [127.0.0.1]) by icu.ac.kr (8.12.10/8.12.8) with ESMTP id iAIGMBj7009097; Fri, 19 Nov 2004 01:22:11 +0900 (KST) Received: (from kebi@localhost) by mail.icu.ac.kr (8.12.10/8.12.8/Submit) id iAIGM1GF009061; Fri, 19 Nov 2004 01:22:01 +0900 (KST) Date: Fri, 19 Nov 2004 01:22:01 +0900 (KST) Message-Id: <200411181622.iAIGM1GF009061@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.62 In-Reply-To: dip@icu.ac.kr To: pce@ietf.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: dip.90591100794921313 X-Priority: 3 MIME-Version: 1.0 Cc: jkchoi@icu.ac.kr Subject: [Pce] PCE WG contributions 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="===============0242109265==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Multi-Message. --===============0242109265== Content-type: multipart/alternative; boundary="kebi210.107.137.62.90591100794921242" Multi-Message. --kebi210.107.137.62.90591100794921242 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit
Hi JP, Adrian and members of the PCE Community,
 
We would like to contribute to the aspects of the PCE WG charter on the following points:
 
1. protocols for PCE-based path computation techniques
2. protocols for communication between PCEs and PCC with focus upon lesser computational costs in path computation techniques across multiple administrative domains
3. security issues and protocol extensions (this is quite an important feature of the WG charter)
4. MIB definition and requirements. (This is something that has to be worked out. We can work with Emile on this and other management criteria)
 
We have already submitted a couple of drafts related to Point 2 for the bygone PCE BOF, for example:
 
 
Please let us know what you think about this.
 
Thanks,
 
Dip
--kebi210.107.137.62.90591100794921242 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit
Hi JP, Adrian and members of the PCE Community,

 

We would like to contribute to the aspects of the PCE WG charter on the following points:

 

1. protocols for PCE-based path computation techniques

2. protocols for communication between PCEs and PCC with focus upon lesser computational costs in path computation techniques across multiple administrative domains

3. security issues and protocol extensions (this is quite an important feature of the WG charter)

4. MIB definition and requirements. (This is something that has to be worked out. We can work with Emile on this and other management criteria)

 

We have already submitted a couple of drafts related to Point 2 for the bygone PCE BOF, for example:

 


 

Please let us know what you think about this.

 

Thanks,

 

Dip
  --kebi210.107.137.62.90591100794921242-- --===============0242109265== 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 --===============0242109265==-- From pce-bounces@ietf.org Mon Nov 22 17:52: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 RAA02043; Mon, 22 Nov 2004 17:52:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWN6v-0003AH-7X; Mon, 22 Nov 2004 17:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMpx-0003BY-5S; Mon, 22 Nov 2004 17:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMcL-0000YB-NO for pce@megatron.ietf.org; Mon, 22 Nov 2004 17:25:05 -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 RAA28644 for ; Mon, 22 Nov 2004 17:25:03 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMfr-0007CF-QC for pce@ietf.org; Mon, 22 Nov 2004 17:28:44 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 1D0D5E000146 for ; Mon, 22 Nov 2004 22:24:30 +0000 (GMT) Received: from Puppy ([217.158.145.21] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 22:24:26 +0000 Message-ID: <0a5501c4d0e2$229653c0$749c9ed9@Puppy> From: "Adrian Farrel" To: References: <004c01c4cad4$61040f30$9756430a@Puppy> Date: Mon, 22 Nov 2004 22:23:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Nov 2004 22:24:27.0459 (UTC) FILETIME=[0729E930:01C4D0E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Content-Transfer-Encoding: 7bit Subject: [Pce] Last call on draft PCE minutes 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: 04b84659b2acb599bee006e63124a606 Content-Transfer-Encoding: 7bit Last call for comments on the minutes. Please send any comments to me by Wednesday 24th November. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Monday, November 15, 2004 5:31 AM Subject: [Pce] PCE BOF - Draft minutes > Thanks to Richard Rabbat, Jonathan Saddler and Andy Malis. > Comments to the PCE list or to me/JP privately. > > Thanks, > Adrian > ===== > Path Computation Element BOF (pce) > Wednesday, November 10 at 1530-1730 > CHAIR: JP Vasseur (jvasseur@cisco.com) > Adrian Farrel (adrian@olddog.co.uk) > > Minute takers Richard Rabbat, Jonathan Sadler and Andrew Malis > > Slides and charter available on the Routing Area web site. > http://rtg.ietf.org > > 1) Introduction, admin, statement of objectives of this second > BOF (5 minutes) Adrian/JP > > Adrian: > In the interest of getting to the charter, slides are on the web site. > Went over the agenda. No questions were raised. > At the mic, please limit yourselves to clarifications. > > JP: > Scope of the Potential PCE WG > > Specify a set of mechanism for PCE-based path computation of MPLS > Traffic Engineered LSPs in the context of a specific application. > > There is no intent to come up with a new Inter-domain routing protocol. > The scope is very clear and is for TE LSPs > > Based on discussions with SPs, are we trying to come up with a mesh of > 1000 LSPs? Answer is no. So we start by trying to find techniques to > compute limited number of TE LSPs. > > We will have 2 or 3 ASes. For the same SP, 4 or 5 ASes likely. > > JP: > Objectives of this BOF > - Jerry will go over proposed architecture > - Recap different perceived requirements > - Agree a proposed charter for a working group > > > 2) Quick summary of the conclusion of the first BOF held in San Diego > (5 minutes) JP > > JP: > - Clear statements of requirements from many providers > (Infonet, KDDI, AT&T, FT, NTT, MCI) > - To be able to compute shortest path in multiple domains > - Diverse path computation (intra and inter domain) > - Dealing with multiple (complex) constraints > - If you have to try to solve a problem with multiple constraints, > it is NP-complete. So off-line computation is necessary. > - Asked to write an architecture I-D. > - Common theme at SD PCE BOF was need for (G)MPLS TE LSP path > computation > - Need to develop a draft charter > - We want to narrow the scope of work > > Adrian: > - Kireeti asks that MPLS be changed to say GMPLS in all instances > - Agreement that this work needs to cover MPLS-TE and GMPLS > - Asked questions on the CCAMP ML. > - Is this an appropriate technology to solve inter-domain TE? > - Does it look like it may solve a problem that CCAMP > is charted to work on? > - Answers were positive, especially from SPs > - CCAMP will commit to help provide requirements to a future PCE WG > for the inter-domain TE problem space > - Comments made on the CCAMP list were that the architecture needs > polishing. Comments are good and were expected > > > 3) Problem space: recap of the PCE architecture ID > draft-ash-pce-architecture-00.txt (15 minutes) Jerry Ash > > Jerry Ash: > - Main architects are JP, Adrian and Jerry > - Good amount of discussion. Will summarize issues discussed on list > > Terminology: > > What is a path computation element (PCE) > - entity (component, application or network node) capable of computing > a network path based on network graph & computational constraints > - e.g., PCE computes path of a TE LSP by using TED & bandwidth/other > constraints > > What is path computation client (PCC)? > - any client application requesting a path computation by the PCE > > What is a domain? > - any collection of network elements within a common sphere of address > management or path computational responsibility > - e.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs > across multiple SP networks > > What is single PCE path computation? > - single PCE computes a path in a domain > > Defining multiple PCE path computation: > - multiple PCEs compute a path in a domain > > Defining centralized computation model: > - all paths in a domain computed by a single, centralized PCE > > Defining distributed computation model: > - computation of paths in a domain shared among multiple PCEs > > Assumptions that are made: > - PCE may or may not be located at head-end > - e.g. nodes on path contribute to path computation (e.g., loose > hops) making them PCEs > - Path computation may be made by PCE physically distinct from the > computed path > - The path computed by PCE may be: > - complete: full explicit path of strict hops > - partial: mix of strict & loose hops (may be an abstract node such > as an AS) > > PCE path computation can be used in conjunction with other path > computation models > - e.g., inter-AS TE LSP may be computed using PCE in some domains but > not others > > We make no assumptions made about PCE implementation > - e.g., could be implemented on a router, LSR, dedicated network > server, etc. > > PCE function is independent of the forwarding capability of the node > on which it is implemented > > The motivation for this are: > - inter-area/AS optimal path computation (node has partial visibility) > - computation of inter-area/AS diverse path (node has partial > visibility) > - CPU-intensive path computation/global optimization > - backup path computation for bandwidth protection with backup > capacity optimization > - multi-layer networks e.g. TDM network provides connectivity for > client-layer (IP, MPLS, L2, etc.) > - absence of TED or use of non-TE-enabled IGP > - where the node is outside routing domain (e.g., CE to PE path > computation) > - where the network element lacks control plan or routing capability > > > Jerry then presented the composite PCE architecture. It is embedded > in the router. It could also be external to be queried for a path. It > could also be a headend LSR, where you query along the way. We can > have multiple PCEs with inter-pce communication. It looks like it's > computed by one PCE. > > He listed some considerations discussed in the draft: > - Synchronization > - non-synchronized (e.g., PCE makes multiple individual path > computations to generate set of paths) > - synchronized (e.g., single PCE invokes computations by other > PCEs before supplying result to PCC > - PCE discovery & load balancing > - Detecting PCE liveness > - PCC-PCE & PCE-PCE communication > - PCE TED synchronization > - Stateful vs. stateless PCEs > - We need to monitor the state of the PCE > > A major issue is that of policy & confidentiality > - we must preserve confidentiality across multiple SPs > - we must ensure confidentiality & security of PCC-PCE & PCE-PCE > messages > > For security & confidentiality: > On the PCC-PCE communication > - Snooping not a significant issue but requires authentication > - might want to encrypt > - Spoofing is a very serious issue as it would allow for traffic > intercept > - must offer strong authentication > - protocol is P2P so this is relatively easy > - DoS important because of 'centralized' nature of PCE > PCE-PCE communication > - same as for PCC-PCE, but add confidentiality > Confidentiality (protection of domain topology information) > - Policy and confidentiality issues must be handled in the information > returned by the PCE > - Could be done through the use loose routes > - PCE encrypts ERO segments > - decrypt on entry to domain > - Replace ERO segment with cookie, keeping confidentiality. > > JP: > Manageability is probably also something that should be added > > Jerry: > PCE Evaluation Metrics > - optimality > - scalability > - load sharing > - multiple path computation > - reoptimization > - path computation time > - network stability > - synchronization > - between TED & network topology/resource states > - speed of TED synchronization > - impact of synchronization on data flows > > There's been a good amount of discussion on the list. He listed > them as shown on the slide > - PCE should advertise its capabilities (constraints that can be > handled, etc.) > - PCE request should handle near-disjoint as well as mandatory disjoint > - TED can include info from sources other than IGP > - Evaluation metrics should include TED sync speed, and impact on data > flows > - Architecture should elaborate on advantages of stateful PCE and > pitfalls of stateful PCE in a distributed PCE environment > > We've already spoken about TED synchronization speed & impact on > the data flows > > > JP: > Please give comments about 1st cut at PCE architecture > > Mark Handley: > Which part of the architecture are we talking about standardizing? > > Adrian: > Please wait for the charter discussion as the charter lists this > > Dimitri Papadimitriou: > The name "entity" broadens the scope instead of focusing > Appears that we are standardizing an entity, not a protocol. So what > is expected to be standardize here? LSR behavior internally is not > standardized. > > Adrian: > You are saying if we co-locate a PCE with an LSR there is nothing > to do > > Dimitri: > Right > > ???? (MCI): > Please clarify what can be done through dynamic stuff and what can be > done statically > > Hani ???: > Does the architecture allow for PCEs to initiate rerouting in the > network? > > JP: > Stateful PCE may allow such behavior > > > 4) Summary of existing/future drafts (5 minutes) Adrian/JP > > JP: > We'll go very quickly through the drafts > - Techniques for establishing and controlling (G)MPLS LSPs in > multi-domain networks > - Presents PCE as a possible approach > - Procedural and operational considerations for PCE in inter-domain TE > - Use of PCE for MPLS Fast Reroute > - GMPLS considerations for PCE (multi-region, MPLS/GMPLS) > - Generalized Traffic Engineering Protocol > - Proposal for communications between LSRs and PCE based on GTEP > - Use of ring-based SRLG for back-up path computation > > Since the last IETF, we had something like 8 new drafts. This shows > interest in the area. No time to go over them. Please go to the slides > on the web site. > > Let's go to the key questions. > Clear requirements have been expressed by many Service Providers > during the last BOF in San Diego, on the mailing list, > - Is there agreement on this point? > - No dissent was expressed. > > Can we say that this work belongs to the IETF (under the IETF scope > of expertise)? > - Scope is limited to (G)MPLS-TE LSPs > > Alex Zinin: > Are there are any comments on JPs question? > > Mark Handley: > Still haven't figured out what we're doing (standardizing). > We can't answer this question. > > JP: > The charter slide does provide more definition, but has not been > presented yet. So ordering of slides was probably suboptimal. > We'll go back to your point during the discussion of the charter. > Is there enough interest on this architecture? > - No answer > > Adrian: > Let's move on to the charter > > 5) Proposed charter (15 minutes) > > The charter is on the slides and separately on the web site. > > JP: (Picking out key points) > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) based architecture for the computation of paths for MPLS > and GMPLS Traffic Engineering LSPs. > > The Working Group will determine requirements for extensions to > existing routing and signaling protocols in support of such functions > as PCE discovery and the secure and confidential signaling of inter- > domain paths. Any necessary extensions will be produced in > collaboration with the Working Groups responsible for the protocols. > > The goal is what kind of protocol we should end up with. We came up > with an architecture but it is not the objective to standardize the > architecture. > > Signalling extensions is for a reply/response protocol, not for > other changes. > Note that the communications protocol between PCC and PCE is not > signaling and should not be referred to as signaling. > > Currently there are 6 proposals on the table for the protocol. > New protocols, and existing protocols. > > Adrian: > We'll not standardize all of them. We will have just one protocol. > > JP: > In some cases, it might not be completely desirable to have automatic > discovery of PCE to communicate with and otherwise, fall back to > policy or static configuration > > Routing extensions are for auto discovery of PCE. > > Loa Andersson: > On this slide, I can't parse the 2nd paragraph. It doesn't come to > conclusion. What do you want to cooperate with other WGs about? > > JP: > It means that we may need to extend OSPF > > Loa: > On the previous slide, there is a very general comment about > extending/using routing protocols. Do you include PNNI? I want to > exclude LDP. > > JP: > We need to be more explicit > > Adrian: > You're not going to ask us to list all the exclusions? > > Loa: > No, a list of inclusions would be good enough > > JP: > When we come up with new protocols, we come up with protocol- > independent metrics to evaluate the protocol. > > You want to hide internal topology when you provide path computation > > If you return a loose hop, when you signal the LSP, you may not > preserve path diversity > > We will need extensions to RSVP > > Need security > > Arthi Ayyangar: > Are extensions for policy, security and confidentiality specifically > for diverse path computation? > > JP: > No general requirement. > > Mark Handley: > You talk about specifying techniques. We don't standardize techniques. > We do protocols. > Don't do protocols or techniques when you don't need to have interop. > > JP: > In some techniques, you have 2 ABRs that are acting as PCEs, you may > need communication between PCEs and agreed techniques. > Algorithms are not specified but inputs/outputs need to be specified. > > George Swallow: > You should not specify an algorithm but the outcome of the algorithm > > Choi: > Some of the NEs don't have signaling / traffic engineering capabilities > > Adrian: > You're describing a situation where legacy (optical) equipment does not > have a control plane, and PCE is able to choose a route in the network > on behalf of that equipment. I understand. > > Kireeti Kompella: > Show the interactions and tell what is going to be standardized. You > need multiple PCEs for reliability. If I'm a PCC, I discover the PCE, > ask it for a path, get it back from it. If I run the PCE as a > distributed computation, that's something we don't need to have > standardized. Use of distributed or centralized computation should be > an implementation detail -- not a standardized item. Please draw a > picture to show what is going to be worked on. > > Adrian: > Clearly, it is none of our business to specify what they do when > they implement. Distributed computation is within scope. If in > multi-AS with PCE to PCE communication, is that distributed > computation, and shouldn't it be standardized? > > Kireeti: > The behavior of a PCE should be standardized, but the way that the PCE > is used to develop an end-to-end route is not necessarily something > that should be standardized. > > If I take a problem and hierarchically decompose it, then we do > need to standardize this. > > If I'm the one holding the database, another is doing the computation, > no need to standardize. > > JP: > What we try to mention is in the PCE id > > Anna C: > If we do have distributed computation do we need to standardize the > inter-PCE communication method? > > Adrian: > Somewhat > > Richard Rabbat: > Distributed algorithm (not hierarchical decomposition) is an > implantation decision, so it shouldn't be standardized. > > Alex Zinin: > Please continue through the milestones. > > Adrian: > List is where we will start rather than a complete set > > JP: > 1st submit a requirements draft. Kireeti, how about CCAMP? > > Kireeti: > Previously other groups do the requirements and CCAMP does the work; > this is the other way around. This discusses inter-area/domain/region > work. The other part of the problem is protection. We've been working > on both of these so CCAMP will have some requirements. You also need > to take input from other WG. > > JP: > How about MPLS working group for P2MP requirements? > > George: > Not quite there yet for P2MP; getting the base thing done so can't > specify PCE requirements yet. Doing the unicast case is a good start. > > Adrian: > Not an attempt to force other WGs to do significant work or to > deliver requirements. Rather a statement that PCE does not develop > requirements. > > Dimitri: > Previous MPLS work was on signalling/routing protocols, not behaviors. > PCE work should still not be about behaviors even though computational > complexity is increasing. > > Kireeti: > One of the things in the charter I read was mp2mp LSPs. This makes me > shiver. > > Adrian: > That was an early version of the charter. It's gone now. > > JP: > Submit requirements draft. > We need to start with requirements. > > Submit draft describing the PCE arch > Try to flesh out PCE architecture I-D. Need to define more precisely > to explain what we mean by distributed computation. > > Submit draft specifying communications protocol requirements between > PCC and PCe and PCEs. > > Submit draft of a SINGLE communication protocol for use between a PCC > and a PCE and between PCEs. > > Submit an applicability draft > Nice to have an applicability draft describing the processes and > procedures for the use of the PCE architecture, protocols and protocol > extensions. > > Kireeti: > Do we need a MIB? > > Adrian: > If we have a protocol, we must have a MIB. Not immediately obvious > that we need one, but that's the rules. > > Kireeti: > Agree that we need management, I'm just wondering if we need a MIB. > > Adrian: > Until the IESG changes the rules, we need a MIB. > > Richard Rabbat: > Does this include Load balancing between PCEs? > > JP: > MPLS PCE Load balancing draft has been created already, need to have > GMPLS extensions > > Richard: > Doesn't this mean that PCE needs to provide information on its > Computation power, etc? Does that cause confidentiality problem? > > JP: > There are ways around this... > > Kireeti: > We should walk before we run, but I would like to see in the charter > the use of PCE for Optical VPNs. > > Alex: > This is the 2nd BOF. We don't normally have more than 2 BOFs. > You need to take into consideration whether there is enough interest > in this work and whether we have a good idea, whether we have good > candidates for this work. > > Are there any questions on the key questions? > There are two questions: > Is there a need for a WG? Who believes the WG should be chartered? > Many hands raised > Are there any people that don't believe there is a need for a WG? > No hands raised > > Hmm. Not all hands raised for those two questions. Who isn't thinking? > Some hands > > Ok. Seems to be consensus in the room. > > I will take it to the IESG for consideration and we will work on the > proposed BOF charter > > Keep discussion going on PCE mailing list. > Find the mailing list for PCE on the routing area web pages. > All discussions on PCE will happen on that list. > > Thanks for coming > > JP: > Thanks. > > > _______________________________________________ > 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