From pce-bounces@ietf.org Tue Feb 1 13:31:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03802; Tue, 1 Feb 2005 13:31:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw36b-0001Kf-GD; Tue, 01 Feb 2005 13:50:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2gN-0006OS-3F; Tue, 01 Feb 2005 13:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2Zb-0005EH-1J; Tue, 01 Feb 2005 13:16:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02439; Tue, 1 Feb 2005 13:16:20 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw2rm-0000yn-77; Tue, 01 Feb 2005 13:35:11 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 19:15:34 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 1 Feb 2005 19:15:33 +0100 Message-ID: Thread-Topic: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality Thread-Index: AcUHbkXTE9xaFBjKSU+gHAkR9RgTtAANQucw From: "STEPHAN Emile RD-CORE-LAN" To: "Henk Uijterwaal" X-OriginalArrivalTime: 01 Feb 2005 18:15:34.0820 (UTC) FILETIME=[05F24640:01C5088A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, ippm@ietf.org Subject: [Pce] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable Dear Henk, >From my point of view these 3 drafts may merge and in a WG draft that = defines the minimal set of metrics to permit spatial and multicast = measurements. These metrics are the ones needed in the PCE WG to measure path quality = and the ones needed to measure multicast tree performance: - The decomposition of 'singletons' of IPPM one-way delay, packet loss = and jitter over a path:=20 Samples of instantaneous per hop performance; - The delay, loss and jitter of a hop of a path; An item of the previous decomposition;=20 - The aggregation of end-to-end one-way delays over a path is needed = too: Permits aggregation of inter domain delay and aggregation of delay of a = branch of a multicast tree. - The samples of 'singletons' of IPPM one-way delay, packet loss and = jitter for a group of receiver:=20 Permit multiparty statistics; Regards Emile -----Message d'origine----- De=A0: Henk Uijterwaal [mailto:henk@ripe.net]=20 Envoy=E9=A0: lundi 31 janvier 2005 08:26 =C0=A0: STEPHAN Emile RD-CORE-LAN; ippm@ietf.org Cc=A0: Matthew J Zekauskas Objet=A0: Re: 'IPPM' IDs on multicast an spatial measure Dear Emile, >During the last WG meeting Matt asked me to reread the draft=20 >draft-liang-multiparty-para-00.txt while considering the previous IDs I = >posted on spatial and multicast metrics. > >I reread them. Following is the list of metrics I found. I can make=20 >further classifications, comparisons or comments if needed. Based on your reading of this draft, do you have any opinion on how we should proceed with draft-liang-multiparty... Pick it up as a WG item? Leave it to the authors to pursue as an individual submission? Kind regards, Henk >Regards > >Emile >--------------- draft-stephan-ippm-multicast-metrics-00.txt = ---------------- > >The draft defines 1 network metrics: > > + Type-P-spatial-hop-one-way-delay > > > >The draft defines several aggregation metrics: > > + Type-P-spatial-one-way-delay-stream > > + Type-P-spatial-one-way-delay > > + Type-P-Multicast-Instantaneous-Hop-One-way-Delay > > + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile > > + Type-P-Multicast-Instantaneous-One-way-Delay-Median > > + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse = Percentile > > + Type-P-Multicast-Instantaneous-Packet-Loss-Stream > > + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile > > + Type-P-Multicast-Instantaneous-Packet-Loss-Median > > + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse = Percentile > > + Type-P-Multicast-Instantaneous-Connectivity > > > >--------------- draft-stephan-ippm-spatial-metrics-01.txt = --------------- > > > >The draft defines 2 network metrics: > > + Type-P-spatial-one-way-delay > > + Type-P-Spatial-packet-loss > > > >The draft defines several path aggregation metrics : > > + Type-P-one-way-delay-trajectory > > + Type-P-aggregated-one-way-delay > > + Type-P-asynchronous-one-way-delay-trajectory > > + Type-P-asynchronous-aggregated-one-way-delay > > + Type-P-Spatial-packet-loss-stream > > + Type-P-Spatial-packet-loss-Average > > > >--------------- draft-liang-multiparty-para-00.txt --------------- > >The draft defines statistics for end to end multicast performance, = mainly=20 >to identify the variation of the performance between the member of a = group. > >Actually the draft has 4 groups of statistics metrics: > > One-to-group-Mean-Paramater > > One-to-group-Variation-Paramater > > Group-to-one-Mean-Paramater > > Group-to-one-Variation-Paramater > >The value of Parameter depends on what one-way metric is used from = delay,=20 >loss ot jitter. > >To permit comparison I extended the list of metrics defined using IPPM=20 >metrics terminology: > > + Type-P-One-to-group-Mean-one-way-delay; > > + Type-P-One-to-group-Mean-Packet-Loss; > > + Type-P-One-to-group-Mean-ipdv; > > > > + Type-P-One-to-group-Variation-one-way-delay; > > + Type-P-One-to-group-Variation-Packet-Loss; > > + Type-P-One-to-group-Variation-ipdv; > > > > + Type-P-Group-to-one-Mean-one-way-delay; > > + Type-P-Group-to-one-Mean-Packet-Loss; > > + Type-P-Group-to-one-Mean-ipdv; > > > > + Type-P-Group-to-one-Variation-one-way-delay; > > + Type-P-Group-to-one-Variation-Packet-Loss; > > + Type-P-Group-to-one-Variation-ipdv; -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre = http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom = Verlaine)=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Wed Feb 2 11:49:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27075; Wed, 2 Feb 2005 11:49:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNzI-0005DR-W5; Wed, 02 Feb 2005 12:08:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNd4-0001yN-SK; Wed, 02 Feb 2005 11:45:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNZ4-0000FV-5x; Wed, 02 Feb 2005 11:41:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25853; Wed, 2 Feb 2005 11:41:09 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNrR-0004qf-JC; Wed, 02 Feb 2005 12:00:15 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 17:41:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2005 17:41:08 +0100 Message-ID: Thread-Topic: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality Thread-Index: AcUJJKwt/KaPWEeNQQuBKdAETsUUbgACVREA From: "STEPHAN Emile RD-CORE-LAN" To: "Lei Liang" X-OriginalArrivalTime: 02 Feb 2005 16:41:09.0608 (UTC) FILETIME=[FFA14680:01C50945] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable Cc: Zhili SunZhiliSun , pce@ietf.org, Henk Uijterwaal , ippm@ietf.org Subject: [Pce] RE: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: quoted-printable Dear Lei, You might take a glance at the old draft defining multicast metrics too. = As an example the section 7 defines the metric = Type-P-Multicast-Instantaneous-One-way-Delay-Stream. This stream is the = list of the instantaneous delays between one source and a group of = receiver. So from my point of view it provides directly the material for = computing One-to-group statistics. These drafts are no more available on the IETF site, but they are still = online = http://www.watersprings.org/pub/id/draft-stephan-ippm-multicast-metrics-0= 0.txt = http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01.= txt Regards Emile -----Message d'origine----- De=A0: Lei Liang [mailto:L.Liang@surrey.ac.uk]=20 Envoy=E9=A0: mercredi 2 f=E9vrier 2005 13:42 =C0=A0: STEPHAN Emile RD-CORE-LAN Cc=A0: Henk Uijterwaal; pce@ietf.org; ippm@ietf.org; Zhili SunZhiliSun Objet=A0: Re: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / = PCE metric to measure path quality Dear Emile and Henk, Thank you very much for your comments on the draft. I will read through draft-stephan-ippm-spatial-metrics-01.txt to help merge these two drafts together according to the comments cheers, lei Tue, 2005-02-01 at 18:15, STEPHAN Emile RD-CORE-LAN wrote: > Dear Henk, >=20 > >From my point of view these 3 drafts may merge and in a WG draft that = defines the minimal set of metrics to permit spatial and multicast = measurements. >=20 > These metrics are the ones needed in the PCE WG to measure path = quality and the ones needed to measure multicast tree performance: >=20 > - The decomposition of 'singletons' of IPPM one-way delay, packet loss = and jitter over a path:=20 > Samples of instantaneous per hop performance; >=20 > - The delay, loss and jitter of a hop of a path; > An item of the previous decomposition;=20 >=20 > - The aggregation of end-to-end one-way delays over a path is needed = too: > Permits aggregation of inter domain delay and aggregation of delay of = a branch of a multicast tree. >=20 > - The samples ofcomment 'singletons' of IPPM one-way delay, packet = loss and jitter for a group of receiver:=20 > Permit multiparty statistics; >=20 >=20 > Regards > Emile >=20 > -----Message d'origine----- > De : Henk Uijterwaal [mailto:henk@ripe.net]=20 > Envoy=E9 : lundi 31 janvier 2005 08:26 > =C0 : STEPHAN Emile RD-CORE-LAN; ippm@ietf.org > Cc : Matthew J Zekauskas > Objet : Re: 'IPPM' IDs on multicast an spatial measure >=20 > Dear Emile, >=20 > >During the last WG meeting Matt asked me to reread the draft=20 > >draft-liang-multiparty-para-00.txt while considering the previous IDs = I=20 > >posted on spatial and multicast metrics. > > > >I reread them. Following is the list of metrics I found. I can make=20 > >further classifications, comparisons or comments if needed. >=20 > Based on your reading of this draft, do you have any opinion on how > we should proceed with draft-liang-multiparty... Pick it up as a WG > item? Leave it to the authors to pursue as an individual submission? >=20 > Kind regards, >=20 > Henk >=20 >=20 >=20 >=20 > >Regards > > > >Emile >=20 >=20 >=20 > >--------------- draft-stephan-ippm-multicast-metrics-00.txt = ---------------- > > > >The draft defines 1 network metrics: > > > > + Type-P-spatial-hop-one-way-delay > > > > > > > >The draft defines several aggregation metrics: > > > > + Type-P-spatial-one-way-delay-stream > > > > + Type-P-spatial-one-way-delay > > > > + Type-P-Multicast-Instantaneous-Hop-One-way-Delay > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Median > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse = Percentile > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Stream > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Median > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse = Percentile > > > > + Type-P-Multicast-Instantaneous-Connectivity > > > > > > > >--------------- draft-stephan-ippm-spatial-metrics-01.txt = --------------- > > > > > > > >The draft defines 2 network metrics: > > > > + Type-P-spatial-one-way-delay > > > > + Type-P-Spatial-packet-loss > > > > > > > >The draft defines several path aggregation metrics : > > > > + Type-P-one-way-delay-trajectory > > > > + Type-P-aggregated-one-way-delay > > > > + Type-P-asynchronous-one-way-delay-trajectory > > > > + Type-P-asynchronous-aggregated-one-way-delay > > > > + Type-P-Spatial-packet-loss-stream > > > > + Type-P-Spatial-packet-loss-Average > > > > > > > >--------------- draft-liang-multiparty-para-00.txt --------------- > > > >The draft defines statistics for end to end multicast performance, = mainly=20 > >to identify the variation of the performance between the member of a = group. > > > >Actually the draft has 4 groups of statistics metrics: > > > > One-to-group-Mean-Paramater > > > > One-to-group-Variation-Paramater > > > > Group-to-one-Mean-Paramater > > > > Group-to-one-Variation-Paramater > > > >The value of Parameter depends on what one-way metric is used from = delay,=20 > >loss ot jitter. > > > >To permit comparison I extended the list of metrics defined using = IPPM=20 > >metrics terminology: > > > > + Type-P-One-to-group-Mean-one-way-delay; > > > > + Type-P-One-to-group-Mean-Packet-Loss; > > > > + Type-P-One-to-group-Mean-ipdv; > > > > > > > > + Type-P-One-to-group-Variation-one-way-delay; > > > > + Type-P-One-to-group-Variation-Packet-Loss; > > > > + Type-P-One-to-group-Variation-ipdv; > > > > > > > > + Type-P-Group-to-one-Mean-one-way-delay; > > > > + Type-P-Group-to-one-Mean-Packet-Loss; > > > > + Type-P-Group-to-one-Mean-ipdv; > > > > > > > > + Type-P-Group-to-one-Variation-one-way-delay; > > > > + Type-P-Group-to-one-Variation-Packet-Loss; > > > > + Type-P-Group-to-one-Variation-ipdv; >=20 > = -------------------------------------------------------------------------= ----- > Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre = http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > = -------------------------------------------------------------------------= ----- >=20 > Look here junior, don't you be so happy. > And for Heaven's sake, don't you be so sad. (Tom = Verlaine)=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 3 12:48:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20195; Thu, 3 Feb 2005 12:48:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwlOh-0006f0-Nn; Thu, 03 Feb 2005 13:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwl3i-0002FK-At; Thu, 03 Feb 2005 12:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwjzr-0001fv-I6; Thu, 03 Feb 2005 11:38:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13046; Thu, 3 Feb 2005 11:38:20 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwkIR-00047m-Op; Thu, 03 Feb 2005 11:57:36 -0500 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 3 Feb 2005 16:29:49 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 16:29:47 +0000 Received: from 131.227.89.181 ([131.227.89.181]) by EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2005 16:29:46 +0000 Received: from ccsrlt31 by evs-ec1-node1.surrey.ac.uk; 03 Feb 2005 16:29:46 +0000 From: Lei Liang To: STEPHAN Emile RD-CORE-LAN In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <1107448186.14307.75.camel@ccsrlt31.ee.surrey.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 03 Feb 2005 16:29:46 +0000 X-OriginalArrivalTime: 03 Feb 2005 16:29:47.0666 (UTC) FILETIME=[9392EF20:01C50A0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 03 Feb 2005 12:46:24 -0500 Cc: Zhili SunZhiliSun , pce , Henk Uijterwaal , ippm Subject: [Pce] RE: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Dear Emile, Thanks for your sugguestion. I have read through the mulitcast metrics and got some comments here.=20 1:the general difference of your draft and mine is our view point. your draft mainly consided the individual users in the group while mine emphasized the group. I am trying to view the group as one client with special consideration on the relative QoS. =20 2: your spatial metrics can be for more general measurement cases rather than only limited to multicast. It can provide very detail information for each multicast branch that is extremely useful to identify the problem network segment for inter-domain connctions. 3:regarding your Instantaneous One-way Delay Stream, it is trying to collect a set of unicast measurement results together if I didn't misunderstand. I have one question here that if we extremely need such a collection to form a new metric while we actually can have the unicast one-way metric first. The potential problem might be the metric size while we have huge size multicast groups, e.g. internet gaming, live tv, etc.=20 4: regarding the Type-P-Multicast-Instantaneous-Hop-One-way-Delay, it is quite similar to the one-to-group mean delay defined in my draft. I suggest we can merge them together. 5:the mean, or average, of the one-way delay can't present the relative delay which is also very important for group communication as I mentioned in my draft. so I suggest to keep the consideration on the delay variation. 6: moreover, the jitter is also very important for the highly interactive communications and we can not ignore it. 7: the relevant metrics you defined for packet loss is more concern with individual users, as i said above, and can be very useful for problem identification. the problem is still regarding the huge group size.=20 8: I suggest we use mean instead of median because it can reflect the trend of the QoS among the group members. Those are the comments for now. Your response will be appreciated. Regards, lei =20 On Wed, 2005-02-02 at 16:41, STEPHAN Emile RD-CORE-LAN wrote: > Dear Lei, >=20 > You might take a glance at the old draft defining multicast metrics too. = As an example the section 7 defines the metric Type-P-Multicast-Instantaneo= us-One-way-Delay-Stream. This stream is the list of the instantaneous delay= s between one source and a group of receiver. So from my point of view it p= rovides directly the material for computing One-to-group statistics. >=20 > These drafts are no more available on the IETF site, but they are still o= nline > http://www.watersprings.org/pub/id/draft-stephan-ippm-multicast-metrics-= 00.txt > http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01= .txt >=20 > Regards > Emile >=20 > -----Message d'origine----- > De : Lei Liang [mailto:L.Liang@surrey.ac.uk]=20 > Envoy=E9 : mercredi 2 f=E9vrier 2005 13:42 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : Henk Uijterwaal; pce@ietf.org; ippm@ietf.org; Zhili SunZhiliSun > Objet : Re: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE = metric to measure path quality >=20 > Dear Emile and Henk, > Thank you very much for your comments on the draft. I will read > through draft-stephan-ippm-spatial-metrics-01.txt to help merge these > two drafts together according to the comments >=20 > cheers, > lei >=20 > Tue, 2005-02-01 at 18:15, STEPHAN Emile RD-CORE-LAN wrote: > > Dear Henk, > >=20 > > >From my point of view these 3 drafts may merge and in a WG draft that = defines the minimal set of metrics to permit spatial and multicast measurem= ents. > >=20 > > These metrics are the ones needed in the PCE WG to measure path quality= and the ones needed to measure multicast tree performance: > >=20 > > - The decomposition of 'singletons' of IPPM one-way delay, packet loss = and jitter over a path:=20 > > Samples of instantaneous per hop performance; > >=20 > > - The delay, loss and jitter of a hop of a path; > > An item of the previous decomposition;=20 > >=20 > > - The aggregation of end-to-end one-way delays over a path is needed to= o: > > Permits aggregation of inter domain delay and aggregation of delay of = a branch of a multicast tree. > >=20 > > - The samples ofcomment 'singletons' of IPPM one-way delay, packet loss= and jitter for a group of receiver:=20 > > Permit multiparty statistics; > >=20 > >=20 > > Regards > > Emile > >=20 > > -----Message d'origine----- > > De : Henk Uijterwaal [mailto:henk@ripe.net]=20 > > Envoy=E9 : lundi 31 janvier 2005 08:26 > > =C0 : STEPHAN Emile RD-CORE-LAN; ippm@ietf.org > > Cc : Matthew J Zekauskas > > Objet : Re: 'IPPM' IDs on multicast an spatial measure > >=20 > > Dear Emile, > >=20 > > >During the last WG meeting Matt asked me to reread the draft=20 > > >draft-liang-multiparty-para-00.txt while considering the previous IDs = I=20 > > >posted on spatial and multicast metrics. > > > > > >I reread them. Following is the list of metrics I found. I can make=20 > > >further classifications, comparisons or comments if needed. > >=20 > > Based on your reading of this draft, do you have any opinion on how > > we should proceed with draft-liang-multiparty... Pick it up as a WG > > item? Leave it to the authors to pursue as an individual submission? > >=20 > > Kind regards, > >=20 > > Henk > >=20 > >=20 > >=20 > >=20 > > >Regards > > > > > >Emile > >=20 > >=20 > >=20 > > >--------------- draft-stephan-ippm-multicast-metrics-00.txt ----------= ------ > > > > > >The draft defines 1 network metrics: > > > > > > + Type-P-spatial-hop-one-way-delay > > > > > > > > > > > >The draft defines several aggregation metrics: > > > > > > + Type-P-spatial-one-way-delay-stream > > > > > > + Type-P-spatial-one-way-delay > > > > > > + Type-P-Multicast-Instantaneous-Hop-One-way-Delay > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Median > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse Percen= tile > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Stream > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Median > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse Percenti= le > > > > > > + Type-P-Multicast-Instantaneous-Connectivity > > > > > > > > > > > >--------------- draft-stephan-ippm-spatial-metrics-01.txt ------------= --- > > > > > > > > > > > >The draft defines 2 network metrics: > > > > > > + Type-P-spatial-one-way-delay > > > > > > + Type-P-Spatial-packet-loss > > > > > > > > > > > >The draft defines several path aggregation metrics : > > > > > > + Type-P-one-way-delay-trajectory > > > > > > + Type-P-aggregated-one-way-delay > > > > > > + Type-P-asynchronous-one-way-delay-trajectory > > > > > > + Type-P-asynchronous-aggregated-one-way-delay > > > > > > + Type-P-Spatial-packet-loss-stream > > > > > > + Type-P-Spatial-packet-loss-Average > > > > > > > > > > > >--------------- draft-liang-multiparty-para-00.txt --------------- > > > > > >The draft defines statistics for end to end multicast performance, mai= nly=20 > > >to identify the variation of the performance between the member of a g= roup. > > > > > >Actually the draft has 4 groups of statistics metrics: > > > > > > One-to-group-Mean-Paramater > > > > > > One-to-group-Variation-Paramater > > > > > > Group-to-one-Mean-Paramater > > > > > > Group-to-one-Variation-Paramater > > > > > >The value of Parameter depends on what one-way metric is used from del= ay,=20 > > >loss ot jitter. > > > > > >To permit comparison I extended the list of metrics defined using IPPM= =20 > > >metrics terminology: > > > > > > + Type-P-One-to-group-Mean-one-way-delay; > > > > > > + Type-P-One-to-group-Mean-Packet-Loss; > > > > > > + Type-P-One-to-group-Mean-ipdv; > > > > > > > > > > > > + Type-P-One-to-group-Variation-one-way-delay; > > > > > > + Type-P-One-to-group-Variation-Packet-Loss; > > > > > > + Type-P-One-to-group-Variation-ipdv; > > > > > > > > > > > > + Type-P-Group-to-one-Mean-one-way-delay; > > > > > > + Type-P-Group-to-one-Mean-Packet-Loss; > > > > > > + Type-P-Group-to-one-Mean-ipdv; > > > > > > > > > > > > + Type-P-Group-to-one-Variation-one-way-delay; > > > > > > + Type-P-Group-to-one-Variation-Packet-Loss; > > > > > > + Type-P-Group-to-one-Variation-ipdv; > >=20 > > -----------------------------------------------------------------------= ------- > > Henk Uijterwaal Email: henk.uijterwaal(at)rip= e.net > > RIPE Network Coordination Centre http://www.amsterdamned.org/~= henk > > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > > The Netherlands The Netherlands Mobile: +31.6.55861746 > > -----------------------------------------------------------------------= ------- > >=20 > > Look here junior, don't you be so happy. > > And for Heaven's sake, don't you be so sad. (Tom Verlai= ne)=20 > >=20 > >=20 > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 3 13:08:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21945; Thu, 3 Feb 2005 13:08:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwli6-0007FQ-N1; Thu, 03 Feb 2005 13:28:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwlNV-0008Ja-3H; Thu, 03 Feb 2005 13:06:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwlGu-0006Dp-VX; Thu, 03 Feb 2005 13:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20817; Thu, 3 Feb 2005 13:00:01 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwlZW-0006wU-7G; Thu, 03 Feb 2005 13:19:19 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 18:59:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2005 18:59:57 +0100 Message-ID: Thread-Topic: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality Thread-Index: AcUKEDQhdmKnX4/YReSrrc9VeYm40QAATNpw From: "STEPHAN Emile RD-CORE-LAN" To: "Lei Liang" X-OriginalArrivalTime: 03 Feb 2005 17:59:58.0465 (UTC) FILETIME=[2CA95710:01C50A1A] X-Spam-Score: 1.0 (+) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable Cc: Zhili SunZhiliSun , pce , Henk Uijterwaal , ippm Subject: [Pce] RE: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / PCE metric to measure path quality X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Content-Transfer-Encoding: quoted-printable Dear Lei, The following comments focus on one idea: preparing a draft acceptable = from the IPPM framework point of view, which defines the minimal set of = metrics we need.=20 Regarding point 1: I consider that one-to-group metrics are easy to define on the top of = the metrics already defined by the IPPM WG. On the opposite group-to-one metrics are not easy to define while being = respectful of the IPPM framework mainly because a group-to-one metric = doesn't rely on one event but on a set of different packets, sent at = different time, arriving at different time...=20 I have the same issue with the aggregation of end-to-end one-way delays = over a path: the IPPM framework does not apply because it relies on = measures made at different times. So, in a way to merge ours drafts in a single IPPM one I propose to = ignore both the group-to-one metrics definitions and the definitions of = metrics for aggregation of end-to-end one-way delays and loss (and = obviously jitter!); =09 Regarding point 2: I agree, spatial metrics are applicable to multicast, to TE, to = interdomain...but this doesn't look to be a hot topic at IETF :-) Regarding points 3 and 7: The definitions of One-to-group streams of delay or of loss are needed = only to write unambiguous definitions of statistics. The way the = measures of singletons of end-to-end metrics are collected is out of the = scope of the definition. Regarding points 4 and 8:=20 Several metrics can merge. We can use the name group-to-one... Regarding points 5 and 6: I agree. Jitter is needed. What about the next step. I propose that we write quickly an I-D = considering the comments above in a way to present it during the next = meeting in Minneapolis. I am quite that Henk will give us at least 5 = minutes to present it. I can send you a first template in xml if you agree. Regards Emile =20 qclearly define statistic metrics on it stream -----Message d'origine----- De=A0: Lei Liang [mailto:L.Liang@surrey.ac.uk]=20 Envoy=E9=A0: jeudi 3 f=E9vrier 2005 17:30 =C0=A0: STEPHAN Emile RD-CORE-LAN Cc=A0: Henk Uijterwaal; pce; ippm; Zhili SunZhiliSun Objet=A0: RE: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / = PCE metric to measure path quality Dear Emile, Thanks for your sugguestion. I have read through the mulitcast metrics and got some comments here.=20 1:the general difference of your draft and mine is our view point. your draft mainly consided the individual users in the group while mine emphasized the group. I am trying to view the group as one client with special consideration on the relative QoS. =20 2: your spatial metrics can be for more general measurement cases rather than only limited to multicast. It can provide very detail information for each multicast branch that is extremely useful to identify the problem network segment for inter-domain connctions. 3:regarding your Instantaneous One-way Delay Stream, it is trying to collect a set of unicast measurement results together if I didn't misunderstand. I have one question here that if we extremely need such a collection to form a new metric while we actually can have the unicast one-way metric first. The potential problem might be the metric size while we have huge size multicast groups, e.g. internet gaming, live tv, etc.=20 4: regarding the Type-P-Multicast-Instantaneous-Hop-One-way-Delay, it is quite similar to the one-to-group mean delay defined in my draft. I suggest we can merge them together. 5:the mean, or average, of the one-way delay can't present the relative delay which is also very important for group communication as I mentioned in my draft. so I suggest to keep the consideration on the delay variation. 6: moreover, the jitter is also very important for the highly interactive communications and we can not ignore it. 7: the relevant metrics you defined for packet loss is more concern with individual users, as i said above, and can be very useful for problem identification. the problem is still regarding the huge group size.=20 8: I suggest we use mean instead of median because it can reflect the trend of the QoS among the group members. Those are the comments for now. Your response will be appreciated. Regards, lei =20 On Wed, 2005-02-02 at 16:41, STEPHAN Emile RD-CORE-LAN wrote: > Dear Lei, >=20 > You might take a glance at the old draft defining multicast metrics = too. As an example the section 7 defines the metric = Type-P-Multicast-Instantaneous-One-way-Delay-Stream. This stream is the = list of the instantaneous delays between one source and a group of = receiver. So from my point of view it provides directly the material for = computing One-to-group statistics. >=20 > These drafts are no more available on the IETF site, but they are = still online > = http://www.watersprings.org/pub/id/draft-stephan-ippm-multicast-metrics-0= 0.txt > = http://www.watersprings.org/pub/id/draft-stephan-ippm-spatial-metrics-01.= txt >=20 > Regards > Emile >=20 > -----Message d'origine----- > De : Lei Liang [mailto:L.Liang@surrey.ac.uk]=20 > Envoy=E9 : mercredi 2 f=E9vrier 2005 13:42 > =C0 : STEPHAN Emile RD-CORE-LAN > Cc : Henk Uijterwaal; pce@ietf.org; ippm@ietf.org; Zhili SunZhiliSun > Objet : Re: [ippm] RE: 'IPPM' IDs on multicast and spatial measure / = PCE metric to measure path quality >=20 > Dear Emile and Henk, > Thank you very much for your comments on the draft. I will read > through draft-stephan-ippm-spatial-metrics-01.txt to help merge these > two drafts together according to the comments >=20 > cheers, > lei >=20 > Tue, 2005-02-01 at 18:15, STEPHAN Emile RD-CORE-LAN wrote: > > Dear Henk, > >=20 > > >From my point of view these 3 drafts may merge and in a WG draft = that defines the minimal set of metrics to permit spatial and multicast = measurements. > >=20 > > These metrics are the ones needed in the PCE WG to measure path = quality and the ones needed to measure multicast tree performance: > >=20 > > - The decomposition of 'singletons' of IPPM one-way delay, packet = loss and jitter over a path:=20 > > Samples of instantaneous per hop performance; > >=20 > > - The delay, loss and jitter of a hop of a path; > > An item of the previous decomposition;=20 > >=20 > > - The aggregation of end-to-end one-way delays over a path is needed = too: > > Permits aggregation of inter domain delay and aggregation of delay = of a branch of a multicast tree. > >=20 > > - The samples ofcomment 'singletons' of IPPM one-way delay, packet = loss and jitter for a group of receiver:=20 > > Permit multiparty statistics; > >=20 > >=20 > > Regards > > Emile > >=20 > > -----Message d'origine----- > > De : Henk Uijterwaal [mailto:henk@ripe.net]=20 > > Envoy=E9 : lundi 31 janvier 2005 08:26 > > =C0 : STEPHAN Emile RD-CORE-LAN; ippm@ietf.org > > Cc : Matthew J Zekauskas > > Objet : Re: 'IPPM' IDs on multicast an spatial measure > >=20 > > Dear Emile, > >=20 > > >During the last WG meeting Matt asked me to reread the draft=20 > > >draft-liang-multiparty-para-00.txt while considering the previous = IDs I=20 > > >posted on spatial and multicast metrics. > > > > > >I reread them. Following is the list of metrics I found. I can make = > > >further classifications, comparisons or comments if needed. > >=20 > > Based on your reading of this draft, do you have any opinion on how > > we should proceed with draft-liang-multiparty... Pick it up as a WG > > item? Leave it to the authors to pursue as an individual = submission? > >=20 > > Kind regards, > >=20 > > Henk > >=20 > >=20 > >=20 > >=20 > > >Regards > > > > > >Emile > >=20 > >=20 > >=20 > > >--------------- draft-stephan-ippm-multicast-metrics-00.txt = ---------------- > > > > > >The draft defines 1 network metrics: > > > > > > + Type-P-spatial-hop-one-way-delay > > > > > > > > > > > >The draft defines several aggregation metrics: > > > > > > + Type-P-spatial-one-way-delay-stream > > > > > > + Type-P-spatial-one-way-delay > > > > > > + Type-P-Multicast-Instantaneous-Hop-One-way-Delay > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Percentile > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Median > > > > > > + Type-P-Multicast-Instantaneous-One-way-Delay-Inverse = Percentile > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Stream > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Percentile > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Median > > > > > > + Type-P-Multicast-Instantaneous-Packet-Loss-Inverse = Percentile > > > > > > + Type-P-Multicast-Instantaneous-Connectivity > > > > > > > > > > > >--------------- draft-stephan-ippm-spatial-metrics-01.txt = --------------- > > > > > > > > > > > >The draft defines 2 network metrics: > > > > > > + Type-P-spatial-one-way-delay > > > > > > + Type-P-Spatial-packet-loss > > > > > > > > > > > >The draft defines several path aggregation metrics : > > > > > > + Type-P-one-way-delay-trajectory > > > > > > + Type-P-aggregated-one-way-delay > > > > > > + Type-P-asynchronous-one-way-delay-trajectory > > > > > > + Type-P-asynchronous-aggregated-one-way-delay > > > > > > + Type-P-Spatial-packet-loss-stream > > > > > > + Type-P-Spatial-packet-loss-Average > > > > > > > > > > > >--------------- draft-liang-multiparty-para-00.txt --------------- > > > > > >The draft defines statistics for end to end multicast performance, = mainly=20 > > >to identify the variation of the performance between the member of = a group. > > > > > >Actually the draft has 4 groups of statistics metrics: > > > > > > One-to-group-Mean-Paramater > > > > > > One-to-group-Variation-Paramater > > > > > > Group-to-one-Mean-Paramater > > > > > > Group-to-one-Variation-Paramater > > > > > >The value of Parameter depends on what one-way metric is used from = delay,=20 > > >loss ot jitter. > > > > > >To permit comparison I extended the list of metrics defined using = IPPM=20 > > >metrics terminology: > > > > > > + Type-P-One-to-group-Mean-one-way-delay; > > > > > > + Type-P-One-to-group-Mean-Packet-Loss; > > > > > > + Type-P-One-to-group-Mean-ipdv; > > > > > > > > > > > > + Type-P-One-to-group-Variation-one-way-delay; > > > > > > + Type-P-One-to-group-Variation-Packet-Loss; > > > > > > + Type-P-One-to-group-Variation-ipdv; > > > > > > > > > > > > + Type-P-Group-to-one-Mean-one-way-delay; > > > > > > + Type-P-Group-to-one-Mean-Packet-Loss; > > > > > > + Type-P-Group-to-one-Mean-ipdv; > > > > > > > > > > > > + Type-P-Group-to-one-Variation-one-way-delay; > > > > > > + Type-P-Group-to-one-Variation-Packet-Loss; > > > > > > + Type-P-Group-to-one-Variation-ipdv; > >=20 > > = -------------------------------------------------------------------------= ----- > > Henk Uijterwaal Email: = henk.uijterwaal(at)ripe.net > > RIPE Network Coordination Centre = http://www.amsterdamned.org/~henk > > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > > The Netherlands The Netherlands Mobile: +31.6.55861746 > > = -------------------------------------------------------------------------= ----- > >=20 > > Look here junior, don't you be so happy. > > And for Heaven's sake, don't you be so sad. (Tom = Verlaine)=20 > >=20 > >=20 > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 10 07:35:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24148; Thu, 10 Feb 2005 07:35:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzDrh-0002C5-CE; Thu, 10 Feb 2005 07:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDUO-0006g1-MC; Thu, 10 Feb 2005 07:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDOn-000589-5O for pce@megatron.ietf.org; Thu, 10 Feb 2005 07:26:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23145 for ; Thu, 10 Feb 2005 07:26:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzDin-0001xG-Qy for pce@ietf.org; Thu, 10 Feb 2005 07:47:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2005 04:34:42 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1ACPjuC000275; Thu, 10 Feb 2005 04:25:45 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-108.cisco.com [10.86.240.108]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA00975; Thu, 10 Feb 2005 04:25:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: pce@ietf.org Message-Id: <79a9f1c7f7710c36e2fa3d3caae37ee1@cisco.com> From: JP Vasseur Date: Thu, 10 Feb 2005 07:25:47 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Pce] Provisional PCE WG meeting agenda for Minneapolis 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="===============0055442643==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --===============0055442643== Content-Type: multipart/alternative; boundary=Apple-Mail-16-882129158 --Apple-Mail-16-882129158 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, Considering our Milestones and since protocol requirements IDs must be worked out first before protocols IDs, we would like to propose the following agenda: 1) Agenda/admin (5mn) 2) Charter overview and ground-rules for WG (10mn) 3) Architecture draft: (Jerry Ash - 15mn) draft-ash-pce-architecture-01.txt 4) PCE Discovery requirements draft (Jean-Louis Le Roux - 10mn) draft-leroux-pce-discovery-reqs.txt 5) PCC/PCE + PCE/PCE Communication requirements slides (Design Team - 20mn) - No draft at this time. 6) Discussion (30mn) 7) Any other business (5) Feel free to make suggestion. End Speakers, please provide me your slides by March 5. Thanks, JP and Adrian. --Apple-Mail-16-882129158 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Considering our Milestones and since protocol requirements IDs must be worked out first before protocols IDs, we would like to propose the following agenda: 1) Agenda/admin (5mn) 2) Charter overview and ground-rules for WG (10mn) 3) Architecture draft: (Jerry Ash - 15mn) draft-ash-pce-architecture-01.txt 4) PCE Discovery requirements draft (Jean-Louis Le Roux - 10mn) draft-leroux-pce-discovery-reqs.txt 5) PCC/PCE + PCE/PCE Communication requirements slides (Design Team - 20mn) - No draft at this time. 6) Discussion (30mn) 7) Any other business (5) Feel free to make suggestion. End Speakers, please provide me your slides by March 5. Thanks, JP and Adrian. --Apple-Mail-16-882129158-- --===============0055442643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0055442643==-- From pce-bounces@ietf.org Thu Feb 10 17:58:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03163; Thu, 10 Feb 2005 17:58:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNau-0005gE-Kl; Thu, 10 Feb 2005 18:19:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzN6m-0000SR-F7; Thu, 10 Feb 2005 17:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzMfq-0007c8-9J for pce@megatron.ietf.org; Thu, 10 Feb 2005 17:20:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24397 for ; Thu, 10 Feb 2005 17:20:31 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzMzv-0002iu-Or for pce@ietf.org; Thu, 10 Feb 2005 17:41:20 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 13A17E000220 for ; Thu, 10 Feb 2005 22:19:53 +0000 (GMT) Received: from Puppy ([212.43.203.252] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 22:11:37 +0000 Message-ID: <034c01c50fbd$ade04980$b5cb2bd4@Puppy> From: "Adrian Farrel" To: Date: Thu, 10 Feb 2005 22:09:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 10 Feb 2005 22:11:38.0483 (UTC) FILETIME=[7DDD7C30:01C50FBD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Pce] Early WG schedule for Minneapolis X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, The early, provisional schedule for Minneapolis shows PCE on Wednesday at 1 pm. This is not yet definitive. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 17 05:03:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01415; Thu, 17 Feb 2005 05:03:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ir0-00060T-Sp; Thu, 17 Feb 2005 05:25:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iTH-0005EX-8v; Thu, 17 Feb 2005 05:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iQX-0004Cv-4P for pce@megatron.ietf.org; Thu, 17 Feb 2005 04:58:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00873 for ; Thu, 17 Feb 2005 04:58:24 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ilu-0005sd-33 for pce@ietf.org; Thu, 17 Feb 2005 05:20:35 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 4B81DE000214; Thu, 17 Feb 2005 09:57:49 +0000 (GMT) Received: from Puppy ([212.43.203.197] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 09:57:48 +0000 Message-ID: <037c01c514d7$5471b770$adcb2bd4@Puppy> From: "Adrian Farrel" To: Date: Thu, 17 Feb 2005 09:53:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Feb 2005 09:57:49.0125 (UTC) FILETIME=[2336DF50:01C514D7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Pce] PCE Meeting re-scheduled X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, The PCE meeting appears to have been re-scheduled to Monday at 1530-1730. That this was done apparently without any request and without consultation with the chairs is only a minor source of aggravation. :-) I hope this gives no-one any greater problem than it gives me. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 17 16:18:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06400; Thu, 17 Feb 2005 16:18:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tO0-0008Aa-95; Thu, 17 Feb 2005 16:40:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r3Y-0008Ne-2X; Thu, 17 Feb 2005 14:11:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1pEJ-0000xU-G5 for pce@megatron.ietf.org; Thu, 17 Feb 2005 12:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26096 for ; Thu, 17 Feb 2005 12:14:17 -0500 (EST) Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1pZk-0004Sp-U7 for pce@ietf.org; Thu, 17 Feb 2005 12:36:32 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j1HHBvI8009880 for ; Thu, 17 Feb 2005 11:13:43 -0600 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.1.006) id 41EA9EF5006F821E for pce@ietf.org; Thu, 17 Feb 2005 12:13:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2005 11:13:43 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE486@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-pce-comm-protocol-reqs-00.txt Thread-Index: AcUTg4Cx7B69YMDoR/m6KuTpvjacggBjlfQQ From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Pce] RE: I-D ACTION:draft-ash-pce-comm-protocol-reqs-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi All, Please review and comment on "Path Computation Element (PCE) Communication Protocol Requirements" http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-reqs-00. txt. This document is the result of a joint effort by the PCE communication protocol requirements design team, and will be discussed at IETF-62. It would be a good time to raise comments and issues for discussion on the list prior to the meeting. Thanks, Regards, =20 PCE Communication Protocol Requirements Design Team: Jerry Ash (AT&T) Alia Atlas (Avici) Arthi Ayyangar (Juniper) Igor Bryskin (Independent Consultant) Dean Cheng (Cisco) Durga Gangisetti (MCI) Kenji Kumaki (KDDI) Jean-Louis Le Roux (France Telecom) Eiji Oki (NTT) Raymond Zhang (Infonet) -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 15, 2005 10:24 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-pce-comm-protocol-reqs-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element (PCE) Communication Protocol Requirements Author(s) : J. Ash Filename : draft-ash-pce-comm-protocol-reqs-00.txt Pages : 12 Date : 2005-2-14 =09 Constraint-based path computation is a fundamental building block for traffic engineering systems such as MPLS and GMPLS networks. Path computation in large, multi-domain or multi-layer networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the communication protocol requirements for a Path Computation Element (PCE)-based model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-pce-comm-protocol-reqs-00. txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Tue Feb 22 22:36:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20951; Tue, 22 Feb 2005 22:36:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nh9-0005PD-Ei; Tue, 22 Feb 2005 23:00:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NTt-0005PO-7m; Mon, 21 Feb 2005 19:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3LXd-0005lR-VU for pce@megatron.ietf.org; Mon, 21 Feb 2005 16:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19365 for ; Mon, 21 Feb 2005 16:56:26 -0500 (EST) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Ltv-00066E-5E for pce@ietf.org; Mon, 21 Feb 2005 17:19:35 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j1LLtTxe013216 for ; Mon, 21 Feb 2005 15:55:54 -0600 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.1.006) id 4218C3700004AB27 for pce@ietf.org; Mon, 21 Feb 2005 16:55:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2005 15:55:53 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE492@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-pce-architecture-01.txt Thread-Index: AcUV0l94OVpV34qQSKuWaUq/DbBNFwCizYrQ From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Subject: [Pce] RE: I-D ACTION:draft-ash-pce-architecture-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Hi All, Please review and comment on the updated "PCE Architecture" draft http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt. =20 Updates to the draft were made based on discussions of issues on the list and at IETF-61. Here is a summary of the changes: 1. Text added to Section 6.4: PCE should advertise its capabilities, for example, set of constraints it can account for (diversity, SRLGs, optical impairments, wavelength continuity, etc.). 2. Text added to Section 6.6: Path computation request should include if near-disjoint paths acceptable. 3. Text added to Section 6.7: TED information can include info from sources other than IGP (e.g. LSP routes, reserved bandwidth, measured traffic volume). Information needed to perform LSP re-optimization and to reconfigure virtual network topology (VNT) lower layer (e.g., optical) paths. 4. Text added to Section 6.8: Elaborate on advantages of stateful PCE and pitfalls of using stateful PCE in a distributed PCE environment. 5. Text added to Section 7: Evaluation metrics should include TED synchronization speed and impact on the data flows. 6. Added Section 5.5 "Areas for Standardization": Identifies areas for standardization based on PCE Charter. 7. Other editorial changes. The PCE architecture document will be discussed at IETF-62. It would be a good time to raise comments and issues for discussion on the list prior to the meeting. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 18, 2005 10:03 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ash-pce-architecture-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element (PCE) Architecture Author(s) : A. Farrel, et al. Filename : draft-ash-pce-architecture-01.txt Pages : 20 Date : 2005-2-17 =09 Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layers networks is highly complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-01.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Thu Feb 24 13:08:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24734; Thu, 24 Feb 2005 13:08:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Nmh-0005sT-Vl; Thu, 24 Feb 2005 13:32:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NL1-0005JW-SX; Thu, 24 Feb 2005 13:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NL0-0005Is-1j for pce@megatron.ietf.org; Thu, 24 Feb 2005 13:03:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23942 for ; Thu, 24 Feb 2005 13:03:42 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Nhw-0005f8-5r for pce@ietf.org; Thu, 24 Feb 2005 13:27:28 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 19:02:51 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 24 Feb 2005 19:03:09 +0100 Message-ID: Thread-Topic: PCE Discovery Requirements Thread-Index: AcUamxINkZ9/IUb0Q9GYH0xWp+yNZQ== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 24 Feb 2005 18:02:51.0828 (UTC) FILETIME=[0EAB2F40:01C51A9B] X-Spam-Score: 0.6 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [Pce] PCE Discovery Requirements 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="===============0326834174==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d This is a multi-part message in MIME format. --===============0326834174== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51A9B.195EA214" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51A9B.195EA214 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here is a requirements ID for automatic PCE discovery. Your comments on this draft would be highly welcome. Best Regards, JL A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-leroux-pce-discovery-reqs-00.txt Pages : 10 Date : 2005-2-14 =09 This document presents a set of requirements for a Path Computation=20 Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs=20 along with their capabilities. It is intended that solutions that=20 specify procedures and protocol extensions for such PCE discovery=20 satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.t xt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-leroux-pce-discovery-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_001_01C51A9B.195EA214 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PCE Discovery Requirements

Hi all,

Here is a requirements ID for = automatic PCE discovery.

Your comments on this draft would be = highly welcome.

Best Regards,

JL


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


        Title   =         : Requirements for Path = Computation Element (PCE) Discovery
        Author(s)       : J. Le = Roux, et al.
        Filename        : = draft-leroux-pce-discovery-reqs-00.txt
        Pages   =         : 10
        Date    =         : 2005-2-14
       =20
This document presents a set of = requirements for a Path Computation
   Element (PCE) discovery = mechanism that would allow a Path Computation
   Client (PCC) to = discover dynamically and automatically a set of PCEs
   along with their = capabilities. It is intended that solutions that
   specify procedures and = protocol extensions for such PCE discovery
   satisfy these = requirements.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-leroux-pce-dis= covery-reqs-00.txt

To remove yourself from the I-D = Announcement list, send a message to
i-d-announce-request at 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-leroux-pce-discovery-reqs-00.txt".

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


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

Send a message to:
        mailserv at ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable = a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-leroux-pce-disc= overy-reqs-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce



------_=_NextPart_001_01C51A9B.195EA214-- --===============0326834174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0326834174==-- From pce-bounces@ietf.org Fri Feb 25 02:51:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12138; Fri, 25 Feb 2005 02:51:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4aFx-0001kj-OD; Fri, 25 Feb 2005 02:51:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4aFf-0005o3-Ph; Fri, 25 Feb 2005 02:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4aFA-0005fM-MD for pce@megatron.ietf.org; Fri, 25 Feb 2005 02:50:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12041 for ; Fri, 25 Feb 2005 02:50:34 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4aF7-0001jR-Ox for pce@ietf.org; Fri, 25 Feb 2005 02:50:41 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00EVSJ1XU9@szxga03-in.huawei.com> for pce@ietf.org; Fri, 25 Feb 2005 15:49:09 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00JA0J1XN8@szxga03-in.huawei.com> for pce@ietf.org; Fri, 25 Feb 2005 15:49:09 +0800 (CST) Received: from z18605 ([10.110.49.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICG00LUTJ4MJI@szxml02-in.huawei.com>; Fri, 25 Feb 2005 15:50:47 +0800 (CST) Date: Fri, 25 Feb 2005 15:27:30 +0800 From: zrh Subject: Re: [Pce] PCE Discovery Requirements To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org Message-id: <02bf01c51b0b$7e457ac0$37316e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 1.1 (+) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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="===============1967229229==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. --===============1967229229== Content-type: multipart/alternative; boundary="Boundary_(ID_lC3TcxB+uYu7YL0AbSaqpQ)" This is a multi-part message in MIME format. --Boundary_(ID_lC3TcxB+uYu7YL0AbSaqpQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT PCE Discovery RequirementsDear J. Le Roux, I have been looking in detail at draft-leroux-pce-discovery-reqs-00.txt,and I have some questions and comments.I'd really appreciate it if you could spare the time to look at both these points. 1)In section 5.2,the last PCE computation capabilities to be advertised is "The PCE capacity in terms of computation power", for the reasion of weighted load balancing of requests in case PCEs do not have the same capacity. I think this is not enough, before PCC sends a request to PCE for a path compution,PCC should also know if the PCE is busy, how busy(maybe the PCE has many path compution requests from another PCCs which have not reply for some reason even if the PCE have pawerful CPU). To reasonably distribute PCCs's computation requests to PCEs ,PCCs should know the current status of all PCEs's CPU. so I think the status of PCE's CPU(or number of requests which have not been replied, etc) can be included in the hello packet sent by PCE,maybe such hello packet is needed. 2)In section 5.3,the backup PCEs are discussed,the location of backup PCE is advertised by PCE. I don't think location of backup PCE can be decided by PCE . Each PCE may has different abilities for path compution,so PCC may select different PCE to send request for different request,backup PCE is also not fixed.In other words,the selection of PCE and buckup PCE are also relevant to the computation requests,and are not fixed because of the different requirement of computation. 3)In section 5.5 third paragraph"The delay for such detection MUST be beyond 60s" Maybe a "not" is needed. Thanks, Zhang ----- Original Message ----- From: LE ROUX Jean-Louis RD-CORE-LAN To: pce@ietf.org Sent: Friday, February 25, 2005 2:03 AM Subject: [Pce] PCE Discovery Requirements Hi all, Here is a requirements ID for automatic PCE discovery. Your comments on this draft would be highly welcome. Best Regards, JL A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-leroux-pce-discovery-reqs-00.txt Pages : 10 Date : 2005-2-14 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with their capabilities. It is intended that solutions that specify procedures and protocol extensions for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-leroux-pce-discovery-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_lC3TcxB+uYu7YL0AbSaqpQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT PCE Discovery Requirements
Dear J. Le Roux,
I have been looking in detail at draft-leroux-pce-discovery-reqs-00.txt,and I have some questions and comments.I'd really appreciate it if
 you could spare the time to look at both these points.
 
1)In section 5.2,the last PCE computation capabilities to be advertised is "The PCE capacity in terms of computation power", for the reasion of weighted load balancing of requests in case PCEs do not have the same capacity.
 
I think this is not enough, before PCC sends a request to PCE for a path compution,PCC should also know if the PCE is busy, how busy(maybe the PCE has many path compution requests from another PCCs which have not reply for some reason even if the PCE have pawerful CPU).
To reasonably distribute PCCs's computation requests to PCEs ,PCCs should know the current status of all PCEs's CPU. so I think the status of PCE's CPU(or number of requests which have not been replied, etc) can be included in the hello packet sent by PCE,maybe such hello packet is needed.
 
2)In section 5.3,the backup PCEs are discussed,the location of backup PCE is advertised by PCE.
 
I don't think location of backup PCE can be decided by PCE .
Each PCE may has different abilities for path compution,so PCC may select different PCE to send request for different request,backup PCE  is also not fixed.In other words,the selection of PCE and buckup PCE are also relevant to the computation requests,and are not fixed because of the different requirement of computation.
 
3)In section 5.5 third paragraph"The delay for such detection MUST be beyond 60s"
Maybe a "not" is needed.
 
Thanks,
Zhang
----- Original Message -----
Sent: Friday, February 25, 2005 2:03 AM
Subject: [Pce] PCE Discovery Requirements

Hi all,

Here is a requirements ID for automatic PCE discovery.

Your comments on this draft would be highly welcome.

Best Regards,

JL


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


        Title           : Requirements for Path Computation Element (PCE) Discovery
        Author(s)       : J. Le Roux, et al.
        Filename        : draft-leroux-pce-discovery-reqs-00.txt
        Pages           : 10
        Date            : 2005-2-14
       
This document presents a set of requirements for a Path Computation
   Element (PCE) discovery mechanism that would allow a Path Computation
   Client (PCC) to discover dynamically and automatically a set of PCEs
   along with their capabilities. It is intended that solutions that
   specify procedures and protocol extensions for such PCE discovery
   satisfy these requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at 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-leroux-pce-discovery-reqs-00.txt".

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


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

Send a message to:
        mailserv at ietf.org.
In the body type:
        "FILE /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
               
               
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
--Boundary_(ID_lC3TcxB+uYu7YL0AbSaqpQ)-- --===============1967229229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1967229229==-- From pce-bounces@ietf.org Fri Feb 25 07:16:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06106; Fri, 25 Feb 2005 07:16:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4eOo-0007Dl-Pv; Fri, 25 Feb 2005 07:16:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eN8-0006MS-2E; Fri, 25 Feb 2005 07:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4eN5-0006M7-OW for pce@megatron.ietf.org; Fri, 25 Feb 2005 07:15:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06061 for ; Fri, 25 Feb 2005 07:15:00 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4eNB-0007CL-O2 for pce@ietf.org; Fri, 25 Feb 2005 07:15:11 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id B824CE000283; Fri, 25 Feb 2005 12:14:41 +0000 (GMT) Received: from Puppy ([212.43.203.99] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 12:12:25 +0000 Message-ID: <10e801c51b33$77c57b00$adcb2bd4@Puppy> From: "Adrian Farrel" To: "zrh" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <02bf01c51b0b$7e457ac0$37316e0a@huawei.com> Subject: Re: [Pce] PCE Discovery Requirements Date: Fri, 25 Feb 2005 12:11:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Feb 2005 12:12:26.0579 (UTC) FILETIME=[450E8A30:01C51B33] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Hi Zhang, Thanks for your comments. > 1)In section 5.2,the last PCE computation capabilities to be advertised is "The PCE capacity in terms of computation power", for the reasion of weighted load balancing of requests in case PCEs do not have the same capacity. > > I think this is not enough, before PCC sends a request to PCE for a path compution,PCC should also know if the PCE is busy, how busy(maybe the PCE has many path compution requests from another PCCs which have not reply for some reason even if the PCE have pawerful CPU). > To reasonably distribute PCCs's computation requests to PCEs ,PCCs should know the current status of all PCEs's CPU. so I think the status of PCE's CPU(or number of requests which have not been replied, etc) can be included in the hello packet sent by PCE,maybe such hello packet is needed. On the face of it, this is a reasonable requirement. As you say, the PCC would ideally select the least busy PCE to perform its computation for it. We need to be careful to separate this requirement from how it might be satisfied. So discussion of hello packets snet by PCE should be avoided at this stage. This is probably important because the use of a hello packet might not be a good way of satisfying this requirement - the computation time for a single PCE request is likely to be no more than a few hundred milliseconds and we would certainly need to think hard before asking that each PCE sends a new status message to every PCC in the network every hundred milliseconds. I have a concern however. Suppose you had a network with two PCEs and a lot of active PCCs. In the event that one PCE was slightly more busy than the other, all of the PCCs would send their requests to the other PCE causing immediate congestion. So here is a suggestion. Suppose instead of measuring queue size and CPU capacity we simply allow a PCE to report its status as "congested" if it deems that it is too busy. PCEs may still continue to send requests to a congested PCE, but may use this information to prefer a different PCE. The congested flag can be set and flooded instantly the PCE believes that it is congested, and only releases under a threshold and on a normal discovery refresh. > 2)In section 5.3,the backup PCEs are discussed,the location of backup PCE is advertised by PCE. > > I don't think location of backup PCE can be decided by PCE . > Each PCE may has different abilities for path compution,so PCC may select different PCE to send request for different request,backup PCE is also not fixed.In other words,the selection of PCE and buckup PCE are also relevant to the computation requests,and are not fixed because of the different requirement of computation. Well, a PCE *might* know that it has a partner that matches (or betters) its capabilities and which acts as its backup. In this case, why should it not advertise this information? > 3)In section 5.5 third paragraph"The delay for such detection MUST be beyond 60s" > Maybe a "not" is needed. Indeed. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Feb 26 02:29:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07801; Sat, 26 Feb 2005 02:29:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4wOX-00061p-7M; Sat, 26 Feb 2005 02:29:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4wNC-0004xV-QW; Sat, 26 Feb 2005 02:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4wNA-0004wI-Lr for pce@megatron.ietf.org; Sat, 26 Feb 2005 02:28:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07713 for ; Sat, 26 Feb 2005 02:28:18 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4wNL-00060N-FH for pce@ietf.org; Sat, 26 Feb 2005 02:28:37 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICI00LRVCU91A@szxga02-in.huawei.com> for pce@ietf.org; Sat, 26 Feb 2005 15:30:10 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICI00EYZCU94Y@szxga02-in.huawei.com> for pce@ietf.org; Sat, 26 Feb 2005 15:30:09 +0800 (CST) Received: from z18605 ([10.110.49.55]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICI008AFCU5OY@szxml02-in.huawei.com>; Sat, 26 Feb 2005 15:30:05 +0800 (CST) Date: Sat, 26 Feb 2005 15:06:53 +0800 From: Renhai Zhang Subject: Re: [Pce] PCE Discovery Requirements To: Adrian Farrel Message-id: <03e601c51bd1$c0b61380$37316e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <02bf01c51b0b$7e457ac0$37316e0a@huawei.com> <10e801c51b33$77c57b00$adcb2bd4@Puppy> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Dear Adrian, Thanks for your reply.Please see my words in-line. > So here is a suggestion. Suppose instead of measuring queue size and CPU > capacity we simply allow a PCE to report its status as "congested" if it > deems that it is too busy. PCEs may still continue to send requests to a > congested PCE, but may use this information to prefer a different PCE. > The congested flag can be set and flooded instantly the PCE believes that > it is congested, and only releases under a threshold and on a normal > discovery refresh. Good idea. I think it is the best way to solve PCE's congesttion if such thing exists. > Well, a PCE *might* know that it has a partner that matches (or betters) > its capabilities and which acts as its backup. In this case, why should it > not advertise this information? Right, but I have a doubt: Why does PCE know more such info than PCCs? Is there anything defferent between PCE and PCC for discovery of PCE in the discovery mechanism? Can we use the mechanism of selecting DR and BDR in OSPF protocol for reference? Best regards, Zhang _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Feb 26 07:23:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24918; Sat, 26 Feb 2005 07:23:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D50zE-0002Am-Cw; Sat, 26 Feb 2005 07:23:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D50xN-00054Z-B7; Sat, 26 Feb 2005 07:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D50xJ-00054L-6u for pce@megatron.ietf.org; Sat, 26 Feb 2005 07:21:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24871 for ; Sat, 26 Feb 2005 07:21:53 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D50xa-00029o-Gr for pce@ietf.org; Sat, 26 Feb 2005 07:22:17 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Feb 2005 13:18:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE : [Pce] PCE Discovery Requirements Date: Sat, 26 Feb 2005 13:18:42 +0100 Message-ID: Thread-Topic: [Pce] PCE Discovery Requirements Thread-Index: AcUbDnlTz43h++wbQ52SXHWsRIwzUAA6fugg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "zrh" , X-OriginalArrivalTime: 26 Feb 2005 12:18:32.0056 (UTC) FILETIME=[494FA780:01C51BFD] X-Spam-Score: 0.8 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 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="===============0816047275==" Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: e9051aca6d23a9cf6df09e1ef4738712 This is a multi-part message in MIME format. --===============0816047275== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51BFD.51425B4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51BFD.51425B4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zhang, =20 Please see inline, =20 =20 -----Message d'origine----- De : zrh [mailto:zhangrenhai@huawei.com]=20 Envoy=E9 : vendredi 25 f=E9vrier 2005 08:28 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] PCE Discovery Requirements Dear J. Le Roux, I have been looking in detail at = draft-leroux-pce-discovery-reqs-00.txt,and I have some questions and = comments.I'd really appreciate it if you could spare the time to look at both these points. =20 1)In section 5.2,the last PCE computation capabilities to be advertised = is "The PCE capacity in terms of computation power", for the reasion of = weighted load balancing of requests in case PCEs do not have the same = capacity. =20 I think this is not enough, before PCC sends a request to PCE for a path = compution,PCC should also know if the PCE is busy, how busy(maybe the = PCE has many path compution requests from another PCCs which have not = reply for some reason even if the PCE have pawerful CPU). To reasonably distribute PCCs's computation requests to PCEs ,PCCs = should know the current status of all PCEs's CPU. so I think the status = of PCE's CPU(or number of requests which have not been replied, etc) can = be included in the hello packet sent by PCE,maybe such hello packet is = needed. [JLLR]=20 Actually, advertising CPU status, would require very frequent = advertisements to be meaningful. As mentionned by Adrian, a PCE CPU = status may change highly frequently.=20 For instance let's assume 10 path computations served per second with = 50ms per path computation. This would lead to 20 advertisements per second... An alternative could rely on a periodic advertisement of the average CPU = load, but this may actually not be really relevant. =20 =20 2)In section 5.3,the backup PCEs are discussed,the location of backup = PCE is advertised by PCE. =20 I don't think location of backup PCE can be decided by PCE . Each PCE may has different abilities for path compution,so PCC may = select different PCE to send request for different request,backup PCE = is also not fixed.In other words,the selection of PCE and buckup PCE are = also relevant to the computation requests,and are not fixed because of = the different requirement of computation. [JLLR] Yes but assuming that PCE and backup PCE have the same = capabilities this may ease backup selection procedure. Note that this is not a MUST but a SHOULD requirement. But I agree that this point requires more discussions... =20 3)In section 5.5 third paragraph"The delay for such detection MUST be = beyond 60s" Maybe a "not" is needed. [JLLR]=20 Yes this is of course a "not", =20 Thanks a lot, Zhang, for these useful comments. =20 Best Regards =20 JL=20 =20 Thanks, Zhang ----- Original Message -----=20 From: LE ROUX Jean-Louis = RD-CORE-LAN=20 To: pce@ietf.org=20 Sent: Friday, February 25, 2005 2:03 AM Subject: [Pce] PCE Discovery Requirements Hi all,=20 Here is a requirements ID for automatic PCE discovery.=20 Your comments on this draft would be highly welcome.=20 Best Regards,=20 JL=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 Title : Requirements for Path Computation Element = (PCE) Discovery=20 Author(s) : J. Le Roux, et al.=20 Filename : draft-leroux-pce-discovery-reqs-00.txt=20 Pages : 10=20 Date : 2005-2-14=20 =20 This document presents a set of requirements for a Path Computation=20 Element (PCE) discovery mechanism that would allow a Path Computation = Client (PCC) to discover dynamically and automatically a set of PCEs=20 along with their capabilities. It is intended that solutions that=20 specify procedures and protocol extensions for such PCE discovery=20 satisfy these requirements.=20 A URL for this Internet-Draft is:=20 = = http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.tx= t=20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body = of the message. =20 You can also visit = = https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings.=20 Internet-Drafts are also available by anonymous FTP. Login with the = username=20 "anonymous" and a password of your e-mail address. After logging in,=20 type "cd internet-drafts" and then=20 "get draft-leroux-pce-discovery-reqs-00.txt".=20 A list of Internet-Drafts directories can be found in=20 http://www.ietf.org/shadow.html=20 or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 Internet-Drafts can also be obtained by e-mail.=20 Send a message to:=20 mailserv at ietf.org.=20 In the body type:=20 "FILE /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt".=20 =20 NOTE: The mail server at ietf.org can return the document in=20 MIME-encoded form by using the "mpack" utility. To use this=20 feature, insert the command "ENCODING mime" before the "FILE"=20 command. To decode the response(s), you will need "munpack" or=20 a MIME-compliant mail reader. Different MIME-compliant mail = readers=20 exhibit different behavior, especially when dealing with=20 "multipart" MIME messages (i.e. documents which have been split=20 up into multiple messages), so check your local documentation on = how to manipulate these messages.=20 =20 =20 Below is the data which will enable a MIME compliant mail reader=20 implementation to automatically retrieve the ASCII version of the=20 Internet-Draft.=20 < = = ftp://ftp.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt= >=20 _______________________________________________=20 I-D-Announce mailing list=20 I-D-Announce at ietf.org=20 = https://www1.ietf.org/mailman/listinfo/i-d-announce=20 _____ =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C51BFD.51425B4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Zhang,
 
Please=20 see inline,
 
 
-----Message d'origine-----
De : zrh=20 [mailto:zhangrenhai@huawei.com]
Envoy=E9 : vendredi 25 = f=E9vrier=20 2005 08:28
=C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 pce@ietf.org
Objet : Re: [Pce] PCE Discovery=20 Requirements

Dear J. Le = Roux,
I have been looking in = detail at=20 draft-leroux-pce-discovery-reqs-00.txt,and I have some questions and=20 comments.I'd really appreciate it if
 you could spare the time = to look=20 at both these points.
 
1)In section 5.2,the last = PCE computation=20 capabilities to be advertised is "The PCE capacity in terms of = computation=20 power", for the reasion of weighted load balancing of requests in case = PCEs do=20 not have the same capacity.
 
I think this is not = enough, before PCC sends a=20 request to PCE for a path compution,PCC should also know if the PCE is = busy,=20 how busy(maybe the PCE has many path compution requests from another = PCCs=20 which have not reply for some reason even if the PCE have pawerful=20 CPU).
To = reasonably distribute PCCs's=20 computation requests to PCEs ,PCCs should know the current status = of all=20 PCEs's CPU. so I think the status of PCE's CPU(or number of requests=20 which have not been replied, etc) can be included in the hello = packet=20 sent by PCE,maybe such hello packet is needed.
[JLLR] 
Actually, advertising CPU = status, would=20 require very frequent advertisements to be meaningful. As = mentionned by=20 Adrian, a PCE CPU status may change highly frequently.=20
For instance let's assume 10 path = computations served=20 per second with 50ms per path = computation.
This would lead to 20 advertisements per=20 second...
An alternative could rely on a = periodic=20 advertisement of the average CPU load, but this may actually not be = really=20 relevant.
 
 
2)In section 5.3,the = backup PCEs are discussed,the=20 location of backup PCE is advertised by PCE.
 
I don't think location of = backup PCE can be=20 decided by PCE .
Each PCE may has = different abilities for path=20 compution,so PCC may select different PCE to send request for = different=20 request,backup PCE  is also not fixed.In other words,the = selection=20 of PCE and buckup PCE are also relevant to the=20 computation requests,and are not fixed because of the different=20 requirement of computation.
[JLLR] Yes but assuming that PCE and backup PCE = have the=20 same capabilities this may ease backup selection=20 procedure.
Note that this is not a MUST but = a SHOULD=20 requirement.
But I agree that this point requires=20 more discussions...
 
3)In section 5.5 third = paragraph"The delay for such=20 detection MUST be beyond 60s"
Maybe a "not" is = needed.
[JLLR] 
Yes  this is of course a=20 "not",
 
Thanks a lot, Zhang, for = these useful=20 comments.
 
Best = Regards
 
JL 
 
Thanks,
Zhang
----- Original Message = -----
From: LE ROUX = Jean-Louis=20 RD-CORE-LAN
Sent: Friday, = February 25, 2005 2:03=20 AM
Subject: [Pce] PCE = Discovery=20 Requirements

Hi all,

Here is a requirements ID for = automatic PCE=20 discovery.

Your comments on this draft would = be highly=20 welcome.

Best Regards,

JL


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


        Title   =         :=20 Requirements for Path Computation Element (PCE) Discovery=20
        Author(s)       : J. Le Roux, = et=20 al.
        Filename        :=20 draft-leroux-pce-discovery-reqs-00.txt=20
        Pages   =         :=20 10
        Date    =         :=20 2005-2-14
        =
This document presents a set of requirements = for a Path=20 Computation
   = Element (PCE)=20 discovery mechanism that would allow a Path Computation =
   Client (PCC) to discover = dynamically and=20 automatically a set of PCEs
   along with their capabilities. It is intended = that=20 solutions that
   = specify=20 procedures and protocol extensions for such PCE discovery =
   satisfy these = requirements.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-r= eqs-00.txt=20

To remove yourself from the I-D = Announcement=20 list, send a message to
i-d-announce-request at ietf.org with the word unsubscribe = in the=20 body of the message. 
You can also=20 visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to = change your=20 subscription settings.


Internet-Drafts are also available = by anonymous=20 FTP. Login with the username
"anonymous" and a password of your e-mail address. After = logging=20 in,
type "cd = internet-drafts" and=20 then
        "get = draft-leroux-pce-discovery-reqs-00.txt".=20

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


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

Send a message to:=20
        mailserv at ietf.org.
In the=20 body type:
        = "FILE=20 /internet-drafts/draft-leroux-pce-discovery-reqs-00.txt".=20
       
