From pce-bounces@lists.ietf.org Fri Dec 01 12:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCAY-0004r0-QR; Fri, 01 Dec 2006 12:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCAY-0004q5-0x; Fri, 01 Dec 2006 12:27:26 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCAS-0007y8-Ov; Fri, 01 Dec 2006 12:27:26 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GqCAU-0001K0-00; Fri, 01 Dec 2006 17:27:22 +0000 Received: from your029b8cecfe ([194.54.8.87] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 17:27:04 +0000 Message-ID: <006001c7156d$e6f47ef0$3800a8c0@your029b8cecfe> From: "Adrian Farrel" To: , , Date: Fri, 1 Dec 2006 17:26:44 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 01 Dec 2006 17:27:04.0495 (UTC) FILETIME=[EB32EBF0:01C7156D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Lucent/Alcatel changes in email addresses X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, If your email address is changing, don't forget to update your subscription to the mailing lists. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Dec 05 07:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZSO-0003OV-Jg; Tue, 05 Dec 2006 07:31:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZSO-0003OQ-1q for pce@ietf.org; Tue, 05 Dec 2006 07:31:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZSL-0005gg-Gq for pce@ietf.org; Tue, 05 Dec 2006 07:31:32 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 05 Dec 2006 04:31:27 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB5CVQYF028486; Tue, 5 Dec 2006 07:31:26 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB5CVQYJ018982; Tue, 5 Dec 2006 07:31:26 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 07:31:26 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 07:31:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) References: <1DBE0992-37F6-4306-9CC5-41D200078B8A@cisco.com> Message-Id: <947FB44A-8DE8-499F-BB74-4AF594F9BD4D@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] Feed-back on new WGs documents Date: Tue, 5 Dec 2006 07:31:23 -0500 To: STEPHAN Emile RD-CORE-LAN X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 05 Dec 2006 12:31:25.0685 (UTC) FILETIME=[47B25250:01C71869] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5189; t=1165321886; x=1166185886; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20Feed-back=20on=20new=20WGs=20documents |Sender:=20 |To:=20STEPHAN=20Emile=20RD-CORE-LAN=20; bh=SfFOiuH9hhxMyk2yDb7ZRwZMPb9kDEeLzYLXy5Xeolo=; b=kMJC7LIm4F7KqRxcUB5QxeGrtPvt9x60Sa2Evxu6uHQKDvZNZ7Vtsb9mm7IPZDEY11lz3bWv q7Q+F4RGFwlD2ZBze7KeAOzukKB7D3iH+MeVBJD3o91HB2olqfQpD2B4; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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="===============0391823105==" Errors-To: pce-bounces@lists.ietf.org --===============0391823105== Content-Type: multipart/alternative; boundary=Apple-Mail-20-183606603 --Apple-Mail-20-183606603 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed There's a relatively light support of these drafts but no opposition and we clearly need MIBs for PCE discovery. Emile, could you re-publish both I-Ds as WG documents? Furthermore, I would suggest you to pool the WG on the various related items that were discussed in San diego for which you asked for WG feed-back. Thanks. JP and Adrian. Begin forwarded message: > From: JP Vasseur > Date: November 22, 2006 10:01:18 AM EST > To: pce@ietf.org > Subject: [Pce] Feed-back on new WGs documents > > Dear WG, > > Could you provide us your feed-back on adopting the two following > IDs as a WG documents ? > > draft-stephan-pce-tc-mib-00 - Definitions of Textual Conventions > for Path Computation Element > > draft-stephan-pce-disc-mib-00 - Definitions of Managed Objects for > Path Computation Element Discovery Protoocl > > Note that other MIB-related IDs are expected (e.g. PCEP, ...). > > JP and Adrian. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-20-183606603 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 There's a relatively light = support of these drafts but no opposition and we clearly need MIBs for = PCE discovery.
Emile, could you re-publish both I-Ds as WG = documents?
Furthermore, I would suggest you to pool the WG on = the various related items that were discussed in San diego for which you = asked for WG feed-back.

Thanks.

JP and = Adrian.

Begin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 22, 2006 10:01:18 AM EST
Subject: = [Pce] Feed-back on new WGs documents

Dear WG,

Could you provide us your feed-back on adopting the two following = IDs as a WG documents ?

draft-stephan-pce-tc-mib-00 -=A0Definitions of Textual = Conventions for Path Computation Element

draft-stephan-pce-disc-mib-00 -=A0Definitions of = Managed Objects for Path Computation Element Discovery Protoocl

Note that other MIB-related = IDs are expected (e.g. PCEP, ...).

JP and Adrian.

Pce mailing list
=

= --Apple-Mail-20-183606603-- --===============0391823105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0391823105==-- From pce-bounces@lists.ietf.org Thu Dec 07 13:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOAW-0003WK-AQ; Thu, 07 Dec 2006 13:40:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOAV-0003Vg-GI for pce@ietf.org; Thu, 07 Dec 2006 13:40:27 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsO7B-00082v-TL for pce@ietf.org; Thu, 07 Dec 2006 13:37:09 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GsO78-0007qx-00 for pce@ietf.org; Thu, 07 Dec 2006 18:36:58 +0000 Received: from your029b8cecfe ([217.158.132.34] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 18:36:33 +0000 Message-ID: <019b01c71a2e$8a59d7b0$4302010a@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 7 Dec 2006 18:30:31 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Dec 2006 18:36:36.0633 (UTC) FILETIME=[A0772890:01C71A2E] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Pce] Communicaiton from the OIF - 7/12/06 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We have received a communication from the OIF regarding their Carrier Working Group Requirements Document for Multi Domain Intelligent Optical Networks. The communication and the current requirement document can be found on the CCAMP (sic) alternative Web pages at www.olddog.co.uk/ccamp.htm. The text of the covering letter can be seen below. The OIF do not specifically ask us to perform any actions, but I am sure they would welcome any review comments that you might have. These can be sent direct or sent to the mailing list in which case JP and I will send a response. Thanks, Adrian === December 6, 2006 To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs J.P. Vasseur and Adrian Farrel, IETF PCE WG Co-Chairs From: Jim Jones, OIF TC Chair Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors Subject: OIF liaison letter regarding Carrier WG Requirements Document Dear Adrian, J.P. and Deborah, The OIF Carrier WG is in the process of updating the carrier requirements document related to control plane for intelligent optcal networks. The attached draft document represents an update to two previous requirements documents, focused on specific interfaces (i.e., UNI and E-NNI, respectively). Sincerely yours, Jim Jones OIF, Technical Committee Chair cc: Lyndon Ong, Richard Bradford, Hans-Martin Foisel Attachments: oif2006.134.02 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Dec 08 09:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsgbk-0000Bp-BZ; Fri, 08 Dec 2006 09:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsgbj-0000Bf-6u for pce@ietf.org; Fri, 08 Dec 2006 09:21:47 -0500 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsgbg-0000wE-G2 for pce@ietf.org; Fri, 08 Dec 2006 09:21:47 -0500 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Dec 2006 19:51:40 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Dec 2006 19:51:40 +0530 Message-ID: <434F1CE611459F45BBC351FEB5A83F4302B05901@kavithai.ctd.hcltech.com> From: "Vijayanand C - TLS, Chennai." To: Date: Fri, 8 Dec 2006 19:51:39 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C71AD4.2D108383" X-OriginalArrivalTime: 08 Dec 2006 14:21:40.0184 (UTC) FILETIME=[2D7C0580:01C71AD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Somen Bhattacharya Subject: [Pce] FW: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-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: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_000_01C71AD4.2D108383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hello all, Please send in your comments/suggestion on the following I-D Regards Vijay -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, December 01, 2006 9:20 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE=20 Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-00.txt Pages : 26 Date : 2006-12-1 =09 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of FA-LSPs to be traversed in each AS. The=20 method described here uses BGP running in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the FA-LSPs in=20 each AS to its neighbors to facilitate the construction of an inter- AS topology graph which can be used for computing inter-AS paths.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te-= pat h-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-vijay-somen-pce-bgp-interas-te-path-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vijay-somen-pce-bgp-interas-te-path-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_000_01C71AD4.2D108383 Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 To: Subject: Date: Fri, 1 Dec 2006 21:22:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C71AD4.2D108383" ------_=_NextPart_002_01C71AD4.2D108383 Content-Type: text/plain ------_=_NextPart_002_01C71AD4.2D108383 Content-Type: application/octet-stream; name="ATT55875" Content-Disposition: attachment; filename="ATT55875" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-1084111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-somen-pce-bgp-interas-te-path-00.txt ------_=_NextPart_002_01C71AD4.2D108383 Content-Type: message/external-body; site="internet-drafts"; dir="draft-vijay-somen-pce-bgp-interas-te-path-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C71AD4.2D108383-- ------_=_NextPart_000_01C71AD4.2D108383 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="ATT558760.txt" Content-Disposition: attachment; filename="ATT558760.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C71AD4.2D108383 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_000_01C71AD4.2D108383-- From pce-bounces@lists.ietf.org Fri Dec 08 12:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsj5r-0006ar-Uh; Fri, 08 Dec 2006 12:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsj5q-0006am-Sf for pce@ietf.org; Fri, 08 Dec 2006 12:01:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsj5o-0002jM-Ae for pce@ietf.org; Fri, 08 Dec 2006 12:01:02 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2006 09:00:57 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kB8H0vbl003844 for ; Fri, 8 Dec 2006 09:00:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB8H0ndY020346 for ; Fri, 8 Dec 2006 09:00:57 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 12:00:55 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 12:00:55 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: <26774B45-13E1-4902-A970-021BF0E86CF4@cisco.com> From: JP Vasseur Date: Fri, 8 Dec 2006 12:00:53 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Dec 2006 17:00:55.0505 (UTC) FILETIME=[6CE64C10:01C71AEA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5971; t=1165597257; x=1166461257; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20WG=20LC=20on=20draft-ietf-pce-pcecp-interarea-reqs-04.txt=20e nded. |Sender:=20; bh=UbU9gL0R74czPx5v+Jdzl5sFHFt5ab+txhG0N86Y/ig=; b=ky5YhJSpCivxz4TfKeQDDTbYJTvUCso9WvRu/Df/tiksMH4W/m6V97LU/iGeRVURIeBUN9/B a+cKjvj6841GE3hva2WAJnigZhfI6SpydXDToah4G+yRbvnLVoe1ZvV7; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Subject: [Pce] WG LC on draft-ietf-pce-pcecp-interarea-reqs-04.txt ended. X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954402002==" Errors-To: pce-bounces@lists.ietf.org --===============1954402002== Content-Type: multipart/alternative; boundary=Apple-Mail-57-458976355 --Apple-Mail-57-458976355 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, The WG LC on draft-ietf-pce-pcecp-interarea-reqs-04.txt has now ended with comments received by Dimitri. Authors, could you address those comments ? Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: November 22, 2006 9:51:47 AM EST > To: pce@ietf.org > Subject: [Pce] Working Group Last Call on draft-ietf-pce-pcecp- > interarea-reqs-04.txt > > Dear WG, > > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev -04) has > been posted that addresses the remaining issues/comments. > > This email initiates a Working Group Last Call on draft-ietf-pce- > pcecp-interarea-reqs-04.txt. The last call will end on December 8th > at noon EST. > > Please send your comments to the mailing list. > > Thanks. > > JP. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-57-458976355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

The WG LC = on=A0draft-ietf-pce-pcecp-interarea-reqs-04.txt has now ended with = comments received by Dimitri. Authors, could you address those comments = ?

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 22, 2006 9:51:47 AM EST
Subject: = [Pce] Working Group Last Call on = draft-ietf-pce-pcecp-interarea-reqs-04.txt=A0

Dear = WG,

A new revision of = draft-ietf-pce-pcecp-interarea-reqs (rev -04) has been posted that = addresses the remaining issues/comments.

This email = initiates a Working Group Last Call on = draft-ietf-pce-pcecp-interarea-reqs-04.txt. The last call will end on = December 8th at noon EST.

Please send your comments to the = mailing list.

Thanks.

JP.


Pce mailing list
=

= --Apple-Mail-57-458976355-- --===============1954402002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1954402002==-- From pce-bounces@lists.ietf.org Fri Dec 08 18:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsoh7-0001dl-4o; Fri, 08 Dec 2006 17:59:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsoh5-0001cR-IX for pce@ietf.org; Fri, 08 Dec 2006 17:59:51 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsogt-0006N9-Gz for pce@ietf.org; Fri, 08 Dec 2006 17:59:51 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Gsoga-0003z3-00 for pce@ietf.org; Fri, 08 Dec 2006 22:59:20 +0000 Received: from your029b8cecfe ([85.210.173.86] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 22:59:23 +0000 Message-ID: <012b01c71b1c$7d296e90$47849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 8 Dec 2006 22:55:02 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 Dec 2006 22:59:24.0084 (UTC) FILETIME=[8102FF40:01C71B1C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Pce] Fw: I-D ACTION:draft-farrel-pce-manageability-requirements-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, This version includes updates to address comments made in San Diego mainly by Lou and Ops ADs. I'll ask JP to arbitrate and handle whether this becomes a WG I-D. Adrian ----- Original Message ----- From: To: Sent: Friday, December 08, 2006 8:50 PM Subject: I-D ACTION:draft-farrel-pce-manageability-requirements-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Requirements for Manageability Sections in PCE Working Group > Drafts > Author(s) : A. Farrel > Filename : draft-farrel-pce-manageability-requirements-02.txt > Pages : 8 > Date : 2006-12-8 > > It has often been the case that manageability considerations have > been retrofitted to protocols. This is sub-optimal. > > Similarly, new protocols or protocol extensions are frequently > designed without due consideration of manageability requirements. > > This document specifies the requirement for all new Internet-Drafts > in the PCE Working Group to include a "Manageability Considerations" > section, and gives guidance on what that section should contain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-pce-manageability-requirements-02.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Dec 11 15:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6B-0000Uf-Tr; Mon, 11 Dec 2006 15:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts65-0000R8-V1; Mon, 11 Dec 2006 15:50:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gts65-0004XU-L8; Mon, 11 Dec 2006 15:50:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 993D232982; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hX-F4; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-tc-mib-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: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Textual Conventions for Path Computation Element Author(s) : E. Stephan Filename : draft-ietf-pce-tc-mib-00.txt Pages : 7 Date : 2006-12-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-tc-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-tc-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-tc-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11133807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-tc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-tc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11133807.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Dec 11 15:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6B-0000Ua-Lu; Mon, 11 Dec 2006 15:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts65-0000RF-V2; Mon, 11 Dec 2006 15:50:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gts65-0004XT-KV; Mon, 11 Dec 2006 15:50:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 93E373297D; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hR-Dg; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disc-mib-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: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Managed Objects for Path Computation Element Discovery Author(s) : E. Stephan Filename : draft-ietf-pce-disc-mib-00.txt Pages : 23 Date : 2006-12-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disc-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disc-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disc-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11133411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11133411.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Dec 11 15:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6t-0001TJ-MT; Mon, 11 Dec 2006 15:50:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0000sm-UQ; Mon, 11 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0006AY-Cs; Mon, 11 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DAF2E175DB; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hO-D7; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disc-mib-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: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Managed Objects for Path Computation Element Discovery Author(s) : E. Stephan Filename : draft-ietf-pce-disc-mib-00.txt Pages : 23 Date : 2006-12-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disc-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disc-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disc-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11133344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11133344.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Mon Dec 11 15:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts73-0001kK-Bs; Mon, 11 Dec 2006 15:51:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6b-0000sw-2f; Mon, 11 Dec 2006 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0006Ab-DT; Mon, 11 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DE109175DD; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hU-EN; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-tc-mib-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: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Definitions of Textual Conventions for Path Computation Element Author(s) : E. Stephan Filename : draft-ietf-pce-tc-mib-00.txt Pages : 7 Date : 2006-12-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-tc-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-tc-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-tc-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11133738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-tc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-tc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11133738.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Dec 12 15:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDtG-0002na-VI; Tue, 12 Dec 2006 15:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDp4-0001NX-Vp for pce@ietf.org; Tue, 12 Dec 2006 15:01:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDp2-0003KX-I5 for pce@ietf.org; Tue, 12 Dec 2006 15:01:54 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 12 Dec 2006 12:01:52 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBCK1ppw011355; Tue, 12 Dec 2006 12:01:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBCK1pin004989; Tue, 12 Dec 2006 12:01:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:01:51 -0800 Received: from kkoushikwxp ([64.101.185.54]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:01:51 -0800 Message-ID: <029301c71e28$5d04f6c0$80d1520a@apac.cisco.com> From: "A S Kiran Koushik" To: "STEPHAN Emile RD-CORE-LAN" , , References: Date: Tue, 12 Dec 2006 14:01:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 12 Dec 2006 20:01:51.0215 (UTC) FILETIME=[5D0F2FF0:01C71E28] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7506; t=1165953711; x=1166817711; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkoushik@cisco.com; z=From:=20=22A=20S=20Kiran=20Koushik=22=20 |Subject:=20Re=3A=20=20PCE=20MIB=20modules |Sender:=20; bh=n1NMlgFRW5P23cb8msfjnk7Wik2IHz82kCk7m/yb53I=; b=ORB3RNBK0gzMPmYOjbHcHnqBLzM1Xy+PYR8HMXQhpIRWapYKZjtfbj/2zXn82RcnqmkYdwtd Ow70eD8/ziIHN1INfoE1BFWW5NwHEOoXYP3FQZVmESkA0ZVXBhVdEfGX; Authentication-Results: sj-dkim-4; header.From=kkoushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae X-Mailman-Approved-At: Tue, 12 Dec 2006 15:06:13 -0500 Cc: pce@ietf.org Subject: [Pce] Re: PCE MIB modules X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Emile, Thanks for this message. I have gone through this thread and the existing MIBs. I have listed my comments/observations below: 1. In general, we do not include "STD" for a draft MIB. Only when they are about to become RFC, we call them STD. Before becoming an RFC we have "DRAFT" for the MIBs. This way if some companies want to implement the draft versions and later want to upgrade to standard versions do not have a name clash with the OIDs. 2. I agree with most of your decomposition. However, I want to propose : PCEP-DRAFT-MIB draft-ietf-pcep-mib instead of PCE-COMP-STD-MIB draft-ietf-pce-comp-mib This will give a clear idea to the user on what the MIB contains. So the new decomposition looks like: MIB module WG draft name ================================================ PCE-DISC-DRAFT-MIB draft-ietf-pce-disc-mib -- PCE discovery MIB. PCEP-DRAFT-MIB draft-ietf-pcep-mib -- PCE communication protocol MIB PCE-PCC-DRAFT-MIB draft-ietf-pce-pcc-mib -- Path Computation Client MIB PCE-TC-DRAFT-MIB draft-ietf-pce-tc-mib -- PCE Textual conventions MIB. 3. I see that the SMIv2 structures of the existing MIB modules need to be fixed and SMIC utility must be run. I can take care of that. 4. I will also start working on the PCEP-MIB for which you will be my co-author. Please let me know if you have any more comments/observations? I intend to start working on these soon. Regards, Kiran. ----- Original Message ----- From: "STEPHAN Emile RD-CORE-LAN" To: ; "A S Kiran Koushik" ; Cc: "LE ROUX Jean-Louis RD-CORE-LAN" Sent: Wednesday, November 29, 2006 10:46 AM Subject: PCE MIB modules Hi Kiran, Adrian and JP I am really happy that Kiran join us. I am sure that we are going to do excellent works together... and that there is enough work for 2 people. So let's start. In July we identify the following MIB modules decomposition. MIB module WG draft name ================================================ PCE-DISC-STD-MIB draft-ietf-pce-disc-mib PCE-COMP-STD-MIB draft-ietf-pce-comp-mib PCE-PCC-STD-MIB draft-ietf-pce-pcc-mib PCE-TC-STD-MIB draft-ietf-pce-tc-mib draft-ietf-pce-disc-mib and draft-ietf-pce-tc-mib are already in progress. As JP spoke recently of a "PCEP MIB", I want to be sure that we still agree on this decomposition? Then I propose to draft the abstract of each document conjointly with the chairs. Finally, I think that we may identify the drafts and the sections giving directions to write each MIB module. At this point, each of us will share the minimal understanding before writing any SMI line. Regards Emile -----Message d'origine----- De: Adrian Farrel [mailto:adrian@olddog.co.uk] Envoy: vendredi 28 juillet 2006 14:08 : STEPHAN Emile RD-CORE-LAN Cc: LE ROUX Jean-Louis RD-CORE-LAN; jpv@cisco.com Objet: Re: PCE MIB modules names Good work. Thanks. Adrian ----- Original Message ----- From: "STEPHAN Emile RD-CORE-LAN" To: Cc: "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Friday, July 28, 2006 11:02 AM Subject: RE: PCE MIB modules names Hi Adrian, I think we got it: MIB module WG draft name ================================================ PCE-DISC-STD-MIB draft-ietf-pce-disc-mib PCE-COMP-STD-MIB draft-ietf-pce-comp-mib PCE-PCC-STD-MIB draft-ietf-pce-pcc-mib PCE-TC-STD-MIB draft-ietf-pce-tc-mib According to that I will firstly review and rename my current draft as draft-stephan-pce-disc-mib-00.txt. Then I will create draft-stephan-pce-tc-mib-00.txt. Finally I will post both of them. Regards Emile > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy : mercredi 26 juillet 2006 18:04 > : STEPHAN Emile RD-CORE-LAN; jpv@cisco.com > Cc : LE ROUX Jean-Louis RD-CORE-LAN > Objet : Re: PCE MIB modules names > > Hi Emile, > > > During the meeting we decided to move the TCs defined in > > draft-stephan-pcc-pcedp-mib-01.txt in a dedicated MIB > > module to permit them to be shared by any (PCE) MIB > > modules; > > Yes please. > > > Prior to do that I would like to determine the names of > > the PCE MIB modules and the name of the corresponding > > drafts. The aim is to avoid collisions in the names of the > > MIB modules and drafts, renaming, misunderstanding... > > and annoying discussions in the ML for people not > > interested by MIB aspects. > > This is very sensible, to avoid the collisions and any thrashing. > > It is not so important to avoid the mailing list. I agree that not many > people are interetsed in MIB modules, but it is important to make sure > that > those who might be interested feel that there is a discussion going on > that > they can contribute to. Also, it is nice to show some interactions about > the > I-D becuase it helps to build evidence of support for the work. > > > I identify 3 potential modules plus the TC one: > >1- A module to monitor from within a PCC (a PCE may > > includes a PCC), the PCEs discovered by this PCC or > > PCE (the intend of pcc-pcedp-mib); > > Right. So this controls and monitors the discovery process, and reports on > discovered PCEs. > Presumably it also allows you to configure the location and capabilities > of > remote PCEs. > > > 2- A module to monitor from within a PCE, path > > computation activities of this PCE; > > Yes. I assume this includes the PCEP activities. > > > 3- A module to monitor from within a PCC (a > > PCE may includes a PCC), path computation > > requested by this PCC or PCE; > > Yes. > > > I propose the 4 following names: > > > > MIB module WG draft name > > ======================================== > > PCC-PCEDP-MIB draft-ietf-pce-pcc-pcedp-mib > > PCE-PATHCOMP-MIB draft-ietf-pce-pce-pathcomp-mib > > PCC-PATHCOMP-MIB draft-ietf-pce-pcc-pathcomp-mib > > PCE-TC-MIB draft-ietf-pce-tc-mib > > Now, I have always had some trouble understanding how MIB modules are > supposed to be named, but from experience, it seems that we need... > > xxx-yyy-STD-MIB > > ...where > > xxx is the field of applicability (e.g. MPLS, GMPLS, PCE, etc.) > yyy is the thing being modeled. > STD means "standard" > > So this would give us: > > PCE-DISC-STD-MIB > PCE-COMP-STD-MIB > PCE-PCC-STD-MIB > PCE-TC-STD-MIB > > The document names are fine as you feel appropriate. > > Note that you are allowed to put multiple MIB modules in the same I-D, but > actually four documents is probably easier for everyone. > > > The intent of the proposal above is only to start the discussion. > > Yes. And I very much appreciate it. Thanks for driving this. > > > We may use shorter names like in ccamp or mpls WG. > > What about PCC-DP-MIB, PCE-PC-MIB PCC-PC-MIB > > and PCE-TC-MIB? > > My suggestions, above, are to keep the names looking a little less the > same! > > Alternatives for the middle two of PCE-PCE-STD-MIB and PCE-PCC-STD-MIB > just > looked too confusing! > > Cheers, > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Dec 12 15:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEaf-0006RF-5k; Tue, 12 Dec 2006 15:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEab-0006PG-Gm; Tue, 12 Dec 2006 15:51:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuEab-0005IA-97; Tue, 12 Dec 2006 15:51:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3DDEF32B2C; Tue, 12 Dec 2006 20:51:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuEaX-00088f-KT; Tue, 12 Dec 2006 15:50:58 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Dec 2006 15:50:57 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-isis-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : IS-IS protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-isis-01.txt Pages : 22 Date : 2006-12-12 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information that can be used for PCE selection. When the PCE is a Label Switch Router (LSR) participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery consists of relying on IGP flooding. For that purpose this document defines IS-IS extensions for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-isis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-12142820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-isis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-isis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-12142820.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Tue Dec 12 15:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEbI-0007HZ-Lm; Tue, 12 Dec 2006 15:51:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEbF-0007Ft-Rv; Tue, 12 Dec 2006 15:51:41 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuEbF-00026s-Hc; Tue, 12 Dec 2006 15:51:41 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 755F42ACD8; Tue, 12 Dec 2006 20:51:11 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuEab-00089B-4a; Tue, 12 Dec 2006 15:51:05 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Dec 2006 15:51:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-01.txt Pages : 25 Date : 2006-12-12 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information that can be used for PCE selection. When the PCE is a Label Switch Router (LSR) participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery consists of relying on IGP flooding. For that purpose this document defines OSPF extensions for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-disco-proto-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-12143214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-ospf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-12143214.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Dec 13 02:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuOk7-0002JQ-E7; Wed, 13 Dec 2006 02:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuOk5-0002Ip-VS for pce@ietf.org; Wed, 13 Dec 2006 02:41:29 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuOk4-000841-HA for pce@ietf.org; Wed, 13 Dec 2006 02:41:29 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 08:40:47 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-01.txt & draft-ietf-pce-disco-proto-isis-01.txt Date: Wed, 13 Dec 2006 08:41:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-01.txt & draft-ietf-pce-disco-proto-isis-01.txt Thread-Index: AcceL1mCAvvTSo/DTjCGPvHyOP/7DQAWilSQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 13 Dec 2006 07:40:47.0625 (UTC) FILETIME=[011B8790:01C71E8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi all, Here are the minor changes in these new revisions (ISIS and OSPF): -The security section has been detailed -Added considerations on hierarchical TLVs -Identification of PCED and PCES: the same IP address must be used -A few minor edits for the sake of clarity Regards, JL -----Message d'origine----- De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Envoy=E9 : mardi 12 d=E9cembre 2006 21:51 =C0 : i-d-announce@ietf.org Cc : pce@ietf.org Objet : [Pce] I-D ACTION:draft-ietf-pce-disco-proto-ospf-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Path Computation Element Working Group = of the IETF. Title : OSPF protocol extensions for Path Computation Element (PCE) = Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-ospf-01.txt Pages : 25 Date : 2006-12-12 =09 There are various circumstances where it is highly desirable for a=20 Path Computation Client (PCC) to be able to dynamically and=20 automatically discover a set of Path Computation Element(s) (PCE),=20 along with some of information that can be used for PCE selection. When the PCE is a Label Switch Router (LSR) participating to the IGP, = or even a server participating passively to the IGP, a simple and=20 efficient way for PCE discovery consists of relying on IGP flooding.=20 For that purpose this document defines OSPF extensions for the=20 advertisement of PCE Discovery information within an OSPF area or=20 within the entire OSPF routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-01.tx= t To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get = draft-ietf-pce-disco-proto-ospf-01.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-disco-proto-ospf-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Dec 13 15:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub4y-0001ms-6L; Wed, 13 Dec 2006 15:51:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub4t-0001ht-Ux; Wed, 13 Dec 2006 15:51:48 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gub4t-0006PE-LV; Wed, 13 Dec 2006 15:51:47 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5E53B175AC; Wed, 13 Dec 2006 20:51:17 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gub4L-0006BB-W8; Wed, 13 Dec 2006 15:51:15 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Dec 2006 15:51:13 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-04.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Author(s) : J. Le Roux, J. Vasseur Filename : draft-ietf-pce-pcep-04.txt Pages : 66 Date : 2006-12-13 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-13143919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-13143919.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Dec 15 13:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvHou-0002Dr-D0; Fri, 15 Dec 2006 13:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvHot-0002Dl-E2 for pce@ietf.org; Fri, 15 Dec 2006 13:30:07 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvHor-0005wG-TB for pce@ietf.org; Fri, 15 Dec 2006 13:30:07 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 19:29:58 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Date: Fri, 15 Dec 2006 19:29:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Thread-Index: AccTkYKMEnXoectMTzCCx/0FkWGAtwM1ot6Q From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "JP Vasseur" X-OriginalArrivalTime: 15 Dec 2006 18:29:58.0425 (UTC) FILETIME=[066B7090:01C72077] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Sorry for this late answer. Thanks for your comments. Please see inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : mercredi 29 novembre 2006 09:35 > =C0 : JP Vasseur > Cc : pce@ietf.org > Objet : Re: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 > hi >=20 > comment on this doc. >=20 > 4.5. Inclusion of Area IDs in Request=20 > =20 > The knowledge of the areas in which the source and destination lie=20 > would allow selection of appropriate cooperating PCEs.=20 >=20 > =3D> so is there an assumption that the PCE-Area ID knowledge=20 > is available - how come ? Yes this information can be made available with the discovery protocol, = see [RFC4674] section 4.1.1.2. We can rephrase as follows: "The knowledge of the areas in which the source and destination lie=20 would allow selection of appropriate cooperating PCEs. This would be = useful when the area ID(s) of a PCE (i.e. the area(s) where it has = visibility) is/are known, which can be achieved by the PCE Discovery = Protocol (see [RFC4674]) or any other mean." >=20 > A PCE may not=20 > be able to determine the location of the source and=20 > destination and=20 > in such a case it would be useful that a PCC indicates the=20 > source and=20 > destination area IDs.=20 >=20 > =3D> not sure to see the reasoning - i guess the initial PCE=20 > referred to here is an intermediate PCE that does not have=20 > any visibility of the source/destination areas and=20 > potentially more > - the whole problem in this sentence is the=20 > interpretation of the term - location - OK we can rephrase as follows "A PCE in a PCE chain, may not have any visibility of the = source/destination area and hence may not be able to determine the area = of the source/destination"=20 > =20 > For that purpose the request message MUST support the inclusion of=20 > the source and destination area IDs. Note that this=20 > information could=20 > be learned by the PCC through configuration.=20 > =20 > =3D> how to be sure that the local area PCE is going only to be=20 > contacted by local area PCC's=20 Why do you need such assurance? I don't catch your point here. >- we're entering into a chicken=20 > egg problem, from one side mandate knowledge of=20 > source/destination area We don't mandate knowledge of src/dest area. We say "the request message = MUST support the inclusion", we don't say "MUST include" > but on the other there is no=20 > guarantee about interpretation of this information before=20 > knowing the PCC - area ID relationship Here we simply ask the PCECP to support the inclusion of source and = destination area IDs in the request. When this information is known by the PCC (through configuration or any = other means), then it may be included in the request message, and this = may facilitate selection of downstream PCEs. >=20 >=20 > 4.6. Area Inclusion/Exclusion=20 > =20 > In some situations it may be useful to include one or more=20 > area(s) in=20 > the path.=20 >=20 > =3D> for inter-area it is certainly true that the actual path=20 > will cross multiple areas but i wonder whether what you mean=20 > is not the request includes one or more areas to be followed=20 > by the path to be computed=20 Yes it is, will be reworded as follows. "It may be useful that the request message indicate one or more area(s) = that must be followed by the path to be computed. It may also be useful that the request message indicate one or more = area(s) that must be avoided by the path to be computed." >=20 > It may also be useful to exclude one or more area(s) from=20 > the path (e.g. request for a path between LSRs in two stub areas=20 > connected to the same ABR(s), which must not cross the backbone=20 > area). Hence the request message MUST allow indicating a=20 > set of one=20 > or more area(s) that must be explicitly included in the=20 > path, and a=20 > set of one or more area(s) that must be explicitly=20 > excluded from the=20 > path.=20 >=20 > =3D> be prepared to incorporate a loop avoidance mechanism, in=20 > case the request will have to cross multiple PCEs Yes a loop avoidance mechanism will be needed, independantly of this = area inclusion/exclusion by the way. I don't think this requires any specific text here. >=20 > other comments to follow > - d. OK, see below, > section 4.7 Inter-area Diverse Path computation >=20 > o) wrt 6. Security Considerations "IGP areas are=20 > administrated by the same entity. .." >=20 > does the latter ensure uniqueness of the SRLG IDs ? YES >=20 > o) The response message MUST allow indicating the level of=20 > diversity of=20 > a set of computed loose paths.=20 >=20 > do you mean partial disjointness ? or something equivalent ?=20 This refers to link, node, SRLG diversity of a set of paths. We can add the following "The response message MUST allow indicating the level of diversity of a = set of computed inter-area loose paths (link, node, SRLG diversity), = globally and on a per-area basis (link, node, SRLG diversity of = intra-area path segments).=20 >=20 > o) last sentence =A73 unclear to me wrt to the next sentence -=20 > is it referring to a diversity of a given wrt to a set of=20 > resources but the next sentence refers to the diversity of a=20 > given LSP wrt to a set of other LSPs but also their SRLG set=20 > for inst. ? >=20 It refers to the diversity of a set of paths. I agree that this is not = clear. Will rephrase as follows "It MUST allow indicating the required level of diversity of a set of = inter-area paths (link, node, SRLG diversity), as well as the required = level of diversity of a set of intra-area segments of inter-area = paths(link, node, SRLG diversity) on a per-area basis. Thanks a lot for your comments Dimitri. Let us know if the proposed text is fine with you and we will submit a = new revision. Best Regards, JL >=20 >=20 >=20 >=20 > JP Vasseur > 22/11/2006 15:51 > =20 > To: pce@ietf.org > cc:=20 > Subject: [Pce] Working Group Last Call on=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 >=20 > Dear WG, >=20 > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev=20 > -04) has been posted that addresses the remaining issues/comments. >=20 > This email initiates a Working Group Last Call on=20 > draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call=20 > will end on December 8th at noon EST. >=20 > Please send your comments to the mailing list. >=20 > Thanks. >=20 > JP. >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Dec 15 18:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvMp5-00037v-1v; Fri, 15 Dec 2006 18:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvMp1-000352-Sp; Fri, 15 Dec 2006 18:50:35 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvMp1-0006JW-Hl; Fri, 15 Dec 2006 18:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 630C426E9D; Fri, 15 Dec 2006 23:50:35 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GvMoy-0002oP-4S; Fri, 15 Dec 2006 18:50:34 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Dec 2006 18:50:32 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter- domain Traffic Engineering Label Switched Paths Author(s) : J. Vasseur Filename : draft-ietf-pce-brpc-02.txt Pages : 16 Date : 2006-12-15 The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-brpc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-brpc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-15151956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-brpc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-brpc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-15151956.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Sat Dec 16 16:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvhTh-0002Ee-Sv; Sat, 16 Dec 2006 16:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvhTg-0002EZ-IW for pce@ietf.org; Sat, 16 Dec 2006 16:53:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvhTe-0005kx-9u for pce@ietf.org; Sat, 16 Dec 2006 16:53:56 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2006 13:53:52 -0800 X-IronPort-AV: i="4.12,179,1165219200"; d="scan'208"; a="48793970:sNHT42833912" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBGLrprA017309 for ; Sat, 16 Dec 2006 16:53:51 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBGLrtOd002111 for ; Sat, 16 Dec 2006 16:53:55 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Dec 2006 16:53:51 -0500 Received: from [10.86.104.180] ([10.86.104.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Dec 2006 16:53:51 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Sat, 16 Dec 2006 16:53:50 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Dec 2006 21:53:51.0736 (UTC) FILETIME=[AC744F80:01C7215C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=995; t=1166306031; x=1167170031; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20update=20of=20PCEP=20rev-04=20and=20BRPC=20rev-02 |Sender:=20 |To:=20pce@ietf.org; bh=SmqGsP506mNqWemxnug1iz+AdSGTzujR6aV9P5hXfY4=; b=DwejmZ0z0Vps3NNHCk/cZtn7lO+SQizzK/DTWOiksw2hp4548cbGHhBOvI9cBo38is59M7Hn Q1cfasX+bnIVqd8HEQ6WxX3rdxrMz6VjnUloPXkG//ddeCYss+ZUhHBp; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Pce] update of PCEP rev-04 and BRPC rev-02 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear WG, Just a quick update on this rev-04 of PCEP and rev-02 of the BRPC IDs. In the previous revision of PCEP, in case of unsuccesful path computation, the PCE had the ability to indicate the constraint(s) that could not be satisfied when the path computation failure was due to the inability to find a path satisfying the constraints. But if the cause of path computation failure is non related to the constraints (e.g. PCE unavailable, Unknown destination, ...) there was no way to indicate such failure cause. Thus we simply defined a new optional TLV (32-bit flags) named the NO-PATH-VECTOR TLV carried within the NO-PATH object to support that feature. In the case of the BRPC procedure, one possible cause of path computation failure that falls into this category could be the unavailability of a downstream PCE. Thus, we define a new bit for the NO-PATH-VECTOR TLV in draft- ietf-pce-brpc-02.txt to report such failure case. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Dec 18 04:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwEkK-0004H2-3K; Mon, 18 Dec 2006 04:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwEkJ-0004G1-5W for pce@ietf.org; Mon, 18 Dec 2006 04:25:19 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwEkI-0005wi-Ck for pce@ietf.org; Mon, 18 Dec 2006 04:25:19 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBI9PKmB021261; Mon, 18 Dec 2006 10:25:20 +0100 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Mon, 18 Dec 2006 10:25:12 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/18/2006 10:25:14, Serialize complete at 12/18/2006 10:25:14 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 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: , Errors-To: pce-bounces@lists.ietf.org hi jean-louis see in-line for a couple of clarifications "LE ROUX Jean-Louis RD-CORE-LAN" 15/12/2006 19:29 =20 To: , "JP Vasseur"=20 cc: Subject: RE: [Pce] Working Group Last Callon=20 draft-ietf-pce-pcecp-interarea-reqs-04.txt Hi Dimitri, Sorry for this late answer. Thanks for your comments. Please see inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : mercredi 29 novembre 2006 09:35 > =C0 : JP Vasseur > Cc : pce@ietf.org > Objet : Re: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 > hi >=20 > comment on this doc. >=20 > 4.5. Inclusion of Area IDs in Request=20 >=20 > The knowledge of the areas in which the source and destination lie=20 > would allow selection of appropriate cooperating PCEs.=20 >=20 > =3D> so is there an assumption that the PCE-Area ID knowledge=20 > is available - how come ? Yes this information can be made available with the discovery protocol,=20 see [RFC4674] section 4.1.1.2. We can rephrase as follows: "The knowledge of the areas in which the source and destination lie=20 would allow selection of appropriate cooperating PCEs. This would be=20 useful when the area ID(s) of a PCE (i.e. the area(s) where it has=20 visibility) is/are known, which can be achieved by the PCE Discovery=20 Protocol (see [RFC4674]) or any other mean." >=20 > A PCE may not=20 > be able to determine the location of the source and=20 > destination and=20 > in such a case it would be useful that a PCC indicates the=20 > source and=20 > destination area IDs.=20 >=20 > =3D> not sure to see the reasoning - i guess the initial PCE=20 > referred to here is an intermediate PCE that does not have=20 > any visibility of the source/destination areas and=20 > potentially more > - the whole problem in this sentence is the=20 > interpretation of the term - location - OK we can rephrase as follows "A PCE in a PCE chain, may not have any visibility of the=20 source/destination area and hence may not be able to determine the area=20 of the source/destination"=20 >=20 > For that purpose the request message MUST support the inclusion of=20 > the source and destination area IDs. Note that this=20 > information could=20 > be learned by the PCC through configuration.=20 >=20 > =3D> how to be sure that the local area PCE is going only to be=20 > contacted by local area PCC's=20 Why do you need such assurance? [dp] because the PCC itself may be an area where PCE learning and PCC learning are not identical (PCC knows less than the PCE) I don't catch your point here. [dp] but this can also happen in the other way around, the issue is=20 that this information is provided as helper to the PCE looking at the different cases we've at hand even if this information is provided it does not still guarantee that the "local PCE" will be able to determine the location of the destination and hence the next/downstream PCE >- we're entering into a chicken=20 > egg problem, from one side mandate knowledge of=20 > source/destination area We don't mandate knowledge of src/dest area. We say "the request message=20 MUST support the inclusion", we don't say "MUST include" > but on the other there is no=20 > guarantee about interpretation of this information before=20 > knowing the PCC - area ID relationship Here we simply ask the PCECP to support the inclusion of source and=20 destination area IDs in the request. When this information is known by the PCC (through configuration or any=20 other means), then it may be included in the request message, and this may = facilitate selection of downstream PCEs. >=20 >=20 > 4.6. Area Inclusion/Exclusion=20 >=20 > In some situations it may be useful to include one or more=20 > area(s) in=20 > the path.=20 >=20 > =3D> for inter-area it is certainly true that the actual path=20 > will cross multiple areas but i wonder whether what you mean=20 > is not the request includes one or more areas to be followed=20 > by the path to be computed=20 Yes it is, will be reworded as follows. "It may be useful that the request message indicate one or more area(s)=20 that must be followed by the path to be computed. It may also be useful that the request message indicate one or more=20 area(s) that must be avoided by the path to be computed." >=20 > It may also be useful to exclude one or more area(s) from=20 > the path (e.g. request for a path between LSRs in two stub areas=20 > connected to the same ABR(s), which must not cross the backbone=20 > area). Hence the request message MUST allow indicating a=20 > set of one=20 > or more area(s) that must be explicitly included in the=20 > path, and a=20 > set of one or more area(s) that must be explicitly=20 > excluded from the=20 > path.=20 >=20 > =3D> be prepared to incorporate a loop avoidance mechanism, in=20 > case the request will have to cross multiple PCEs Yes a loop avoidance mechanism will be needed, independantly of this area=20 inclusion/exclusion by the way. I don't think this requires any specific text here. [dp] shouldn't that specific text be included in the document, as it is=20 meant to cover both PCC-PCE and PCE-PCE messaging ? >=20 > other comments to follow > - d. OK, see below, > section 4.7 Inter-area Diverse Path computation >=20 > o) wrt 6. Security Considerations "IGP areas are=20 > administrated by the same entity. .." >=20 > does the latter ensure uniqueness of the SRLG IDs ? YES [dp] in theory yes, in practice not - just think upon the case where a=20 single entity borrows fibers from two different plants each of them having = chosen different SRLG IDs for two fibers lying in the same duct -=20 =20 > o) The response message MUST allow indicating the level of=20 > diversity of=20 > a set of computed loose paths.=20 >=20 > do you mean partial disjointness ? or something equivalent ?=20 This refers to link, node, SRLG diversity of a set of paths. We can add the following "The response message MUST allow indicating the level of diversity of a=20 set of computed inter-area loose paths (link, node, SRLG diversity),=20 globally and on a per-area basis (link, node, SRLG diversity of intra-area = path segments).=20 >=20 > o) last sentence =A73 unclear to me wrt to the next sentence -=20 > is it referring to a diversity of a given wrt to a set of=20 > resources but the next sentence refers to the diversity of a=20 > given LSP wrt to a set of other LSPs but also their SRLG set=20 > for inst. ? >=20 It refers to the diversity of a set of paths. I agree that this is not=20 clear. Will rephrase as follows "It MUST allow indicating the required level of diversity of a set of=20 inter-area paths (link, node, SRLG diversity), as well as the required=20 level of diversity of a set of intra-area segments of inter-area=20 paths(link, node, SRLG diversity) on a per-area basis. Thanks a lot for your comments Dimitri. Let us know if the proposed text is fine with you and we will submit a new = revision. Best Regards, JL >=20 >=20 >=20 >=20 > JP Vasseur > 22/11/2006 15:51 >=20 > To: pce@ietf.org > cc:=20 > Subject: [Pce] Working Group Last Call on=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 >=20 > Dear WG, >=20 > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev=20 > -04) has been posted that addresses the remaining issues/comments. >=20 > This email initiates a Working Group Last Call on=20 > draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call=20 > will end on December 8th at noon EST. >=20 > Please send your comments to the mailing list. >=20 > Thanks. >=20 > JP. >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Dec 18 18:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSDM-0004Qd-Mw; Mon, 18 Dec 2006 18:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSDM-0004QY-9X for pce@ietf.org; Mon, 18 Dec 2006 18:48:12 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwSDL-0006vq-IX for pce@ietf.org; Mon, 18 Dec 2006 18:48:12 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 00:48:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Date: Tue, 19 Dec 2006 00:48:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Thread-Index: AccihnCGsUcgwkl8ROaCjONX/AAW0QAbM/YQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 18 Dec 2006 23:48:06.0083 (UTC) FILETIME=[F6CA2930:01C722FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, Thanks for these clarifications. Please see in-line,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : lundi 18 d=E9cembre 2006 10:25 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Dimitri.Papadimitriou@alcatel-lucent.be; JP Vasseur; pce@ietf.org > Objet : RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 > hi jean-louis >=20 > see in-line for a couple of clarifications >=20 >=20 >=20 >=20 > "LE ROUX Jean-Louis RD-CORE-LAN" > 15/12/2006 19:29 > =20 > To: ,=20 > "JP Vasseur"=20 > > cc: > Subject: RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 >=20 > Hi Dimitri, >=20 > Sorry for this late answer. > Thanks for your comments. >=20 > Please see inline,=20 >=20 > > -----Message d'origine----- > > De : Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Envoy=E9 : mercredi 29 novembre 2006 09:35 =C0 : JP Vasseur Cc :=20 > > pce@ietf.org Objet : Re: [Pce] Working Group Last Callon=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > > hi > >=20 > > comment on this doc. > >=20 > > 4.5. Inclusion of Area IDs in Request > >=20 > > The knowledge of the areas in which the source and=20 > destination lie=20 > > would allow selection of appropriate cooperating PCEs.=20 > >=20 > > =3D> so is there an assumption that the PCE-Area ID knowledge is=20 > > available - how come ? >=20 > Yes this information can be made available with the discovery=20 > protocol, see [RFC4674] section 4.1.1.2. >=20 > We can rephrase as follows: >=20 > "The knowledge of the areas in which the source and=20 > destination lie would allow selection of appropriate=20 > cooperating PCEs. This would be useful when the area ID(s) of=20 > a PCE (i.e. the area(s) where it has > visibility) is/are known, which can be achieved by the PCE=20 > Discovery Protocol (see [RFC4674]) or any other mean." >=20 > >=20 > > A PCE may not=20 > > be able to determine the location of the source and=20 > destination and > > in such a case it would be useful that a PCC indicates=20 > the source=20 > > and > > destination area IDs.=20 > >=20 > > =3D> not sure to see the reasoning - i guess the initial PCE=20 > referred to=20 > > here is an intermediate PCE that does not have any=20 > visibility of the=20 > > source/destination areas and potentially more > > - the whole problem in this sentence is the interpretation=20 > of the term=20 > > - location - >=20 > OK we can rephrase as follows >=20 > "A PCE in a PCE chain, may not have any visibility of the=20 > source/destination area and hence may not be able to=20 > determine the area of the source/destination"=20 >=20 > >=20 > > For that purpose the request message MUST support the=20 > inclusion of=20 > > the source and destination area IDs. Note that this information=20 > > could > > be learned by the PCC through configuration.=20 > >=20 > > =3D> how to be sure that the local area PCE is going only to be=20 > > contacted by local area PCC's >=20 > Why do you need such assurance? >=20 > [dp] because the PCC itself may be an area where PCE learning=20 > and PCC learning are not identical (PCC knows less than the PCE) Again, we don't mandate the inclusion of source/dest area IDs in any = request. In situations where the PCC is aware of this information this may be = useful to include it in the request.=20 >=20 > I don't catch your point here. >=20 > [dp] but this can also happen in the other way around, the=20 > issue is that this information is provided as helper to the=20 > PCE looking at the different cases we've at hand even if this=20 > information is provided it does not still guarantee that the=20 > "local PCE" will be able to determine the location of the=20 > destination and hence the next/downstream PCE If the request includes the destination area, then the PCE becomes aware = of it, it can then select a downstream PCE based on advertised PCE = information (PCE areas). >=20 > >- we're entering into a chicken > > egg problem, from one side mandate knowledge of source/destination=20 > >area >=20 > We don't mandate knowledge of src/dest area. We say "the=20 > request message MUST support the inclusion", we don't say=20 > "MUST include" >=20 > > but on the other there is no > > guarantee about interpretation of this information before=20 > knowing the=20 > > PCC - area ID relationship >=20 >=20 > Here we simply ask the PCECP to support the inclusion of source and=20 > destination area IDs in the request. > When this information is known by the PCC (through=20 > configuration or any=20 > other means), then it may be included in the request message,=20 > and this may=20 > facilitate selection of downstream PCEs. >=20 >=20 > >=20 > >=20 > > 4.6. Area Inclusion/Exclusion=20 > >=20 > > In some situations it may be useful to include one or more=20 > > area(s) in=20 > > the path.=20 > >=20 > > =3D> for inter-area it is certainly true that the actual path=20 > > will cross multiple areas but i wonder whether what you mean=20 > > is not the request includes one or more areas to be followed=20 > > by the path to be computed=20 >=20 > Yes it is, will be reworded as follows. >=20 > "It may be useful that the request message indicate one or=20 > more area(s)=20 > that must be followed by the path to be computed. > It may also be useful that the request message indicate one or more=20 > area(s) that must be avoided by the path to be computed." >=20 > >=20 > > It may also be useful to exclude one or more area(s) from=20 > > the path (e.g. request for a path between LSRs in two stub areas=20 > > connected to the same ABR(s), which must not cross the backbone=20 > > area). Hence the request message MUST allow indicating a=20 > > set of one=20 > > or more area(s) that must be explicitly included in the=20 > > path, and a=20 > > set of one or more area(s) that must be explicitly=20 > > excluded from the=20 > > path.=20 > >=20 > > =3D> be prepared to incorporate a loop avoidance mechanism, in=20 > > case the request will have to cross multiple PCEs >=20 > Yes a loop avoidance mechanism will be needed, independantly=20 > of this area=20 > inclusion/exclusion by the way. > I don't think this requires any specific text here. >=20 > [dp] shouldn't that specific text be included in the=20 > document, as it is=20 > meant to cover both PCC-PCE and PCE-PCE messaging ? OK, we can add the following section 4.9 Loop Avoidance In case of multiple-PCE inter-area path computation there may be risks = of PCECP request loops. A mechanism MUST be defined to detect and supress PCECP request message = loops. This may rely, for instance, on the recording, in the request = message, of the set of traversed PCEs.=20 Also the returned path in a response message MUST be loop free. Would such a section make sense to you? >=20 > >=20 > > other comments to follow > > - d. >=20 > OK, see below, >=20 > > section 4.7 Inter-area Diverse Path computation > >=20 > > o) wrt 6. Security Considerations "IGP areas are=20 > > administrated by the same entity. .." > >=20 > > does the latter ensure uniqueness of the SRLG IDs ? >=20 > YES >=20 > [dp] in theory yes, in practice not - > just think upon the=20 > case where a=20 > single entity borrows fibers from two different plants each=20 > of them having=20 > chosen different SRLG IDs for two fibers lying in the same duct -=20 But when you build SRLGs for an IP network you also account for the = ducts. By the way you can be aware of the duct that is actually used, even if = the fiber is rent (this can be provided in the contract). Anyway, a requirement for SRLG diverse path computation makes the = assumption of consistent SRLGs...and there is nothing specific to the = PCE nor to the inter-area case here. Thanks, JL > =20 > > o) The response message MUST allow indicating the level of=20 > > diversity of=20 > > a set of computed loose paths.=20 > >=20 > > do you mean partial disjointness ? or something equivalent ?=20 >=20 > This refers to link, node, SRLG diversity of a set of paths. >=20 > We can add the following >=20 > "The response message MUST allow indicating the level of=20 > diversity of a=20 > set of computed inter-area loose paths (link, node, SRLG diversity),=20 > globally and on a per-area basis (link, node, SRLG diversity=20 > of intra-area=20 > path segments).=20 >=20 > >=20 > > o) last sentence =A73 unclear to me wrt to the next sentence -=20 > > is it referring to a diversity of a given wrt to a set of=20 > > resources but the next sentence refers to the diversity of a=20 > > given LSP wrt to a set of other LSPs but also their SRLG set=20 > > for inst. ? > >=20 >=20 > It refers to the diversity of a set of paths. I agree that=20 > this is not=20 > clear. >=20 > Will rephrase as follows >=20 > "It MUST allow indicating the required level of diversity of a set of=20 > inter-area paths (link, node, SRLG diversity), as well as the=20 > required=20 > level of diversity of a set of intra-area segments of inter-area=20 > paths(link, node, SRLG diversity) on a per-area basis. >=20 > Thanks a lot for your comments Dimitri. > Let us know if the proposed text is fine with you and we will=20 > submit a new=20 > revision. >=20 > Best Regards, >=20 > JL >=20 >=20 >=20 > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 22/11/2006 15:51 > >=20 > > To: pce@ietf.org > > cc:=20 > > Subject: [Pce] Working Group Last Call on=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > >=20 > > Dear WG, > >=20 > > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev=20 > > -04) has been posted that addresses the remaining issues/comments. > >=20 > > This email initiates a Working Group Last Call on=20 > > draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call=20 > > will end on December 8th at noon EST. > >=20 > > Please send your comments to the mailing list. > >=20 > > Thanks. > >=20 > > JP. > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Dec 21 15:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUCn-0004H3-HJ; Thu, 21 Dec 2006 15:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUCB-0003qX-Vk for pce@ietf.org; Thu, 21 Dec 2006 15:07:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxUAa-0007SH-HI for pce@ietf.org; Thu, 21 Dec 2006 15:05:39 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2006 12:05:30 -0800 X-IronPort-AV: i="4.12,200,1165219200"; d="scan'208"; a="452851722:sNHT327495284" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBLK5UTM008474; Thu, 21 Dec 2006 12:05:30 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBLK5Hnc022903; Thu, 21 Dec 2006 12:05:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 12:05:16 -0800 Received: from kkoushikwxp ([64.101.185.54]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 12:05:16 -0800 Message-ID: <029401c7253b$551e8470$36b96540@apac.cisco.com> From: "A S Kiran Koushik" To: "STEPHAN Emile RD-CORE-LAN" , , Date: Thu, 21 Dec 2006 14:05:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 21 Dec 2006 20:05:16.0664 (UTC) FILETIME=[553BF780:01C7253B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7869; t=1166731530; x=1167595530; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkoushik@cisco.com; z=From:=20=22A=20S=20Kiran=20Koushik=22=20 |Subject:=202nd=20try=20-=20Re=3A=20PCE=20MIB=20modules |Sender:=20; bh=F+u4LI99le1/40c0GmA6tPsoq/PfofOzvQi+SrHVJqQ=; b=rN1sut7QYWDdLUHDX/7xyKK8DYZGRTC1wd55EwMEN+iLQxE+d/7byI05GaRmF2AytOv1vnhN QOYd+LirXi07g9f6yGzj2et0x2yo0PrUEWuAflDIGLTmocZ09WzQJEmP; Authentication-Results: sj-dkim-4; header.From=kkoushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: pce@ietf.org Subject: [Pce] 2nd try - Re: PCE MIB modules X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > Hi Emile/PCE group members, > > Thanks for this message. I have gone through this thread and the existing > MIBs. I have listed my comments/observations below: > > 1. In general, we do not include "STD" for a draft MIB. Only > when they are about to become RFC, we call them STD. > > Before becoming an RFC we have "DRAFT" for the MIBs. > This way if some companies want to implement the draft versions > and later want to upgrade to standard versions do not have a name > clash with the OIDs. > > > 2. I agree with most of your decomposition. > However, I want to propose : > PCEP-DRAFT-MIB draft-ietf-pcep-mib > > instead of > PCE-COMP-STD-MIB draft-ietf-pce-comp-mib > > This will give a clear idea to the user on what the MIB contains. > > So the new decomposition looks like: > MIB module WG draft name > ================================================ > PCE-DISC-DRAFT-MIB draft-ietf-pce-disc-mib > -- PCE discovery MIB. > > PCEP-DRAFT-MIB draft-ietf-pcep-mib > -- PCE communication protocol MIB > > PCE-PCC-DRAFT-MIB draft-ietf-pce-pcc-mib > -- Path Computation Client MIB > > PCE-TC-DRAFT-MIB draft-ietf-pce-tc-mib > -- PCE Textual conventions MIB. > > 3. I see that the SMIv2 structures of the existing MIB modules > need to be fixed and SMIC utility must be run. I can take care of that. > > 4. I will also start working on the PCEP-MIB for which you will > be my co-author. > > Please let me know if you have any more comments/observations? I > intend to start working on these soon. > > Regards, > Kiran. > > ----- Original Message ----- > From: "STEPHAN Emile RD-CORE-LAN" > To: ; "A S Kiran Koushik" ; > > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" > Sent: Wednesday, November 29, 2006 10:46 AM > Subject: PCE MIB modules > > > Hi Kiran, Adrian and JP > > > I am really happy that Kiran join us. I am sure that we are going to do > excellent works together... and that there is enough work for 2 people. > > So let's start. > > In July we identify the following MIB modules decomposition. > > MIB module WG draft name > ================================================ > PCE-DISC-STD-MIB draft-ietf-pce-disc-mib > PCE-COMP-STD-MIB draft-ietf-pce-comp-mib > PCE-PCC-STD-MIB draft-ietf-pce-pcc-mib > PCE-TC-STD-MIB draft-ietf-pce-tc-mib > > draft-ietf-pce-disc-mib and draft-ietf-pce-tc-mib are already in progress. > > As JP spoke recently of a "PCEP MIB", I want to be sure that we still agree on > this decomposition? > > Then I propose to draft the abstract of each document conjointly with the > chairs. > > Finally, I think that we may identify the drafts and the sections giving > directions to write each MIB module. > > At this point, each of us will share the minimal understanding before writing > any SMI line. > > Regards > Emile > > > -----Message d'origine----- > De: Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy: vendredi 28 juillet 2006 14:08 > : STEPHAN Emile RD-CORE-LAN > Cc: LE ROUX Jean-Louis RD-CORE-LAN; jpv@cisco.com > Objet: Re: PCE MIB modules names > > Good work. > > Thanks. > > Adrian > ----- Original Message ----- > From: "STEPHAN Emile RD-CORE-LAN" > To: > Cc: "LE ROUX Jean-Louis RD-CORE-LAN" ; > > Sent: Friday, July 28, 2006 11:02 AM > Subject: RE: PCE MIB modules names > > > Hi Adrian, > > I think we got it: > > MIB module WG draft name > ================================================ > PCE-DISC-STD-MIB draft-ietf-pce-disc-mib > PCE-COMP-STD-MIB draft-ietf-pce-comp-mib > PCE-PCC-STD-MIB draft-ietf-pce-pcc-mib > PCE-TC-STD-MIB draft-ietf-pce-tc-mib > > > According to that I will firstly review and rename my current draft as > draft-stephan-pce-disc-mib-00.txt. Then I will create > draft-stephan-pce-tc-mib-00.txt. Finally I will post both of them. > > Regards > Emile > >> -----Message d'origine----- >> De : Adrian Farrel [mailto:adrian@olddog.co.uk] >> Envoy : mercredi 26 juillet 2006 18:04 >> : STEPHAN Emile RD-CORE-LAN; jpv@cisco.com >> Cc : LE ROUX Jean-Louis RD-CORE-LAN >> Objet : Re: PCE MIB modules names >> >> Hi Emile, >> >> > During the meeting we decided to move the TCs defined in >> > draft-stephan-pcc-pcedp-mib-01.txt in a dedicated MIB >> > module to permit them to be shared by any (PCE) MIB >> > modules; >> >> Yes please. >> >> > Prior to do that I would like to determine the names of >> > the PCE MIB modules and the name of the corresponding >> > drafts. The aim is to avoid collisions in the names of the >> > MIB modules and drafts, renaming, misunderstanding... >> > and annoying discussions in the ML for people not >> > interested by MIB aspects. >> >> This is very sensible, to avoid the collisions and any thrashing. >> >> It is not so important to avoid the mailing list. I agree that not many >> people are interetsed in MIB modules, but it is important to make sure >> that >> those who might be interested feel that there is a discussion going on >> that >> they can contribute to. Also, it is nice to show some interactions about >> the >> I-D becuase it helps to build evidence of support for the work. >> >> > I identify 3 potential modules plus the TC one: >> >1- A module to monitor from within a PCC (a PCE may >> > includes a PCC), the PCEs discovered by this PCC or >> > PCE (the intend of pcc-pcedp-mib); >> >> Right. So this controls and monitors the discovery process, and reports on >> discovered PCEs. >> Presumably it also allows you to configure the location and capabilities >> of >> remote PCEs. >> >> > 2- A module to monitor from within a PCE, path >> > computation activities of this PCE; >> >> Yes. I assume this includes the PCEP activities. >> >> > 3- A module to monitor from within a PCC (a >> > PCE may includes a PCC), path computation >> > requested by this PCC or PCE; >> >> Yes. >> >> > I propose the 4 following names: >> > >> > MIB module WG draft name >> > ======================================== >> > PCC-PCEDP-MIB draft-ietf-pce-pcc-pcedp-mib >> > PCE-PATHCOMP-MIB draft-ietf-pce-pce-pathcomp-mib >> > PCC-PATHCOMP-MIB draft-ietf-pce-pcc-pathcomp-mib >> > PCE-TC-MIB draft-ietf-pce-tc-mib >> >> Now, I have always had some trouble understanding how MIB modules are >> supposed to be named, but from experience, it seems that we need... >> >> xxx-yyy-STD-MIB >> >> ...where >> >> xxx is the field of applicability (e.g. MPLS, GMPLS, PCE, etc.) >> yyy is the thing being modeled. >> STD means "standard" >> >> So this would give us: >> >> PCE-DISC-STD-MIB >> PCE-COMP-STD-MIB >> PCE-PCC-STD-MIB >> PCE-TC-STD-MIB >> >> The document names are fine as you feel appropriate. >> >> Note that you are allowed to put multiple MIB modules in the same I-D, but >> actually four documents is probably easier for everyone. >> >> > The intent of the proposal above is only to start the discussion. >> >> Yes. And I very much appreciate it. Thanks for driving this. >> >> > We may use shorter names like in ccamp or mpls WG. >> > What about PCC-DP-MIB, PCE-PC-MIB PCC-PC-MIB >> > and PCE-TC-MIB? >> >> My suggestions, above, are to keep the names looking a little less the >> same! >> >> Alternatives for the middle two of PCE-PCE-STD-MIB and PCE-PCC-STD-MIB >> just >> looked too confusing! >> >> Cheers, >> Adrian >> >> > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Dec 22 18:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxtcz-0002Qm-4o; Fri, 22 Dec 2006 18:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxtcy-0002QZ-0v for pce@ietf.org; Fri, 22 Dec 2006 18:16:36 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxtcx-0004bR-3H for pce@ietf.org; Fri, 22 Dec 2006 18:16:36 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBMNGd4i005725; Sat, 23 Dec 2006 00:16:39 +0100 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Sat, 23 Dec 2006 00:16:32 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/23/2006 00:16:33, Serialize complete at 12/23/2006 00:16:33 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 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: , Errors-To: pce-bounces@lists.ietf.org hi jean-louis i think we're converging beside one point about section 4.5 & 4.6=20 as indicated here below=20 edit: on the SRLG comment for ensuring some level of consistency=20 identifiers should assigned and allocated from the same entity -=20 this would solve the issue mentioned thanks, - d. "LE ROUX Jean-Louis RD-CORE-LAN" 19/12/2006 00:48 =20 To: cc: pce@ietf.org Subject: RE: [Pce] Working Group Last Callon=20 draft-ietf-pce-pcecp-interarea-reqs-04.txt Hi Dimitri, Thanks for these clarifications. Please see in-line,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : lundi 18 d=E9cembre 2006 10:25 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Dimitri.Papadimitriou@alcatel-lucent.be; JP Vasseur; pce@ietf.org > Objet : RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 > hi jean-louis >=20 > see in-line for a couple of clarifications >=20 >=20 >=20 >=20 > "LE ROUX Jean-Louis RD-CORE-LAN" > 15/12/2006 19:29 >=20 > To: ,=20 > "JP Vasseur"=20 > > cc: > Subject: RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 >=20 > Hi Dimitri, >=20 > Sorry for this late answer. > Thanks for your comments. >=20 > Please see inline,=20 >=20 > > -----Message d'origine----- > > De : Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Envoy=E9 : mercredi 29 novembre 2006 09:35 =C0 : JP Vasseur Cc :=20 > > pce@ietf.org Objet : Re: [Pce] Working Group Last Callon=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > > hi > >=20 > > comment on this doc. > >=20 > > 4.5. Inclusion of Area IDs in Request > >=20 > > The knowledge of the areas in which the source and=20 > destination lie=20 > > would allow selection of appropriate cooperating PCEs.=20 > >=20 > > =3D> so is there an assumption that the PCE-Area ID knowledge is=20 > > available - how come ? >=20 > Yes this information can be made available with the discovery=20 > protocol, see [RFC4674] section 4.1.1.2. >=20 > We can rephrase as follows: >=20 > "The knowledge of the areas in which the source and=20 > destination lie would allow selection of appropriate=20 > cooperating PCEs. This would be useful when the area ID(s) of=20 > a PCE (i.e. the area(s) where it has > visibility) is/are known, which can be achieved by the PCE=20 > Discovery Protocol (see [RFC4674]) or any other mean." >=20 > >=20 > > A PCE may not=20 > > be able to determine the location of the source and=20 > destination and > > in such a case it would be useful that a PCC indicates=20 > the source=20 > > and > > destination area IDs.=20 > >=20 > > =3D> not sure to see the reasoning - i guess the initial PCE=20 > referred to=20 > > here is an intermediate PCE that does not have any=20 > visibility of the=20 > > source/destination areas and potentially more > > - the whole problem in this sentence is the interpretation=20 > of the term=20 > > - location - >=20 > OK we can rephrase as follows >=20 > "A PCE in a PCE chain, may not have any visibility of the=20 > source/destination area and hence may not be able to=20 > determine the area of the source/destination"=20 >=20 > >=20 > > For that purpose the request message MUST support the=20 > inclusion of=20 > > the source and destination area IDs. Note that this information=20 > > could > > be learned by the PCC through configuration.=20 > >=20 > > =3D> how to be sure that the local area PCE is going only to be=20 > > contacted by local area PCC's >=20 > Why do you need such assurance? >=20 > [dp] because the PCC itself may be an area where PCE learning=20 > and PCC learning are not identical (PCC knows less than the PCE) Again, we don't mandate the inclusion of source/dest area IDs in any=20 request. In situations where the PCC is aware of this information this may be=20 useful to include it in the request.=20 >=20 > I don't catch your point here. >=20 > [dp] but this can also happen in the other way around, the=20 > issue is that this information is provided as helper to the=20 > PCE looking at the different cases we've at hand even if this=20 > information is provided it does not still guarantee that the=20 > "local PCE" will be able to determine the location of the=20 > destination and hence the next/downstream PCE If the request includes the destination area, then the PCE becomes aware=20 of it, it can then select a downstream PCE based on advertised PCE=20 information (PCE areas). >=20 > >- we're entering into a chicken > > egg problem, from one side mandate knowledge of source/destination=20 > >area >=20 > We don't mandate knowledge of src/dest area. We say "the=20 > request message MUST support the inclusion", we don't say=20 > "MUST include" >=20 > > but on the other there is no > > guarantee about interpretation of this information before=20 > knowing the=20 > > PCC - area ID relationship >=20 >=20 > Here we simply ask the PCECP to support the inclusion of source and=20 > destination area IDs in the request. > When this information is known by the PCC (through=20 > configuration or any=20 > other means), then it may be included in the request message,=20 > and this may=20 > facilitate selection of downstream PCEs. >=20 >=20 > >=20 > >=20 > > 4.6. Area Inclusion/Exclusion=20 > >=20 > > In some situations it may be useful to include one or more=20 > > area(s) in=20 > > the path.=20 > >=20 > > =3D> for inter-area it is certainly true that the actual path=20 > > will cross multiple areas but i wonder whether what you mean=20 > > is not the request includes one or more areas to be followed=20 > > by the path to be computed=20 >=20 > Yes it is, will be reworded as follows. >=20 > "It may be useful that the request message indicate one or=20 > more area(s)=20 > that must be followed by the path to be computed. > It may also be useful that the request message indicate one or more=20 > area(s) that must be avoided by the path to be computed." >=20 > >=20 > > It may also be useful to exclude one or more area(s) from=20 > > the path (e.g. request for a path between LSRs in two stub areas=20 > > connected to the same ABR(s), which must not cross the backbone=20 > > area). Hence the request message MUST allow indicating a=20 > > set of one=20 > > or more area(s) that must be explicitly included in the=20 > > path, and a=20 > > set of one or more area(s) that must be explicitly=20 > > excluded from the=20 > > path.=20 > >=20 > > =3D> be prepared to incorporate a loop avoidance mechanism, in=20 > > case the request will have to cross multiple PCEs >=20 > Yes a loop avoidance mechanism will be needed, independantly=20 > of this area=20 > inclusion/exclusion by the way. > I don't think this requires any specific text here. >=20 > [dp] shouldn't that specific text be included in the=20 > document, as it is=20 > meant to cover both PCC-PCE and PCE-PCE messaging ? OK, we can add the following section 4.9 Loop Avoidance In case of multiple-PCE inter-area path computation there may be risks of=20 PCECP request loops. A mechanism MUST be defined to detect and supress PCECP request message=20 loops. This may rely, for instance, on the recording, in the request=20 message, of the set of traversed PCEs.=20 Also the returned path in a response message MUST be loop free. Would such a section make sense to you? >=20 > >=20 > > other comments to follow > > - d. >=20 > OK, see below, >=20 > > section 4.7 Inter-area Diverse Path computation > >=20 > > o) wrt 6. Security Considerations "IGP areas are=20 > > administrated by the same entity. .." > >=20 > > does the latter ensure uniqueness of the SRLG IDs ? >=20 > YES >=20 > [dp] in theory yes, in practice not - > just think upon the=20 > case where a=20 > single entity borrows fibers from two different plants each=20 > of them having=20 > chosen different SRLG IDs for two fibers lying in the same duct -=20 But when you build SRLGs for an IP network you also account for the ducts. By the way you can be aware of the duct that is actually used, even if the = fiber is rent (this can be provided in the contract). Anyway, a requirement for SRLG diverse path computation makes the=20 assumption of consistent SRLGs...and there is nothing specific to the PCE=20 nor to the inter-area case here. Thanks, JL >=20 > > o) The response message MUST allow indicating the level of=20 > > diversity of=20 > > a set of computed loose paths.=20 > >=20 > > do you mean partial disjointness ? or something equivalent ?=20 >=20 > This refers to link, node, SRLG diversity of a set of paths. >=20 > We can add the following >=20 > "The response message MUST allow indicating the level of=20 > diversity of a=20 > set of computed inter-area loose paths (link, node, SRLG diversity),=20 > globally and on a per-area basis (link, node, SRLG diversity=20 > of intra-area=20 > path segments).=20 >=20 > >=20 > > o) last sentence =A73 unclear to me wrt to the next sentence -=20 > > is it referring to a diversity of a given wrt to a set of=20 > > resources but the next sentence refers to the diversity of a=20 > > given LSP wrt to a set of other LSPs but also their SRLG set=20 > > for inst. ? > >=20 >=20 > It refers to the diversity of a set of paths. I agree that=20 > this is not=20 > clear. >=20 > Will rephrase as follows >=20 > "It MUST allow indicating the required level of diversity of a set of=20 > inter-area paths (link, node, SRLG diversity), as well as the=20 > required=20 > level of diversity of a set of intra-area segments of inter-area=20 > paths(link, node, SRLG diversity) on a per-area basis. >=20 > Thanks a lot for your comments Dimitri. > Let us know if the proposed text is fine with you and we will=20 > submit a new=20 > revision. >=20 > Best Regards, >=20 > JL >=20 >=20 >=20 > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 22/11/2006 15:51 > >=20 > > To: pce@ietf.org > > cc:=20 > > Subject: [Pce] Working Group Last Call on=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > >=20 > > Dear WG, > >=20 > > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev=20 > > -04) has been posted that addresses the remaining issues/comments. > >=20 > > This email initiates a Working Group Last Call on=20 > > draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last call=20 > > will end on December 8th at noon EST. > >=20 > > Please send your comments to the mailing list. > >=20 > > Thanks. > >=20 > > JP. > >=20 > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 >=20 >=20 >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Dec 29 07:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0GzU-0007Gz-PF; Fri, 29 Dec 2006 07:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0GzT-0007Cx-Nv for pce@ietf.org; Fri, 29 Dec 2006 07:37:39 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0GzR-0004so-Qo for pce@ietf.org; Fri, 29 Dec 2006 07:37:38 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 13:37:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Date: Fri, 29 Dec 2006 13:37:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt Thread-Index: AccmHzqZkXaI9MLxSAG3tBnX5reoJQFJrqOQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 29 Dec 2006 12:37:35.0084 (UTC) FILETIME=[1DCA22C0:01C72B46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 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: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, > edit: on the SRLG comment for ensuring some level of=20 > consistency identifiers should assigned and allocated from=20 > the same entity - this would solve the issue mentioned Ok I'm going to submit v05 that accounts for your comments Thanks JL =20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : samedi 23 d=E9cembre 2006 00:17 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 > hi jean-louis >=20 > i think we're converging beside one point about section 4.5 &=20 > 4.6 as indicated here below=20 >=20 > edit: on the SRLG comment for ensuring some level of=20 > consistency identifiers should assigned and allocated from=20 > the same entity - this would solve the issue mentioned >=20 > thanks, > - d. >=20 >=20 >=20 >=20 >=20 > "LE ROUX Jean-Louis RD-CORE-LAN" > 19/12/2006 00:48 > =20 > To: > cc: pce@ietf.org > Subject: RE: [Pce] Working Group Last Callon=20 > draft-ietf-pce-pcecp-interarea-reqs-04.txt >=20 >=20 > Hi Dimitri, >=20 > Thanks for these clarifications. >=20 > Please see in-line,=20 >=20 > > -----Message d'origine----- > > De : Dimitri.Papadimitriou@alcatel-lucent.be > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > > Envoy=E9 : lundi 18 d=E9cembre 2006 10:25 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > Cc : Dimitri.Papadimitriou@alcatel-lucent.be; JP Vasseur;=20 > pce@ietf.org=20 > > Objet : RE: [Pce] Working Group Last Callon=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > > hi jean-louis > >=20 > > see in-line for a couple of clarifications > >=20 > >=20 > >=20 > >=20 > > "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > > 15/12/2006 19:29 > >=20 > > To: ,=20 > > "JP Vasseur"=20 > > > > cc: > > Subject: RE: [Pce] Working Group Last Callon=20 > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > >=20 > >=20 > > Hi Dimitri, > >=20 > > Sorry for this late answer. > > Thanks for your comments. > >=20 > > Please see inline, > >=20 > > > -----Message d'origine----- > > > De : Dimitri.Papadimitriou@alcatel.be=20 > > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > > Envoy=E9 : mercredi 29 novembre 2006 09:35 =C0 : JP Vasseur Cc :=20 > > > pce@ietf.org Objet : Re: [Pce] Working Group Last Callon=20 > > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > > >=20 > > > hi > > >=20 > > > comment on this doc. > > >=20 > > > 4.5. Inclusion of Area IDs in Request > > >=20 > > > The knowledge of the areas in which the source and > > destination lie > > > would allow selection of appropriate cooperating PCEs.=20 > > >=20 > > > =3D> so is there an assumption that the PCE-Area ID knowledge is=20 > > > available - how come ? > >=20 > > Yes this information can be made available with the discovery=20 > > protocol, see [RFC4674] section 4.1.1.2. > >=20 > > We can rephrase as follows: > >=20 > > "The knowledge of the areas in which the source and destination lie=20 > > would allow selection of appropriate cooperating PCEs. This=20 > would be=20 > > useful when the area ID(s) of a PCE (i.e. the area(s) where it has > > visibility) is/are known, which can be achieved by the PCE=20 > Discovery=20 > > Protocol (see [RFC4674]) or any other mean." > >=20 > > >=20 > > > A PCE may not=20 > > > be able to determine the location of the source and > > destination and > > > in such a case it would be useful that a PCC indicates > > the source > > > and > > > destination area IDs.=20 > > >=20 > > > =3D> not sure to see the reasoning - i guess the initial PCE > > referred to > > > here is an intermediate PCE that does not have any > > visibility of the > > > source/destination areas and potentially more > > > - the whole problem in this sentence is the interpretation > > of the term > > > - location - > >=20 > > OK we can rephrase as follows > >=20 > > "A PCE in a PCE chain, may not have any visibility of the=20 > > source/destination area and hence may not be able to determine the=20 > > area of the source/destination" > >=20 > > >=20 > > > For that purpose the request message MUST support the > > inclusion of > > > the source and destination area IDs. Note that this=20 > information=20 > > > could > > > be learned by the PCC through configuration.=20 > > >=20 > > > =3D> how to be sure that the local area PCE is going only to be=20 > > > contacted by local area PCC's > >=20 > > Why do you need such assurance? > >=20 > > [dp] because the PCC itself may be an area where PCE=20 > learning and PCC=20 > > learning are not identical (PCC knows less than the PCE) >=20 > Again, we don't mandate the inclusion of source/dest area IDs=20 > in any request. > In situations where the PCC is aware of this information this=20 > may be useful to include it in the request.=20 >=20 > >=20 > > I don't catch your point here. > >=20 > > [dp] but this can also happen in the other way around, the issue is=20 > > that this information is provided as helper to the PCE=20 > looking at the=20 > > different cases we've at hand even if this information is=20 > provided it=20 > > does not still guarantee that the "local PCE" will be able to=20 > > determine the location of the destination and hence the=20 > > next/downstream PCE >=20 > If the request includes the destination area, then the PCE=20 > becomes aware of it, it can then select a downstream PCE=20 > based on advertised PCE information (PCE areas). >=20 >=20 >=20 > >=20 > > >- we're entering into a chicken > > > egg problem, from one side mandate knowledge of =20 > source/destination=20 > > >area > >=20 > > We don't mandate knowledge of src/dest area. We say "the request=20 > > message MUST support the inclusion", we don't say "MUST include" > >=20 > > > but on the other there is no > > > guarantee about interpretation of this information before > > knowing the > > > PCC - area ID relationship > >=20 > >=20 > > Here we simply ask the PCECP to support the inclusion of source and=20 > > destination area IDs in the request. > > When this information is known by the PCC (through configuration or=20 > > any other means), then it may be included in the request=20 > message, and=20 > > this may facilitate selection of downstream PCEs. > >=20 > >=20 > > >=20 > > >=20 > > > 4.6. Area Inclusion/Exclusion > > >=20 > > > In some situations it may be useful to include one or more > > > area(s) in=20 > > > the path.=20 > > >=20 > > > =3D> for inter-area it is certainly true that the actual path will = > > > cross multiple areas but i wonder whether what you mean=20 > is not the=20 > > > request includes one or more areas to be followed by the=20 > path to be=20 > > > computed > >=20 > > Yes it is, will be reworded as follows. > >=20 > > "It may be useful that the request message indicate one or more=20 > > area(s) that must be followed by the path to be computed. > > It may also be useful that the request message indicate one or more > > area(s) that must be avoided by the path to be computed." > >=20 > > >=20 > > > It may also be useful to exclude one or more area(s) from=20 > > > the path (e.g. request for a path between LSRs in two=20 > stub areas=20 > > > connected to the same ABR(s), which must not cross the=20 > backbone=20 > > > area). Hence the request message MUST allow indicating=20 > a set of=20 > > > one > > > or more area(s) that must be explicitly included in=20 > the path, and=20 > > > a > > > set of one or more area(s) that must be explicitly=20 > excluded from=20 > > > the > > > path.=20 > > >=20 > > > =3D> be prepared to incorporate a loop avoidance mechanism, in = case=20 > > > the request will have to cross multiple PCEs > >=20 > > Yes a loop avoidance mechanism will be needed,=20 > independantly of this=20 > > area inclusion/exclusion by the way. > > I don't think this requires any specific text here. > >=20 > > [dp] shouldn't that specific text be included in the=20 > document, as it=20 > > is meant to cover both PCC-PCE and PCE-PCE messaging ? >=20 > OK, we can add the following section >=20 > 4.9 Loop Avoidance >=20 > In case of multiple-PCE inter-area path computation there may=20 > be risks of PCECP request loops. > A mechanism MUST be defined to detect and supress PCECP=20 > request message loops. This may rely, for instance, on the=20 > recording, in the request message, of the set of traversed PCEs.=20 > Also the returned path in a response message MUST be loop free. >=20 > Would such a section make sense to you? >=20 >=20 > >=20 > > >=20 > > > other comments to follow > > > - d. > >=20 > > OK, see below, > >=20 > > > section 4.7 Inter-area Diverse Path computation > > >=20 > > > o) wrt 6. Security Considerations "IGP areas are administrated by=20 > > > the same entity. .." > > >=20 > > > does the latter ensure uniqueness of the SRLG IDs ? > >=20 > > YES > >=20 > > [dp] in theory yes, in practice not - > > just think upon the >=20 > > case where a > > single entity borrows fibers from two different plants each of them=20 > > having chosen different SRLG IDs for two fibers lying in=20 > the same duct=20 > > - >=20 > But when you build SRLGs for an IP network you also account=20 > for the ducts. > By the way you can be aware of the duct that is actually=20 > used, even if the fiber is rent (this can be provided in the=20 > contract). >=20 > Anyway, a requirement for SRLG diverse path computation makes=20 > the assumption of consistent SRLGs...and there is nothing=20 > specific to the PCE nor to the inter-area case here. >=20 > Thanks, >=20 > JL >=20 >=20 >=20 > >=20 > > > o) The response message MUST allow indicating the level=20 > of diversity=20 > > > of > > > a set of computed loose paths.=20 > > >=20 > > > do you mean partial disjointness ? or something equivalent ?=20 > >=20 > > This refers to link, node, SRLG diversity of a set of paths. > >=20 > > We can add the following > >=20 > > "The response message MUST allow indicating the level of=20 > diversity of=20 > > a set of computed inter-area loose paths (link, node, SRLG=20 > diversity),=20 > > globally and on a per-area basis (link, node, SRLG diversity of=20 > > intra-area path segments). > >=20 > > >=20 > > > o) last sentence =A73 unclear to me wrt to the next=20 > sentence - is it=20 > > > referring to a diversity of a given wrt to a set of resources but=20 > > > the next sentence refers to the diversity of a given LSP wrt to a=20 > > > set of other LSPs but also their SRLG set for inst. ? > > >=20 > >=20 > > It refers to the diversity of a set of paths. I agree that=20 > this is not=20 > > clear. > >=20 > > Will rephrase as follows > >=20 > > "It MUST allow indicating the required level of diversity=20 > of a set of=20 > > inter-area paths (link, node, SRLG diversity), as well as=20 > the required=20 > > level of diversity of a set of intra-area segments of inter-area=20 > > paths(link, node, SRLG diversity) on a per-area basis. > >=20 > > Thanks a lot for your comments Dimitri. > > Let us know if the proposed text is fine with you and we=20 > will submit a=20 > > new revision. > >=20 > > Best Regards, > >=20 > > JL > >=20 > >=20 > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > JP Vasseur > > > 22/11/2006 15:51 > > >=20 > > > To: pce@ietf.org > > > cc:=20 > > > Subject: [Pce] Working Group Last Call on=20 > > > draft-ietf-pce-pcecp-interarea-reqs-04.txt > > >=20 > > >=20 > > > Dear WG, > > >=20 > > > A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev > > > -04) has been posted that addresses the remaining issues/comments. > > >=20 > > > This email initiates a Working Group Last Call on > > > draft-ietf-pce- pcecp-interarea-reqs-04.txt. The last=20 > call will end=20 > > > on December 8th at noon EST. > > >=20 > > > Please send your comments to the mailing list. > > >=20 > > > Thanks. > > >=20 > > > JP. > > >=20 > > >=20 > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Dec 29 15:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Og4-0004S9-RB; Fri, 29 Dec 2006 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Ofz-0004Qa-Ic; Fri, 29 Dec 2006 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Ofy-0005kF-A1; Fri, 29 Dec 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 44CFC328D1; Fri, 29 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H0Ofy-0000eU-3o; Fri, 29 Dec 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Dec 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-pcecp-interarea-reqs-05.txt Pages : 11 Date : 2006-12-29 For scalability purposes a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered-Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCC) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcecp-interarea-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-29101034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcecp-interarea-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-29101034.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart--