From pce-bounces@lists.ietf.org Mon Aug 06 10:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3vy-0006of-Ro; Mon, 06 Aug 2007 10:51:50 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IF7fy-0006Q0-OQ for pce-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 08:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF7fy-0006Ps-E8 for pce@ietf.org; Sun, 29 Jul 2007 08:15:10 -0400 Received: from tsmail11.t-systems.com ([62.225.37.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IF7fw-0007e8-NR for pce@ietf.org; Sun, 29 Jul 2007 08:15:10 -0400 Received: from S4DE8PSAANV.t-systems.com (S4DE8PSAANV.t-systems.com [10.151.180.171]) by tsmail11.t-systems.com with ESMTP; Sun, 29 Jul 2007 14:15:16 +0200 Received: from S4DE8PSAAQL.t-systems.com ([10.151.229.23]) by S4DE8PSAANV.t-systems.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Jul 2007 14:15:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Pce] New draft on wavelength switched optical networks Date: Sun, 29 Jul 2007 14:15:03 +0200 Message-Id: <392EEBC34BD2724D9DAD2DCE73D0F53C03C8AC@S4DE8PSAAQL.t-systems.com> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604B8D322@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New draft on wavelength switched optical networks Thread-Index: Ace44kBWGI51s+KyS66O9uwz+WvwnwMaUN7gAyNtKiA= From: To: X-OriginalArrivalTime: 29 Jul 2007 12:15:04.0339 (UTC) FILETIME=[1841CE30:01C7D1DA] X-Spam-Score: -1.0 (-) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Mon, 06 Aug 2007 10:51:48 -0400 Cc: ccamp@ops.ietf.org, pce@ietf.org, ylee@huawei.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Greg, this is a timely topic to be tackled for both the PCE and GMPLS WGs, and well worth supporting. I would like to highlight that the renewed interest in this work by carriers is sparked by the fact that there is new optical equipment moving into the network, both in the core as well as in the metro/aggregation area which needs management and configuration. There is no intention to implement fast optical switching at large scale, except during failure recovery and for planned maintenance etc which would affect the IGP stability. Dimitri's remark during the GMPLS WG meeting showed me that it might be necessary to emphasize that position. Regards, Michael -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Hi CCAMPer's and PCEr's, we have just published a new draft on the=20 "Applicability of GMPLS and PCE to Wavelength Switched Optical=20 Networks" =20 http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-00.txt=20 . This draft looks at optical networks that include tunable lasers and=20 ROADM (reconfigurable optical add/drop multiplexers) with no or limited=20 wavelength conversion capability (these components are defined in the=20 draft).=20 These limitations lead to the RWA (routing and wavelength assignment)=20 problem which is a bit more demanding in terms of input information and=20 computation than other constrained path computation problems. In the=20 draft we look at the implications for GMPLS signaling, GMPLS routing,=20 and PCE protocols and suggest some potential extensions to better=20 accommodate this application. We'd appreciate feedback/collaboration on (a) overall interest in this=20 application, (b) requirements discussions, and (c) solution/extension=20 discussions. Cheers Greg B. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ 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 Thu Aug 09 14:05:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCM8-0002nO-HU; Thu, 09 Aug 2007 14:03:32 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IJCM7-0002nB-Jl for pce-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:03:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCM7-0002mw-2J for pce@ietf.org; Thu, 09 Aug 2007 14:03:31 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJCM6-0002Cb-PE for pce@ietf.org; Thu, 09 Aug 2007 14:03:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2007 11:03:30 -0700 X-IronPort-AV: i="4.19,241,1183359600"; d="scan'208"; a="511989914:sNHT40615996" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l79I3UMx019110 for ; Thu, 9 Aug 2007 11:03:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l79I3TiH029638 for ; Thu, 9 Aug 2007 18:03:29 GMT 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); Thu, 9 Aug 2007 14:03:24 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:03:23 -0400 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: Thu, 9 Aug 2007 14:02:59 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Aug 2007 18:03:23.0919 (UTC) FILETIME=[93EBE1F0:01C7DAAF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=163; t=1186682610; x=1187546610; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20minutes=20PCE=20WG=20Meeting=20IETF-69 |Sender:=20; bh=rdDwaJXpPMkoVgzAge5KFHUTfLL9g+FJ+QuuLmBFTng=; b=jeuaCqVWBIADGwPR+1EUXIL/Tauvho1JDlr+miWjZI80f4GpCPV3/dxiFHf3uji1toEiFTD+ ywbBe/MHjtJ6aOJEM+VhtRLdphu56jVa9A0frymxl5SoN4WAwIA6ffF9; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Draft minutes PCE WG Meeting IETF-69 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, The draft minutes have been posted: http://www3.ietf.org/proceedings/ 07jul/minutes/pce.txt Please comments your comments if any by August 24. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 09 14:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCTu-0001dY-Lt; Thu, 09 Aug 2007 14:11:34 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IJCTt-0001dT-6a for pce-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:11:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCTs-0001dL-Rt for pce@ietf.org; Thu, 09 Aug 2007 14:11:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJCTs-0002NR-FP for pce@ietf.org; Thu, 09 Aug 2007 14:11:32 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2007 14:11:32 -0400 X-IronPort-AV: i="4.19,241,1183348800"; d="scan'208,217"; a="128446320:sNHT67018990" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l79IBVkx028592 for ; Thu, 9 Aug 2007 14:11:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l79IBHn5028591 for ; Thu, 9 Aug 2007 18:11:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:11:25 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 14:11:25 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: From: JP Vasseur Subject: Fwd: [Pce] Draft minutes PCE WG Meeting IETF-69 Date: Thu, 9 Aug 2007 14:11:01 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Aug 2007 18:11:25.0632 (UTC) FILETIME=[B30B7400:01C7DAB0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4647; t=1186683092; x=1187547092; 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:=20Fwd=3A=20[Pce]=20Draft=20minutes=20PCE=20WG=20Meeting=20IETF- 69 |Sender:=20 |To:=20pce@ietf.org; bh=c/qNTll/o11BmdXjzAfotl2irE9P6G5u4O2MKKaAKaY=; b=e3BoJ9fawDSlRGRKPVTFVFSNDcO7WxqmcsBF+ITQFT6R7mL9LaqHar8cuo+3+Xcdh76Q4L9k BjTBoIJ5JafdTBZ7EE/u7eMIze+D0KD9h7sUqVX/S1JJql/0DD2PxzsD; 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Content-Type: multipart/mixed; boundary="===============0996480661==" Errors-To: pce-bounces@lists.ietf.org --===============0996480661== Content-Type: multipart/alternative; boundary=Apple-Mail-22-69947551 --Apple-Mail-22-69947551 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Please "send" your comments if any by August 24. Begin forwarded message: > From: JP Vasseur > Date: August 9, 2007 2:02:59 PM EDT > To: pce@ietf.org > Subject: [Pce] Draft minutes PCE WG Meeting IETF-69 > > Hi, > > The draft minutes have been posted: http://www3.ietf.org/ > proceedings/07jul/minutes/pce.txt > > Please comments your comments if any by August 24. > > JP. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-22-69947551 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
Please = "send" your comments if any by August = 24.


Begin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = August 9, 2007 2:02:59 PM EDT
Subject: = [Pce] Draft minutes PCE WG Meeting = IETF-69
Hi,

The draft = minutes have been posted: http://www= 3.ietf.org/proceedings/07jul/minutes/pce.txt

Please = comments your comments if any by August 24.

JP.


Pce mailing list

= --Apple-Mail-22-69947551-- --===============0996480661== 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 --===============0996480661==-- From pce-bounces@lists.ietf.org Sat Aug 11 09:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJrFm-0004qM-2W; Sat, 11 Aug 2007 09:43:42 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IJTZn-0004al-6B for pce-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 08:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJTZm-0004aa-SH for pce@ietf.org; Fri, 10 Aug 2007 08:26:46 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee03s.mail.mercury.atosorigin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJTZl-00047W-2i for pce@ietf.org; Fri, 10 Aug 2007 08:26:46 -0400 Received: from wpwuee03s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id D619911403E for ; Fri, 10 Aug 2007 14:26:43 +0200 (CEST) Received: from AOFR11476 (unknown [10.10.10.10]) by wpwuee03s.mail.mercury.atosorigin.com (Postfix) with ESMTP id AF23711403D for ; Fri, 10 Aug 2007 14:26:43 +0200 (CEST) From: "Fabien VERHAEGHE" To: Date: Fri, 10 Aug 2007 14:25:54 +0200 Message-ID: <002001c7db49$994303f0$75600337@AOFR11476> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfasLubc8kSH1yqRFit9qXiDRobwgAlbSyA In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e X-Mailman-Approved-At: Sat, 11 Aug 2007 09:43:41 -0400 Cc: Subject: [Pce] PCEP Request ID X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.verhaeghe@marben-products.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108592565==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0108592565== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C7DB5A.5CCBD3F0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C7DB5A.5CCBD3F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello all, I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that "The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context". I agree with that, however there may be 2 requests with same request Id exchanged on the same session in the case of session between 2 PCEs. One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to PCE#1. I don't think there is any problem with that but I am a little concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and value. I guess this is why for instance for the "Pending Request cancelled" notification there are 2 values. One for PCC and one for the PCE. One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in order to retrieve the correct PathRequest. Another problem is if an implementation does not recognize a given Error type/value, then it can't tell for sure which PathRequest it is related to. So it seems to me it would be more consistent to add a bit in the RP object (in the flag field) to indicate the "direction" of the PathRequest. For instance if the bit is set the Message that carry the RP object is related to the request sent by the destination of the message. Hence, an RP object would actually uniquely indentifies a PathRequest. Regards Fabien Verhaeghe ------=_NextPart_000_0021_01C7DB5A.5CCBD3F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello = all,

 =

I have a little = comment/suggestion on PCEP regarding the request Id.

In section 7.3.1 = states that

“The Request-ID-number value combined with the source IP address of the PCC = and the PCE address uniquely

identify the = path computation request context”.

 =

I agree with = that, however there may be 2 requests with same request Id exchanged on the = same session in

the case of = session between 2 PCEs.

One Path Request = being sent by PCE#1 to PCE#2 and the other one by PCE#2 to = PCE#1.

 =

I don’t = think there is any problem with that but I am a little concerned about potential misinterpretation especially

in PCErr and = PCNotif message.

If a PCNtf/PCErr = message contains an RP object, nothing indicates if it is related to the Request = from PCE#1 to PCE#2

or the one from = PCE#2 to PCE#1, except the notification/error type and = value.

I guess this is = why for instance for the “Pending Request cancelled” notification = there are 2 values. One for PCC and

one for the = PCE.

 =

One of the = problem, from an implementation perspective, is that we must first ready the = Notification type/value in order to retrieve

the correct = PathRequest.

Another problem = is if an implementation does not recognize a given Error type/value, then it can’t tell = for sure which PathRequest it

is related = to.

 =

So it seems to = me it would be more consistent to add a bit in the RP object (in the flag = field) to indicate the

“direction&= #8221; of the PathRequest.

For instance if = the bit is set the Message that carry the RP object is related to the request = sent by the destination of the message.

 =

Hence, an RP = object would actually uniquely indentifies a = PathRequest.

 =

Regards

Fabien = Verhaeghe

 

------=_NextPart_000_0021_01C7DB5A.5CCBD3F0-- --===============0108592565== 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 --===============0108592565==-- From pce-bounces@lists.ietf.org Sun Aug 12 09:43:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKDhc-0005G3-P3; Sun, 12 Aug 2007 09:41:56 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKDha-0005Fp-SN for pce-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 09:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKDha-0005Fh-Iv for pce@ietf.org; Sun, 12 Aug 2007 09:41:54 -0400 Received: from asmtp2.iomartmail.com ([62.128.201.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKDhZ-0003VG-2P for pce@ietf.org; Sun, 12 Aug 2007 09:41:54 -0400 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7CDfn0R030160; Sun, 12 Aug 2007 14:41:49 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7CDfkN7030145; Sun, 12 Aug 2007 14:41:48 +0100 Message-ID: <00b101c7dce6$82a72790$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: , Date: Sun, 12 Aug 2007 14:40:51 +0100 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-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Ross Callon , dward@cisco.com, Scott Bradner Subject: [Pce] Draft liaison #5 - ITU-T Optical Transport Networks Work Plan 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, In June this year, the ITU-T Study Group 15 sent us a revised copy of their work plan for Optical Transport Network topics. You can see their liaison and the work plan at https://datatracker.ietf.org/documents/LIAISON/file451.doc. You can cut straight to the work plan at http://www.itu.int/dms_pub/itu-t/oth/09/01/T09010000010001MSWE.doc. It is interesting to look through this plan to check for any overlap or conflict. Table 7-1-2 is a long list of IETF drafts and RFCs that are related to the work being done by SG15. In addition to periodic emails to notify SG15 of new RFCs, we also comment on the content of this table from time to time. At the moment I can see nothing in the work plan that requires immediate comment, but please check for yourselves if you are interested or concerned. Otherwise, I will send the following simple liaison on 18th August. Thanks, Adrian === To: ITU-T Q3/15 From: IETF CCAMP and PCE working groups In response Subject: Your OTNT Work Plan Thank you for continuing to share your OTNT work plan through your liaison from your June plenary in Geneva. I have made the IETF's CCAMP and PCE working groups aware of the work plan, and at this time we do not have any issues or concerns to raise resulting from the content of the plan. Please note that the publication of new RFCs related to the optical control plane are notified to SG15 through separate liaisons from time to time, and you may wish to update table 7-1-2 accordingly. Please keep us informed as your work plan evolves. Best regards, Adrian Farrel IETF Liaison to the ITU-T SG15 on Optical Control Plane _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 12 11:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKFXm-0003n3-2O; Sun, 12 Aug 2007 11:39:54 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKFXl-0003my-1A for pce-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 11:39:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKFXk-0003mq-NX for pce@ietf.org; Sun, 12 Aug 2007 11:39:52 -0400 Received: from asmtp1.iomartmail.com ([62.128.201.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKFXk-00014B-7Y for pce@ietf.org; Sun, 12 Aug 2007 11:39:52 -0400 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7CFdoet005210 for ; Sun, 12 Aug 2007 16:39:50 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7CFdfwN005087 for ; Sun, 12 Aug 2007 16:39:50 +0100 Message-ID: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Sun, 12 Aug 2007 16:31:59 +0100 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-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Pce] New PCE working group I-Ds 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, The meeting in Chicago was broadly in support of adopting two I-Ds as working group drafts: - Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols draft-leroux-pce-of-01.txt - Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol draft-sivabalan-pce-dste-01.txt Can you please indicate your opinion. Now that the inter-AS requirements work is stable, the authors of two I-Ds related to the use of PCE for P2MP path computations (Adrian is one of the authors) have asked us to look at adopting this work. We think that a little more discussion is needed first, and have asked them to present the I-Ds in Vancouver so that we can make a decision immediately afterwards. Please have a look at the I-Ds and send your comments to the mailing list. - PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) draft-yasukawa-pce-p2mp-req-02.txt - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) draft-yasukawa-pce-p2mp-app-00.txt Thanks, JP and Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 13 05:45:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWSV-0005oz-Eq; Mon, 13 Aug 2007 05:43:35 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKWST-0005ot-8O for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 05:43:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWSP-0005ok-7x for pce@ietf.org; Mon, 13 Aug 2007 05:43:29 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWSO-0006fj-MX for pce@ietf.org; Mon, 13 Aug 2007 05:43:29 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 11:43:19 +0200 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] New PCE working group I-Ds Date: Mon, 13 Aug 2007 11:43:14 +0200 Message-ID: In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acfc+RdfK1bKaFgZTGuGprLDXZHgPAAlTfVQ References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 13 Aug 2007 09:43:19.0228 (UTC) FILETIME=[61625FC0:01C7DD8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Yes for the adoption of these two IDs=20 > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : dimanche 12 ao=FBt 2007 17:32 > =C0 : pce@ietf.org > Objet : [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > The meeting in Chicago was broadly in support of adopting two=20 > I-Ds as working group drafts: >=20 > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt >=20 > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt >=20 > Can you please indicate your opinion. >=20 >=20 > Now that the inter-AS requirements work is stable, the=20 > authors of two I-Ds related to the use of PCE for P2MP path=20 > computations (Adrian is one of the > authors) have asked us to look at adopting this work. We=20 > think that a little more discussion is needed first, and have=20 > asked them to present the I-Ds in Vancouver so that we can=20 > make a decision immediately afterwards. Please have a look at=20 > the I-Ds and send your comments to the mailing list. >=20 > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt >=20 > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt >=20 > Thanks, > JP and Adrian=20 >=20 >=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 Mon Aug 13 06:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKX3W-0007QI-1f; Mon, 13 Aug 2007 06:21:50 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKX3U-0007JK-9B for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKX3T-0007I5-UQ for pce@ietf.org; Mon, 13 Aug 2007 06:21:47 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKX3R-00006H-Jx for pce@ietf.org; Mon, 13 Aug 2007 06:21:47 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMP002R8JEZWE@szxga02-in.huawei.com> for pce@ietf.org; Mon, 13 Aug 2007 18:20:59 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMP00G24JEXK8@szxga02-in.huawei.com> for pce@ietf.org; Mon, 13 Aug 2007 18:20:59 +0800 (CST) Received: from l37133 ([10.70.77.65]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMP001ITJEXHL@szxml03-in.huawei.com> for pce@ietf.org; Mon, 13 Aug 2007 18:20:57 +0800 (CST) Date: Mon, 13 Aug 2007 18:20:57 +0800 From: Dan Li Subject: Re: [Pce] New PCE working group I-Ds To: pce@ietf.org Message-id: <018001c7dd93$a34d4670$414d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-Spam-Score: 1.2 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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, > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > Yes, I support this work. One question: There are 6 OFs are mandatory, so PCE may not need to advertise these 6 OFs to PCC, and PCC can assume that PCE should support these 6 OFs. If PCE does not, then the error message should be sent to PCC. Is this implied in this draft? > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > Yse, I support this work. Regards, Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Sunday, August 12, 2007 11:31 PM Subject: [Pce] New PCE working group I-Ds > Hi, > > The meeting in Chicago was broadly in support of adopting two I-Ds as > working group drafts: > > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > > Can you please indicate your opinion. > > > Now that the inter-AS requirements work is stable, the authors of two I-Ds > related to the use of PCE for P2MP path computations (Adrian is one of the > authors) have asked us to look at adopting this work. We think that a little > more discussion is needed first, and have asked them to present the I-Ds in > Vancouver so that we can make a decision immediately afterwards. Please have > a look at the I-Ds and send your comments to the mailing list. > > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt > > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt > > Thanks, > JP and Adrian > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 13 06:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXFe-0008SB-7g; Mon, 13 Aug 2007 06:34:22 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKXFd-0008S5-CO for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXFc-0008Rx-DV for pce@ietf.org; Mon, 13 Aug 2007 06:34:21 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKXFa-0000z2-Rd for pce@ietf.org; Mon, 13 Aug 2007 06:34:20 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 12:34:17 +0200 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] New PCE working group I-Ds Date: Mon, 13 Aug 2007 12:34:08 +0200 Message-ID: In-Reply-To: <018001c7dd93$a34d4670$414d460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acfdk8eZCFfaJuLaRAaSvvql76jRXAAANK6A References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <018001c7dd93$a34d4670$414d460a@china.huawei.com> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Dan Li" , X-OriginalArrivalTime: 13 Aug 2007 10:34:17.0038 (UTC) FILETIME=[7FFB26E0:01C7DD95] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Dan,=20 Thanks for your support. Please see inline, > -----Message d'origine----- > De : Dan Li [mailto:danli@huawei.com]=20 > Envoy=E9 : lundi 13 ao=FBt 2007 12:21 > =C0 : pce@ietf.org > Objet : Re: [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > > - Encoding of Objective Functions in Path Computation Element (PCE) > > communication and discovery protocols > > draft-leroux-pce-of-01.txt > >=20 > Yes, I support this work.=20 > One question: > There are 6 OFs are mandatory, so PCE may not need to=20 > advertise these 6 OFs to PCC, and PCC can assume that PCE=20 > should support these 6 OFs. If PCE does not, then the error=20 > message should be sent to PCC. Is this implied in this draft? Actually no. What is mandatory is the capability to encode these six OF, = and not the support of these six OF on the PCE. Also have a look at section 8.1:=20 "Also note that it is not mandatory for an implementation to support=20 all objective functions defined in section 5." Hope this clarifies. Regards, JL >=20 > > - Diff-Serv Aware Class Type Object for Path Computation Element > > Communication Protocol draft-sivabalan-pce-dste-01.txt > >=20 > Yse, I support this work. >=20 > Regards, >=20 > Dan >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Sunday, August 12, 2007 11:31 PM > Subject: [Pce] New PCE working group I-Ds >=20 >=20 > > Hi, > >=20 > > The meeting in Chicago was broadly in support of adopting=20 > two I-Ds as=20 > > working group drafts: > >=20 > > - Encoding of Objective Functions in Path Computation Element (PCE) > > communication and discovery protocols > > draft-leroux-pce-of-01.txt > >=20 > > - Diff-Serv Aware Class Type Object for Path Computation Element > > Communication Protocol draft-sivabalan-pce-dste-01.txt > >=20 > > Can you please indicate your opinion. > >=20 > >=20 > > Now that the inter-AS requirements work is stable, the=20 > authors of two I-Ds=20 > > related to the use of PCE for P2MP path computations=20 > (Adrian is one of the=20 > > authors) have asked us to look at adopting this work. We=20 > think that a little=20 > > more discussion is needed first, and have asked them to=20 > present the I-Ds in=20 > > Vancouver so that we can make a decision immediately=20 > afterwards. Please have=20 > > a look at the I-Ds and send your comments to the mailing list. > >=20 > > - PCC-PCE Communication Requirements for Point to Multipoint > > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > > draft-yasukawa-pce-p2mp-req-02.txt > >=20 > > - Applicability of the Path Computation Element (PCE) to > > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > > draft-yasukawa-pce-p2mp-app-00.txt > >=20 > > Thanks, > > JP and Adrian=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 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 13 07:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYIv-0004Vn-Dw; Mon, 13 Aug 2007 07:41:49 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKYIu-0004Qr-U7 for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 07:41:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYIu-0004On-Id for pce@ietf.org; Mon, 13 Aug 2007 07:41:48 -0400 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKYIu-0002AC-60 for pce@ietf.org; Mon, 13 Aug 2007 07:41:48 -0400 Received: from [192.168.1.45] (pool-68-163-42-55.phil.east.verizon.net [68.163.42.55]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id l7DBjKlG015117; Mon, 13 Aug 2007 07:45:20 -0400 (EDT) In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] New PCE working group I-Ds Date: Mon, 13 Aug 2007 07:41:38 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: *** (3.703) AWL,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Yes to both. On Aug 12, 2007, at 11:31 AM, Adrian Farrel wrote: > Hi, > > The meeting in Chicago was broadly in support of adopting two I-Ds > as working group drafts: > > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > > Can you please indicate your opinion. > > > Now that the inter-AS requirements work is stable, the authors of > two I-Ds related to the use of PCE for P2MP path computations > (Adrian is one of the authors) have asked us to look at adopting > this work. We think that a little more discussion is needed first, > and have asked them to present the I-Ds in Vancouver so that we can > make a decision immediately afterwards. Please have a look at the I- > Ds and send your comments to the mailing list. > > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt > > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt > > Thanks, > JP and Adrian > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 13 10:03:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaUd-000063-Sk; Mon, 13 Aug 2007 10:02:03 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKaUb-00005q-TN for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaUb-00005g-Jo for pce@ietf.org; Mon, 13 Aug 2007 10:02:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKaUa-0005ng-DP for pce@ietf.org; Mon, 13 Aug 2007 10:02:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2007 10:02:00 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="67838485:sNHT58639352" 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 l7DE1xE2007776; Mon, 13 Aug 2007 10:01:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7DE1sjQ023765; Mon, 13 Aug 2007 14:02:02 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:01:58 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New PCE working group I-Ds Date: Mon, 13 Aug 2007 10:01:57 -0400 Message-ID: In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acfc9xDbfIWfqfBaTWO0cdTHN7cHOwAu2j+Q References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 13 Aug 2007 14:01:58.0574 (UTC) FILETIME=[83A2A4E0:01C7DDB2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1812; t=1187013719; x=1187877719; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20[Pce]=20New=20PCE=20working=20group=20I-Ds |Sender:=20 |To:=20=22Adrian=20Farrel=22=20,=20; bh=zKl0iY0Pm6oWp4m+vgCzFI6julUUeU3vXfnEHaQU75Q=; b=Yh0U9R9kviYLB/M0M7ozdMgFejZRMTLyXGl36gE4Oqkcn3ajeqci86HPlLQxtxHKINOeBBW2 ZXT5Kr5B00rF7U1VnOJ9396fUEifqiuweulfWJFnkIv5xBoHGx0dgJuD; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Yes to both.=20 Thanks Regards.. Zafar =20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Sunday, August 12, 2007 11:32 AM > To: pce@ietf.org > Subject: [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > The meeting in Chicago was broadly in support of adopting two=20 > I-Ds as working group drafts: >=20 > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt >=20 > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt >=20 > Can you please indicate your opinion. >=20 >=20 > Now that the inter-AS requirements work is stable, the=20 > authors of two I-Ds related to the use of PCE for P2MP path=20 > computations (Adrian is one of the > authors) have asked us to look at adopting this work. We=20 > think that a little more discussion is needed first, and have=20 > asked them to present the I-Ds in Vancouver so that we can=20 > make a decision immediately afterwards. Please have a look at=20 > the I-Ds and send your comments to the mailing list. >=20 > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt >=20 > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt >=20 > Thanks, > JP and Adrian=20 >=20 >=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 Mon Aug 13 13:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdae-0001hw-9s; Mon, 13 Aug 2007 13:20:28 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKdad-0001hj-2q for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdac-0001hb-PP for pce@ietf.org; Mon, 13 Aug 2007 13:20:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKdab-0005kx-GT for pce@ietf.org; Mon, 13 Aug 2007 13:20:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 10:20:25 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="199252605:sNHT55357731" 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 l7DHKOgf028057; Mon, 13 Aug 2007 10:20:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7DHKIWT029043; Mon, 13 Aug 2007 17:20:24 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:20:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New PCE working group I-Ds Date: Mon, 13 Aug 2007 10:20:15 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E0409F7B3@xmb-sjc-234.amer.cisco.com> In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acfc9xBMvs/A58MkRwyGFu7l1O/ooQA1xBmQ References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 13 Aug 2007 17:20:16.0029 (UTC) FILETIME=[371234D0:01C7DDCE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1784; t=1187025625; x=1187889625; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=20=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:=20RE=3A=20[Pce]=20New=20PCE=20working=20group=20I-Ds |Sender:=20; bh=vL3v69GD0xARxgMaMeDhg81mMh98Trfu7yoM5eMXI/Q=; b=nT68d51qFLgkcleBP6k8XAPEq/KVg1t+qfnVBEBR5xr84dLJ+dQfQN/3sL1t0KIE7fWPg/RK oF+vRBWeQh7WoMS6f0z7XZQ+1+VkAQKvGFg7mfQ6gXCU8cSTS5sNjc8C; Authentication-Results: sj-dkim-4; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Yes to both.=20 Dean > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Sunday, August 12, 2007 8:32 AM > To: pce@ietf.org > Subject: [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > The meeting in Chicago was broadly in support of adopting two=20 > I-Ds as working group drafts: >=20 > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt >=20 > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt >=20 > Can you please indicate your opinion. >=20 >=20 > Now that the inter-AS requirements work is stable, the=20 > authors of two I-Ds related to the use of PCE for P2MP path=20 > computations (Adrian is one of the > authors) have asked us to look at adopting this work. We=20 > think that a little more discussion is needed first, and have=20 > asked them to present the I-Ds in Vancouver so that we can=20 > make a decision immediately afterwards. Please have a look at=20 > the I-Ds and send your comments to the mailing list. >=20 > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt >=20 > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt >=20 > Thanks, > JP and Adrian=20 >=20 >=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 Mon Aug 13 14:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKetu-0007UB-0Y; Mon, 13 Aug 2007 14:44:26 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKett-0007U4-0v for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 14:44:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKets-0007Tw-L2 for pce@ietf.org; Mon, 13 Aug 2007 14:44:24 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKetn-00011b-Ke for pce@ietf.org; Mon, 13 Aug 2007 14:44:24 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMQ00JGU6PUI4@usaga01-in.huawei.com> for pce@ietf.org; Mon, 13 Aug 2007 11:44:19 -0700 (PDT) Received: from Lee736821 ([10.124.12.125]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMQ0026Z6PRXF@usaga01-in.huawei.com> for pce@ietf.org; Mon, 13 Aug 2007 11:44:18 -0700 (PDT) Date: Mon, 13 Aug 2007 13:44:15 -0500 From: Young Lee Subject: [Pce] New PCE working group I-Ds To: pce@ietf.org Message-id: <000001c7ddd9$f31af3a0$7d0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acfd2fLCNBU41BXrQrmu3CKF1qaFsQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad 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: , Content-Type: multipart/mixed; boundary="===============0456862031==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0456862031== Content-type: multipart/alternative; boundary="Boundary_(ID_/V0GOFgzizxnI1lb75QjNQ)" This is a multi-part message in MIME format. --Boundary_(ID_/V0GOFgzizxnI1lb75QjNQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes, I support both I-D's. Young -----Message ------------------------------------- Date: Sun, 12 Aug 2007 16:31:59 +0100 From: "Adrian Farrel" Subject: [Pce] New PCE working group I-Ds To: Message-ID: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Hi, The meeting in Chicago was broadly in support of adopting two I-Ds as working group drafts: - Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols draft-leroux-pce-of-01.txt - Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol draft-sivabalan-pce-dste-01.txt Can you please indicate your opinion. Now that the inter-AS requirements work is stable, the authors of two I-Ds related to the use of PCE for P2MP path computations (Adrian is one of the authors) have asked us to look at adopting this work. We think that a little more discussion is needed first, and have asked them to present the I-Ds in Vancouver so that we can make a decision immediately afterwards. Please have a look at the I-Ds and send your comments to the mailing list. - PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) draft-yasukawa-pce-p2mp-req-02.txt - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) draft-yasukawa-pce-p2mp-app-00.txt Thanks, JP and Adrian ------------------------------ --Boundary_(ID_/V0GOFgzizxnI1lb75QjNQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Yes, I support both I-D’s.

 

Young

 

-----Message -------------------------------------

Date: Sun, 12 Aug 2007 16:31:59 +0100

From: "Adrian Farrel" <adrian@olddog.co.uk>

Subject: [Pce] New PCE working group I-Ds

To: <pce@ietf.org>

Message-ID: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe>

Content-Type: text/plain; format=flowed; charset="iso-8859-1";

            reply-type=original

 

Hi,

 

The meeting in Chicago was broadly in support of adopting two I-Ds as working group drafts:

 

- Encoding of Objective Functions in Path Computation Element (PCE)

  communication and discovery protocols

  draft-leroux-pce-of-01.txt

 

- Diff-Serv Aware Class Type Object for Path Computation Element

  Communication Protocol draft-sivabalan-pce-dste-01.txt

 

Can you please indicate your opinion.

 

 

Now that the inter-AS requirements work is stable, the authors of two I-Ds related to the use of PCE for P2MP path computations (Adrian is one of the

authors) have asked us to look at adopting this work. We think that a little more discussion is needed first, and have asked them to present the I-Ds in Vancouver so that we can make a decision immediately afterwards. Please have a look at the I-Ds and send your comments to the mailing list.

 

- PCC-PCE Communication Requirements for Point to Multipoint

  Multiprotocol Label Switching Traffic Engineering (MPLS-TE)

  draft-yasukawa-pce-p2mp-req-02.txt

 

- Applicability of the Path Computation Element (PCE) to

   Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)

   and Generalized MPLS (GMPLS) Traffic Engineering (TE)

   draft-yasukawa-pce-p2mp-app-00.txt

 

Thanks,

JP and Adrian

 

 

 

 

 

 

------------------------------

 

 

 

--Boundary_(ID_/V0GOFgzizxnI1lb75QjNQ)-- --===============0456862031== 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 --===============0456862031==-- From pce-bounces@lists.ietf.org Mon Aug 13 21:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKlHF-0004Fi-N1; Mon, 13 Aug 2007 21:32:57 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKlHD-00046r-Lv for pce-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 21:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKlHD-000451-BV for pce@ietf.org; Mon, 13 Aug 2007 21:32:55 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKlHB-0007Em-5p for pce@ietf.org; Mon, 13 Aug 2007 21:32:55 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMQ00BX3PLG1K@szxga04-in.huawei.com> for pce@ietf.org; Tue, 14 Aug 2007 09:32:04 +0800 (CST) Received: from M55527 ([10.111.12.154]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMQ00CYZPLBY1@szxga04-in.huawei.com> for pce@ietf.org; Tue, 14 Aug 2007 09:32:04 +0800 (CST) Date: Tue, 14 Aug 2007 09:32:00 +0800 From: Mach Chen Subject: =?gb2312?B?tPC4tDogW1BjZV0gTmV3IFBDRSB3b3JraW5nIGdyb3VwIEktRHM=?= In-reply-to: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> To: 'Adrian Farrel' Message-id: <006501c7de12$e9293d00$9a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acfc9xfwifw/mjxPSfOysqenDpOoaABG7EPw X-Spam-Score: 2.5 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, Yes to both. Best regards, Mach > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Adrian Farrel [mailto:adrian@olddog.co.uk] > =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA8=D4=C212=C8=D5 23:32 > =CA=D5=BC=FE=C8=CB: pce@ietf.org > =D6=F7=CC=E2: [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > The meeting in Chicago was broadly in support of adopting two I-Ds as > working group drafts: >=20 > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt >=20 > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt >=20 > Can you please indicate your opinion. >=20 >=20 > Now that the inter-AS requirements work is stable, the authors of two = I-Ds > related to the use of PCE for P2MP path computations (Adrian is one of = the > authors) have asked us to look at adopting this work. We think that a little > more discussion is needed first, and have asked them to present the = I-Ds in > Vancouver so that we can make a decision immediately afterwards. = Please have > a look at the I-Ds and send your comments to the mailing list. >=20 > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt >=20 > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt >=20 > Thanks, > JP and Adrian >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 00:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoMr-0005QH-DL; Tue, 14 Aug 2007 00:50:57 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKoMp-0005QA-Cd for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 00:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoMp-0005Q2-38 for pce@ietf.org; Tue, 14 Aug 2007 00:50:55 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKoMn-0004Aq-SF for pce@ietf.org; Tue, 14 Aug 2007 00:50:55 -0400 Received: from localhost (imp-4-2.polymtl.ca [132.207.4.77]) by smtp.polymtl.ca (8.13.6/8.13.6) with ESMTP id l7E4oq8m001744; Tue, 14 Aug 2007 00:50:53 -0400 Received: from bas12-montrealak-1167976634.dsl.bell.ca (bas12-montrealak-1167976634.dsl.bell.ca [69.157.232.186]) by www.imp.polymtl.ca (IMP) with HTTP for ; Tue, 14 Aug 2007 00:50:51 -0400 Message-ID: <1187067051.46c134abd4326@www.imp.polymtl.ca> Date: Tue, 14 Aug 2007 00:50:51 -0400 From: Meral Shirazipour To: Adrian Farrel Subject: Re: [Pce] New PCE working group I-Ds References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 69.157.232.186 X-Poly-FromMTA: (imp-4-2.polymtl.ca [132.207.4.77]) at Tue, 14 Aug 2007 04:50:52 +0000 X-Spam-Score: -0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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, in favor of both I-Ds. Regards, Meral Selon Adrian Farrel : > Hi, > > The meeting in Chicago was broadly in support of adopting two I-Ds as > working group drafts: > > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > > Can you please indicate your opinion. > > > Now that the inter-AS requirements work is stable, the authors of two I-Ds > related to the use of PCE for P2MP path computations (Adrian is one of the > authors) have asked us to look at adopting this work. We think that a little > more discussion is needed first, and have asked them to present the I-Ds in > Vancouver so that we can make a decision immediately afterwards. Please have > a look at the I-Ds and send your comments to the mailing list. > > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt > > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt > > Thanks, > JP and Adrian > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 02:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKq3m-00005q-6T; Tue, 14 Aug 2007 02:39:22 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKq3l-00005l-DQ for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 02:39:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKq3l-00005d-2Q for pce@ietf.org; Tue, 14 Aug 2007 02:39:21 -0400 Received: from smtp1.mail.atosorigin.com ([160.92.103.80] helo=wpwuee01s.mail.mercury.atosorigin.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKq3k-0007eC-HW for pce@ietf.org; Tue, 14 Aug 2007 02:39:20 -0400 Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 91998F400B for ; Tue, 14 Aug 2007 08:39:19 +0200 (CEST) Received: from AOFR11476 (lon92-2-82-66-48-170.fbx.proxad.net [82.66.48.170]) by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id 5EEF4F4002 for ; Tue, 14 Aug 2007 08:39:19 +0200 (CEST) From: "fabien.verhaeghe" To: Subject: RE: [Pce] New PCE working group I-Ds Date: Tue, 14 Aug 2007 08:38:28 +0200 Message-ID: <000501c7de3d$ba213be0$aa304252@AOFR11476> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acfc9w01tLl9pKyBRSyv+4NaI+DOGQBRo1fQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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, I support both I-Ds. Regards Fabien -----Message d'origine----- De=A0: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Envoy=E9=A0: dimanche 12 ao=FBt 2007 17:32 =C0=A0: pce@ietf.org Objet=A0: [Pce] New PCE working group I-Ds Hi, The meeting in Chicago was broadly in support of adopting two I-Ds as=20 working group drafts: - Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols draft-leroux-pce-of-01.txt - Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol draft-sivabalan-pce-dste-01.txt Can you please indicate your opinion. Now that the inter-AS requirements work is stable, the authors of two = I-Ds=20 related to the use of PCE for P2MP path computations (Adrian is one of = the=20 authors) have asked us to look at adopting this work. We think that a = little more discussion is needed first, and have asked them to present the I-Ds = in=20 Vancouver so that we can make a decision immediately afterwards. Please = have a look at the I-Ds and send your comments to the mailing list. - PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) draft-yasukawa-pce-p2mp-req-02.txt - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) draft-yasukawa-pce-p2mp-app-00.txt Thanks, JP and Adrian=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 10:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxLG-0001ga-Tt; Tue, 14 Aug 2007 10:25:54 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IKxLE-0001dN-4d for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 10:25:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxLD-0001dF-Qt for pce@ietf.org; Tue, 14 Aug 2007 10:25:51 -0400 Received: from eastrmmtao101.cox.net ([68.230.240.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKxLD-0005nD-DZ for pce@ietf.org; Tue, 14 Aug 2007 10:25:51 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070814142055.LCFN19516.eastrmmtao101.cox.net@eastrmimpo01.cox.net> for ; Tue, 14 Aug 2007 10:20:55 -0400 Received: from Yong73674 ([68.0.102.87]) by eastrmimpo01.cox.net with bizsmtp id bqLs1X0061t8SFY0000000; Tue, 14 Aug 2007 10:20:55 -0400 From: "Lucy Yong" To: Subject: RE: [Pce] New PCE working group I-Ds Date: Tue, 14 Aug 2007 09:20:54 -0500 Message-ID: <00c101c7de7e$533b76c0$6700a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acfc9xm5W45Z5pcyQkSn7GvdMom6egBhxH6w X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Yes to both. Cheers, Lucy -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, August 12, 2007 10:32 AM To: pce@ietf.org Subject: [Pce] New PCE working group I-Ds Hi, The meeting in Chicago was broadly in support of adopting two I-Ds as working group drafts: - Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols draft-leroux-pce-of-01.txt - Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol draft-sivabalan-pce-dste-01.txt Can you please indicate your opinion. Now that the inter-AS requirements work is stable, the authors of two I-Ds related to the use of PCE for P2MP path computations (Adrian is one of the authors) have asked us to look at adopting this work. We think that a little more discussion is needed first, and have asked them to present the I-Ds in Vancouver so that we can make a decision immediately afterwards. Please have a look at the I-Ds and send your comments to the mailing list. - PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) draft-yasukawa-pce-p2mp-req-02.txt - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) draft-yasukawa-pce-p2mp-app-00.txt Thanks, JP and Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 15:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1bk-0000sw-RA; Tue, 14 Aug 2007 14:59:12 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IL1bj-0000ot-KN for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 14:59:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1bj-0000oh-6S for pce@ietf.org; Tue, 14 Aug 2007 14:59:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL1bi-0006cp-Tk for pce@ietf.org; Tue, 14 Aug 2007 14:59:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2007 14:59:10 -0400 X-IronPort-AV: i="4.19,261,1183348800"; d="scan'208"; a="67987461:sNHT46088858" 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 l7EIxApM004468 for ; Tue, 14 Aug 2007 14:59:10 -0400 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 l7EIx0jY004289 for ; Tue, 14 Aug 2007 18:59:10 GMT 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, 14 Aug 2007 14:59:05 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:59:05 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <0091C938-CE7E-40EA-A08C-66968E58DCF2@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Tue, 14 Aug 2007 14:58:36 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Aug 2007 18:59:05.0784 (UTC) FILETIME=[2FE4C380:01C7DEA5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=557; t=1187117950; x=1187981950; 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:=20IPR=20Path-Key=20ID |Sender:=20 |To:=20pce@ietf.org; bh=IauxrFs4m03tSwUKML0HWbQ15piJ2qy8rf7vtLAdqto=; b=LQmCqCQXIY1kpTOAjoYkm2XgalpL+2HLsw5jZP+pLemkz5DMyS5oz9M79aao8VVyF3WyH9w+ 32Xy/F5uoz2vfT1kabzNXG8blBjrkshteL+QQRBCaQ0fL5c1qEC8Z/7N; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Pce] IPR Path-Key ID 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, I want to let you know about an IPR disclosure that has been filed with the IETF in relation to http://tools.ietf.org/id/draft-ietf-pce- path-key-00.txt. You can see the disclosure at https:// datatracker.ietf.org/ipr/871/ and see the terms offered by the IPR claimant. Sorry for the delay in disclosing the IPR claim. If you have any issues on this please contact the chairs. Adrian has agreed to act as arbitrator as he has not interest in the IPR claim, and will drop off the I-D author list if necessary. Thanks, JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 15:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1cX-0001eq-Ls; Tue, 14 Aug 2007 15:00:01 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IL1cW-0001eQ-CG for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1cW-0001eI-2o for pce@ietf.org; Tue, 14 Aug 2007 15:00:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1cU-00034r-IN for pce@ietf.org; Tue, 14 Aug 2007 15:00:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 11:59:58 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="199993169:sNHT39723426" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EIxvOi005661 for ; Tue, 14 Aug 2007 11:59:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EIxmW9000788 for ; Tue, 14 Aug 2007 18:59:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:59:56 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:59:56 -0400 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: Tue, 14 Aug 2007 14:59:27 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Aug 2007 18:59:56.0503 (UTC) FILETIME=[4E1FDE70:01C7DEA5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=306; t=1187117998; x=1187981998; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20IPR=20PCE=20Monitoring |Sender:=20; bh=EJlBF+tlNTw84Kwv56lMBZltKmfI+wx77MGakiU8dTk=; b=ObA5ctjrfOUMdwXYmzm8a6WHzEklmsn7VtBdLW7nRwuke7AZViyjnVhDZWFot9Co2JInBAdx H6vuIBCxDZIRGjT8J1bGR4l7xex94bcErtv+VwMLPs+7dH7ye3vShGwH; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Pce] IPR PCE Monitoring 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, Just let you know about an IPR disclosure that has been filed with the IETF in relation to http://tools.ietf.org/id/draft-vasseur-pce- monitoring-03.txt. You can see the disclosure at https:// datatracker.ietf.org/ipr/872/ and see the terms offered by the IPR claimant. Thanks, JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 14 15:06:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1gY-0002ct-Hs; Tue, 14 Aug 2007 15:04:10 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IL1gW-0002c7-Oq for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1gW-0002bT-48 for pce@ietf.org; Tue, 14 Aug 2007 15:04:08 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1gU-00039d-Mt for pce@ietf.org; Tue, 14 Aug 2007 15:04:08 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l7EJ3mJb022219; Tue, 14 Aug 2007 21:03:48 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 14 Aug 2007 21:04:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] New PCE working group I-Ds Date: Tue, 14 Aug 2007 21:03:31 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds thread-index: Acfc9w6gYMQtnOaoSx2kw0DURacWpwBc/itw References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 14 Aug 2007 19:04:05.0721 (UTC) FILETIME=[E2AB8490:01C7DEA5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 =20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Sunday, August 12, 2007 5:32 PM > To: pce@ietf.org > Subject: [Pce] New PCE working group I-Ds >=20 > Hi, >=20 > The meeting in Chicago was broadly in support of adopting two I-Ds as=20 > working group drafts: >=20 > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt ok, three comments though:=20 - units B-R is from def. speed(bps)-res.capacity(b) -> ? please check - still unclear to me whether isis pce disc. will or not use a separate inst. (cf. gen-app discussion at isis working group) - question about oscillation effects resulting from opposed obj. adv. from diff. pce's > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt architectural impact to be clarified before moving forward i think that the important disc. point is whether such info obtained from=20 TED or via other means also from * 13) Diff-Serv Aware Class Type Object for Path Computation Element=20 * Communication Protocol=20 * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95]=20 * * Pce does not know class pool. * Dimitri: in interprovider context, how do you assure global significance? * Jon: this is an issue not tackled here. * Adrian: how PCE has knowledge class pool ? You would suggest to build this knowledge based on IGP=20 * flooded information ? * JP: please respin the draft tackling issue raised by Dimitri * Not many people red the draft -> draft still does not seem to address that issue. =20 > Can you please indicate your opinion. >=20 >=20 > Now that the inter-AS requirements work is stable, the=20 > authors of two I-Ds=20 > related to the use of PCE for P2MP path computations (Adrian=20 > is one of the=20 > authors) have asked us to look at adopting this work. We=20 > think that a little=20 > more discussion is needed first, and have asked them to=20 > present the I-Ds in=20 > Vancouver so that we can make a decision immediately=20 > afterwards. Please have=20 > a look at the I-Ds and send your comments to the mailing list. >=20 > - PCC-PCE Communication Requirements for Point to Multipoint > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > draft-yasukawa-pce-p2mp-req-02.txt >=20 > - Applicability of the Path Computation Element (PCE) to > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > draft-yasukawa-pce-p2mp-app-00.txt >=20 > Thanks, > JP and Adrian=20 >=20 >=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 Tue Aug 14 21:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL7QB-0005L2-4c; Tue, 14 Aug 2007 21:11:39 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IL7Q9-0005Kx-MU for pce-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 21:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL7Q9-0005Kp-BI for pce@ietf.org; Tue, 14 Aug 2007 21:11:37 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL7Q8-0005Nq-Rl for pce@ietf.org; Tue, 14 Aug 2007 21:11:37 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6502DEC8FD for ; Wed, 15 Aug 2007 10:11:34 +0900 (JST) Received: from platinum.inc.kddilabs.jp (unknown [2001:200:601:1300:20a:48ff:fe12:3f1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1BDC7EC8F7 for ; Wed, 15 Aug 2007 10:11:34 +0900 (JST) Received: from [127.0.0.1] (unknown [172.19.83.190]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 94FFB57810F for ; Wed, 15 Aug 2007 10:11:32 +0900 (JST) Message-ID: <46C252DC.6090906@kddilabs.jp> Date: Wed, 15 Aug 2007 10:11:56 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pce@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -1.4 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Pce] MPLS 2007 International Conference - October 28-31, Washington DC 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 You are invited to attend the MPLS 2007 International Conference to be held in Washington, DC from October 28-31, 2007. The 4-day event consists of technical sessions, tutorials, panel discussions, and exhibits. Program details are available at: www.mpls2007.com Important Dates: ------------------------ - Early Registration Rate Cut-off Date: August 20, 2007 - Tutorials: Sunday, October 28 - Technical Sessions: Monday-Wednesday, October 29-31 - Exhibits: Monday, October 29 - Wednesday, October 31 - 8th Public Interoperability Demonstration: November 1, 11:00 am _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 15 08:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHgW-00085v-TP; Wed, 15 Aug 2007 08:09:12 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILHgV-00085q-V0 for pce-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 08:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHgV-00085i-IS for pce@ietf.org; Wed, 15 Aug 2007 08:09:11 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILHgU-0002vq-23 for pce@ietf.org; Wed, 15 Aug 2007 08:09:11 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 14:09:07 +0200 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] New PCE working group I-Ds Date: Wed, 15 Aug 2007 14:08:52 +0200 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acfc9w6gYMQtnOaoSx2kw0DURacWpwBc/itwADHQRbA= References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "PAPADIMITRIOU Dimitri" , , X-OriginalArrivalTime: 15 Aug 2007 12:09:07.0820 (UTC) FILETIME=[14C712C0:01C7DF35] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Dimitri, Thanks for these comments. Please see inline, > -----Message d'origine----- > De : PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : mardi 14 ao=FBt 2007 21:04 > =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org > Objet : RE: [Pce] New PCE working group I-Ds >=20 > =20 >=20 > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Sunday, August 12, 2007 5:32 PM > > To: pce@ietf.org > > Subject: [Pce] New PCE working group I-Ds > >=20 > > Hi, > >=20 > > The meeting in Chicago was broadly in support of adopting=20 > two I-Ds as=20 > > working group drafts: > >=20 > > - Encoding of Objective Functions in Path Computation Element (PCE) > > communication and discovery protocols > > draft-leroux-pce-of-01.txt >=20 > ok, three comments though:=20 >=20 > - units B-R is from def. speed(bps)-res.capacity(b) -> ?=20 >please check B is in bps and R is in bps.=20 B-R is the actual bandwidth consumption on the link, in bps. We will clarify the units in next revision. > - still unclear to me whether isis pce disc. will or not use a > separate inst. (cf. gen-app discussion at isis working group) ISIS pce disc relies on procedures defined in 4971.=20 This is a deployment issue to use same or separate instances. > - question about oscillation effects resulting from opposed obj. > adv. from diff. pce's Would you please clarify and provide an example? Regards, JL >=20 > > - Diff-Serv Aware Class Type Object for Path Computation Element > > Communication Protocol draft-sivabalan-pce-dste-01.txt >=20 > architectural impact to be clarified before moving forward i=20 > think that the important disc. point is whether such info=20 > obtained from TED or via other means >=20 > also from >=20 > * 13) Diff-Serv Aware Class Type Object for Path Computation Element > * Communication Protocol > * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] > * > * Pce does not know class pool. > * Dimitri: in interprovider context, how do you assure global=20 > significance? > * Jon: this is an issue not tackled here. > * Adrian: how PCE has knowledge class pool ? You would=20 > suggest to build this knowledge based on IGP > * flooded information ? > * JP: please respin the draft tackling issue raised by Dimitri > * Not many people red the draft >=20 > -> draft still does not seem to address that issue. > =20 > > Can you please indicate your opinion. > >=20 > >=20 > > Now that the inter-AS requirements work is stable, the=20 > authors of two=20 > > I-Ds related to the use of PCE for P2MP path computations=20 > (Adrian is=20 > > one of the > > authors) have asked us to look at adopting this work. We=20 > think that a=20 > > little more discussion is needed first, and have asked them=20 > to present=20 > > the I-Ds in Vancouver so that we can make a decision immediately=20 > > afterwards. Please have a look at the I-Ds and send your=20 > comments to=20 > > the mailing list. > >=20 > > - PCC-PCE Communication Requirements for Point to Multipoint > > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > > draft-yasukawa-pce-p2mp-req-02.txt > >=20 > > - Applicability of the Path Computation Element (PCE) to > > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > > draft-yasukawa-pce-p2mp-app-00.txt > >=20 > > Thanks, > > JP and Adrian > >=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 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 15 16:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPOq-0000Je-Q8; Wed, 15 Aug 2007 16:23:28 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILPOp-0000JZ-GH for pce-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:23:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPOp-0000JR-4e for pce@ietf.org; Wed, 15 Aug 2007 16:23:27 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILPOo-0007ij-8b for pce@ietf.org; Wed, 15 Aug 2007 16:23:27 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l7FKN8X5011596; Wed, 15 Aug 2007 22:23:08 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 15 Aug 2007 22:23:24 +0200 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] New PCE working group I-Ds Date: Wed, 15 Aug 2007 22:22:49 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] New PCE working group I-Ds thread-index: Acfc9w6gYMQtnOaoSx2kw0DURacWpwBc/itwADHQRbAAAL7uYA== References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "LE ROUX Jean-Louis RD-CORE-LAN" , , X-OriginalArrivalTime: 15 Aug 2007 20:23:24.0661 (UTC) FILETIME=[21A1E250:01C7DF7A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 j-l=20 > -----Original Message----- > From: LE ROUX Jean-Louis RD-CORE-LAN=20 > [mailto:jeanlouis.leroux@orange-ftgroup.com]=20 > Sent: Wednesday, August 15, 2007 2:09 PM > To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org > Subject: RE: [Pce] New PCE working group I-Ds >=20 > Hi Dimitri, >=20 > Thanks for these comments. >=20 > Please see inline, >=20 >=20 > > -----Message d'origine----- > > De : PAPADIMITRIOU Dimitri=20 > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > Envoy=E9 : mardi 14 ao=FBt 2007 21:04 > > =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org > > Objet : RE: [Pce] New PCE working group I-Ds > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Sunday, August 12, 2007 5:32 PM > > > To: pce@ietf.org > > > Subject: [Pce] New PCE working group I-Ds > > >=20 > > > Hi, > > >=20 > > > The meeting in Chicago was broadly in support of adopting=20 > > two I-Ds as=20 > > > working group drafts: > > >=20 > > > - Encoding of Objective Functions in Path Computation=20 > Element (PCE) > > > communication and discovery protocols > > > draft-leroux-pce-of-01.txt > >=20 > > ok, three comments though:=20 > >=20 > > - units B-R is from def. speed(bps)-res.capacity(b) -> ?=20 > >please check >=20 > B is in bps and R is in bps.=20 > B-R is the actual bandwidth consumption on the link, in bps. > We will clarify the units in next revision. i thought that capacity/residual bandwidth was expressed in b and you were using the term speed for bps - pls check > > - still unclear to me whether isis pce disc. will or not use a > > separate inst. (cf. gen-app discussion at isis working group) >=20 > ISIS pce disc relies on procedures defined in 4971.=20 > This is a deployment issue to use same or separate instances. do you assume that you would leave such choice possible ? i=20 was left with the impression after last isis mtg discussion that there is a real incentive for making this a recommended behavior > > - question about oscillation effects resulting from opposed obj. > > adv. from diff. pce's >=20 > Would you please clarify and provide an example? PCE_1 advertizing OF_1 attracts all demands in normal conditions while PCE_2 advertizing OF_2 attracts demands after failure/re-routing or other rare event hence, you would then be balancing between both PCEs=20 after failure and when reverting and back again if the=20 failure occur once more (e.g. flapping) i am not saying this will happen but heterogeneity in OF advertized may lead to unbalanced request between PCEs thanks, -d.=20 > Regards, >=20 > JL >=20 > >=20 > > > - Diff-Serv Aware Class Type Object for Path Computation Element > > > Communication Protocol draft-sivabalan-pce-dste-01.txt > >=20 > > architectural impact to be clarified before moving forward i=20 > > think that the important disc. point is whether such info=20 > > obtained from TED or via other means > >=20 > > also from > >=20 > > * 13) Diff-Serv Aware Class Type Object for Path Computation Element > > * Communication Protocol > > * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] > > * > > * Pce does not know class pool. > > * Dimitri: in interprovider context, how do you assure global=20 > > significance? > > * Jon: this is an issue not tackled here. > > * Adrian: how PCE has knowledge class pool ? You would=20 > > suggest to build this knowledge based on IGP > > * flooded information ? > > * JP: please respin the draft tackling issue raised by Dimitri > > * Not many people red the draft > >=20 > > -> draft still does not seem to address that issue. > > =20 > > > Can you please indicate your opinion. > > >=20 > > >=20 > > > Now that the inter-AS requirements work is stable, the=20 > > authors of two=20 > > > I-Ds related to the use of PCE for P2MP path computations=20 > > (Adrian is=20 > > > one of the > > > authors) have asked us to look at adopting this work. We=20 > > think that a=20 > > > little more discussion is needed first, and have asked them=20 > > to present=20 > > > the I-Ds in Vancouver so that we can make a decision immediately=20 > > > afterwards. Please have a look at the I-Ds and send your=20 > > comments to=20 > > > the mailing list. > > >=20 > > > - PCC-PCE Communication Requirements for Point to Multipoint > > > Multiprotocol Label Switching Traffic Engineering (MPLS-TE) > > > draft-yasukawa-pce-p2mp-req-02.txt > > >=20 > > > - Applicability of the Path Computation Element (PCE) to > > > Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) > > > and Generalized MPLS (GMPLS) Traffic Engineering (TE) > > > draft-yasukawa-pce-p2mp-app-00.txt > > >=20 > > > Thanks, > > > JP and Adrian > > >=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 > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 15 18:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRgg-0006VP-Az; Wed, 15 Aug 2007 18:50:02 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILRgf-0006V8-AP for pce-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 18:50:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRge-0006V0-Ud for pce@ietf.org; Wed, 15 Aug 2007 18:50:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILRge-000499-64 for pce@ietf.org; Wed, 15 Aug 2007 18:50:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2007 18:50:00 -0400 X-IronPort-AV: i="4.19,268,1183348800"; d="scan'208"; a="128992396:sNHT57460754" 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 l7FMnxot032418; Wed, 15 Aug 2007 18:49:59 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7FMntjI002762; Wed, 15 Aug 2007 22:49:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:49:55 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:49:54 -0400 In-Reply-To: <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com> References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] New PCE working group I-Ds Date: Wed, 15 Aug 2007 18:49:19 -0400 To: PAPADIMITRIOU Dimitri X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Aug 2007 22:49:54.0381 (UTC) FILETIME=[98B6B7D0:01C7DF8E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5579; t=1187218199; x=1188082199; 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:=20Re=3A=20[Pce]=20New=20PCE=20working=20group=20I-Ds |Sender:=20 |To:=20PAPADIMITRIOU=20Dimitri=20; bh=ufqL+EWAsBFtNGnayrzHIR1B4WFoHs7vfQGVuMm3Wgg=; b=qNsjA8hf7pDYynEZkDOdlY4Ujyy2IVQ3waxftVS+sNtfzutm12OpgvdtRd8JY7LeVP/3rymj 3qWADqic/moUYkzIMU0i+dd9gs48FKzewdCLe84WWWDY38i9nDqNaqKv; 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: 2bf730a014b318fd3efd65b39b48818c 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, Chair hat off On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote: > hi j-l > >> -----Original Message----- >> From: LE ROUX Jean-Louis RD-CORE-LAN >> [mailto:jeanlouis.leroux@orange-ftgroup.com] >> Sent: Wednesday, August 15, 2007 2:09 PM >> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org >> Subject: RE: [Pce] New PCE working group I-Ds >> >> Hi Dimitri, >> >> Thanks for these comments. >> >> Please see inline, >> >> >>> -----Message d'origine----- >>> De : PAPADIMITRIOU Dimitri >>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>> Envoy=E9 : mardi 14 ao=FBt 2007 21:04 >>> =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org >>> Objet : RE: [Pce] New PCE working group I-Ds >>> >>> >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Sunday, August 12, 2007 5:32 PM >>>> To: pce@ietf.org >>>> Subject: [Pce] New PCE working group I-Ds >>>> >>>> Hi, >>>> >>>> The meeting in Chicago was broadly in support of adopting >>> two I-Ds as >>>> working group drafts: >>>> >>>> - Encoding of Objective Functions in Path Computation >> Element (PCE) >>>> communication and discovery protocols >>>> draft-leroux-pce-of-01.txt >>> >>> ok, three comments though: >>> >>> - units B-R is from def. speed(bps)-res.capacity(b) -> ? >>> please check >> >> B is in bps and R is in bps. >> B-R is the actual bandwidth consumption on the link, in bps. >> We will clarify the units in next revision. > > i thought that capacity/residual bandwidth was expressed in b > and you were using the term speed for bps - pls check > >>> - still unclear to me whether isis pce disc. will or not use a >>> separate inst. (cf. gen-app discussion at isis working group) >> >> ISIS pce disc relies on procedures defined in 4971. >> This is a deployment issue to use same or separate instances. > > do you assume that you would leave such choice possible ? i > was left with the impression after last isis mtg discussion > that there is a real incentive for making this a recommended > behavior Just to avoid confusion: the PCED is being carried within the ISIS Router Capability TLV, the processing of which is defined in RFC4971. > >>> - question about oscillation effects resulting from opposed obj. >>> adv. from diff. pce's >> >> Would you please clarify and provide an example? > > PCE_1 advertizing OF_1 attracts all demands in normal > conditions while PCE_2 advertizing OF_2 attracts demands > after failure/re-routing or other rare event > > hence, you would then be balancing between both PCEs > after failure and when reverting and back again if the > failure occur once more (e.g. flapping) > > i am not saying this will happen but heterogeneity in > OF advertized may lead to unbalanced request between > PCEs Which might precisely be a deployment objective. Thanks. JP. > > thanks, > -d. > >> Regards, >> >> JL >> >>> >>>> - Diff-Serv Aware Class Type Object for Path Computation Element >>>> Communication Protocol draft-sivabalan-pce-dste-01.txt >>> >>> architectural impact to be clarified before moving forward i >>> think that the important disc. point is whether such info >>> obtained from TED or via other means >>> >>> also from >>> >>> * 13) Diff-Serv Aware Class Type Object for Path Computation Element >>> * Communication Protocol >>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] >>> * >>> * Pce does not know class pool. >>> * Dimitri: in interprovider context, how do you assure global >>> significance? >>> * Jon: this is an issue not tackled here. >>> * Adrian: how PCE has knowledge class pool ? You would >>> suggest to build this knowledge based on IGP >>> * flooded information ? >>> * JP: please respin the draft tackling issue raised by Dimitri >>> * Not many people red the draft >>> >>> -> draft still does not seem to address that issue. >>> >>>> Can you please indicate your opinion. >>>> >>>> >>>> Now that the inter-AS requirements work is stable, the >>> authors of two >>>> I-Ds related to the use of PCE for P2MP path computations >>> (Adrian is >>>> one of the >>>> authors) have asked us to look at adopting this work. We >>> think that a >>>> little more discussion is needed first, and have asked them >>> to present >>>> the I-Ds in Vancouver so that we can make a decision immediately >>>> afterwards. Please have a look at the I-Ds and send your >>> comments to >>>> the mailing list. >>>> >>>> - PCC-PCE Communication Requirements for Point to Multipoint >>>> Multiprotocol Label Switching Traffic Engineering (MPLS-TE) >>>> draft-yasukawa-pce-p2mp-req-02.txt >>>> >>>> - Applicability of the Path Computation Element (PCE) to >>>> Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) >>>> and Generalized MPLS (GMPLS) Traffic Engineering (TE) >>>> draft-yasukawa-pce-p2mp-app-00.txt >>>> >>>> Thanks, >>>> JP and Adrian >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> > > > _______________________________________________ > 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 Thu Aug 16 03:19:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZcC-0002Zh-V9; Thu, 16 Aug 2007 03:17:56 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILZcC-0002Z0-AF for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 03:17:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZcB-0002YL-QM for pce@ietf.org; Thu, 16 Aug 2007 03:17:55 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILZcA-0005AC-VW for pce@ietf.org; Thu, 16 Aug 2007 03:17:55 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILZc4-0008XF-VH; Thu, 16 Aug 2007 07:17:50 +0000 Message-ID: <46C3F9F9.7030805@psg.com> Date: Thu, 16 Aug 2007 09:17:13 +0200 From: dimitri papadimitriou User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] New PCE working group I-Ds References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com> <3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com> In-Reply-To: <3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -104.1 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi JP Vasseur wrote: > Hi, > > Chair hat off > > On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote: > >> hi j-l >> >>> -----Original Message----- >>> From: LE ROUX Jean-Louis RD-CORE-LAN >>> [mailto:jeanlouis.leroux@orange-ftgroup.com] >>> Sent: Wednesday, August 15, 2007 2:09 PM >>> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org >>> Subject: RE: [Pce] New PCE working group I-Ds >>> >>> Hi Dimitri, >>> >>> Thanks for these comments. >>> >>> Please see inline, >>> >>> >>>> -----Message d'origine----- >>>> De : PAPADIMITRIOU Dimitri >>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>> Envoyé : mardi 14 août 2007 21:04 >>>> À : zzx-adrian@olddog.co.uk; pce@ietf.org >>>> Objet : RE: [Pce] New PCE working group I-Ds >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>> Sent: Sunday, August 12, 2007 5:32 PM >>>>> To: pce@ietf.org >>>>> Subject: [Pce] New PCE working group I-Ds >>>>> >>>>> Hi, >>>>> >>>>> The meeting in Chicago was broadly in support of adopting >>>> two I-Ds as >>>>> working group drafts: >>>>> >>>>> - Encoding of Objective Functions in Path Computation >>> Element (PCE) >>>>> communication and discovery protocols >>>>> draft-leroux-pce-of-01.txt >>>> >>>> ok, three comments though: >>>> >>>> - units B-R is from def. speed(bps)-res.capacity(b) -> ? >>>> please check >>> >>> B is in bps and R is in bps. >>> B-R is the actual bandwidth consumption on the link, in bps. >>> We will clarify the units in next revision. >> >> i thought that capacity/residual bandwidth was expressed in b >> and you were using the term speed for bps - pls check >> >>>> - still unclear to me whether isis pce disc. will or not use a >>>> separate inst. (cf. gen-app discussion at isis working group) >>> >>> ISIS pce disc relies on procedures defined in 4971. >>> This is a deployment issue to use same or separate instances. >> >> do you assume that you would leave such choice possible ? i >> was left with the impression after last isis mtg discussion >> that there is a real incentive for making this a recommended >> behavior > > Just to avoid confusion: the PCED is being carried within the ISIS > Router Capability TLV, the processing of which is defined in RFC4971. indeed, i am not referring to 4971 at such, i am referring to the fact that if exchanging non-routing info w/ is-is result in recommending separated instance then the ISIS PCE disc. w-g doc becomes a prime candidate for such recommendation. just a matter of consistency. >>>> - question about oscillation effects resulting from opposed obj. >>>> adv. from diff. pce's >>> >>> Would you please clarify and provide an example? >> >> PCE_1 advertizing OF_1 attracts all demands in normal >> conditions while PCE_2 advertizing OF_2 attracts demands >> after failure/re-routing or other rare event >> >> hence, you would then be balancing between both PCEs >> after failure and when reverting and back again if the >> failure occur once more (e.g. flapping) >> >> i am not saying this will happen but heterogeneity in >> OF advertized may lead to unbalanced request between >> PCEs > > Which might precisely be a deployment objective. then how do you ensure that prevent the oscillation effect ? thanks, -d. > Thanks. > > JP. > >> >> thanks, >> -d. >> >>> Regards, >>> >>> JL >>> >>>> >>>>> - Diff-Serv Aware Class Type Object for Path Computation Element >>>>> Communication Protocol draft-sivabalan-pce-dste-01.txt >>>> >>>> architectural impact to be clarified before moving forward i >>>> think that the important disc. point is whether such info >>>> obtained from TED or via other means >>>> >>>> also from >>>> >>>> * 13) Diff-Serv Aware Class Type Object for Path Computation Element >>>> * Communication Protocol >>>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] >>>> * >>>> * Pce does not know class pool. >>>> * Dimitri: in interprovider context, how do you assure global >>>> significance? >>>> * Jon: this is an issue not tackled here. >>>> * Adrian: how PCE has knowledge class pool ? You would >>>> suggest to build this knowledge based on IGP >>>> * flooded information ? >>>> * JP: please respin the draft tackling issue raised by Dimitri >>>> * Not many people red the draft >>>> >>>> -> draft still does not seem to address that issue. >>>> >>>>> Can you please indicate your opinion. >>>>> >>>>> >>>>> Now that the inter-AS requirements work is stable, the >>>> authors of two >>>>> I-Ds related to the use of PCE for P2MP path computations >>>> (Adrian is >>>>> one of the >>>>> authors) have asked us to look at adopting this work. We >>>> think that a >>>>> little more discussion is needed first, and have asked them >>>> to present >>>>> the I-Ds in Vancouver so that we can make a decision immediately >>>>> afterwards. Please have a look at the I-Ds and send your >>>> comments to >>>>> the mailing list. >>>>> >>>>> - PCC-PCE Communication Requirements for Point to Multipoint >>>>> Multiprotocol Label Switching Traffic Engineering (MPLS-TE) >>>>> draft-yasukawa-pce-p2mp-req-02.txt >>>>> >>>>> - Applicability of the Path Computation Element (PCE) to >>>>> Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) >>>>> and Generalized MPLS (GMPLS) Traffic Engineering (TE) >>>>> draft-yasukawa-pce-p2mp-app-00.txt >>>>> >>>>> Thanks, >>>>> JP and Adrian >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 16 04:22:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILabG-0000lt-RL; Thu, 16 Aug 2007 04:21:02 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILabF-0000lo-T3 for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 04:21:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILabF-0000lg-F2 for pce@ietf.org; Thu, 16 Aug 2007 04:21:01 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILabF-0006UH-08 for pce@ietf.org; Thu, 16 Aug 2007 04:21:01 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILabC-000GOv-NS; Thu, 16 Aug 2007 08:21:00 +0000 Message-ID: <46C408C7.1080409@psg.com> Date: Thu, 16 Aug 2007 10:20:23 +0200 From: dimitri papadimitriou User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: JP Vasseur Subject: PCE monitoring doc (was Re: [Pce] IPR PCE Monitoring) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -104.2 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p as far as i remember, this doc. is still open for discussion from San Diego and Prague mtg discussion. here below for the record v03 has been reworked but does not provide answer to the concerns expressed so far - quoting the doc. > In PCE-based environments, it is critical to monitor the state of the critical for what ? if computation time is an issue why delegate it (isn't that the safest assumption ?) > path computation chain for troubeshooting and performance monitoring > purposes: troubleshooting of what ? if there is congestion/troubles how would you ensure the information received back is accurate ? > liveness of each element (PCE) involved in the PCE chain, if i well remember the PCE is a client-server model (fundamental assumption about the PCE approach) hence, why the client needs to know the "chain" of PCE servers ? > detection of potential resource contention states a t[0] contention, at t[1] message for perf.mon -> are running conditions identical ? since probabilisticaly, not what is the expectation behind this mechanism ? would it be possible to have a "curve" of the deterioration of the performance as with an increasing number of computed path the number of "monitoring messages" will also increase ? > statistics in term of path computation times are examples of such > metrics of interest. interest to who and for which purpose (detection is fine but what is the issue to be solved) ? like any system, PCE requires suitable planning and dimensioning wrt to perf.objectives i have impression that these fundamental design steps are skipped. let's start discussion with this. side note: the document states "In this document we call a "state metric" a metric that characterizes a PCE state" -> need to define the latter. thanks, -d. JP Vasseur wrote: > Hi, > > Just let you know about an IPR disclosure that has been filed with the > IETF in relation to > http://tools.ietf.org/id/draft-vasseur-pce-monitoring-03.txt. You can > see the disclosure at https://datatracker.ietf.org/ipr/872/ and see the > terms offered by the IPR claimant. > > Thanks, > > JP. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 16 05:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbMy-0003gp-Gm; Thu, 16 Aug 2007 05:10:20 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILbMw-0003gY-IH for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 05:10:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbMv-0003g1-6t for pce@ietf.org; Thu, 16 Aug 2007 05:10:18 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILbMt-0007ee-CJ for pce@ietf.org; Thu, 16 Aug 2007 05:10:17 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 11:10:08 +0200 Received: from 10.193.106.56 ([10.193.106.56]) by ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) via Exchange Front-End Server parowa2 ([10.193.117.117]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Aug 2007 09:10:08 +0000 MIME-Version: 1.0 Subject: =?iso-8859-1?Q?RE=A0:_[Pce]_New_PCE_working_group_I-Ds?= From: LE ROUX Jean-Louis RD-CORE-LAN In-Reply-To: <46C3F9F9.7030805@psg.com> References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D4 3AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380EDCCF4@FR VELSMBS22.ad2.ad.alcatel.com><3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com>, <46C3F9F9.7030805@psg.com> To: , JP Vasseur Thread-Topic: [Pce] New PCE working group I-Ds Thread-Index: Acff43+q6BwMd8wVTmaWXAiolehXXgAAbZQe Date: Thu, 16 Aug 2007 11:09:55 +0200 Message-ID: <04C57FF1-6023-4C4E-A009-AAC0F3325DFC@mimectl> X-Mailer: Microsoft Outlook Web Access 6.5.7232.34 X-MimeCtl: Produced By Microsoft Exchange V6.5.7232.34 X-OriginalArrivalTime: 16 Aug 2007 09:10:08.0873 (UTC) FILETIME=[3E478D90:01C7DFE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c8611c7316981838cbe4195d07ac7fdb 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="===============0049638060==" Errors-To: pce-bounces@lists.ietf.org --===============0049638060== Content-Type: multipart/alternative; boundary="_5FF37498-96AC-4BAD-9BB4-93FD8A790BC8_" --_5FF37498-96AC-4BAD-9BB4-93FD8A790BC8_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable >> PCE_1 advertizing OF_1 attracts all demands in normal >> conditions while PCE_2 advertizing OF_2 attracts demands >> after failure/re-routing or other rare event >> >> hence, you would then be balancing between both PCEs >> after failure and when reverting and back again if the >> failure occur once more (e.g. flapping) >> >> i am not saying this will happen but heterogeneity in >> OF advertized may lead to unbalanced request between >> PCEs > > Which might precisely be a deployment objective. >then how do you ensure that prevent the oscillation effect ? The failure example you provide is solved by fixing flapping with a dampeni= ng mechanism, this is not a PCE issue by the way... Would you please provide a practical example where heterogeneity leads to o= scillations? Regards, JL De: dimitri papadimitriou Date: jeu. 16/08/2007 09:17 =C0: JP Vasseur Cc: pce@ietf.org Objet : Re: [Pce] New PCE working group I-Ds hi JP Vasseur wrote: > Hi, >=20 > Chair hat off >=20 > On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote: >=20 >> hi j-l >> >>> -----Original Message----- >>> From: LE ROUX Jean-Louis RD-CORE-LAN >>> [mailto:jeanlouis.leroux@orange-ftgroup.com] >>> Sent: Wednesday, August 15, 2007 2:09 PM >>> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org >>> Subject: RE: [Pce] New PCE working group I-Ds >>> >>> Hi Dimitri, >>> >>> Thanks for these comments. >>> >>> Please see inline, >>> >>> >>>> -----Message d'origine----- >>>> De : PAPADIMITRIOU Dimitri >>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>> Envoy=E9 : mardi 14 ao=FBt 2007 21:04 >>>> =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org >>>> Objet : RE: [Pce] New PCE working group I-Ds >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>> Sent: Sunday, August 12, 2007 5:32 PM >>>>> To: pce@ietf.org >>>>> Subject: [Pce] New PCE working group I-Ds >>>>> >>>>> Hi, >>>>> >>>>> The meeting in Chicago was broadly in support of adopting >>>> two I-Ds as >>>>> working group drafts: >>>>> >>>>> - Encoding of Objective Functions in Path Computation >>> Element (PCE) >>>>> communication and discovery protocols >>>>> draft-leroux-pce-of-01.txt >>>> >>>> ok, three comments though: >>>> >>>> - units B-R is from def. speed(bps)-res.capacity(b) -> ? >>>> please check >>> >>> B is in bps and R is in bps. >>> B-R is the actual bandwidth consumption on the link, in bps. >>> We will clarify the units in next revision. >> >> i thought that capacity/residual bandwidth was expressed in b >> and you were using the term speed for bps - pls check >> >>>> - still unclear to me whether isis pce disc. will or not use a >>>> separate inst. (cf. gen-app discussion at isis working group) >>> >>> ISIS pce disc relies on procedures defined in 4971. >>> This is a deployment issue to use same or separate instances. >> >> do you assume that you would leave such choice possible ? i >> was left with the impression after last isis mtg discussion >> that there is a real incentive for making this a recommended >> behavior >=20 > Just to avoid confusion: the PCED is being carried within the ISIS > Router Capability TLV, the processing of which is defined in RFC4971. indeed, i am not referring to 4971 at such, i am referring to the fact that if exchanging non-routing info w/ is-is result in recommending=20 separated instance then the ISIS PCE disc. w-g doc becomes a prime=20 candidate for such recommendation. just a matter of consistency. >>>> - question about oscillation effects resulting from opposed obj. >>>> adv. from diff. pce's >>> >>> Would you please clarify and provide an example? >> >> PCE_1 advertizing OF_1 attracts all demands in normal >> conditions while PCE_2 advertizing OF_2 attracts demands >> after failure/re-routing or other rare event >> >> hence, you would then be balancing between both PCEs >> after failure and when reverting and back again if the >> failure occur once more (e.g. flapping) >> >> i am not saying this will happen but heterogeneity in >> OF advertized may lead to unbalanced request between >> PCEs >=20 > Which might precisely be a deployment objective. then how do you ensure that prevent the oscillation effect ? thanks, -d. > Thanks. >=20 > JP. >=20 >> >> thanks, >> -d. >> >>> Regards, >>> >>> JL >>> >>>> >>>>> - Diff-Serv Aware Class Type Object for Path Computation Element >>>>> Communication Protocol draft-sivabalan-pce-dste-01.txt >>>> >>>> architectural impact to be clarified before moving forward i >>>> think that the important disc. point is whether such info >>>> obtained from TED or via other means >>>> >>>> also from >>>> >>>> * 13) Diff-Serv Aware Class Type Object for Path Computation Element >>>> * Communication Protocol >>>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] >>>> * >>>> * Pce does not know class pool. >>>> * Dimitri: in interprovider context, how do you assure global >>>> significance? >>>> * Jon: this is an issue not tackled here. >>>> * Adrian: how PCE has knowledge class pool ? You would >>>> suggest to build this knowledge based on IGP >>>> * flooded information ? >>>> * JP: please respin the draft tackling issue raised by Dimitri >>>> * Not many people red the draft >>>> >>>> -> draft still does not seem to address that issue. >>>> >>>>> Can you please indicate your opinion. >>>>> >>>>> >>>>> Now that the inter-AS requirements work is stable, the >>>> authors of two >>>>> I-Ds related to the use of PCE for P2MP path computations >>>> (Adrian is >>>>> one of the >>>>> authors) have asked us to look at adopting this work. We >>>> think that a >>>>> little more discussion is needed first, and have asked them >>>> to present >>>>> the I-Ds in Vancouver so that we can make a decision immediately >>>>> afterwards. Please have a look at the I-Ds and send your >>>> comments to >>>>> the mailing list. >>>>> >>>>> - PCC-PCE Communication Requirements for Point to Multipoint >>>>> Multiprotocol Label Switching Traffic Engineering (MPLS-TE) >>>>> draft-yasukawa-pce-p2mp-req-02.txt >>>>> >>>>> - Applicability of the Path Computation Element (PCE) to >>>>> Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) >>>>> and Generalized MPLS (GMPLS) Traffic Engineering (TE) >>>>> draft-yasukawa-pce-p2mp-app-00.txt >>>>> >>>>> Thanks, >>>>> JP and Adrian >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 > . >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --_5FF37498-96AC-4BAD-9BB4-93FD8A790BC8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
&= gt;> PCE_1 advertizing OF_1 attracts all demands in normal
>> c= onditions while PCE_2 advertizing OF_2 attracts demands
>> after f= ailure/re-routing or other rare event
>>
>> hence, you wo= uld then be balancing between both PCEs
>> after failure and when = reverting and back again if the
>> failure occur once more (e.g. f= lapping)
>>
>> i am not saying this will happen but heter= ogeneity in
>> OF advertized may lead to unbalanced request betwee= n
>> PCEs
>
> Which might precisely be a deployment ob= jective.

>then how do you ensure that prevent the oscillation eff= ect ?
The failure exam= ple you provide is solved by fixing flapping with a dampening mechanis= m, this is not a PCE issue by the way...
 
Would you please provide a = practical example where heterogeneity leads to oscillations?
 
Regards,<= /DIV>
 
JL
<= /DIV>

De: dimitri papadimitriou
Date: jeu. 16/08/2007 09:17
=C0: JP Vasseur
Cc: pce@ietf.o= rg
Objet : Re: [Pce] New PCE working group I-Ds

hi

JP Vasseur wrote:
> Hi,
>=20
> Chair hat off
>=20
> On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote:
>=20
>> hi j-l
>>
>>> -----Original Message-----
>>> From: LE ROUX Jean-Louis RD-CORE-LAN
>>> [mailto:jeanlouis.leroux@orange-ftgroup.com]
>>> Sent: Wednesday, August 15, 2007 2:09 PM
>>> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org
>>> Subject: RE: [Pce] New PCE working group I-Ds
>>>
>>> Hi Dimitri,
>>>
>>> Thanks for these comments.
>>>
>>> Please see inline,
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : PAPADIMITRIOU Dimitri
>>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
>>>> Envoy=E9 : mardi 14 ao=FBt 2007 21:04
>>>> =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org
>>>> Objet : RE: [Pce] New PCE working group I-Ds
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>>>>> Sent: Sunday, August 12, 2007 5:32 PM
>>>>> To: pce@ietf.org
>>>>> Subject: [Pce] New PCE working group I-Ds
>>>>>
>>>>> Hi,
>>>>>
>>>>> The meeting in Chicago was broadly in support of adopt=
ing
>>>> two I-Ds as
>>>>> working group drafts:
>>>>>
>>>>> - Encoding of Objective Functions in Path Computation
>>> Element (PCE)
>>>>>   communication and discovery protocols
>>>>>   draft-leroux-pce-of-01.txt
>>>>
>>>> ok, three comments though:
>>>>
>>>> - units B-R is from def. speed(bps)-res.capacity(b) -> =
?
>>>> please check
>>>
>>> B is in bps and R is in bps.
>>> B-R is the actual bandwidth consumption on the link, in bps.
>>> We will clarify the units in next revision.
>>
>> i thought that capacity/residual bandwidth was expressed in b
>> and you were using the term speed for bps - pls check
>>
>>>> - still unclear to me whether isis pce disc. will or not u=
se a
>>>>   separate inst. (cf. gen-app discussion at isis working g=
roup)
>>>
>>> ISIS pce disc relies on procedures defined in 4971.
>>> This is a deployment issue to use same or separate instances.
>>
>> do you assume that you would leave such choice possible ? i
>> was left with the impression after last isis mtg discussion
>> that there is a real incentive for making this a recommended
>> behavior
>=20
> Just to avoid confusion: the PCED is being carried within the ISIS
> Router Capability TLV, the processing of which is defined in RFC4971.

indeed, i am not referring to 4971 at such, i am referring to the
fact that if exchanging non-routing info w/ is-is result in recommending=20
separated instance then the ISIS PCE disc. w-g doc becomes a prime=20
candidate for such recommendation. just a matter of consistency.

>>>> - question about oscillation effects resulting from oppose=
d obj.
>>>>   adv. from diff. pce's
>>>
>>> Would you please clarify and provide an example?
>>
>> PCE_1 advertizing OF_1 attracts all demands in normal
>> conditions while PCE_2 advertizing OF_2 attracts demands
>> after failure/re-routing or other rare event
>>
>> hence, you would then be balancing between both PCEs
>> after failure and when reverting and back again if the
>> failure occur once more (e.g. flapping)
>>
>> i am not saying this will happen but heterogeneity in
>> OF advertized may lead to unbalanced request between
>> PCEs
>=20
> Which might precisely be a deployment objective.

then how do you ensure that prevent the oscillation effect ?

thanks,
-d.
> Thanks.
>=20
> JP.
>=20
>>
>> thanks,
>> -d.
>>
>>> Regards,
>>>
>>> JL
>>>
>>>>
>>>>> - Diff-Serv Aware Class Type Object for Path Computati=
on Element
>>>>>   Communication Protocol draft-sivabalan-pce-dste-01.t=
xt
>>>>
>>>> architectural impact to be clarified before moving forward=
 i
>>>> think that the important disc. point is whether such info
>>>> obtained from TED or via other means
>>>>
>>>> also from <http://www3.ietf.org/proceedings/07mar/minut=
es/pce.txt>
>>>>
>>>> * 13) Diff-Serv Aware Class Type Object for Path Computati=
on Element
>>>> * Communication Protocol
>>>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95]
>>>> *
>>>> * Pce does not know class pool.
>>>> * Dimitri: in interprovider context, how do you assure glo=
bal
>>>> significance?
>>>> * Jon: this is an issue not tackled here.
>>>> * Adrian: how PCE has knowledge class pool ? You would
>>>> suggest to build this knowledge based on IGP
>>>> * flooded information ?
>>>> * JP: please respin the draft tackling issue raised by Dim=
itri
>>>> * Not many people red the draft
>>>>
>>>> -> draft still does not seem to address that issue.
>>>>
>>>>> Can you please indicate your opinion.
>>>>>
>>>>>
>>>>> Now that the inter-AS requirements work is stable, the
>>>> authors of two
>>>>> I-Ds related to the use of PCE for P2MP path computati=
ons
>>>> (Adrian is
>>>>> one of the
>>>>> authors) have asked us to look at adopting this work. =
We
>>>> think that a
>>>>> little more discussion is needed first, and have asked=
 them
>>>> to present
>>>>> the I-Ds in Vancouver so that we can make a decision i=
mmediately
>>>>> afterwards. Please have a look at the I-Ds and send yo=
ur
>>>> comments to
>>>>> the mailing list.
>>>>>
>>>>> - PCC-PCE Communication Requirements for Point to Mult=
ipoint
>>>>>   Multiprotocol Label Switching Traffic Engineering (M=
PLS-TE)
>>>>>   draft-yasukawa-pce-p2mp-req-02.txt
>>>>>
>>>>> - Applicability of the Path Computation Element (PCE) =
to
>>>>>    Point-to-Multipoint (P2MP) Multiprotocol Label Swit=
ching (MPLS)
>>>>>    and Generalized MPLS (GMPLS) Traffic Engineering (T=
E)
>>>>>    draft-yasukawa-pce-p2mp-app-00.txt
>>>>>
>>>>> Thanks,
>>>>> JP and Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pce mailing list
>>>>> Pce@lists.ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pce mailing list
>>>> Pce@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>
>>>
>>
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/pce
>=20
>=20
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
>=20
> .
>=20


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--_5FF37498-96AC-4BAD-9BB4-93FD8A790BC8_-- --===============0049638060== 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 --===============0049638060==-- From pce-bounces@lists.ietf.org Thu Aug 16 05:32:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbgx-0004Uk-Hj; Thu, 16 Aug 2007 05:30:59 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILbgw-0004N0-4z for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 05:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILbgv-0004KB-Ne for pce@ietf.org; Thu, 16 Aug 2007 05:30:57 -0400 Received: from asmtp1.iomartmail.com ([62.128.201.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILbgu-0008Ii-6G for pce@ietf.org; Thu, 16 Aug 2007 05:30:57 -0400 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7G9Ur0g009539; Thu, 16 Aug 2007 10:30:53 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id l7G9UkqE009413; Thu, 16 Aug 2007 10:30:50 +0100 Message-ID: <03a401c7dfe8$1bcf0fb0$0300a8c0@your029b8cecfe> From: "Adrian Farrel" To: , "JP Vasseur" References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com><3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com> <46C3F9F9.7030805@psg.com> Date: Thu, 16 Aug 2007 10:30:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Les Ginsberg , Christian Hopps , pce@ietf.org, dward@cisco.com Subject: [Pce] ISIS Separate instances [Was: New PCE working group I-Ds] 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 >>>>> - still unclear to me whether isis pce disc. will or not use a >>>>> separate inst. (cf. gen-app discussion at isis working group) >>>> >>>> ISIS pce disc relies on procedures defined in 4971. >>>> This is a deployment issue to use same or separate instances. >>> >>> do you assume that you would leave such choice possible ? i >>> was left with the impression after last isis mtg discussion >>> that there is a real incentive for making this a recommended >>> behavior >> >> Just to avoid confusion: the PCED is being carried within the ISIS >> Router Capability TLV, the processing of which is defined in RFC4971. > > indeed, i am not referring to 4971 at such, i am referring to the > fact that if exchanging non-routing info w/ is-is result in recommending > separated instance then the ISIS PCE disc. w-g doc becomes a prime > candidate for such recommendation. just a matter of consistency. My understanding of the discussion in the ISIS working group is that: - They are tending towards believing that there should be a separation between flooding of IP link-state information and *all* other information - They think that such a separation might reasonably be handled by using multiple (greater than one) instances of ISIS - They have not yet reached a conclusion as to whether existing extensions fall into this category, but there was building opinion that TE advertisements might be strong candidates for off-loading to a second instance - The Router Capability TLV would also be up for consideration No slides for this topic from the ISIS working group in Chicago seem to have been posted yet. The most recent version of the relevant I-D appears to be http://www.ietf.org/internet-drafts/draft-ginsberg-isis-genapp-01.txt although I know Les was planning some updates as a result of the Chicago meeting. It seems to me that: 1. The ISIS working group is not going to reach a conclusion on this in a hurry. 2. When they do reach a conclusion we MUST fall in with it. 3. In the mean time, just as TE and Router Caps are currently carried in a single instance, the PCE discovery will be so carried. 4. You should all contribute to this discussion on the ISIS mailing list. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 16 08:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILeUB-00020l-2a; Thu, 16 Aug 2007 08:29:59 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILeU9-00020d-Iy for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 08:29:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILeU9-00020R-71 for pce@ietf.org; Thu, 16 Aug 2007 08:29:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILeU8-0005qD-Ap for pce@ietf.org; Thu, 16 Aug 2007 08:29:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2007 08:29:56 -0400 X-IronPort-AV: i="4.19,271,1183348800"; d="scan'208"; a="68157115:sNHT61215310" 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 l7GCTtOf022810; Thu, 16 Aug 2007 08:29:55 -0400 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 l7GCTrjI016108; Thu, 16 Aug 2007 12:29:53 GMT 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); Thu, 16 Aug 2007 08:29:53 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 08:29:52 -0400 In-Reply-To: <46C3F9F9.7030805@psg.com> References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> <8144761F31F48D43AD53D09F5350E380EDCC7A@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380EDCCF4@FRVELSMBS22.ad2.ad.alcatel.com> <3E693EBA-BB4C-4CD4-923B-A8C71AC47214@cisco.com> <46C3F9F9.7030805@psg.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1939BD60-A575-405D-8F64-141C05EFB74B@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] New PCE working group I-Ds Date: Thu, 16 Aug 2007 08:29:20 -0400 To: dpapadimitriou@psg.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Aug 2007 12:29:52.0639 (UTC) FILETIME=[252920F0:01C7E001] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7388; t=1187267395; x=1188131395; 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:=20Re=3A=20[Pce]=20New=20PCE=20working=20group=20I-Ds |Sender:=20 |To:=20dpapadimitriou@psg.com; bh=gC1N3L7Fd+bj6Rpa/W8NKG7VE7DdqjJMitaVpHIaFQM=; b=afF4oRhweYCV03ue/N2lox3VuErB4d83cw3ZV+N/egho765BZ9QPGbVb1mAuIrD9T225JNe/ 8Wgfl1EQYdEpI4+evJCLAu8pH3P45+6Tx83EBol2wQz96pCsz2gKxQnt; 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: bc6181926481d86059e678c9f7cb8b34 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, On Aug 16, 2007, at 3:17 AM, dimitri papadimitriou wrote: > hi > > JP Vasseur wrote: >> Hi, >> Chair hat off >> On Aug 15, 2007, at 4:22 PM, PAPADIMITRIOU Dimitri wrote: >>> hi j-l >>> >>>> -----Original Message----- >>>> From: LE ROUX Jean-Louis RD-CORE-LAN >>>> [mailto:jeanlouis.leroux@orange-ftgroup.com] >>>> Sent: Wednesday, August 15, 2007 2:09 PM >>>> To: PAPADIMITRIOU Dimitri; adrian@olddog.co.uk; pce@ietf.org >>>> Subject: RE: [Pce] New PCE working group I-Ds >>>> >>>> Hi Dimitri, >>>> >>>> Thanks for these comments. >>>> >>>> Please see inline, >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : PAPADIMITRIOU Dimitri >>>>> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] >>>>> Envoy=E9 : mardi 14 ao=FBt 2007 21:04 >>>>> =C0 : zzx-adrian@olddog.co.uk; pce@ietf.org >>>>> Objet : RE: [Pce] New PCE working group I-Ds >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>> Sent: Sunday, August 12, 2007 5:32 PM >>>>>> To: pce@ietf.org >>>>>> Subject: [Pce] New PCE working group I-Ds >>>>>> >>>>>> Hi, >>>>>> >>>>>> The meeting in Chicago was broadly in support of adopting >>>>> two I-Ds as >>>>>> working group drafts: >>>>>> >>>>>> - Encoding of Objective Functions in Path Computation >>>> Element (PCE) >>>>>> communication and discovery protocols >>>>>> draft-leroux-pce-of-01.txt >>>>> >>>>> ok, three comments though: >>>>> >>>>> - units B-R is from def. speed(bps)-res.capacity(b) -> ? >>>>> please check >>>> >>>> B is in bps and R is in bps. >>>> B-R is the actual bandwidth consumption on the link, in bps. >>>> We will clarify the units in next revision. >>> >>> i thought that capacity/residual bandwidth was expressed in b >>> and you were using the term speed for bps - pls check >>> >>>>> - still unclear to me whether isis pce disc. will or not use a >>>>> separate inst. (cf. gen-app discussion at isis working group) >>>> >>>> ISIS pce disc relies on procedures defined in 4971. >>>> This is a deployment issue to use same or separate instances. >>> >>> do you assume that you would leave such choice possible ? i >>> was left with the impression after last isis mtg discussion >>> that there is a real incentive for making this a recommended >>> behavior >> Just to avoid confusion: the PCED is being carried within the ISIS >> Router Capability TLV, the processing of which is defined in RFC4971. > > indeed, i am not referring to 4971 at such, i am referring to the > fact that if exchanging non-routing info w/ is-is result in =20 > recommending separated instance then the ISIS PCE disc. w-g doc =20 > becomes a prime candidate for such recommendation. just a matter of =20= > consistency. If the ISIS group leads to the conclusion of using multiple ISIS =20 instances TE related info may be carried within a separate instance, which is =20 fine. As far as the PCED is concerned, the mode of operation is for now compliant to RFC4971. This may also apply to OSPF at some point by the way (at least this has been briefly discussed). Anyway, this is not a PCE related discussion. As far as this ID is concerned, this won't impact its contents since it is carried within the ISIS Router =20 capability. > >>>>> - question about oscillation effects resulting from opposed obj. >>>>> adv. from diff. pce's >>>> >>>> Would you please clarify and provide an example? >>> >>> PCE_1 advertizing OF_1 attracts all demands in normal >>> conditions while PCE_2 advertizing OF_2 attracts demands >>> after failure/re-routing or other rare event >>> >>> hence, you would then be balancing between both PCEs >>> after failure and when reverting and back again if the >>> failure occur once more (e.g. flapping) >>> >>> i am not saying this will happen but heterogeneity in >>> OF advertized may lead to unbalanced request between >>> PCEs >> Which might precisely be a deployment objective. > > then how do you ensure that prevent the oscillation effect ? You're mixing two issues: the fact that the PCEs announce different OF does not by itself lead to oscillation. What you describe above is an example of different use case in normal and failure scenarios which is perfectly fine if the PCE has been configured for doing so. JP. > > thanks, > -d. >> Thanks. >> JP. >>> >>> thanks, >>> -d. >>> >>>> Regards, >>>> >>>> JL >>>> >>>>> >>>>>> - Diff-Serv Aware Class Type Object for Path Computation Element >>>>>> Communication Protocol draft-sivabalan-pce-dste-01.txt >>>>> >>>>> architectural impact to be clarified before moving forward i >>>>> think that the important disc. point is whether such info >>>>> obtained from TED or via other means >>>>> >>>>> also from >>>>> >>>>> * 13) Diff-Serv Aware Class Type Object for Path Computation =20 >>>>> Element >>>>> * Communication Protocol >>>>> * draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] >>>>> * >>>>> * Pce does not know class pool. >>>>> * Dimitri: in interprovider context, how do you assure global >>>>> significance? >>>>> * Jon: this is an issue not tackled here. >>>>> * Adrian: how PCE has knowledge class pool ? You would >>>>> suggest to build this knowledge based on IGP >>>>> * flooded information ? >>>>> * JP: please respin the draft tackling issue raised by Dimitri >>>>> * Not many people red the draft >>>>> >>>>> -> draft still does not seem to address that issue. >>>>> >>>>>> Can you please indicate your opinion. >>>>>> >>>>>> >>>>>> Now that the inter-AS requirements work is stable, the >>>>> authors of two >>>>>> I-Ds related to the use of PCE for P2MP path computations >>>>> (Adrian is >>>>>> one of the >>>>>> authors) have asked us to look at adopting this work. We >>>>> think that a >>>>>> little more discussion is needed first, and have asked them >>>>> to present >>>>>> the I-Ds in Vancouver so that we can make a decision immediately >>>>>> afterwards. Please have a look at the I-Ds and send your >>>>> comments to >>>>>> the mailing list. >>>>>> >>>>>> - PCC-PCE Communication Requirements for Point to Multipoint >>>>>> Multiprotocol Label Switching Traffic Engineering (MPLS-TE) >>>>>> draft-yasukawa-pce-p2mp-req-02.txt >>>>>> >>>>>> - Applicability of the Path Computation Element (PCE) to >>>>>> Point-to-Multipoint (P2MP) Multiprotocol Label Switching =20 >>>>>> (MPLS) >>>>>> and Generalized MPLS (GMPLS) Traffic Engineering (TE) >>>>>> draft-yasukawa-pce-p2mp-app-00.txt >>>>>> >>>>>> Thanks, >>>>>> JP and Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pce mailing list >>>>>> Pce@lists.ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> . _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 16 09:05:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILf0v-0001rM-GV; Thu, 16 Aug 2007 09:03:49 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILf0t-0001q8-Q9 for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 09:03:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILf0t-0001q0-Ef for pce@ietf.org; Thu, 16 Aug 2007 09:03:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILf0s-0006eJ-NS for pce@ietf.org; Thu, 16 Aug 2007 09:03:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2007 06:03:45 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="201123990:sNHT4368137148" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7GD3ic8013850; Thu, 16 Aug 2007 06:03:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7GD3UFE020980; Thu, 16 Aug 2007 13:03:44 GMT 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); Thu, 16 Aug 2007 09:03:34 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:03:33 -0400 In-Reply-To: <46C408C7.1080409@psg.com> References: <46C408C7.1080409@psg.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <884A0F77-5D4A-455D-A7A7-C4B4791702F1@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 16 Aug 2007 09:03:01 -0400 To: dpapadimitriou@psg.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Aug 2007 13:03:34.0085 (UTC) FILETIME=[DA094F50:01C7E005] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4556; t=1187269424; x=1188133424; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20PCE=20monitoring=20doc=20 |Sender:=20; bh=oVyZSjqd378SG5tA2ISpXbj3/hrDw4Sb1+YkwkrUiEQ=; b=BNTp5d38etud4Nvv65oRnVpoPWrO/bc+dHEUFlR3C7tIzHVXHMFgQu0+uY9FV2W+cmjUEk6S PtSBL5Cvs6tOrol1IJvRVQrCyLn/eI8Wtu6GMhDiUrNNnFZ46CQhklrg; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pce@ietf.org Subject: [Pce] Re: PCE monitoring doc 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, On Aug 16, 2007, at 4:20 AM, dimitri papadimitriou wrote: > hi j-p > > as far as i remember, this doc. is still open for discussion from > San Diego and Prague mtg discussion. > An ID is always open for discussion as long as it is not an RFC. > here below for the record > > > > v03 has been reworked but does not provide answer to the concerns > expressed so far - quoting the doc. > > > In PCE-based environments, it is critical to monitor the state of > the > > critical for what ? if computation time is an issue why delegate it > (isn't that the safest assumption ?) > Looking like you are quibbling on words here ... Do want to replace "critical" by "useful", is that your point ? > > path computation chain for troubeshooting and performance monitoring > > purposes: > > troubleshooting of what ? I think that I gave this explanation a few times already ... Suppose that the head-end experiences long response times. I think that we can agree on the fact that this is potentially an issue., in which case the user may want to troubleshoot by issuing such a request in order to determine the location (which PCE of the chain) and the root cause. > if there is congestion/troubles how would you ensure the > information received back is accurate ? > The information of the waiting times, CPU utilization, ... is provided by the PCE. The issue of accurateness is no different than for any other information provided for example by the MIB. > > liveness of each element (PCE) involved in the PCE chain, > > if i well remember the PCE is a client-server model (fundamental > assumption about the PCE approach) hence, why the client needs to > know the "chain" of PCE servers ? Strange question ... Try to operate a network and you'll immediately figure out. Back to the previous case, consider the case of an inter-domain TE deployment where the number of PCE chain may potentially be large. Isn't useful during a troubleshooting event for example to know the set of PCEs involved in a PCE chain ? (or to check a particular PCE chain). > > > detection of potential resource contention states > > a t[0] contention, at t[1] message for perf.mon -> are running > conditions identical ? since probabilisticaly, not what is the > expectation behind this mechanism ? > > would it be possible to have a "curve" of the deterioration of the > performance as with an increasing number of computed path the > number of "monitoring messages" will also increase ? Sure but ... this is true for all OAM tools. If you use a ping to locate a congestion spot at the time you get your reply the network state may have changed 10 times ... but if you use it because of a sustained congestion state then the ping may help you to locate the problem. The exact same reasoning applies here. Note that you can also retrieve historical data computed over a period of time, this is a matter of local configuration on the PCE, in which case you could retrieve the averaged (using for example a low pass filter) computation time. > > > statistics in term of path computation times are examples of such > > metrics of interest. > > interest to who and for which purpose (detection is fine but what > is the issue to be solved) ? Again sorry ... but strange question ... Interest to the user of course. Before fixing a problem it is usually useful to locate the root cause of the problem. This tool may help for that purpose. > like any system, PCE requires suitable planning and dimensioning > wrt to perf.objectives i have impression that these fundamental > design steps are skipped. > > let's start discussion with this. > > side note: the document states "In this document we call a "state > metric" a metric that characterizes a PCE state" -> need to define > the latter. Sure. JP. > > thanks, > -d. > > > JP Vasseur wrote: >> Hi, >> Just let you know about an IPR disclosure that has been filed with >> the IETF in relation to http://tools.ietf.org/id/draft-vasseur-pce- >> monitoring-03.txt. You can see the disclosure at https:// >> datatracker.ietf.org/ipr/872/ and see the terms offered by the IPR >> claimant. >> Thanks, >> JP. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> . _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 16 11:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgtb-0007MJ-1M; Thu, 16 Aug 2007 11:04:23 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1ILgbU-0001Qy-Mf for pce-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 10:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgbU-0001Qq-Cp; Thu, 16 Aug 2007 10:45:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgbP-0000BW-2N; Thu, 16 Aug 2007 10:45:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2007 10:45:33 -0400 X-IronPort-AV: i="4.19,272,1183348800"; d="scan'208"; a="129043187:sNHT52284640" 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 l7GEjW6j027611; Thu, 16 Aug 2007 10:45:32 -0400 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 l7GEjSjK028071; Thu, 16 Aug 2007 14:45:32 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:45:28 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:45:28 -0400 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 16 Aug 2007 09:45:23 -0500 From: David Ward To: Adrian Farrel , , JP Vasseur , , David Ward Message-ID: Thread-Topic: ISIS Separate instances [Was: New PCE working group I-Ds] Thread-Index: AcfgFBM7UetsmUwHEdyliQAX8sbpFw== In-Reply-To: <03a401c7dfe8$1bcf0fb0$0300a8c0@your029b8cecfe> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 14:45:28.0225 (UTC) FILETIME=[16590910:01C7E014] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2548; t=1187275532; x=1188139532; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20ISIS=20Separate=20instances=20[Was=3A=20New=20PCE=20w orking=20group=20I-Ds] |Sender:=20 |To:=20Adrian=20Farrel=20, =20, =0A=20=20=20=20=20=20=20=20JP=20Vasseur=20, =20,=0A=20=20=20=20=20=20=20=20David=20Ward=20; bh=syeqWU/PcGgc+FBsy9XMLEnvjXsEvRtHOJUAUHGW+Rw=; b=0PYePPG/cj048FO2mUmg6piFaQ48tacDEsmt52hw8LVcubPyAFwRHA92Wjo8vDYH5Hze4WJk H5mlLg3ZZnrzzc2B32tSbNxJ0yxa2wbb/u52Nk4JX9dczhvKIvNoeeW5; Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Thu, 16 Aug 2007 11:04:22 -0400 Cc: "Les Ginsberg \(ginsberg\)" , Christian Hopps , pce@ietf.org Subject: [Pce] Re: ISIS Separate instances [Was: New PCE working group I-Ds] 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 Adrian - At this point, the summary and conclusion you have below is the only path forward. -DWard On 8/16/07 4:30 AM, "Adrian Farrel" wrote: >>>>>> - still unclear to me whether isis pce disc. will or not use a >>>>>> separate inst. (cf. gen-app discussion at isis working group) >>>>> >>>>> ISIS pce disc relies on procedures defined in 4971. >>>>> This is a deployment issue to use same or separate instances. >>>> >>>> do you assume that you would leave such choice possible ? i >>>> was left with the impression after last isis mtg discussion >>>> that there is a real incentive for making this a recommended >>>> behavior >>> >>> Just to avoid confusion: the PCED is being carried within the ISIS >>> Router Capability TLV, the processing of which is defined in RFC4971. >> >> indeed, i am not referring to 4971 at such, i am referring to the >> fact that if exchanging non-routing info w/ is-is result in recommending >> separated instance then the ISIS PCE disc. w-g doc becomes a prime >> candidate for such recommendation. just a matter of consistency. > > My understanding of the discussion in the ISIS working group is that: > - They are tending towards believing that there should be a separation > between > flooding of IP link-state information and *all* other information > - They think that such a separation might reasonably be handled by using > multiple (greater than one) instances of ISIS > - They have not yet reached a conclusion as to whether existing extensions > fall into this category, but there was building opinion that TE > advertisements > might be strong candidates for off-loading to a second instance > - The Router Capability TLV would also be up for consideration > > No slides for this topic from the ISIS working group in Chicago seem to have > been posted yet. > > The most recent version of the relevant I-D appears to be > http://www.ietf.org/internet-drafts/draft-ginsberg-isis-genapp-01.txt > although I know Les was planning some updates as a result of the Chicago > meeting. > > It seems to me that: > 1. The ISIS working group is not going to reach a conclusion on this > in a hurry. > 2. When they do reach a conclusion we MUST fall in with it. > 3. In the mean time, just as TE and Router Caps are currently > carried in a single instance, the PCE discovery will be so > carried. > 4. You should all contribute to this discussion on the ISIS mailing list. > > Cheers, > Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 20 03:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1M1-0005Wy-6m; Mon, 20 Aug 2007 03:07:13 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IN1M0-0005Wt-Cp for pce-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1Lw-0005Li-Hz for pce@ietf.org; Mon, 20 Aug 2007 03:07:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1Lu-0004IF-Qr for pce@ietf.org; Mon, 20 Aug 2007 03:07:08 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IN1Lr-0002Yq-Jd; Mon, 20 Aug 2007 07:07:05 +0000 Message-ID: <46C93D96.2090805@psg.com> Date: Mon, 20 Aug 2007 09:07:02 +0200 From: dimitri papadimitriou User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: JP Vasseur References: <46C408C7.1080409@psg.com> <884A0F77-5D4A-455D-A7A7-C4B4791702F1@cisco.com> In-Reply-To: <884A0F77-5D4A-455D-A7A7-C4B4791702F1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -101.8 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: pce@ietf.org Subject: [Pce] Re: PCE monitoring doc X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi, JP Vasseur wrote: > Hi, > > On Aug 16, 2007, at 4:20 AM, dimitri papadimitriou wrote: > >> hi j-p >> >> as far as i remember, this doc. is still open for >> discussion from San Diego and Prague mtg discussion. > > An ID is always open for discussion as long as it is > not an RFC. just want to be sure this doc. is NOT a done deal like presented since a couple of meetings. >> here below for the record >> >> >> >> v03 has been reworked but does not provide answer to the >> concerns expressed so far - quoting the doc. >> >> > In PCE-based environments, it is critical to monitor >> > the state of the >> >> critical for what ? if computation time is an issue why >> delegate it (isn't that the safest assumption ?) > > Looking like you are quibbling on words here ... Do want > to replace "critical" by "useful", is that your point ? this does not answer the real question i think (the real point is why is it "critical" or "useful" to receive this info from the PCE while a local timer on the PCC can very simply determine the delay experienced between initiation of the request and the reception of the response) >> > path computation chain for troubeshooting and >> > performance monitoring purposes: >> >> troubleshooting of what ? > > I think that I gave this explanation a few times already > ... Suppose that the head-end experiences long response > times. I think that we can agree on the fact that this is > potentially an issue., in which case the user may want to > troubleshoot by issuing such a request in order to > determine the location (which PCE of the chain) and the > root cause. does not help. if there are real issues an answer may never be received and the information received may be erroneous anyway note also that it would be rather surprising that PCE and PCC can not make use of local timers to determine such kind of delays (as i said the PCC against the PCE and each PCE against the peering PCE) >> if there is congestion/troubles how would you ensure >> the information received back is accurate ? > > The information of the waiting times, CPU utilization, > ... is provided by the PCE. > > The issue of accurateness is no different than for any > other information provided for example by the MIB. if you seek at MIB information then i suspect that they are also available at the SNMP management level ... why a specific protocol mechanism to correlate it ? i miss why LSR shall now start perform troubleshooting of PCEs ... i thought that PCE where used to decrease load on LSR not the contrary (PCE can be exceptionally blocking / defectuous only otherwise resulting in more troubles than being really improving performance) >> > liveness of each element (PCE) involved in the PCE >> > chain, >> >> if i well remember the PCE is a client-server model >> (fundamental assumption about the PCE approach) hence, >> why the client needs to know the "chain" of PCE servers ? > > Strange question ... Try to operate a network and you'll > immediately figure out. i don't think you have captured the question. the point is not whether the server shall be accountable but why the PCC shall be made aware about the "chain" the notion of the PCE chain is confusing from this point of view > Back to the previous case, consider the case of an inter- > domain TE deployment where the number of PCE chain may > potentially be large. Isn't useful during a troubleshooting > event for example to know the set of PCEs involved in a > PCE chain ? (or to check a particular PCE chain). well i am not sure to follow the operational process you are referring to, if PCCs needs to check/monitoring and validate each computed segment per PCE then it is also better to maintain autonomous segment computation and prevent the overhead of additional cross-verification this triggers to me the following point, before devising methods for troubleshooting and monitoring computational results it may be appropriate to have a much better view of the usage of PCE before progressing on "tools" the same is ongoing at CCAMP where in-depth work has been started in understanding the needs based on the operational practice >> > detection of potential resource contention states >> >> a t[0] contention, at t[1] message for perf.mon -> are >> running conditions identical ? since probabilisticaly, >> not what is the expectation behind this mechanism ? >> >> would it be possible to have a "curve" of the deterioration >> of the performance as with an increasing number of computed >> path the number of "monitoring messages" will also increase ? > > Sure but ... this is true for all OAM tools. nope. it has never been expected that the PCE gets dimensioned to the total number of computed LSP over time (except for the stateful PCEs) meaning that a stateless PCE was only expected to support a certain number of request per unit of time (and this independently of the accumulated number of computed paths) > If you use a ping to locate a congestion spot at the time you > get your reply the network state may have changed 10 times ... > but if you use it because of a sustained congestion state then > the ping may help you to locate the problem. echo request/reply is not equivalent to resource consumption measurement / monitoring on certain nodes and number of cycles required for path computation not sure to really capture the analogy > The exact same reasoning applies here. Note that you can also > retrieve historical data computed over a period of time, this > is a matter of local configuration on the PCE, in which case > you could retrieve the averaged (using for example a low pass > filter) computation time. knowing the computational interval that could result from the use of different PC algorithms and the various conditions (both in terms of input and local resources) i am sure that off-line statistics would be more suitable than real-time collection per PCC >> > statistics in term of path computation times are examples >> > of such metrics of interest. >> >> interest to who and for which purpose (detection is fine but >> what is the issue to be solved) ? > > Again sorry ... but strange question ... Interest to the user > of course. it is not a strange question it is the initial question: which problem are you trying to solve then one could try to assess which method is appropriate > Before fixing a problem it is usually useful to locate the > root cause of the problem. This tool may help for that purpose. hence your problem is the computational limitation of a PCE what a PCC could do about ? do you need to sending back a time value is of any use (delta between send/receive allows the PCC to obtain the same kind of information assuming that the PCE remains "reachable" i.e. no communication channel issue) >> like any system, PCE requires suitable planning and >> dimensioning wrt to perf.objectives i have impression >> that these fundamental design steps are skipped. >> >> let's start discussion with this. >> >> side note: the document states "In this document we >> call a "state metric" a metric that characterizes a >> PCE state" -> need to define the latter. > > Sure. indeed, this question is still open since end of 2004. -d. > JP. > >> >> thanks, >> -d. >> >> >> JP Vasseur wrote: >>> Hi, >>> Just let you know about an IPR disclosure that has been filed with >>> the IETF in relation to >>> http://tools.ietf.org/id/draft-vasseur-pce-monitoring-03.txt. You can >>> see the disclosure at https://datatracker.ietf.org/ipr/872/ and see >>> the terms offered by the IPR claimant. >>> Thanks, >>> JP. >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> . > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 20 04:21:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Uf-000714-DX; Mon, 20 Aug 2007 04:20:13 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IN2Ud-00070z-R3 for pce-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 04:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Ud-00070r-HV for pce@ietf.org; Mon, 20 Aug 2007 04:20:11 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN2Ud-0005uh-54 for pce@ietf.org; Mon, 20 Aug 2007 04:20:11 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 82003EC8D8 for ; Mon, 20 Aug 2007 17:20:08 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [2001:200:601:1a00::10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4137BEC8D6 for ; Mon, 20 Aug 2007 17:20:08 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:200:e01e:f4e7:a7a5:4412]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 355F51E0002 for ; Mon, 20 Aug 2007 17:20:08 +0900 (JST) Message-ID: <46C94EB9.8020902@kddilabs.jp> Date: Mon, 20 Aug 2007 17:20:09 +0900 From: Kenji Kumaki User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: pce@ietf.org Subject: Re: [Pce] New PCE working group I-Ds References: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> In-Reply-To: <011001c7dcf6$ff420210$0300a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 I support these two documents. Thanks, Kenji Adrian Farrel wrote: > Hi, > > The meeting in Chicago was broadly in support of adopting two I-Ds as > working group drafts: > > - Encoding of Objective Functions in Path Computation Element (PCE) > communication and discovery protocols > draft-leroux-pce-of-01.txt > > - Diff-Serv Aware Class Type Object for Path Computation Element > Communication Protocol draft-sivabalan-pce-dste-01.txt > > Can you please indicate your opinion. > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 21 09:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INU3V-0008KQ-1j; Tue, 21 Aug 2007 09:46:01 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1INU3T-0008KL-Ii for pce-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 09:45:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INU3T-0008KD-6d for pce@ietf.org; Tue, 21 Aug 2007 09:45:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INU3R-0006BO-WC for pce@ietf.org; Tue, 21 Aug 2007 09:45:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2007 09:45:56 -0400 X-IronPort-AV: i="4.19,289,1183348800"; d="scan'208"; a="68579469:sNHT68451114" 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 l7LDjvlw003855; Tue, 21 Aug 2007 09:45:57 -0400 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 l7LDjVjk004498; Tue, 21 Aug 2007 13:45:57 GMT 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, 21 Aug 2007 09:45:48 -0400 Received: from [161.44.71.173] ([161.44.71.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:45:48 -0400 In-Reply-To: <46C93D96.2090805@psg.com> References: <46C408C7.1080409@psg.com> <884A0F77-5D4A-455D-A7A7-C4B4791702F1@cisco.com> <46C93D96.2090805@psg.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3492EB8B-E529-4DDC-B905-B31DEFA57155@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 21 Aug 2007 09:45:06 -0400 To: dpapadimitriou@psg.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Aug 2007 13:45:48.0339 (UTC) FILETIME=[94A28830:01C7E3F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10864; t=1187703957; x=1188567957; 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:=20Re=3A=20PCE=20monitoring=20doc |Sender:=20 |To:=20dpapadimitriou@psg.com; bh=dqFa6eUvg8NbDraudjnbqIpzm5+2mxuStgua3xcduZA=; b=PkQyiTyANgXpfKLK+osBHozM9iyCxnL0twOw6F0KRiIto6XskSD7rQmDR0hyIEZMZq12qPMY pUPfUUlnnycQTKbYLZ2/laTvazKLflfePJo5oit+9XVI+ReiEl2z4bzx; 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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: pce@ietf.org Subject: [Pce] Re: PCE monitoring doc 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, On Aug 20, 2007, at 3:07 AM, dimitri papadimitriou wrote: > hi, > > JP Vasseur wrote: >> Hi, >> On Aug 16, 2007, at 4:20 AM, dimitri papadimitriou wrote: >>> hi j-p >>> >>> as far as i remember, this doc. is still open for discussion from >>> San Diego and Prague mtg discussion. >> An ID is always open for discussion as long as it is not an RFC. > > just want to be sure this doc. is NOT a done deal like > presented since a couple of meetings. Not sure what you mean (since it was not presented at all in Chicago), but that's OK. > >>> here below for the record >>> >>> >>> >>> v03 has been reworked but does not provide answer to the concerns >>> expressed so far - quoting the doc. >>> >>> > In PCE-based environments, it is critical to monitor > the >>> state of the >>> >>> critical for what ? if computation time is an issue why delegate >>> it (isn't that the safest assumption ?) >> Looking like you are quibbling on words here ... Do want to >> replace "critical" by "useful", is that your point ? > > this does not answer the real question i think (the real > point is why is it "critical" or "useful" to receive this > info from the PCE while a local timer on the PCC can very > simply determine the delay experienced between initiation > of the request and the reception of the response) > The aim of the newly defined messages is NOT to determine the end to end delay of course *but* each delay along the PCE chain to identify a potential issue, gets statistics, ... If your PCE chain is made of 2 PCEs, it will provide you what delays have been experienced along that chain on each PCE (queueing, processing, ...). >>> > path computation chain for troubeshooting and > performance >>> monitoring purposes: >>> >>> troubleshooting of what ? >> I think that I gave this explanation a few times already ... >> Suppose that the head-end experiences long response times. I think >> that we can agree on the fact that this is >> potentially an issue., in which case the user may want to >> troubleshoot by issuing such a request in order to determine the >> location (which PCE of the chain) and the root cause. > > does not help. if there are real issues an answer may never > be received and the information received may be erroneous > anyway > > note also that it would be rather surprising that PCE and > PCC can not make use of local timers to determine such > kind of delays (as i said the PCC against the PCE and > each PCE against the peering PCE) The local timer gives you the overall end to end time (already available on several PCC/PCE implementations) but does not tell you which delays have been experiences on each element along the PCE chain. You could have a Telnet session on each PCE in your network and upon issuing a request try to log all events and figure this out (try this ...) or have a PCE message that does it for you from the head-end (this is what this ID is about). > >>> if there is congestion/troubles how would you ensure the >>> information received back is accurate ? >> The information of the waiting times, CPU utilization, ... is >> provided by the PCE. >> >> The issue of accurateness is no different than for any other >> information provided for example by the MIB. > > if you seek at MIB information then i suspect that they > are also available at the SNMP management level ... why > a specific protocol mechanism to correlate it ? First I did say that you had similar information provided by SNMP. I was using the example of SNMP answering your point about the accurateness issue. Here we do collect statistics about queueuing delays, processing delays and so on ... so does SNMP, this is no different. Back to your question "Why a specific protocol mechanism to correlate it ?". Because you may want to have on-line mechanisms that do require a NMS system, that's it. Note that this is no different than Ping, LSPPing, ... > > i miss why LSR shall now start perform troubleshooting > of PCEs ... i thought that PCE where used to decrease > load on LSR not the contrary (PCE can be exceptionally > blocking / defectuous only otherwise resulting in more > troubles than being really improving performance) > Dimitri, yes the aim of the PCE is too help solving various issues. Note that in case of inter-area, this is usually not a load issue but a visibility issue, I guess that you noticed that. But when you operate a network you also need tools to make sure that things work as expected and there might be circumstances under which they don't thus the reason for such tools. What a strange discussion ... it looks like you're questioning the usefulness of OAM tools in general ... ? Again look at LSPPing: LSR are of course expected to work, but still OAM tools are useful. >>> > liveness of each element (PCE) involved in the PCE > chain, >>> >>> if i well remember the PCE is a client-server model (fundamental >>> assumption about the PCE approach) hence, why the client needs to >>> know the "chain" of PCE servers ? >> Strange question ... Try to operate a network and you'll >> immediately figure out. > > i don't think you have captured the question. the point > is not whether the server shall be accountable but why > the PCC shall be made aware about the "chain" > > the notion of the PCE chain is confusing from this point > of view Because when you use a set of PCEs and you experience an issue along the PCE chain, you want to know where. > >> Back to the previous case, consider the case of an inter- >> domain TE deployment where the number of PCE chain may potentially >> be large. Isn't useful during a troubleshooting event for example >> to know the set of PCEs involved in a PCE chain ? (or to check a >> particular PCE chain). > > well i am not sure to follow the operational process you > are referring to, I can see that. > if PCCs needs to check/monitoring and > validate each computed segment per PCE then it is also > better to maintain autonomous segment computation and > prevent the overhead of additional cross-verification > > this triggers to me the following point, before devising > methods for troubleshooting and monitoring computational > results it may be appropriate to have a much better view > of the usage of PCE before progressing on "tools" > > the same is ongoing at CCAMP where in-depth work has > been started in understanding the needs based on the > operational practice > >>> > detection of potential resource contention states >>> >>> a t[0] contention, at t[1] message for perf.mon -> are running >>> conditions identical ? since probabilisticaly, not what is the >>> expectation behind this mechanism ? >>> >>> would it be possible to have a "curve" of the deterioration of >>> the performance as with an increasing number of computed path the >>> number of "monitoring messages" will also increase ? >> Sure but ... this is true for all OAM tools. > > nope. it has never been expected that the PCE gets dimensioned > to the total number of computed LSP over time (except for the > stateful PCEs) meaning that a stateless PCE was only expected > to support a certain number of request per unit of time (and > this independently of the accumulated number of computed paths) > So ? I read the comments below and I think that they all fall into the same category. It looks like you do not think that on-line tools to gather data about the PCE chain is useful. Apparently several SPs do think that this is a useful thing to have. If you have any comment to improve the ID there are always very much welcome. Thanks. JP. >> If you use a ping to locate a congestion spot at the time you get >> your reply the network state may have changed 10 times ... but if >> you use it because of a sustained congestion state then the ping >> may help you to locate the problem. > > echo request/reply is not equivalent to resource consumption > measurement / monitoring on certain nodes and number of cycles > required for path computation not sure to really capture the > analogy > >> The exact same reasoning applies here. Note that you can also >> retrieve historical data computed over a period of time, this is a >> matter of local configuration on the PCE, in which case you could >> retrieve the averaged (using for example a low pass >> filter) computation time. > > knowing the computational interval that could result from the > use of different PC algorithms and the various conditions (both > in terms of input and local resources) i am sure that off-line > statistics would be more suitable than real-time collection per > PCC > >>> > statistics in term of path computation times are examples > of >>> such metrics of interest. >>> >>> interest to who and for which purpose (detection is fine but what >>> is the issue to be solved) ? >> Again sorry ... but strange question ... Interest to the user of >> course. > > it is not a strange question it is the initial question: which > problem are you trying to solve then one could try to assess > which method is appropriate > >> Before fixing a problem it is usually useful to locate the root >> cause of the problem. This tool may help for that purpose. > > hence your problem is the computational limitation of a PCE > what a PCC could do about ? do you need to sending back a > time value is of any use (delta between send/receive allows > the PCC to obtain the same kind of information assuming that > the PCE remains "reachable" i.e. no communication channel issue) > >>> like any system, PCE requires suitable planning and dimensioning >>> wrt to perf.objectives i have impression that these fundamental >>> design steps are skipped. >>> >>> let's start discussion with this. >>> >>> side note: the document states "In this document we call a "state >>> metric" a metric that characterizes a PCE state" -> need to >>> define the latter. >> Sure. > > indeed, this question is still open since end of 2004. > > -d. >> JP. >>> >>> thanks, >>> -d. >>> >>> >>> JP Vasseur wrote: >>>> Hi, >>>> Just let you know about an IPR disclosure that has been filed >>>> with the IETF in relation to http://tools.ietf.org/id/draft- >>>> vasseur-pce-monitoring-03.txt. You can see the disclosure at >>>> https://datatracker.ietf.org/ipr/872/ and see the terms offered >>>> by the IPR claimant. >>>> Thanks, >>>> JP. >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pce >>>> . >> . _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 21 19:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INdTO-0002rO-PE; Tue, 21 Aug 2007 19:49:22 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1INdGj-0001r7-Ue for pce-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 19:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INdGj-0001qz-KV for pce@ietf.org; Tue, 21 Aug 2007 19:36:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INdGh-00036a-PA for pce@ietf.org; Tue, 21 Aug 2007 19:36:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2007 19:36:16 -0400 X-IronPort-AV: i="4.19,291,1183348800"; d="scan'208,217"; a="68653263:sNHT164021376" 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 l7LNaFwK024817; Tue, 21 Aug 2007 19:36:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7LNaFxs009606; Tue, 21 Aug 2007 23:36:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 19:36:15 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 19:36:12 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) References: <3492EB8B-E529-4DDC-B905-B31DEFA57155@cisco.com> Message-Id: <70C4AC7A-3315-4A6F-B193-ED422455FECC@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] Re: PCE monitoring doc Date: Tue, 21 Aug 2007 19:35:36 -0400 To: Dimitri Papadimitriou X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Aug 2007 23:36:12.0836 (UTC) FILETIME=[0F47CE40:01C7E44C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=55329; t=1187739375; x=1188603375; 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]=20Re=3A=20PCE=20monitoring=20doc |Sender:=20 |To:=20Dimitri=20Papadimitriou=20; bh=eaXriD56U3jTaFowGCVo4DvuvQl8Dak4aqJlo9Tx+L4=; b=cCiCNmYhuePEuJyKXwhS0jLxvE1/NY6rYhLpgoUqgujnunaPy0Bay4BVj0FKLOpm5L+yetyr jwziXQxgRds2ffM5QUlsYdlngW7p1xIZEz10Mpy0e36Iam/mnucX/ub6; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36ffee4f7c1a67a949d5f97400beba73 X-Mailman-Approved-At: Tue, 21 Aug 2007 19:49:21 -0400 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="===============2077389313==" Errors-To: pce-bounces@lists.ietf.org --===============2077389313== Content-Type: multipart/alternative; boundary=Apple-Mail-11--1021260669 --Apple-Mail-11--1021260669 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Dimitri, I forgot to mention a key point ... This ID meets a specific requirement of RFC4927. 5. Manageability Considerations The inter-area application implies some new manageability requirements in addition to those already listed in [RFC4657]. The PCECP PCC and PCE MIB modules MUST allow recording the proportion of inter-area requests and the success rate of inter-area requests. The PCECP PCC MIB module MUST also allow recording the performances of a PCE chain (minimum, maximum, and average response times), in case of multiple-PCE inter-area path computation. It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly, it is really important to identify the PCE(s) responsible for a delayed reply. Hence, a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum, maximum, and average response times. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: August 21, 2007 9:45:06 AM EDT > To: dpapadimitriou@psg.com > Cc: pce@ietf.org > Subject: [Pce] Re: PCE monitoring doc > > Hi, > > On Aug 20, 2007, at 3:07 AM, dimitri papadimitriou wrote: > >> hi, >> >> JP Vasseur wrote: >>> Hi, >>> On Aug 16, 2007, at 4:20 AM, dimitri papadimitriou wrote: >>>> hi j-p >>>> >>>> as far as i remember, this doc. is still open for discussion >>>> from San Diego and Prague mtg discussion. >>> An ID is always open for discussion as long as it is not an RFC. >> >> just want to be sure this doc. is NOT a done deal like >> presented since a couple of meetings. > > Not sure what you mean (since it was not presented at all > in Chicago), but that's OK. > >> >>>> here below for the record >>>> >>>> >>>> >>>> v03 has been reworked but does not provide answer to the >>>> concerns expressed so far - quoting the doc. >>>> >>>> > In PCE-based environments, it is critical to monitor > the >>>> state of the >>>> >>>> critical for what ? if computation time is an issue why delegate >>>> it (isn't that the safest assumption ?) >>> Looking like you are quibbling on words here ... Do want to >>> replace "critical" by "useful", is that your point ? >> >> this does not answer the real question i think (the real >> point is why is it "critical" or "useful" to receive this >> info from the PCE while a local timer on the PCC can very >> simply determine the delay experienced between initiation >> of the request and the reception of the response) >> > > The aim of the newly defined messages is NOT to determine > the end to end delay of course *but* each delay along the PCE > chain to identify a potential issue, gets statistics, ... If your PCE > chain is made of 2 PCEs, it will provide you what delays have > been experienced along that chain on each PCE (queueing, > processing, ...). > >>>> > path computation chain for troubeshooting and > performance >>>> monitoring purposes: >>>> >>>> troubleshooting of what ? >>> I think that I gave this explanation a few times already ... >>> Suppose that the head-end experiences long response times. I >>> think that we can agree on the fact that this is >>> potentially an issue., in which case the user may want to >>> troubleshoot by issuing such a request in order to determine the >>> location (which PCE of the chain) and the root cause. >> >> does not help. if there are real issues an answer may never >> be received and the information received may be erroneous >> anyway >> >> note also that it would be rather surprising that PCE and >> PCC can not make use of local timers to determine such >> kind of delays (as i said the PCC against the PCE and >> each PCE against the peering PCE) > > The local timer gives you the overall end to end time (already > available on several PCC/PCE implementations) but does not > tell you which delays have been experiences on each element > along the PCE chain. You could have a Telnet session on each > PCE in your network and upon issuing a request try to log all > events and figure this out (try this ...) or have a PCE message that > does it for you from the head-end (this is what this ID is about). > >> >>>> if there is congestion/troubles how would you ensure the >>>> information received back is accurate ? >>> The information of the waiting times, CPU utilization, ... is >>> provided by the PCE. >>> >>> The issue of accurateness is no different than for any other >>> information provided for example by the MIB. >> >> if you seek at MIB information then i suspect that they >> are also available at the SNMP management level ... why >> a specific protocol mechanism to correlate it ? > > First I did say that you had similar information provided by SNMP. > I was using the example of SNMP answering your point about > the accurateness issue. Here we do collect statistics about queueuing > delays, processing delays and so on ... so does SNMP, this is no > different. > > Back to your question "Why a specific protocol mechanism to correlate > it ?". Because you may want to have on-line mechanisms that do > require a NMS system, that's it. Note that this is no different > than Ping, > LSPPing, ... > >> >> i miss why LSR shall now start perform troubleshooting >> of PCEs ... i thought that PCE where used to decrease >> load on LSR not the contrary (PCE can be exceptionally >> blocking / defectuous only otherwise resulting in more >> troubles than being really improving performance) >> > > Dimitri, yes the aim of the PCE is too help solving various issues. > Note that in case of inter-area, this is usually not a load issue but > a visibility issue, I guess that you noticed that. But when you > operate > a network you also need tools to make sure that things work as > expected and there might be circumstances under which they don't > thus the reason for such tools. > > What a strange discussion ... it looks like you're questioning the > usefulness of OAM tools in general ... ? Again look at LSPPing: LSR > are of course expected to work, but still OAM tools are useful. > >>>> > liveness of each element (PCE) involved in the PCE > chain, >>>> >>>> if i well remember the PCE is a client-server model (fundamental >>>> assumption about the PCE approach) hence, why the client needs >>>> to know the "chain" of PCE servers ? >>> Strange question ... Try to operate a network and you'll >>> immediately figure out. >> >> i don't think you have captured the question. the point >> is not whether the server shall be accountable but why >> the PCC shall be made aware about the "chain" >> >> the notion of the PCE chain is confusing from this point >> of view > > Because when you use a set of PCEs and you experience an issue > along the PCE chain, you want to know where. > >> >>> Back to the previous case, consider the case of an inter- >>> domain TE deployment where the number of PCE chain may >>> potentially be large. Isn't useful during a troubleshooting event >>> for example to know the set of PCEs involved in a PCE chain ? (or >>> to check a particular PCE chain). >> >> well i am not sure to follow the operational process you >> are referring to, > > I can see that. > >> if PCCs needs to check/monitoring and >> validate each computed segment per PCE then it is also >> better to maintain autonomous segment computation and >> prevent the overhead of additional cross-verification >> >> this triggers to me the following point, before devising >> methods for troubleshooting and monitoring computational >> results it may be appropriate to have a much better view >> of the usage of PCE before progressing on "tools" >> >> the same is ongoing at CCAMP where in-depth work has >> been started in understanding the needs based on the >> operational practice >> >>>> > detection of potential resource contention states >>>> >>>> a t[0] contention, at t[1] message for perf.mon -> are running >>>> conditions identical ? since probabilisticaly, not what is the >>>> expectation behind this mechanism ? >>>> >>>> would it be possible to have a "curve" of the deterioration of >>>> the performance as with an increasing number of computed path >>>> the number of "monitoring messages" will also increase ? >>> Sure but ... this is true for all OAM tools. >> >> nope. it has never been expected that the PCE gets dimensioned >> to the total number of computed LSP over time (except for the >> stateful PCEs) meaning that a stateless PCE was only expected >> to support a certain number of request per unit of time (and >> this independently of the accumulated number of computed paths) >> > > So ? > > I read the comments below and I think that they all fall > into the same category. It looks like you do not think that > on-line tools to gather data about the PCE chain is > useful. Apparently several SPs do think that this is a useful > thing to have. If you have any comment to improve the ID > there are always very much welcome. > > Thanks. > > JP. > > >>> If you use a ping to locate a congestion spot at the time you get >>> your reply the network state may have changed 10 times ... but if >>> you use it because of a sustained congestion state then the ping >>> may help you to locate the problem. >> >> echo request/reply is not equivalent to resource consumption >> measurement / monitoring on certain nodes and number of cycles >> required for path computation not sure to really capture the >> analogy >> >>> The exact same reasoning applies here. Note that you can also >>> retrieve historical data computed over a period of time, this is >>> a matter of local configuration on the PCE, in which case you >>> could retrieve the averaged (using for example a low pass >>> filter) computation time. >> >> knowing the computational interval that could result from the >> use of different PC algorithms and the various conditions (both >> in terms of input and local resources) i am sure that off-line >> statistics would be more suitable than real-time collection per >> PCC >> >>>> > statistics in term of path computation times are examples > of >>>> such metrics of interest. >>>> >>>> interest to who and for which purpose (detection is fine but >>>> what is the issue to be solved) ? >>> Again sorry ... but strange question ... Interest to the user of >>> course. >> >> it is not a strange question it is the initial question: which >> problem are you trying to solve then one could try to assess >> which method is appropriate >> >>> Before fixing a problem it is usually useful to locate the root >>> cause of the problem. This tool may help for that purpose. >> >> hence your problem is the computational limitation of a PCE >> what a PCC could do about ? do you need to sending back a >> time value is of any use (delta between send/receive allows >> the PCC to obtain the same kind of information assuming that >> the PCE remains "reachable" i.e. no communication channel issue) >> >>>> like any system, PCE requires suitable planning and dimensioning >>>> wrt to perf.objectives i have impression that these fundamental >>>> design steps are skipped. >>>> >>>> let's start discussion with this. >>>> >>>> side note: the document states "In this document we call a >>>> "state metric" a metric that characterizes a PCE state" -> need >>>> to define the latter. >>> Sure. >> >> indeed, this question is still open since end of 2004. >> >> -d. >>> JP. >>>> >>>> thanks, >>>> -d. >>>> >>>> >>>> JP Vasseur wrote: >>>>> Hi, >>>>> Just let you know about an IPR disclosure that has been filed >>>>> with the IETF in relation to http://tools.ietf.org/id/draft- >>>>> vasseur-pce-monitoring-03.txt. You can see the disclosure at >>>>> https://datatracker.ietf.org/ipr/872/ and see the terms offered >>>>> by the IPR claimant. >>>>> Thanks, >>>>> JP. >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>> . >>> . > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-11--1021260669 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Dimitri,

I forgot to mention a key = point ...=A0

This ID meets a specific = requirement of RFC4927.

5.=A0 Manageability = Considerations

=A0=A0 The = inter-area application implies some new = manageability
=A0=A0 requirements in addition to those = already listed in [RFC4657].=A0 The
=A0=A0 PCECP PCC = and PCE MIB modules MUST allow recording the proportion = of
=A0=A0 inter-area requests and the success rate of = inter-area requests.=A0 The
=A0=A0 PCECP PCC MIB module = MUST also allow recording the performances of a
=A0=A0 = PCE chain (minimum, maximum, and average response times), in case = of
=A0=A0 multiple-PCE inter-area path = computation.

=A0=A0 It is really = important, for diagnostic and troubleshooting = reasons,
=A0=A0 to monitor the availability and = performances of each PCE of a PCE
=A0=A0 chain used for = inter-area path computation.=A0 Particularly, it is
=A0=A0= really important to identify the PCE(s) responsible for a = delayed
=A0=A0 reply.

=A0=A0 Hence, a = mechanism MUST be defined to monitor the performances of = a
=A0=A0 PCE chain.=A0 It MUST allow determining the = availability of each PCE of
=A0=A0 the chain as well as = its minimum, maximum, and average response
=A0=A0 = times.

Thanks.

JP.


Begin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = August 21, 2007 9:45:06 AM EDT
To: dpapadimitriou@psg.com
Subject: = [Pce] Re: PCE monitoring doc


On Aug 20, 2007, at 3:07 AM, dimitri papadimitriou = wrote:

=
hi,

JP = Vasseur wrote:
On Aug 16, 2007, at 4:20 AM, = dimitri papadimitriou wrote:
hi j-p

as far as i remember, this doc. = is still open for discussion from San Diego and Prague mtg = discussion.
An ID is = always open for discussion as long as it is not an RFC.
=

just want to be sure this doc. is NOT a done deal = like
presented since a couple of = meetings.

Not sure what you mean (since it = was not presented at all
in Chicago), = but that's OK.

=
here below for the record


v03 has = been reworked but does not provide answer to the concerns expressed so = far - quoting the doc.
> In PCE-based environments, = it is critical to monitor > the state of the

critical = for what ? if computation time is an issue why delegate it (isn't that = the safest assumption ?)
Looking = like you are quibbling on words here ... Do want to replace "critical" = by "useful", is that your point ?

this = does not answer the real question i think (the real
point is why is it "critical" or "useful" to receive = this
info from the PCE while a local = timer on the PCC can very
simply = determine the delay experienced between initiation
of the request and the reception of the = response)

=

The aim of the newly defined messages is NOT to = determine
the end to end delay of course = *but* each delay along the PCE
chain to = identify a potential issue, gets statistics, ... If your PCE
chain is made of 2 PCEs, it will provide you what = delays have
been experienced along that = chain on each PCE (queueing,
processing, = ...).

=
> path computation chain for = troubeshooting and > performance monitoring purposes:

I think = that I gave this explanation a few times already ... Suppose that the = head-end experiences long response times. I think that we can agree on = the fact that this is
potentially an issue., in = which case the user may want to troubleshoot by issuing such a request = in order to determine the location (which PCE of the chain) and the root = cause.
does not help. if there are real = issues an answer may never
be received = and the information received may be erroneous
anyway

note also that it would be = rather surprising that PCE and
PCC can not = make use of local timers to determine such
kind of = delays (as i said the PCC against the PCE and
each PCE against the peering PCE)
=

The local timer gives you the overall end to end = time (already
available on several PCC/PCE = implementations) but does not
tell you = which delays have been experiences on each element
along the PCE chain. You could have a Telnet session = on each
PCE in your network and upon = issuing a request try to log all
events and = figure this out (try this ...) or have a PCE message that
does it for you from the head-end (this is what this = ID is about).

=
if there is congestion/troubles how would you ensure = the information received back is accurate ?
The information of the waiting times, CPU = utilization, ... is provided by the PCE.

The issue of = accurateness is no different than for any other information provided for = example by the MIB.

if you seek at MIB information = then i suspect that they
are also = available at the SNMP management level ... why
a specific protocol mechanism to correlate it = ?

First I did say that you had similar information = provided by SNMP.
I was using the example of SNMP = answering your point about
the = accurateness issue. Here we do collect statistics about = queueuing
delays, processing delays and so = on ... so does SNMP, this is no

Back to your question "Why a specific protocol = mechanism to correlate
it ?". Because you may want = to have on-line mechanisms that do
require a NMS = system, that's it. Note that this is no different than Ping,
LSPPing, ...


i miss why = LSR shall now start perform troubleshooting
of PCEs = ... i thought that PCE where used to decrease
load on LSR not the contrary (PCE can be = exceptionally
blocking / defectuous only = otherwise resulting in more
troubles than = being really improving performance)


Dimitri, yes the aim of the PCE = is too help solving various issues.
Note that in = case of inter-area, this is usually not a load issue but
a visibility issue, I guess that you noticed that. = But when you operate
a network you also need = tools to make sure that things work as
expected = and there might be circumstances under which they don't
thus the reason for such tools.

What a = strange discussion ... it looks like you're questioning the
usefulness of OAM tools in general ... ? Again look = at LSPPing: LSR
are of course expected to work, = but still OAM tools are useful.

> liveness = of each element (PCE) involved in the PCE > chain,

if i = well remember the PCE is a client-server model (fundamental assumption = about the PCE approach) hence, why the client needs to know the "chain" = of PCE servers ?
Strange = question ... Try to operate a network and you'll immediately figure = out.
i don't think you have captured = the question. the point
is not = whether the server shall be accountable but why
the PCC shall be made aware about the = "chain"

the notion of the PCE chain is confusing from this = point
of view

Because = when you use a set of PCEs and you experience an issue
along the PCE chain, you want to know = where.

=
Back to the = previous case, consider the case of an inter-
domain TE deployment where the number of PCE chain = may potentially be large. Isn't useful during a troubleshooting event = for example to know the set of PCEs involved in a PCE chain ? (or to = check a particular PCE chain).

well i = am not sure to follow the operational process you
are referring to,

I can = see that.

=
if PCCs needs to = check/monitoring and
validate each computed = segment per PCE then it is also
better to = maintain autonomous segment computation and
prevent = the overhead of additional cross-verification

this = triggers to me the following point, before devising
methods for troubleshooting and monitoring = computational
results it may be appropriate to = have a much better view
of the usage = of PCE before progressing on "tools"

the same is ongoing at CCAMP = where in-depth work has
been started = in understanding the needs based on the
> detection of potential resource contention = states

a t[0] contention, at t[1] message for perf.mon = -> are running conditions identical ? since probabilisticaly, not = what is the=A0 expectation = behind this mechanism ?

would it be possible to have a = "curve" of the deterioration of the performance as with an increasing = number of computed path the number of "monitoring messages" will also = increase ?
Sure but ... = this is true for all OAM tools.

nope. it = has never been expected that the PCE gets dimensioned
to the total number of computed LSP over time = (except for the
stateful PCEs) meaning that a = stateless PCE was only expected
to support a = certain number of request per unit of time (and
this independently of the accumulated number of = computed paths)

=

So ?

I read the comments below and I = think that they all fall
into the same = category. It looks like you do not think that
on-line tools to gather data about the PCE chain = is
useful. Apparently several SPs do think that = this is a useful
thing to have. If you have any = comment to improve the ID
there are = always very much welcome.

Thanks.



If you use a = ping to locate a congestion spot at the time you get your reply the = network state may have changed 10 times ... but if you use it because of = a sustained congestion state then the ping may help you to locate the = problem.
echo request/reply is not = equivalent to resource consumption
measurement / = monitoring on certain nodes and number of cycles
required for path computation not sure to really = capture the
analogy

The exact same reasoning applies = here. Note that you can also
retrieve = historical data computed over a period of time, this is a matter of = local configuration on the PCE, in which case you could retrieve the = averaged (using for example a low pass
filter) = computation time.

knowing the computational = interval that could result from the
use of = different PC algorithms and the various conditions (both
in terms of input and local resources) i am sure = that off-line
statistics would be more = suitable than real-time collection per

=
> statistics in term of path computation times = are examples > of such metrics of interest.

interest = to who and for which purpose (detection is fine but what is the issue to = be solved) ?
Again sorry = ... but strange question ... Interest to the user of course.
=

it is not a strange question it is the initial = question: which
problem are you trying to solve = then one could try to assess
which method = is appropriate

=
Before fixing a problem it = is usually useful to locate the root cause of the problem. This tool may = help for that purpose.

hence your problem is the = computational limitation of a PCE
what a PCC = could do about ? do you need to sending back a
time value is of any use (delta between send/receive = allows
the PCC to obtain the same kind = of information assuming that
the PCE = remains "reachable" i.e. no communication channel issue)

like any = system, PCE requires suitable planning and dimensioning wrt to = perf.objectives i have impression that these fundamental design steps = are skipped.

let's start discussion with this.

side = note: the document states "In this document we call a "state metric" a = metric that characterizes a PCE state" -> need to define the = latter.
Sure.
=

indeed, this question is still open since end of = 2004.

-d.
JP.

-d.


JP Vasseur wrote:
=
Hi,
Just let you know about an IPR disclosure that has = been filed with the IETF in relation to http= ://tools.ietf.org/id/draft-vasseur-pce-monitoring-03.txt. You can = see the disclosure at https://datatracker.ietf.or= g/ipr/872/ and see the terms offered by the IPR claimant.
Thanks,
JP.
Pce mailing list
.
=
.
=

Pce mailing list
=

= --Apple-Mail-11--1021260669-- --===============2077389313== 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 --===============2077389313==-- From pce-bounces@lists.ietf.org Wed Aug 22 12:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsdL-0004Wj-QQ; Wed, 22 Aug 2007 12:00:39 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1INsTu-0004cB-Ib for pce-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 11:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsTt-0004by-S4; Wed, 22 Aug 2007 11:50:53 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INsTt-0006bE-IT; Wed, 22 Aug 2007 11:50:53 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 76B0332906; Wed, 22 Aug 2007 15:50:23 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1INsTP-00020E-Cf; Wed, 22 Aug 2007 11:50:23 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones From: Adrian Farrel (IETF CCAMP WG) Message-Id: Date: Wed, 22 Aug 2007 11:50:23 -0400 X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 22 Aug 2007 12:00:36 -0400 Cc: Scott Bradner , CCAMP Mailing List , Stephen Trowbridge , PCE Mailing List , David Ward , Ross Callon , Hiroshi Otha Subject: [Pce] New Liaison Statement, "Your OTNT Work Plan" 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 Title: Your OTNT Work Plan Submission Date: 2007-08-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=359 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T Q3/15(Greg Jones ) Cc: Hiroshi Otha Stephen Trowbridge Deborah Brungard JP Vasseur Ross Callon David Ward Scott Bradner CCAMP Mailing List PCE Mailing List Reponse Contact: Adrian Farrel Technical Contact: Adrian Farrel Purpose: In response Body: Thank you for continuing to share your OTNT work plan through your liaison from your June plenary in Geneva. I have made the IETF's CCAMP and PCE working groups aware of the work plan, and at this time we do not have any issues or concerns to raise resulting from the content of the plan. Please note that the publication of new RFCs related to the optical control plane are notified to SG15 through separate liaisons from time to time, and you may wish to update table 7-1-2 accordingly. Please keep us informed as your work plan evolves. Best regards, Adrian Farrel IETF Liaison to the ITU-T SG15 on Optical Control Plane Attachment(s): No document has been attached _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 24 21:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOjzX-0001VI-Cn; Fri, 24 Aug 2007 20:59:07 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IOjzW-0001VD-K2 for pce-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 20:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOjzW-0001V5-8p for pce@ietf.org; Fri, 24 Aug 2007 20:59:06 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOjzV-0000VX-Lm for pce@ietf.org; Fri, 24 Aug 2007 20:59:06 -0400 Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IOjzT-0007NP-H3 for pce@ietf.org; Sat, 25 Aug 2007 00:59:03 +0000 Received: from your029b8cecfe ([219.76.92.149] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Aug 2007 01:59:02 +0100 Message-ID: <014401c7e6b3$163d5080$3407a8c0@your029b8cecfe> From: "Adrian Farrel" To: Date: Sat, 25 Aug 2007 01:56:47 +0100 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: 25 Aug 2007 00:59:02.0639 (UTC) FILETIME=[20C0CFF0:01C7E6B3] X-Originating-Pythagoras-IP: [88.96.235.142] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Pce] Question about PCEP Keepalive 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, I'm looking at r08 sections 6.3 and 7.2. Section 6.3 has Note that sending Keepalive messages to maintain the session alive is optional and PCEP peers may decide to not send Keepalive messages once the PCEP session is established. Section 7.2 has Keepalive (8 bits): maximum period of time (in seconds) between the sending of PCEP messages. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages need to be sent to the remote peer. And also A sends an Open message to B with Keepalive=10 seconds and Deadtimer=30 seconds. This means that A sends Keepalive messages (or ay other PCEP message) to B every 30 seconds and B can declare the PCEP session with A down if no PCEP has been received from A. I find this peculiar. Sending a keepalive message does not verify for the sender that the session is open. It verifies for the receiver. So, surely the parameter in the Open object says how frequently the sender of the Open message wants to receive a Keepalive message. That is, how often the receiver of the Open message must send a Keepalive message. For example, if a PCC is worried that the session may fail, it will want to operate the keepalive process. But as currently specified, the PCC can only tell the PCE how often the PCC will send Keepalive messages, and after what period the PCE may declare the session dead. This is no help to the PCC! If the PCE decides that it will not send Keepalive messages then the PCC cannot determine the health of the session and cannot switch to a new PCE. In other words, the keepalive process is back-to-front. Further, I don't see why you need the keepalive timer value and the dead timer value. One value can be derived from the other, probably through a recommended ratio of 3.5. Lastly, when describing that the use of keepalive is optional, there are a couple of points: 1. Optional should be an RFC 2119 word 2. You need to make it clear that it is not the "PCEP peers" that decide to not send keepalives, but "each PCEP peer" that decides "whether it wants to receive keepalives" 3. You should indicate the circumstances surrounding the choice for this option. I think that, you might suggest that if PCE discovery is in use, the failure of a PCE can be speedily detected by the failure of the IGP, and can be flooded by timing out the LSA containing the discovery information. In this case, keepalive would not be needed. Yes? Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 31 13:17:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRA5o-0008Bz-EX; Fri, 31 Aug 2007 13:15:36 -0400 Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IRA5l-00088b-32 for pce-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 13:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRA5k-00088N-O7; Fri, 31 Aug 2007 13:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRA5k-0004Hd-Ac; Fri, 31 Aug 2007 13:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3599C2AC4F; Fri, 31 Aug 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IRA5F-0006uT-Vm; Fri, 31 Aug 2007 13:15:01 -0400 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, 31 Aug 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-manageability-requirements-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 : Inclusion of Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-02.txt Pages : 12 Date : 2007-8-31 It has often been the case that manageability considerations have been retrofitted to protocols after they have been speicified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation 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-ietf-pce-manageability-requirements-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-manageability-requirements-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-manageability-requirements-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: <2007-8-31125352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-manageability-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-31125352.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--