NOTE:   The mail server at ietf.org can return = the document=20 in
        MIME-encoded form by using the "mpack" utility.  To = use=20 this
        feature, insert the command "ENCODING mime" = before the=20 "FILE"
        command.  To decode the response(s), = you will need=20 "munpack" or
        = a MIME-compliant mail reader.  = Different=20 MIME-compliant mail readers=20
        exhibit different behavior, especially when dealing = with=20
        "multipart" MIME messages (i.e. documents which have been=20 split
        up into multiple messages), so check your = local=20 documentation on =
        how to manipulate these messages.=20
       =20        =20
       =20        
Below is the data which will enable a MIME compliant mail=20 reader
implementation to = automatically=20 retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-leroux-pce-discovery-re= qs-00.txt>
_______________________________________________ =
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce=20



_______________________________________________
Pce = mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR>
------_=_NextPart_001_01C51BFD.51425B4A-- --===============0816047275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0816047275==-- From pce-bounces@ietf.org Sat Feb 26 07:32:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25368; Sat, 26 Feb 2005 07:32:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D517p-0002I3-UD; Sat, 26 Feb 2005 07:32:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D515r-0007MN-H3; Sat, 26 Feb 2005 07:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D515q-0007MI-Es for pce@megatron.ietf.org; Sat, 26 Feb 2005 07:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25288 for ; Sat, 26 Feb 2005 07:30:45 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D516B-0002Gd-0H for pce@ietf.org; Sat, 26 Feb 2005 07:31:07 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Feb 2005 13:30:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [Pce] PCE Discovery Requirements Date: Sat, 26 Feb 2005 13:30:55 +0100 Message-ID: Thread-Topic: [Pce] PCE Discovery Requirements Thread-Index: AcUbM6F41GMRBU1jTC6QRpU4VJ/fJgAydULA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "zrh" , X-OriginalArrivalTime: 26 Feb 2005 12:30:44.0149 (UTC) FILETIME=[FDAC2E50:01C51BFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Hi Adrian, all Some inlined comments >-----Message d'origine----- >De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 >Envoy=E9 : vendredi 25 f=E9vrier 2005 13:12 >=C0 : zrh; LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org >Objet : Re: [Pce] PCE Discovery Requirements > > >Hi Zhang, > >Thanks for your comments. > >> 1)In section 5.2,the last PCE computation capabilities to be=20 >> advertised >is "The PCE capacity in terms of computation power", for the=20 >reasion of weighted load balancing of requests in case PCEs do=20 >not have the same capacity. >> >> I think this is not enough, before PCC sends a request to PCE for a=20 >> path >compution,PCC should also know if the PCE is busy, how=20 >busy(maybe the PCE has many path compution requests from=20 >another PCCs which have not reply for some reason even if the=20 >PCE have pawerful CPU). >> To reasonably distribute PCCs's computation requests to PCEs ,PCCs >should know the current status of all PCEs's CPU. so I think=20 >the status of PCE's CPU(or number of requests which have not=20 >been replied, etc) can be included in the hello packet sent by=20 >PCE,maybe such hello packet is needed. > >On the face of it, this is a reasonable requirement. As you=20 >say, the PCC would ideally select the least busy PCE to=20 >perform its computation for it. > >We need to be careful to separate this requirement from how it=20 >might be satisfied. So discussion of hello packets snet by PCE=20 >should be avoided at this stage.=20 Definitely, >This is probably important=20 >because the use of a hello packet might not be a good way of=20 >satisfying this requirement - the computation time for a=20 >single PCE request is likely to be no more than a few hundred=20 >milliseconds and we would certainly need to think hard before=20 >asking that each PCE sends a new status message to every PCC=20 >in the network every hundred milliseconds. Yes, and actually such CPU load advertisement could become quite CPU = consuming! > >I have a concern however. Suppose you had a network with two=20 >PCEs and a lot of active PCCs. In the event that one PCE was=20 >slightly more busy than the other, all of the PCCs would send=20 >their requests to the other PCE causing immediate congestion. > >So here is a suggestion. Suppose instead of measuring queue=20 >size and CPU capacity we simply allow a PCE to report its=20 >status as "congested" if it deems that it is too busy. PCEs=20 >may still continue to send requests to a congested PCE, but=20 >may use this information to prefer a different PCE. > >The congested flag can be set and flooded instantly the PCE=20 >believes that it is congested, and only releases under a=20 >threshold and on a normal discovery refresh. Yes, this could be a relevant approach, with a kind of hysterisis = mechanism to avoid congestion oscillations. Note that a pretty similar mechanism is defined in = draft-leroux-ccamp-ctrl-saturation-00 to address LSR congestions. > >> 2)In section 5.3,the backup PCEs are discussed,the location of backup >PCE is advertised by PCE. >> >> I don't think location of backup PCE can be decided by PCE .=20 >Each PCE=20 >> may has different abilities for path compution,so PCC may >select different PCE to send request for different=20 >request,backup PCE is also not fixed.In other words,the=20 >selection of PCE and buckup PCE are also relevant to the=20 >computation requests,and are not fixed because of the=20 >different requirement of computation. > >Well, a PCE *might* know that it has a partner that matches=20 >(or betters) its capabilities and which acts as its backup. In=20 >this case, why should it not advertise this information? I agree with you, such information may help backup PCE selection = procedure. Moreover note that this is not a MUST requirement. > >> 3)In section 5.5 third paragraph"The delay for such detection MUST be >beyond 60s" >> Maybe a "not" is needed. > >Indeed. Sure, will be fixed in next revision. Thanks for these useful commments. Regards, JL > >Thanks, >Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sat Feb 26 08:48:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00968; Sat, 26 Feb 2005 08:48:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D52Jg-0003m5-8V; Sat, 26 Feb 2005 08:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D52HN-0002CF-Ea; Sat, 26 Feb 2005 08:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D52HJ-0002Ad-68 for pce@megatron.ietf.org; Sat, 26 Feb 2005 08:46:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00824 for ; Sat, 26 Feb 2005 08:46:39 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D52Hd-0003kS-Aj for pce@ietf.org; Sat, 26 Feb 2005 08:47:02 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id E7EBAE0001FD; Sat, 26 Feb 2005 13:46:21 +0000 (GMT) Received: from Puppy ([212.43.203.58] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Feb 2005 13:46:01 +0000 Message-ID: <120b01c51c09$b687e590$adcb2bd4@Puppy> From: "Adrian Farrel" To: "Renhai Zhang" References: <02bf01c51b0b$7e457ac0$37316e0a@huawei.com> <10e801c51b33$77c57b00$adcb2bd4@Puppy> <03e601c51bd1$c0b61380$37316e0a@huawei.com> Subject: Re: [Pce] PCE Discovery Requirements Date: Sat, 26 Feb 2005 13:47:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 26 Feb 2005 13:46:01.0884 (UTC) FILETIME=[8273D5C0:01C51C09] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi again, [SNIPped to just one issue] > > Well, a PCE *might* know that it has a partner that matches (or betters) > > its capabilities and which acts as its backup. In this case, why should it > > not advertise this information? > > Right, but I have a doubt: Why does PCE know more such info than PCCs? > Is there anything defferent between PCE and PCC for discovery of PCE in the > discovery mechanism? Can we use the mechanism of selecting DR and BDR in > OSPF protocol for reference? You raise an interesting point: that is, the automatic negotiation of primary and backup roles for PCEs. We should discuss this further to determine whether it is functionally useful. If it is, then you have certainly suggested a probable solution. But note that in some of the proposed PCE architectures, the number of PCEs in a domain is relatively small. We might assume, therefore, that the PCEs are under management control and are sufficiently few that the act of managing the full set of PCEs is relatively easy. In this case, we might assume that an operator would designate primary and backup roles for PCEs. PCE discovery is still needed for PCCs since there are far more of them in the network. Regards, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@ietf.org Sun Feb 27 16:30:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06068; Sun, 27 Feb 2005 16:30:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5W0R-0006Jw-4G; Sun, 27 Feb 2005 16:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Vxk-00071P-Gs; Sun, 27 Feb 2005 16:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Vxi-0006yM-Ii for pce@megatron.ietf.org; Sun, 27 Feb 2005 16:28:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05849 for ; Sun, 27 Feb 2005 16:28:24 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5VyJ-0006HY-PD for pce@ietf.org; Sun, 27 Feb 2005 16:29:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2005 13:40:32 -0800 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1RLSAq8012148; Sun, 27 Feb 2005 13:28:11 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-2-274.cisco.com [10.86.243.19]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA23013; Sun, 27 Feb 2005 13:28:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f5426aa4a3d75c784374787673e6a23@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Sun, 27 Feb 2005 22:28:24 +0100 To: pce@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Pce] PCE WG Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@ietf.org Errors-To: pce-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, Please find below the final agenda: 1) Agenda/admin (5mn) 2) Charter overview and ground-rules for WG (10mn) 3) Architecture draft: (Jerry Ash - 15mn) draft-ash-pce-architecture-01.txt 4) PCE Discovery requirements draft (Jean-Louis Le Roux - 10mn) draft-leroux-pce-discovery-reqs.txt 5) PCC/PCE + PCE/PCE Communication requirements slides (Design Team -20mn) draft-ash-pce-comm-protocol-reqs-00 6) Discussion (30mn) 7) Any other business Presenters, please send us your slides by March 3. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce