From pce-bounces@lists.ietf.org Mon Aug 01 02:41:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTzX-0007EV-Rt; Mon, 01 Aug 2005 02:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTzV-0007Bz-1m for pce@megatron.ietf.org; Mon, 01 Aug 2005 02:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06899 for ; Mon, 1 Aug 2005 02:41:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzUVi-00071g-Bk for pce@ietf.org; Mon, 01 Aug 2005 03:14:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Aug 2005 02:41:28 -0400 X-IronPort-AV: i="3.95,156,1120449600"; d="scan'208"; a="64671877:sNHT27517920" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j716fQVu021218; Mon, 1 Aug 2005 02:41:26 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:41:26 -0400 Received: from [172.17.193.177] ([10.86.240.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 02:41:25 -0400 Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DD98E3F-60FF-459B-8BC9-44697B63A524@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 1 Aug 2005 08:41:47 +0200 To: pce@ietf.org X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 01 Aug 2005 06:41:26.0150 (UTC) FILETIME=[0A2C5260:01C59664] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [Pce] Agenda and Presentations available on-line 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, FYI, the agenda and slides for the WG meeting tomorrow (2pm -> 4pm) are available on-line (we're participating to a new experimental proceeding tools): https://datatracker.ietf.org/public/ proceeding_onsite.cgi?meeting_num=63 Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 08:54:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwIF-0004yx-Uz; Tue, 02 Aug 2005 08:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwIC-0004ve-KF for pce@megatron.ietf.org; Tue, 02 Aug 2005 08:54:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16440 for ; Tue, 2 Aug 2005 08:54:46 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dzwod-0006Na-FI for pce@ietf.org; Tue, 02 Aug 2005 09:28:23 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-126.messagelabs.com!1122987272!5513997!3 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 26425 invoked from network); 2 Aug 2005 12:54:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-4.tower-126.messagelabs.com with SMTP; 2 Aug 2005 12:54:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B0022ADEE; Tue, 2 Aug 2005 08:54:34 -0400 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: Tue, 2 Aug 2005 07:54:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA91A6@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWXX3ZHKZYL56MCQraKe22HsHJpWgAAbqzw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: Luca Martini Subject: [Pce] RE: [PWE3] Correction of my statement regarding PCE. X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org FYI.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luca Martini Sent: Tuesday, August 02, 2005 8:39 AM To: pwe3 Subject: [PWE3] Correction of my statement regarding PCE. Now, If Lou Had not derailed my thoughts ... What I meant to say was that neither RSVP-TE nor any flavors of LDP can properly solve the problem of computing the shortest path between two=20 domains/AS/areas. We will need PCE to produce the computed path , which=20 could then be signaled by either RSVP or LDP. I believe that we often do not make the distinction between the C-SPF=20 calculation and RSVP-TE. Luca _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 09:19:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwgH-0004rP-1Q; Tue, 02 Aug 2005 09:19:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwgF-0004nA-0A; Tue, 02 Aug 2005 09:19:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18082; Tue, 2 Aug 2005 09:19:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxCi-0007Ym-BN; Tue, 02 Aug 2005 09:53:13 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j72DHcX02879; Tue, 2 Aug 2005 09:17:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Date: Tue, 2 Aug 2005 09:19:09 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4035AD041@zrtphxm2> Thread-Topic: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWXX3lY9rTEPrx2RNClHHWLOBKZtAAAYrHg From: "Don Fedyk" To: "Luca Martini" , "pwe3" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Pce] RE: [PWE3] Correction of my statement regarding PCE. X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Luca: Is the PWE Multi-Stitching topology congruent with the GMPLS IGP/EGP topology? It was my understanding there is no constraint assuming this. Therefore I think you have an additional requirement that PCE model support multiple Topologies. Just curious, Don > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Luca Martini > > Now, If Lou Had not derailed my thoughts ... > > What I meant to say was that neither RSVP-TE nor any flavors > of LDP can > properly solve the problem of computing the shortest path between two > domains/AS/areas. We will need PCE to produce the computed > path , which > could then be signaled by either RSVP or LDP. > > I believe that we often do not make the distinction between the C-SPF > calculation and RSVP-TE. > > > Luca _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 11:28:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzygi-0005Wz-NV; Tue, 02 Aug 2005 11:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzygf-0005Tn-MR; Tue, 02 Aug 2005 11:28:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28850; Tue, 2 Aug 2005 11:28:11 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzD9-0005Vp-OZ; Tue, 02 Aug 2005 12:01:49 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 17:26:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Tue, 2 Aug 2005 17:26:36 +0200 Message-ID: Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWXX3lY9rTEPrx2RNClHHWLOBKZtAAAYrHgAAUxALA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Don Fedyk" , "Luca Martini" , "pwe3" , X-OriginalArrivalTime: 02 Aug 2005 15:26:38.0323 (UTC) FILETIME=[934E1430:01C59776] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Luca, >We will need PCE to produce the computed path ,=20 > which could then be signaled by either RSVP or LDP.=20 I'm really curious to know how LDP will be used to signal an explicit = path computed by the PCE... CR-LDP??? Regards, JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Don Fedyk > Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > =C0 : Luca Martini; pwe3; pce@ietf.org > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. >=20 > Luca: >=20 > Is the PWE Multi-Stitching topology congruent with the GMPLS=20 > IGP/EGP topology? It was my understanding there is no=20 > constraint assuming this. > Therefore I think you have an additional requirement that PCE=20 > model support multiple Topologies.=20 >=20 > Just curious, > Don=20 >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]=20 > On Behalf=20 > > Of Luca Martini > >=20 > > Now, If Lou Had not derailed my thoughts ... > >=20 > > What I meant to say was that neither RSVP-TE nor any=20 > flavors of LDP=20 > > can properly solve the problem of computing the shortest=20 > path between=20 > > two domains/AS/areas. We will need PCE to produce the=20 > computed path ,=20 > > which could then be signaled by either RSVP or LDP. > >=20 > > I believe that we often do not make the distinction between=20 > the C-SPF=20 > > calculation and RSVP-TE. > >=20 > >=20 > > Luca >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 13:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00k6-0007SH-Fx; Tue, 02 Aug 2005 13:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxXx-00015r-8h; Tue, 02 Aug 2005 10:15:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22045; Tue, 2 Aug 2005 10:15:06 -0400 (EDT) Received: from napoleon.monoski.com ([63.225.114.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzy4P-0001cU-PC; Tue, 02 Aug 2005 10:48:44 -0400 Received: from [2.0.1.6] (rasputin-gw [2.0.1.6]) (authenticated bits=0) by napoleon.monoski.com (8.13.2/8.13.2) with ESMTP id j72EEPvr017131; Tue, 2 Aug 2005 08:14:40 -0600 (MDT) Message-ID: <42EF7FA9.1000509@cisco.com> Date: Tue, 02 Aug 2005 08:14:01 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0+ (X11/20050712) MIME-Version: 1.0 To: Don Fedyk References: <34B3EAA5B3066A42914D28C5ECF5FEA4035AD041@zrtphxm2> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4035AD041@zrtphxm2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Aug 2005 13:39:52 -0400 Cc: pce@ietf.org, pwe3 Subject: [Pce] Re: [PWE3] Correction of my statement regarding PCE. X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Don Fedyk wrote: > Luca: > > Is the PWE Multi-Stitching topology congruent with the GMPLS IGP/EGP > topology? It was my understanding there is no constraint assuming this. no, It is quite independent from the GMPLS IGP/EGP topology. ( PSN ) Luca > Therefore I think you have an additional requirement that PCE model > support multiple Topologies. > > Just curious, > Don > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> Behalf Of Luca Martini >> >> Now, If Lou Had not derailed my thoughts ... >> >> What I meant to say was that neither RSVP-TE nor any flavors >> of LDP can >> properly solve the problem of computing the shortest path between two >> domains/AS/areas. We will need PCE to produce the computed >> path , which >> could then be signaled by either RSVP or LDP. >> >> I believe that we often do not make the distinction between the C-SPF >> calculation and RSVP-TE. >> >> >> Luca > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 13:42:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00me-00014J-Au; Tue, 02 Aug 2005 13:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00mc-0000zb-Cp; Tue, 02 Aug 2005 13:42:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07749; Tue, 2 Aug 2005 13:42:26 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E01J7-0003Ne-PI; Tue, 02 Aug 2005 14:16:07 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 5A8EF1797; Tue, 2 Aug 2005 13:42:14 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 7E2D8AFC4; Tue, 2 Aug 2005 13:42:02 -0400 (EDT) Message-Id: <6.2.3.4.2.20050802133842.02a35810@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 02 Aug 2005 13:42:07 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" From: Lou Berger Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: pwe3 , Luca Martini , 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JL, See below. At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Luca, > > >We will need PCE to produce the computed path , > > which could then be signaled by either RSVP or LDP. > >I'm really curious to know how LDP will be used=20 >to signal an explicit path computed by the PCE... >CR-LDP??? sure, why not? If we *must* use an LDP based=20 solution, it's better to start with CR-LDP (or a=20 CR-LDP subset) than reinventing the wheel! Lou PS (yes, I have my bullet proof vest on!) >Regards, > >JL > > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] De la part de Don Fedyk > > Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > > =C0 : Luca Martini; pwe3; pce@ietf.org > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. > > > > Luca: > > > > Is the PWE Multi-Stitching topology congruent with the GMPLS > > IGP/EGP topology? It was my understanding there is no > > constraint assuming this. > > Therefore I think you have an additional requirement that PCE > > model support multiple Topologies. > > > > Just curious, > > Don > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On Behalf > > > Of Luca Martini > > > > > > Now, If Lou Had not derailed my thoughts ... > > > > > > What I meant to say was that neither RSVP-TE nor any > > flavors of LDP > > > can properly solve the problem of computing the shortest > > path between > > > two domains/AS/areas. We will need PCE to produce the > > computed path , > > > which could then be signaled by either RSVP or LDP. > > > > > > I believe that we often do not make the distinction between > > the C-SPF > > > calculation and RSVP-TE. > > > > > > > > > Luca > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 16:24:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03Ix-00071f-NZ; Tue, 02 Aug 2005 16:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03Iu-0006us-Oh; Tue, 02 Aug 2005 16:24:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15680; Tue, 2 Aug 2005 16:23:58 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E03pQ-000189-Ly; Tue, 02 Aug 2005 16:57:39 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 21:23:44 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Aug 2005 21:23:44 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Tue, 2 Aug 2005 21:23:43 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1E88@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWXiZm9HJ4xfC7lQeqA6jPkkcsItQADaDzQ To: , X-OriginalArrivalTime: 02 Aug 2005 20:23:44.0174 (UTC) FILETIME=[145714E0:01C597A0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Cc: lmartini@cisco.com, pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Lou/folks, Why not re-invent the wheel?...after all PNNI was there long ago on many = topics folks here aspire to. And wrt the routing aspects this was = pretty good at handling hierarchy as I recall, and didn't signalling = here have crankback? But seriously folks, isn't this (wheel = re-invention) THE issue here, ie against the 3 network modes (cl-ps, = co-ps and co-cs) there are only so many ways to 'do' functional = components, so wheel re-invention is unavoidable by definition....here = the topic is signalling, but it could be addressing, routing, OAM, = whatever. Now despite the hype all engineers I know who are worth their salt know = it is simply not technically sensible, let alone commercially viable, to = try and functionally crunch all layer networks from IP to Optics (ie = acrosss the 3 modes) then why not and have some honesty/truth for a = change?......prescriptive doctrines can only work for a while on the = masses and truth has a nasty habit of coming to the surface = eventually....be it via law-suits, eg Ebbers, or practical deployment = experience. For the record: IF the selection of a signalling functional component = is down to RSVP-TE vs LDP (which means CR_LDP in practice for any = sensible co mode technology) then I vote for a COMMON solution between = the control of co-cs mode technologies (ie GMPLS) and co-ps technologies = (ie MPLS), ie RSVP-TE. Note - there is not a 'common' in the sense of = single instance of functional component which operates across all layer = networks, as it operates in a disjoint networking space in each layer = network, but it is 'common' in the sense that it is the SAME choice of = functional component in each disjoint networking space. Now the co-cs = mode FORCES certain behaviours here in GMPLS (like OOB, no QoS classes, = true client/server hierarchy, no LDP-like mp2p merging, no trails = stopping short of their trail term pt (ie PHP in MPLS)) and these are = VERY GOOD THINGS.....so let's please carry these over to the co-ps mode = in MPLS. CCAMPs folks have chosen RSVP-TE for this environment.....not = saying it's THE best functional choice for signalling, but it is the one = that has been made and it seems to work fine. Now discussions on PWE3 = are in the context of MH-PWs, but if we are honest here architecturally = this means 'XoverIP' !=3D 'XoverMPLS' !=3D XoverGMPLS' since GMPLS = (co-cs mode), MPLS (co-ps mode) and IP (cl-ps mode) are all required to = operate in concert. So IMO PWE3 folks have done a great diservice to = progress by erroneously assuming MPLS=3D=3DIP....and clearly this can't = be true else MPLS (nor GMPLS) would exist as a *data-plane* technologies = period. So IMO we should accept/recognise the differences in the 3 = modes and stop pretending they are 'all the same'.....it's these = differences that we should seek to exploit. And I'm all for functional = component re-use......but PLEASE don't try and kid us this is one flat = network, it clearly isn't. regards, Neil > -----Original Message----- > From: pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Lou Berger > Sent: 02 August 2005 18:42 > To: LE ROUX Jean-Louis RD-CORE-LAN > Cc: pwe3; Luca Martini; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE. >=20 >=20 > JL, > See below. >=20 > At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >Hi Luca, > > > > >We will need PCE to produce the computed path , > > > which could then be signaled by either RSVP or LDP. > > > >I'm really curious to know how LDP will be used > >to signal an explicit path computed by the PCE... > >CR-LDP??? >=20 > sure, why not? If we *must* use an LDP based=20 > solution, it's better to start with CR-LDP (or a=20 > CR-LDP subset) than reinventing the wheel! >=20 > Lou >=20 > PS (yes, I have my bullet proof vest on!) >=20 > >Regards, > > > >JL > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org]=20 > > > De la part de Don Fedyk Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > > > =C0 : Luca Martini; pwe3; pce@ietf.org > > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. > > > > > > Luca: > > > > > > Is the PWE Multi-Stitching topology congruent with the=20 > GMPLS IGP/EGP=20 > > > topology? It was my understanding there is no constraint=20 > assuming=20 > > > this. Therefore I think you have an additional=20 > requirement that PCE > > > model support multiple Topologies. > > > > > > Just curious, > > > Don > > > > > > > -----Original Message----- > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On Behalf > > > > Of Luca Martini > > > > > > > > Now, If Lou Had not derailed my thoughts ... > > > > > > > > What I meant to say was that neither RSVP-TE nor any > > > flavors of LDP > > > > can properly solve the problem of computing the shortest > > > path between > > > > two domains/AS/areas. We will need PCE to produce the > > > computed path , > > > > which could then be signaled by either RSVP or LDP. > > > > > > > > I believe that we often do not make the distinction between > > > the C-SPF > > > > calculation and RSVP-TE. > > > > > > > > > > > > Luca > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > > > > > > >_______________________________________________ > >Pce mailing list > >Pce@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 02 18:21:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E058f-0000li-Nq; Tue, 02 Aug 2005 18:21:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03mq-0001fP-6Z; Tue, 02 Aug 2005 16:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16932; Tue, 2 Aug 2005 16:54:53 -0400 (EDT) Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E04JM-0002Hg-7f; Tue, 02 Aug 2005 17:28:34 -0400 Received: from rchemx01.fnc.net.local (167.254.101.101) by fncnmp04.fnc.fujitsu.com with ESMTP; 02 Aug 2005 15:54:44 -0500 X-IronPort-AV: i="3.95,162,1120453200"; d="scan'208"; a="6440286:sNHT22098448" 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 Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Tue, 2 Aug 2005 15:54:44 -0500 Message-ID: Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWXiZm9HJ4xfC7lQeqA6jPkkcsItQADaDzQAAKK6/A= From: "Cupit, John" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 02 Aug 2005 18:21:32 -0400 Cc: pwe3@ietf.org, lmartini@cisco.com, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil: For what is it worth, you comments bespeak experience as well as common = sense. From my perspective, MPLS has been and will continue to be a = transport technology - a means of providing connection orientation for a = connectionless protocol (IP). As such, our focus should be on the = selection of uniform signaling mechanisms for co-cs and co-ps networks = that effectively allow our customers to provision a light path (in a = metro DWDM network, for example) which contains a corresponding MPLS = tunnel and a PWE3 virtual circuit within that tunnel, supporting a = legacy attachment circuit such as a Frame Relay service. It is our = belief that all of our customers are looking for a uniform control plane = which would support psuedowire termination as well as psuedowire = switching on both IP and sub-IP networks. As such, simple uniformity = becomes the key objective. Much has been written and much has been spent in support of = "convergence". If we are truly serious in supporting the reach of PWE3 = technologies to the carrier industry - we need to be more serious in = establishing a uniform signaling approach which can be deployed in the = access, IOF, Service Edge and Core portions of the network. Otherwise, = I feel that we are doing nothing more than positioning additional = overlays for the network operator to muck about with. I join in your call for a common solution. Regards, JC -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of neil.2.harrison@bt.com Sent: Tuesday, August 02, 2005 3:24 PM To: lberger@movaz.com; jeanlouis.leroux@francetelecom.com Cc: lmartini@cisco.com; pwe3@ietf.org; pce@ietf.org Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Lou/folks, Why not re-invent the wheel?...after all PNNI was there long ago on many = topics folks here aspire to. And wrt the routing aspects this was = pretty good at handling hierarchy as I recall, and didn't signalling = here have crankback? But seriously folks, isn't this (wheel = re-invention) THE issue here, ie against the 3 network modes (cl-ps, = co-ps and co-cs) there are only so many ways to 'do' functional = components, so wheel re-invention is unavoidable by definition....here = the topic is signalling, but it could be addressing, routing, OAM, = whatever. Now despite the hype all engineers I know who are worth their salt know = it is simply not technically sensible, let alone commercially viable, to = try and functionally crunch all layer networks from IP to Optics (ie = acrosss the 3 modes) then why not and have some honesty/truth for a = change?......prescriptive doctrines can only work for a while on the = masses and truth has a nasty habit of coming to the surface = eventually....be it via law-suits, eg Ebbers, or practical deployment = experience. For the record: IF the selection of a signalling functional component = is down to RSVP-TE vs LDP (which means CR_LDP in practice for any = sensible co mode technology) then I vote for a COMMON solution between = the control of co-cs mode technologies (ie GMPLS) and co-ps technologies = (ie MPLS), ie RSVP-TE. Note - there is not a 'common' in the sense of = single instance of functional component which operates across all layer = networks, as it operates in a disjoint networking space in each layer = network, but it is 'common' in the sense that it is the SAME choice of = functional component in each disjoint networking space. Now the co-cs = mode FORCES certain behaviours here in GMPLS (like OOB, no QoS classes, = true client/server hierarchy, no LDP-like mp2p merging, no trails = stopping short of their trail term pt (ie PHP in MPLS)) and these are = VERY GOOD THINGS.....so let's please carry these over to the co-ps mode = in MPLS. CCAMPs folks have chosen RSVP-TE for this environment.....not = saying it's THE best functional choice for signalling, but it is the one = that has been made and it seems to work fine. Now discussions on PWE3 = are in the context of MH-PWs, but if we are honest here architecturally = this means 'XoverIP' !=3D 'XoverMPLS' !=3D XoverGMPLS' since GMPLS = (co-cs mode), MPLS (co-ps mode) and IP (cl-ps mode) are all required to = operate in concert. So IMO PWE3 folks have done a great diservice to = progress by erroneously assuming MPLS=3D=3DIP....and clearly this can't = be true else MPLS (nor GMPLS) would exist as a *data-plane* technologies = period. So IMO we should accept/recognise the differences in the 3 = modes and stop pretending they are 'all the same'.....it's these = differences that we should seek to exploit. And I'm all for functional = component re-use......but PLEASE don't try and kid us this is one flat = network, it clearly isn't. regards, Neil > -----Original Message----- > From: pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Lou Berger > Sent: 02 August 2005 18:42 > To: LE ROUX Jean-Louis RD-CORE-LAN > Cc: pwe3; Luca Martini; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE. >=20 >=20 > JL, > See below. >=20 > At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >Hi Luca, > > > > >We will need PCE to produce the computed path , > > > which could then be signaled by either RSVP or LDP. > > > >I'm really curious to know how LDP will be used > >to signal an explicit path computed by the PCE... > >CR-LDP??? >=20 > sure, why not? If we *must* use an LDP based=20 > solution, it's better to start with CR-LDP (or a=20 > CR-LDP subset) than reinventing the wheel! >=20 > Lou >=20 > PS (yes, I have my bullet proof vest on!) >=20 > >Regards, > > > >JL > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org]=20 > > > De la part de Don Fedyk Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > > > =C0 : Luca Martini; pwe3; pce@ietf.org > > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. > > > > > > Luca: > > > > > > Is the PWE Multi-Stitching topology congruent with the=20 > GMPLS IGP/EGP=20 > > > topology? It was my understanding there is no constraint=20 > assuming=20 > > > this. Therefore I think you have an additional=20 > requirement that PCE > > > model support multiple Topologies. > > > > > > Just curious, > > > Don > > > > > > > -----Original Message----- > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On Behalf > > > > Of Luca Martini > > > > > > > > Now, If Lou Had not derailed my thoughts ... > > > > > > > > What I meant to say was that neither RSVP-TE nor any > > > flavors of LDP > > > > can properly solve the problem of computing the shortest > > > path between > > > > two domains/AS/areas. We will need PCE to produce the > > > computed path , > > > > which could then be signaled by either RSVP or LDP. > > > > > > > > I believe that we often do not make the distinction between > > > the C-SPF > > > > calculation and RSVP-TE. > > > > > > > > > > > > Luca > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > > > > > > >_______________________________________________ > >Pce mailing list > >Pce@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 03:14:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DSQ-0003yp-5q; Wed, 03 Aug 2005 03:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DSG-0003yI-U6 for pce@megatron.ietf.org; Wed, 03 Aug 2005 03:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20172 for ; Wed, 3 Aug 2005 03:14:19 -0400 (EDT) Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Dyt-00085w-Of for pce@ietf.org; Wed, 03 Aug 2005 03:48:04 -0400 Received: from m7.gw.fujitsu.co.jp ([10.0.50.77]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) id j737Dink006837 for ; Wed, 3 Aug 2005 16:13:44 +0900 (envelope-from shimizu.takao@jp.fujitsu.com) Received: from s4.gw.fujitsu.co.jp by m7.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j737DhZd030808 for ; Wed, 3 Aug 2005 16:13:43 +0900 (envelope-from shimizu.takao@jp.fujitsu.com) Received: from s4.gw.fujitsu.co.jp (localhost [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 92AA6153626 for ; Wed, 3 Aug 2005 16:13:43 +0900 (JST) Received: from fjm502.ms.jp.fujitsu.com (fjm502.ms.jp.fujitsu.com [10.56.99.74]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 535BA153624 for ; Wed, 3 Aug 2005 16:13:43 +0900 (JST) Received: from SHIMIZUPC (fjmscan503.ms.jp.fujitsu.com [10.56.99.143])by fjm502.ms.jp.fujitsu.com with SMTP id j737D4Di026704 for ; Wed, 3 Aug 2005 16:13:05 +0900 Message-ID: <025901c597fa$dedb4f60$4f334d0a@SHIMIZUPC> From: "T.Shimizu" To: References: Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Wed, 3 Aug 2005 16:13:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA20172 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, All. I partially agree with C.John. My comment are; Policy should not be included in PCE Arch ID, because it has many factors and discussion can not reach conclusion. For PCE Arch ID, Single Pattern and Fully Abstracted Model is preffered for eliminating complexity. The Model at least includes; - Path/Circuit Model VP/VC based Model may be better. VP is LSP with single Label stack. Multi-Label Stack LSP is not adopted since it is cmplicated. VC is Sub-LSP according to FEC in the above LSP. Alternative VP is considered up to 3 LSP. - QoS Model 8 Level Priority based Model as COS/TOS may be better. This Priority Class is mapped with VC. - Metric Model include Static Bandwidth of LSP Dynamic(Available) Bandwidth of LSP/Sub-LSP - Operation Model LSP Initial computing LSP Dynamic best selection amog the LSPs LSP Protection Notiification in case of fault As for PWE3 or other System, it may be better to discuss later on. Best Regards -------- T. Shimizu ----- Original Message -----=20 From: "Cupit, John" To: ; ; Cc: ; ; Sent: Wednesday, August 03, 2005 5:54 AM Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Neil: For what is it worth, you comments bespeak experience as well as common sense. From my perspective, MPLS has been and will continue to be a transport technology - a means of providing connection orientation for a connectionless protocol (IP). As such, our focus should be on the select= ion of uniform signaling mechanisms for co-cs and co-ps networks that effectively allow our customers to provision a light path (in a metro DWD= M network, for example) which contains a corresponding MPLS tunnel and a PW= E3 virtual circuit within that tunnel, supporting a legacy attachment circui= t such as a Frame Relay service. It is our belief that all of our customer= s are looking for a uniform control plane which would support psuedowire termination as well as psuedowire switching on both IP and sub-IP network= s. As such, simple uniformity becomes the key objective. Much has been written and much has been spent in support of "convergence". If we are truly serious in supporting the reach of PWE3 technologies to t= he carrier industry - we need to be more serious in establishing a uniform signaling approach which can be deployed in the access, IOF, Service Edge and Core portions of the network. Otherwise, I feel that we are doing nothing more than positioning additional overlays for the network operato= r to muck about with. I join in your call for a common solution. Regards, JC -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of neil.2.harrison@bt.com Sent: Tuesday, August 02, 2005 3:24 PM To: lberger@movaz.com; jeanlouis.leroux@francetelecom.com Cc: lmartini@cisco.com; pwe3@ietf.org; pce@ietf.org Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Lou/folks, Why not re-invent the wheel?...after all PNNI was there long ago on many topics folks here aspire to. And wrt the routing aspects this was pretty good at handling hierarchy as I recall, and didn't signalling here have crankback? But seriously folks, isn't this (wheel re-invention) THE issu= e here, ie against the 3 network modes (cl-ps, co-ps and co-cs) there are o= nly so many ways to 'do' functional components, so wheel re-invention is unavoidable by definition....here the topic is signalling, but it could b= e addressing, routing, OAM, whatever. Now despite the hype all engineers I know who are worth their salt know i= t is simply not technically sensible, let alone commercially viable, to try and functionally crunch all layer networks from IP to Optics (ie acrosss = the 3 modes) then why not and have some honesty/truth for a change?......prescriptive doctrines can only work for a while on the mass= es and truth has a nasty habit of coming to the surface eventually....be it = via law-suits, eg Ebbers, or practical deployment experience. For the record: IF the selection of a signalling functional component is down to RSVP-TE vs LDP (which means CR_LDP in practice for any sensible c= o mode technology) then I vote for a COMMON solution between the control of co-cs mode technologies (ie GMPLS) and co-ps technologies (ie MPLS), ie RSVP-TE. Note - there is not a 'common' in the sense of single instanc= e of functional component which operates across all layer networks, as it operates in a disjoint networking space in each layer network, but it is 'common' in the sense that it is the SAME choice of functional component = in each disjoint networking space. Now the co-cs mode FORCES certain behaviours here in GMPLS (like OOB, no QoS classes, true client/server hierarchy, no LDP-like mp2p merging, no trails stopping short of their tr= ail term pt (ie PHP in MPLS)) and these are VERY GOOD THINGS.....so let's ple= ase carry these over to the co-ps mode in MPLS. CCAMPs folks have chosen RSVP-TE for this environment.....not saying it's THE best functional choi= ce for signalling, but it is the one that has been made and it seems to work fine. Now discussions on PWE3 are in the context of MH-PWs, but if we ar= e honest here architecturally this means 'XoverIP' !=3D 'XoverMPLS' !=3D XoverGMPLS' since GMPLS (co-cs mode), MPLS (co-ps mode) and IP (cl-ps mo= de) are all required to operate in concert. So IMO PWE3 folks have done a gr= eat diservice to progress by erroneously assuming MPLS=3D=3DIP....and clearly= this can't be true else MPLS (nor GMPLS) would exist as a *data-plane* technologies period. So IMO we should accept/recognise the differences i= n the 3 modes and stop pretending they are 'all the same'.....it's these differences that we should seek to exploit. And I'm all for functional component re-use......but PLEASE don't try and kid us this is one flat network, it clearly isn't. regards, Neil > -----Original Message----- > From: pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] On Behalf Of Lou Berger > Sent: 02 August 2005 18:42 > To: LE ROUX Jean-Louis RD-CORE-LAN > Cc: pwe3; Luca Martini; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement > regarding PCE. > > > JL, > See below. > > At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >Hi Luca, > > > > >We will need PCE to produce the computed path , > > > which could then be signaled by either RSVP or LDP. > > > >I'm really curious to know how LDP will be used > >to signal an explicit path computed by the PCE... > >CR-LDP??? > > sure, why not? If we *must* use an LDP based > solution, it's better to start with CR-LDP (or a > CR-LDP subset) than reinventing the wheel! > > Lou > > PS (yes, I have my bullet proof vest on!) > > >Regards, > > > >JL > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] > > > De la part de Don Fedyk Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > > > =C0 : Luca Martini; pwe3; pce@ietf.org > > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. > > > > > > Luca: > > > > > > Is the PWE Multi-Stitching topology congruent with the > GMPLS IGP/EGP > > > topology? It was my understanding there is no constraint > assuming > > > this. Therefore I think you have an additional > requirement that PCE > > > model support multiple Topologies. > > > > > > Just curious, > > > Don > > > > > > > -----Original Message----- > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On Behalf > > > > Of Luca Martini > > > > > > > > Now, If Lou Had not derailed my thoughts ... > > > > > > > > What I meant to say was that neither RSVP-TE nor any > > > flavors of LDP > > > > can properly solve the problem of computing the shortest > > > path between > > > > two domains/AS/areas. We will need PCE to produce the > > > computed path , > > > > which could then be signaled by either RSVP or LDP. > > > > > > > > I believe that we often do not make the distinction between > > > the C-SPF > > > > calculation and RSVP-TE. > > > > > > > > > > > > Luca > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce > > > > > > >_______________________________________________ > >Pce mailing list > >Pce@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 04:18:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EPk-0005Fz-Jl; Wed, 03 Aug 2005 04:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EPj-0005Fg-Sx; Wed, 03 Aug 2005 04:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23921; Wed, 3 Aug 2005 04:15:46 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EwN-0002hD-TM; Wed, 03 Aug 2005 04:49:32 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id CEFABF77; Wed, 3 Aug 2005 04:15:36 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 760EBAF9B; Wed, 3 Aug 2005 04:15:35 -0400 (EDT) Message-Id: <6.2.3.4.2.20050802191922.03e83c58@mo-ex1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 03 Aug 2005 04:15:42 -0400 To: From: Lou Berger Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F1E88@i2km07-ukbr.domai n1.systemhost.net> References: <0536FC9B908BEC4597EE721BE6A353890A9F1E88@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, pce@ietf.org, lmartini@cisco.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil, Yes, re-invention is inevitable, but=20 we're not talking NSIS here. My understanding of=20 the proposal on the table is that there is a=20 desire to extend LDP to meet PW specific=20 requirements. The changes include QoS,=20 identification intermediate hops, recording of=20 path used, bi-directional LSP, (possibly)=20 end-point identification, etc. All of these have=20 been done before *for LDP*. Also they have been=20 done in a generic, non-application specific context. My point is simply that since there are already=20 TLVs defined for LDP that can be used to meet the=20 PW requirements, we should not define new TLVs=20 but rather use the ones that already exist. Lou At 04:23 PM 8/2/2005, neil.2.harrison@bt.com wrote: >Lou/folks, > >Why not re-invent the wheel?...after all PNNI=20 >was there long ago on many topics folks here=20 >aspire to. And wrt the routing aspects this was=20 >pretty good at handling hierarchy as I recall,=20 >and didn't signalling here have crankback? But=20 >seriously folks, isn't this (wheel re-invention)=20 >THE issue here, ie against the 3 network modes=20 >(cl-ps, co-ps and co-cs) there are only so many=20 >ways to 'do' functional components, so wheel=20 >re-invention is unavoidable by=20 >definition....here the topic is signalling, but=20 >it could be addressing, routing, OAM, whatever. > >Now despite the hype all engineers I know who=20 >are worth their salt know it is simply not=20 >technically sensible, let alone commercially=20 >viable, to try and functionally crunch all layer=20 >networks from IP to Optics (ie acrosss the 3=20 >modes) then why not and have some honesty/truth=20 >for a change?......prescriptive doctrines can=20 >only work for a while on the masses and truth=20 >has a nasty habit of coming to the surface=20 >eventually....be it via law-suits, eg Ebbers, or=20 >practical deployment experience. > >For the record: IF the selection of a=20 >signalling functional component is down to=20 >RSVP-TE vs LDP (which means CR_LDP in practice=20 >for any sensible co mode technology) then I vote=20 >for a COMMON solution between the control of=20 >co-cs mode technologies (ie GMPLS) and co-ps=20 >technologies (ie MPLS), ie RSVP-TE. Note -=20 >there is not a 'common' in the sense of single=20 >instance of functional component which operates=20 >across all layer networks, as it operates in a=20 >disjoint networking space in each layer network,=20 >but it is 'common' in the sense that it is the=20 >SAME choice of functional component in each=20 >disjoint networking space. Now the co-cs mode=20 >FORCES certain behaviours here in GMPLS (like=20 >OOB, no QoS classes, true client/server=20 >hierarchy, no LDP-like mp2p merging, no trails=20 >stopping short of their trail term pt (ie PHP in=20 >MPLS)) and these are VERY GOOD THINGS.....so=20 >let's please carry these over to the co-ps mode=20 >in MPLS. CCAMPs folks have chosen RSVP-TE for=20 >this environment.....not saying it's THE best=20 >functional choice for signalling, but it is the=20 >one that has been made and it seems to work=20 >fine. Now discussions on PWE3 are in the=20 >context of MH-PWs, but if we are honest here=20 >architecturally this means 'XoverIP' !=3D=20 >'XoverMPLS' !=3D XoverGMPLS' since GMPLS (co-cs=20 >mode), MPLS (co-ps mode) and IP (cl-ps mode) are=20 >all required to operate in concert. So IMO PWE3=20 >folks have done a great diservice to progress by=20 >erroneously assuming MPLS=3D=3DIP....and clearly=20 >this can't be true else MPLS (nor GMPLS) would=20 >exist as a *data-plane* technologies period. So=20 >IMO we should accept/recognise the differences=20 >in the 3 modes and stop pretending they are 'all=20 >the same'.....it's these differences that we=20 >should seek to exploit. And I'm all for=20 >functional component re-use......but PLEASE=20 >don't try and kid us this is one flat network, it clearly isn't. > >regards, Neil > > > -----Original Message----- > > From: pce-bounces@lists.ietf.org > >=20 > [mailto:pce-bounces@lists.ietf.org]=20 > On Behalf Of Lou Berger > > Sent: 02 August 2005 18:42 > > To: LE ROUX Jean-Louis RD-CORE-LAN > > Cc: pwe3; Luca Martini; pce@ietf.org > > Subject: RE: [Pce] RE: [PWE3] Correction of my statement > > regarding PCE. > > > > > > JL, > > See below. > > > > At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > >Hi Luca, > > > > > > >We will need PCE to produce the computed path , > > > > which could then be signaled by either RSVP or LDP. > > > > > >I'm really curious to know how LDP will be used > > >to signal an explicit path computed by the PCE... > > >CR-LDP??? > > > > sure, why not? If we *must* use an LDP based > > solution, it's better to start with CR-LDP (or a > > CR-LDP subset) than reinventing the wheel! > > > > Lou > > > > PS (yes, I have my bullet proof vest on!) > > > > >Regards, > > > > > >JL > > > > > > > -----Message d'origine----- > > > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] > > > > De la part de Don Fedyk Envoy=E9 : mardi 2 ao=FBt 2005 15:19 > > > > =C0 : Luca Martini; pwe3; pce@ietf.org > > > > Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. > > > > > > > > Luca: > > > > > > > > Is the PWE Multi-Stitching topology congruent with the > > GMPLS IGP/EGP > > > > topology? It was my understanding there is no constraint > > assuming > > > > this. Therefore I think you have an additional > > requirement that PCE > > > > model support multiple Topologies. > > > > > > > > Just curious, > > > > Don > > > > > > > > > -----Original Message----- > > > > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org] > > > > On Behalf > > > > > Of Luca Martini > > > > > > > > > > Now, If Lou Had not derailed my thoughts ... > > > > > > > > > > What I meant to say was that neither RSVP-TE nor any > > > > flavors of LDP > > > > > can properly solve the problem of computing the shortest > > > > path between > > > > > two domains/AS/areas. We will need PCE to produce the > > > > computed path , > > > > > which could then be signaled by either RSVP or LDP. > > > > > > > > > > I believe that we often do not make the distinction between > > > > the C-SPF > > > > > calculation and RSVP-TE. > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org=20 >= https://www1.ietf.org/mailman/l= istinfo/pce=20 > > > > > > > > > > >_______________________________________________ > > >Pce mailing list > > >Pce@lists.ietf.org > > >h=20 > ttps://www1.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > >=20 >= https://www1.ietf.org/mailman/l= istinfo/pce=20 > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 04:27:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eah-0004Io-52; Wed, 03 Aug 2005 04:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eag-0004II-AS for pce@megatron.ietf.org; Wed, 03 Aug 2005 04:27:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24713 for ; Wed, 3 Aug 2005 04:27:04 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm1.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0F7I-0003HV-JM for pce@ietf.org; Wed, 03 Aug 2005 05:00:50 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm1.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j738Qi6O025884; Wed, 3 Aug 2005 04:26:44 -0400 (EDT) Message-Id: <200508030826.j738Qi6O025884@tm1.ca.alcatel.com> From: "Andrew Dolganow" To: Date: Wed, 3 Aug 2005 04:26:42 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcWYBRIKj47z72hoRPaCjK/bQmFD6g== X-Spam-Score: 0.8 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: pce@ietf.org Subject: [Pce] comments to draft-ietf-pce-discovery-reqs-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: , Content-Type: multipart/mixed; boundary="===============1560008027==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1560008027== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C597E3.8E216210" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C597E3.8E216210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jean Louis et al, Here is few comments/questions to the draft I have: 1. Section 6.1: Propose to change the first paragraph (for clarity) with: The PCE discovery mechanism MUST allow disclosing mandatory, PCE information that will allow PCCs to select appropriate PCEs. The PCE discovery mechanism MAY allow disclosing optional , as defined below PCE information that will allow PCCs to select appropriate PCEs. 2. Section 6.4.1 The draft states that a PCE should advertise alternate PCEs. If that's the case, do you expect those other PCEs to also advertise themselves? If yes (which I expect) then we should add for clarity at the end of that section something like ( is required to allow PCCs to select a Main PCE over an alternate even if the alternate PCE is discovered first by a PCC. ): The alternate PCEs MUST advertise the main PCE(s) for which they alternate. We could also add a role (Main, alternate) in capabilities summary section earlier on. 3 Section 6.3 The section states in the first paragraph that a PCE MUST allow detection of a change of any information advertised to a PCC (capabilities). Why is this a MUST, if advertising of capabilities is a MAY in section 6.1 above? For clarity we should probably add qualification that If a PCE supports advertising of capabilities, then it MUST allow detection. Here is a proposed new text: Iff a PCE supports advertising of optional information, then the PCE discovery mechanism MUST allow a PCC to detect any change in the information related to a PCE (e.g. capability modifications). 4. Section 6.5 I would like to propose that detection of congestion would happen as part of PCE-PCC communication protocol. For simplicity we may have a reactive mode (i.e. a failure to a computation request to a PCC due to congestion would include for example a time value required for that PCC to back-off before sending a next request to a given PCE). If we would need something more proactive, then we could add that in protocol draft and not in here. Regards, Andrew ------=_NextPart_000_002E_01C597E3.8E216210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jean = Louis et=20 al,
 
Here = is few=20 comments/questions to the draft I have:
 
1. = Section=20 6.1:
 
Propose to change=20 the first paragraph (for clarity) with:

The PCE discovery mechanism MUST allow=20 disclosing mandatory, PCE information that will allow PCCs to = select=20 appropriate PCEs. The PCE discovery mechanism MAY allow = disclosing=20 optional , as defined below PCE information that will allow PCCs to = select=20 appropriate PCEs.

2. = Section=20 6.4.1

The = draft states that=20 a PCE should advertise alternate PCEs. If that's the case, do you expect = those=20 other PCEs to also advertise themselves? If yes (which I expect) then we = should=20 add for clarity at the end of that section something like ( is required to = allow PCCs to=20 select a Main PCE over an alternate even if the alternate PCE is = discovered=20 first by a PCC. ):

The alternate PCEs MUST advertise the main = PCE(s) for=20 which they alternate.

We could = also add a=20 role (Main, alternate) in capabilities summary section earlier=20 on.

3 = Section=20 6.3

The = section states in=20 the first paragraph that a PCE MUST allow detection of a change of any=20 information advertised to a PCC (capabilities). Why is this a MUST, if=20 advertising of capabilities is a MAY in section 6.1 = above?

For = clarity we should=20 probably add qualification that If a PCE supports advertising of capabilities, then = it MUST allow=20 detection. Here is a proposed new = text:

Iff a=20 PCE supports advertising of optional information, then = the PCE=20 discovery mechanism MUST allow a PCC to detect any change in the = information=20 related to a PCE (e.g. capability modifications).=20

4. Section 6.5

I would like to propose that detection of = congestion=20 would happen as part of PCE-PCC communication protocol. For simplicity = we may=20 have a reactive mode (i.e. a failure to a computation request to a PCC = due to=20 congestion would include for example a time value required for that = PCC to=20 back-off before sending a next request to a given PCE). If we would need = something more proactive, then we could add that in protocol draft and = not in=20 here.

Regards,

Andrew

 

------=_NextPart_000_002E_01C597E3.8E216210-- --===============1560008027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1560008027==-- From pce-bounces@lists.ietf.org Wed Aug 03 04:49:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ewl-0003jx-AR; Wed, 03 Aug 2005 04:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ewj-0003hX-Ad for pce@megatron.ietf.org; Wed, 03 Aug 2005 04:49:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25615 for ; Wed, 3 Aug 2005 04:49:51 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FTM-0004Cv-VX for pce@ietf.org; Wed, 03 Aug 2005 05:23:37 -0400 Received: from Puppy (open-25-118.ietf63.ietf.org [86.255.25.118]) by pollux.ietf63.ietf.org (Postfix) with SMTP id CC07F4D; Wed, 3 Aug 2005 01:49:45 -0700 (PDT) Message-ID: <019b01c59808$a8881ca0$7619ff56@Puppy> From: "Adrian Farrel" To: "Igor Bryskin" References: <154701c58d1f$ef014e70$d6849ed9@Puppy> <42E239D1.9010907@psg.com> <84945647-6729-4394-A308-17C1D3C79589@cisco.com> <6.2.3.4.2.20050726191150.03f4f040@mo-ex1> <009701c592b3$94409970$7a1810ac@movaz.com> <6.2.3.4.2.20050727102145.04065fc0@mo-ex1> <006601c5943b$551b21f0$6501a8c0@movaz.com> Subject: Re: [Pce] Changes in the new revision of the architecture I-D Date: Wed, 3 Aug 2005 09:51:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor, Sorry I missed this while travelling... > I think that the architectureID is exactly the right context. It seems to me > a hole in the arhcitecture, what other context do you have in mind? JP's email says: - policy should be discussed in the archiecture - policy requirements shoiuld not be discussed in the architecture Hopefully this is consistent with what I said in the PCE meeting. That is: - We will add policy to the architecture I-D as an importnat funcitonal component of PCE - We will develop the policy requirements as a separate requirements I-D - We will work on any protocol extensions as a separate I-D, but may fold them into the PCE-PCC and discovery protocol I-Ds depending on when they are complete. Cheers, Adrian > > Igor > > ----- Original Message ----- > From: "JP Vasseur" > To: "Lou Berger" ; "Igor Bryskin" > Cc: "Adrian Farrel" ; "Ash, Gerald R (Jerry), ALABS" > ; > Sent: Wednesday, July 27, 2005 3:46 PM > Subject: Re: [Pce] Changes in the new revision of the architecture I-D > > > > Hi Lou, > > > > On Jul 27, 2005, at 10:33 AM, Lou Berger wrote: > > > > > Igor, > > > My primary point was that we need to ensure that we fully > > > consider policy in the architecture (and the resulting > > > instantiation of the architecture). > > > > > > The point you raise is a reasonable one up due to such > > > consideration. Although rather than make a statement on the > > > requirement, I would ask the question, does policy being applied at > > > PCE2 need to know the identity of PCC? > > > (I'm not sure...) > > > > > > > This is exactly what I was also about to reply. Indeed, I think that > > we all welcome your useful suggestion to devote more text to Policy > > in the architecture ID since it deserves more focus. On the other > > hand, this does require more discussion on the mailing list to > > determine what the requirements are. Furthermore, requirements should > > not be discussed in the architecture ID and it is pretty likely that > > new requirements related to policy will arise when discussing the > > application-specific requirements IDs. > > > > Thanks. > > > > JP. > > > > > Much thanks, > > > Lou > > > > > > At 10:00 AM 7/27/2005, Bryskin, Igor wrote: > > > > > > > > >> Hi, > > >> > > >> I think Lou has just brought up a very important discussion. > > >> > > >> A PCE can apply a policy for a particular path computation request > > >> only IFF > > >> it can identify original requestor. Consider the situation when a > > >> single > > >> request involves 2 PCEs: PCC<=>PCE1<=>PCE2. > > >> > > >> PCE1 can identify the PCC and apply the polices for this PCC or > > >> this class > > >> of PCCs. However, PCE2 will not be capable to identify PCC ( we > > >> seem to > > >> agree already that PCC-PCE and PCE-PCE is the same protocol, hence > > >> PCE2 will > > >> see PCE1 as PCC), and will apply a wrong policy. For instance, it > > >> may invoke > > >> a computationally expensive algorithm, which it won't do if the PCC > > >> requested computation directly from PCC2. > > >> > > >> So, in the architecture document the reasons should be described > > >> why the > > >> identity of the original requestor should be available for all > > >> PCEs involved > > >> in particular path computation request. Secondly, the same point > > >> should be > > >> reflected in the path computation communication protocol > > >> requirements. > > >> > > >> Igor > > >> > > >> ----- Original Message ----- > > >> From: "Lou Berger" > > >> To: "JP Vasseur" ; "Adrian Farrel" > > >> ; "Ash, Gerald R (Jerry), ALABS" > > >> Cc: > > >> Sent: Tuesday, July 26, 2005 7:14 PM > > >> Subject: Re: [Pce] Changes in the new revision of the architecture > > >> I-D > > >> > > >> > At 09:24 AM 7/23/2005, JP Vasseur wrote: > > >> > >We think that the ID is pretty stable in term of technical > > >> content. > > >> > >As Adrian pointed out, there might be some editorial work to be > > >> done > > >> > >before WG last call. So the short answer is "as soon as possible". > > >> > > > > >> > >Thanks. > > >> > > > > >> > >JP. > > >> > > > >> > JP/Adrian/Jerry, > > >> > As you say, the draft has come together very nicely. The > > >> > primary comment I have on the document is related to how policy is > > >> > presented in the draft: > > >> > > > >> > The draft does mention policy in multiple places, but these > > >> mentions > > >> > are more "in-passing" than as major component. It seems to me that > > >> > Policy and the ability to support path computation based on, or > > >> > influenced by policies, must be a major part of the PCE > > >> > architecture. I do agree with draft in that "policy between > > >> domains > > >> > and between PCEs, and is achieved through configuration not through > > >> > protocol communications." That said, the PCC-PCE and PCE-PCE > > >> > communication protocols must support the communication of all > > >> > information needed to support the installed policies, as well as > > >> > support any policy triggered transactions that may result due to a > > >> > policy (or change in policy). Also, in order to deliver viable > > >> > policy to PCE, policy must not be an after thought. (Consider how > > >> > successful original RSVP was with bringing in policy after the core > > >> > work was complete.) > > >> > > > >> > In short, I think policy should be more prominent in the draft > > >> and in > > >> > the PCE architecture. > > >> > > > >> > I suggest to: > > >> > - add policy related motivations in section 4, > > >> > - add a policy component to the PCE architecture(s) presented in > > >> section > > >> 5, > > >> > - add a full fledged Policy sub-section to section 6 that is > > >> separate > > >> > from confidentiality. > > >> > - and add a policy related evaluation metric to section 7. > > >> > > > >> > Please let me know what you think. > > >> > > > >> > I'll put together some specific text for fodder.... > > >> > > > >> > Lou > > >> > > > >> > > > >> > _______________________________________________ > > >> > Pce mailing list > > >> > Pce@lists.ietf.org > > >> > https:// > > >> www1.ietf.org/mailman/listinfo/pce > > >> > > > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 05:07:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FDn-0004H4-TO; Wed, 03 Aug 2005 05:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FDl-0004Gv-Vx for pce@megatron.ietf.org; Wed, 03 Aug 2005 05:07:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26665 for ; Wed, 3 Aug 2005 05:07:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FkQ-00051f-6i for pce@ietf.org; Wed, 03 Aug 2005 05:41:14 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2005 05:07:20 -0400 X-IronPort-AV: i="3.95,163,1120449600"; d="scan'208"; a="65002401:sNHT34134532" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7397KVu018778; Wed, 3 Aug 2005 05:07:20 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 05:07:20 -0400 Received: from [86.255.24.113] ([10.82.224.14]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 05:07:19 -0400 In-Reply-To: <025901c597fa$dedb4f60$4f334d0a@SHIMIZUPC> References: <025901c597fa$dedb4f60$4f334d0a@SHIMIZUPC> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <32561A40-B264-4391-AB0F-B37137551679@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Wed, 3 Aug 2005 11:07:44 +0200 To: "T.Shimizu" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 03 Aug 2005 09:07:19.0616 (UTC) FILETIME=[C078BC00:01C5980A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, On Aug 3, 2005, at 9:13 AM, T.Shimizu wrote: > Hi, All. > > > I partially agree with C.John. > > My comment are; > > Policy should not be included in PCE Arch ID, because it has many =20 > factors > and > discussion can not reach conclusion. > Policy is undoubtedly a key component of the PCE architecture and as =20 such must be included in the PCE architecture as agreed by the WG. =20 Detailed policy requirements as well as potential protocol extensions =20= will be part of separate IDs. > For PCE Arch ID, Single Pattern and Fully Abstracted Model is > preffered for eliminating complexity. > The Model at least includes; > > - Path/Circuit Model > VP/VC based Model may be better. > VP is LSP with single Label stack. > Multi-Label Stack LSP is not adopted since it is cmplicated. > VC is Sub-LSP according to FEC in the above LSP. > Alternative VP is considered up to 3 LSP. > > - QoS Model > 8 Level Priority based Model as COS/TOS may be better. > This Priority Class is mapped with VC. > > - Metric Model include > Static Bandwidth of LSP > Dynamic(Available) Bandwidth of LSP/Sub-LSP > > - Operation Model > LSP Initial computing > LSP Dynamic best selection amog the LSPs > LSP Protection Notiification in case of fault > There is a mix of items above, some of which are clearly out of the =20 scope of the WG. Thanks. JP. > As for PWE3 or other System, it may be better to discuss later on. > > > Best Regards > > -------- > T. Shimizu > > > > ----- Original Message ----- > From: "Cupit, John" > To: ; ; > > Cc: ; ; > Sent: Wednesday, August 03, 2005 5:54 AM > Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding =20 > PCE. > > > Neil: > > For what is it worth, you comments bespeak experience as well as =20 > common > sense. =46rom my perspective, MPLS has been and will continue to be a > transport technology - a means of providing connection orientation =20 > for a > connectionless protocol (IP). As such, our focus should be on the =20 > selection > of uniform signaling mechanisms for co-cs and co-ps networks that > effectively allow our customers to provision a light path (in a =20 > metro DWDM > network, for example) which contains a corresponding MPLS tunnel =20 > and a PWE3 > virtual circuit within that tunnel, supporting a legacy attachment =20 > circuit > such as a Frame Relay service. It is our belief that all of our =20 > customers > are looking for a uniform control plane which would support psuedowire > termination as well as psuedowire switching on both IP and sub-IP =20 > networks. > As such, simple uniformity becomes the key objective. > > Much has been written and much has been spent in support of =20 > "convergence". > If we are truly serious in supporting the reach of PWE3 =20 > technologies to the > carrier industry - we need to be more serious in establishing a =20 > uniform > signaling approach which can be deployed in the access, IOF, =20 > Service Edge > and Core portions of the network. Otherwise, I feel that we are doing > nothing more than positioning additional overlays for the network =20 > operator > to muck about with. > > I join in your call for a common solution. > > Regards, > > JC > > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > neil.2.harrison@bt.com > Sent: Tuesday, August 02, 2005 3:24 PM > To: lberger@movaz.com; jeanlouis.leroux@francetelecom.com > Cc: lmartini@cisco.com; pwe3@ietf.org; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding =20 > PCE. > > > Lou/folks, > > Why not re-invent the wheel?...after all PNNI was there long ago on =20= > many > topics folks here aspire to. And wrt the routing aspects this was =20 > pretty > good at handling hierarchy as I recall, and didn't signalling here =20 > have > crankback? But seriously folks, isn't this (wheel re-invention) =20 > THE issue > here, ie against the 3 network modes (cl-ps, co-ps and co-cs) there =20= > are only > so many ways to 'do' functional components, so wheel re-invention is > unavoidable by definition....here the topic is signalling, but it =20 > could be > addressing, routing, OAM, whatever. > > Now despite the hype all engineers I know who are worth their salt =20 > know it > is simply not technically sensible, let alone commercially viable, =20 > to try > and functionally crunch all layer networks from IP to Optics (ie =20 > acrosss the > 3 modes) then why not and have some honesty/truth for a > change?......prescriptive doctrines can only work for a while on =20 > the masses > and truth has a nasty habit of coming to the surface =20 > eventually....be it via > law-suits, eg Ebbers, or practical deployment experience. > > For the record: IF the selection of a signalling functional =20 > component is > down to RSVP-TE vs LDP (which means CR_LDP in practice for any =20 > sensible co > mode technology) then I vote for a COMMON solution between the =20 > control of > co-cs mode technologies (ie GMPLS) and co-ps technologies (ie =20 > MPLS), ie > RSVP-TE. Note - there is not a 'common' in the sense of single =20 > instance > of functional component which operates across all layer networks, =20 > as it > operates in a disjoint networking space in each layer network, but =20 > it is > 'common' in the sense that it is the SAME choice of functional =20 > component in > each disjoint networking space. Now the co-cs mode FORCES certain > behaviours here in GMPLS (like OOB, no QoS classes, true client/server > hierarchy, no LDP-like mp2p merging, no trails stopping short of =20 > their trail > term pt (ie PHP in MPLS)) and these are VERY GOOD THINGS.....so =20 > let's please > carry these over to the co-ps mode in MPLS. CCAMPs folks have chosen > RSVP-TE for this environment.....not saying it's THE best =20 > functional choice > for signalling, but it is the one that has been made and it seems =20 > to work > fine. Now discussions on PWE3 are in the context of MH-PWs, but if =20= > we are > honest here architecturally this means 'XoverIP' !=3D 'XoverMPLS' !=3D > XoverGMPLS' since GMPLS (co-cs mode), MPLS (co-ps mode) and IP (cl-=20= > ps mode) > are all required to operate in concert. So IMO PWE3 folks have =20 > done a great > diservice to progress by erroneously assuming MPLS=3D=3DIP....and =20 > clearly this > can't be true else MPLS (nor GMPLS) would exist as a *data-plane* > technologies period. So IMO we should accept/recognise the =20 > differences in > the 3 modes and stop pretending they are 'all the same'.....it's these > differences that we should seek to exploit. And I'm all for =20 > functional > component re-use......but PLEASE don't try and kid us this is one flat > network, it clearly isn't. > > regards, Neil > > >> -----Original Message----- >> From: pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] On Behalf Of Lou Berger >> Sent: 02 August 2005 18:42 >> To: LE ROUX Jean-Louis RD-CORE-LAN >> Cc: pwe3; Luca Martini; pce@ietf.org >> Subject: RE: [Pce] RE: [PWE3] Correction of my statement >> regarding PCE. >> >> >> JL, >> See below. >> >> At 11:26 AM 8/2/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: >> >>> Hi Luca, >>> >>> >>>> We will need PCE to produce the computed path , >>>> which could then be signaled by either RSVP or LDP. >>>> >>> >>> I'm really curious to know how LDP will be used >>> to signal an explicit path computed by the PCE... >>> CR-LDP??? >>> >> >> sure, why not? If we *must* use an LDP based >> solution, it's better to start with CR-LDP (or a >> CR-LDP subset) than reinventing the wheel! >> >> Lou >> >> PS (yes, I have my bullet proof vest on!) >> >> >>> Regards, >>> >>> JL >>> >>> >>>> -----Message d'origine----- >>>> De : pce-bounces@lists.ietf.org >>>> >> [mailto:pce-bounces@lists.ietf.org] >> >>>> De la part de Don Fedyk Envoy=E9 : mardi 2 ao=FBt 2005 15:19 >>>> =C0 : Luca Martini; pwe3; pce@ietf.org >>>> Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. >>>> >>>> Luca: >>>> >>>> Is the PWE Multi-Stitching topology congruent with the >>>> >> GMPLS IGP/EGP >> >>>> topology? It was my understanding there is no constraint >>>> >> assuming >> >>>> this. Therefore I think you have an additional >>>> >> requirement that PCE >> >>>> model support multiple Topologies. >>>> >>>> Just curious, >>>> Don >>>> >>>> >>>>> -----Original Message----- >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>> >>>> On Behalf >>>> >>>>> Of Luca Martini >>>>> >>>>> Now, If Lou Had not derailed my thoughts ... >>>>> >>>>> What I meant to say was that neither RSVP-TE nor any >>>>> >>>> flavors of LDP >>>> >>>>> can properly solve the problem of computing the shortest >>>>> >>>> path between >>>> >>>>> two domains/AS/areas. We will need PCE to produce the >>>>> >>>> computed path , >>>> >>>>> which could then be signaled by either RSVP or LDP. >>>>> >>>>> I believe that we often do not make the distinction between >>>>> >>>> the C-SPF >>>> >>>>> calculation and RSVP-TE. >>>>> >>>>> >>>>> Luca >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce >>>> >>>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 05:10:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FGj-0005Dx-L7; Wed, 03 Aug 2005 05:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FGh-0005DR-NT for pce@megatron.ietf.org; Wed, 03 Aug 2005 05:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26808 for ; Wed, 3 Aug 2005 05:10:29 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FnM-00058w-KA for pce@ietf.org; Wed, 03 Aug 2005 05:44:16 -0400 Received: from Puppy (open-25-118.ietf63.ietf.org [86.255.25.118]) by pollux.ietf63.ietf.org (Postfix) with SMTP id 2197B4D; Wed, 3 Aug 2005 02:10:30 -0700 (PDT) Message-ID: <01cf01c5980b$8e3bc0b0$7619ff56@Puppy> From: "Adrian Farrel" To: , Date: Wed, 3 Aug 2005 10:12:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , pce@ietf.org Subject: [Pce] Applications Area assistance in PCE working group 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, The PCE working group (http://www.ietf.org/html.charters/pce-charter.html) has developed a set of requirements for a protocol that will be used to request path computations and provide responses. The requirements are essentially for a client/server request/response protocol with specific (but not alarming) characteristics. We know that the Applications Area has a little experience with client/server protocols and we would appreciate some consultation from you or from someone you can nominate (do you have an Applications Area Directorate?). Can you please say whether you know of an existing protocol that closely matches our requirements. Our Architecture is draft-ietf-pce-architecture-01.txt This is pretty cooked. The protocol requirements are in draft-ietf-pce-comm-protocol-gen-reqs-01.txt and are stable, but not complete. The PCE working group has some very tight deadlines on this work, so we would appreciate feedback and suggestions by the end of August. Comments back to the chairs or direct to the PCE mailing list. Thanks for any help. Adrian and JP (PCE chairs) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 05:11:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FHi-0005Xm-Ab; Wed, 03 Aug 2005 05:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DmZ-0008Ei-UA; Wed, 03 Aug 2005 03:35:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21249; Wed, 3 Aug 2005 03:35:18 -0400 (EDT) Received: from napoleon.monoski.com ([63.225.114.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EJC-0000hj-J3; Wed, 03 Aug 2005 04:09:04 -0400 Received: from [2.0.1.6] (rasputin-gw [2.0.1.6]) (authenticated bits=0) by napoleon.monoski.com (8.13.2/8.13.2) with ESMTP id j737YefF021959; Wed, 3 Aug 2005 01:34:46 -0600 (MDT) Message-ID: <42F0737C.4090206@cisco.com> Date: Wed, 03 Aug 2005 01:34:20 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0+ (X11/20050712) MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by napoleon.monoski.com id j737YefF021959 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 03 Aug 2005 05:11:32 -0400 Cc: pce@ietf.org, pwe3 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Luca, >=20 >> We will need PCE to produce the computed path ,=20 >> which could then be signaled by either RSVP or LDP.=20 >=20 > I'm really curious to know how LDP will be used to signal an explicit p= ath computed by the PCE... > CR-LDP??? >=20 Not quite. Some kind of explicit PW route object containing some=20 addressing ( probably not IP ) does not turn LDP into CR-LDP. We are also still using DU mode not DOD. Luca > Regards, >=20 > JL >=20 >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org=20 >> [mailto:pce-bounces@lists.ietf.org] De la part de Don Fedyk >> Envoy=E9 : mardi 2 ao=FBt 2005 15:19 >> =C0 : Luca Martini; pwe3; pce@ietf.org >> Objet : [Pce] RE: [PWE3] Correction of my statement regarding PCE. >> >> Luca: >> >> Is the PWE Multi-Stitching topology congruent with the GMPLS=20 >> IGP/EGP topology? It was my understanding there is no=20 >> constraint assuming this. >> Therefore I think you have an additional requirement that PCE=20 >> model support multiple Topologies.=20 >> >> Just curious, >> Don=20 >> >>> -----Original Message----- >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]=20 >> On Behalf=20 >>> Of Luca Martini >>> >>> Now, If Lou Had not derailed my thoughts ... >>> >>> What I meant to say was that neither RSVP-TE nor any=20 >> flavors of LDP=20 >>> can properly solve the problem of computing the shortest=20 >> path between=20 >>> two domains/AS/areas. We will need PCE to produce the=20 >> computed path ,=20 >>> which could then be signaled by either RSVP or LDP. >>> >>> I believe that we often do not make the distinction between=20 >> the C-SPF=20 >>> calculation and RSVP-TE. >>> >>> >>> Luca >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 07:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HW9-0000st-Ro; Wed, 03 Aug 2005 07:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HW8-0000sf-A4 for pce@megatron.ietf.org; Wed, 03 Aug 2005 07:34:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06481 for ; Wed, 3 Aug 2005 07:34:35 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0I2n-0003Oh-8O for pce@ietf.org; Wed, 03 Aug 2005 08:08:22 -0400 Received: from Puppy (open-25-118.ietf63.ietf.org [86.255.25.118]) by pollux.ietf63.ietf.org (Postfix) with SMTP id D75C737 for ; Wed, 3 Aug 2005 04:34:21 -0700 (PDT) Message-ID: <02ba01c5981f$a711d8e0$7619ff56@Puppy> From: "Adrian Farrel" To: References: <7DD98E3F-60FF-459B-8BC9-44697B63A524@cisco.com> Date: Wed, 3 Aug 2005 12:36:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Your input: Agenda and Presentations available on-line 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, As mentioned in the meeting, JP used a prototype of a new tool from the Secretariat to upload the slides for the PCE meeting ahead of time. See the URL below. We would welcome your comments on how well this worked. Compare and contrast with other WGs you go to. Thanks. Adrian ----- Original Message ----- From: "JP Vasseur" To: Cc: "Adrian Farrel" ; "Bill Fenner" ; "Alex Zinin" Sent: Monday, August 01, 2005 7:41 AM Subject: Agenda and Presentations available on-line > Hi, > > FYI, the agenda and slides for the WG meeting tomorrow (2pm -> 4pm) > are available on-line (we're participating to a new experimental > proceeding tools): https://datatracker.ietf.org/public/ > proceeding_onsite.cgi?meeting_num=63 > > Thanks. > > JP. > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 03 09:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JSv-0006Wi-Pa; Wed, 03 Aug 2005 09:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JSu-0006WZ-FK for pce@megatron.ietf.org; Wed, 03 Aug 2005 09:39:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16244 for ; Wed, 3 Aug 2005 09:39:22 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Jza-0001Nd-B4 for pce@ietf.org; Wed, 03 Aug 2005 10:13:11 -0400 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 <0IKN00BFAF1SB5@szxga02-in.huawei.com> for pce@ietf.org; Wed, 03 Aug 2005 21:34:40 +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 <0IKN00KZ3F1SZA@szxga02-in.huawei.com> for pce@ietf.org; Wed, 03 Aug 2005 21:34:40 +0800 (CST) Received: from l10814dell (open-29-186.ietf63.ietf.org [86.255.29.186]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IKN003DJF16BT@szxml02-in.huawei.com> for pce@ietf.org; Wed, 03 Aug 2005 21:34:35 +0800 (CST) Date: Wed, 03 Aug 2005 21:27:47 +0800 From: Zhang Renhai To: "pce@ietf.org" Message-id: <0IKN003E7F1HBT@szxml02-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT Cc: Subject: [Pce] About the presentation of draft-zhang-pce-comm-app-model-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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, all Sorry for not all clear about some questions asked to me at the meeting. I really appreciate that someone can repeat the question and we can discuss more here. Actually, what I proposed surely is just applied to some kind of circumstances. For example, if three PCEs are serving all requests in a domain, and these PCEs are coupled closely, for instance, they may be located in different box but in the same tank or room, or located in different place remote to each other and connected by a high speed line, so based on my proposal, even only one request is sent to one of these PCE, and the PCE can forward the request to other two PCEs quickly to make the two PCEs maintain the request table,and this delation of transmittion may be ignoed by some tradeoff. The essential goal of the draft is just to use the table to solve some known question. I don't know how the communication for the detailed discovery will be because the detailed capability is still not specified now, how complicated a detailed capability could be for a special request? Can a tradeoff be made between below two choice for some special application: -saving the detailed discovery communication, correspondingly sending the same request to all PCEs(or just one of these PCEs like what I mentioned above) -performing the detailed discovery communication for each PCC? Certainly,this proposal is not intent to became part of the PCE communication protocol. Another concern of this draft is to make the requests distributed to different PCE more *reasonable*, for example, three PCEs in a domain, PCE1, PCE2, PCE3, and now PCE3 is congested with too much requests or other reason, for the PCC originating the request, which PCE else should it choose? PCE1 or PCE2? what information should be used to help to select again more reasonable? Based on the Global Computing Table, the congesting PCE(PCE3) will know the number of requests that other PCE is now dealing with, although PCE1 and PCE2 both are not congested now, based on the mentioned information, PCE3 can select other PCE with least number of requests and appropriate capability to make sure the PCC can get the computation result asap, and I think the time from sending request to receiving the computing result may be a important consideration for some application. Cheers, Zhang _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 05:08:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bho-0001Hg-2G; Thu, 04 Aug 2005 05:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bhk-0001ET-Lh; Thu, 04 Aug 2005 05:07:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14578; Thu, 4 Aug 2005 05:07:54 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cEb-00070k-VN; Thu, 04 Aug 2005 05:41:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:07:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 11:07:35 +0200 Message-ID: Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWX/eDNk0bm01pPT/i4sE3z2rI2KQAy6zDw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Luca Martini" X-OriginalArrivalTime: 04 Aug 2005 09:07:34.0087 (UTC) FILETIME=[F3829570:01C598D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, pwe3 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Luca Please see inline,=20 > -----Message d'origine----- > De : Luca Martini [mailto:lmartini@cisco.com]=20 > Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Don Fedyk; pwe3; pce@ietf.org > Objet : Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. >=20 >=20 >=20 > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > Hi Luca, > >=20 > >> We will need PCE to produce the computed path , which=20 > could then be=20 > >> signaled by either RSVP or LDP. > >=20 > > I'm really curious to know how LDP will be used to signal=20 > an explicit path computed by the PCE... > > CR-LDP??? > >=20 > Not quite. Some kind of explicit PW route object containing=20 > some addressing ( probably not IP ) does not turn LDP into CR-LDP. > We are also still using DU mode not DOD. Why not taking leverage of the RSVP-TE explicit routing machinery, = including inter-domain procedures, instead of introducing significant = changes to LDP? Frankly speaking I don't really see why we should choose between LDP and = RSVP-TE for MH PW sig, why not progressing both approaches? When explicit routing is not required then use LDP, and if explicit = routing is required use RSVP-TE. This is what we are doing today for LSP = signaling by the way... Best Regards, JL =20 >=20 > Luca >=20 > > Regards, > >=20 > > JL > >=20 > >> -----Message d'origine----- > >> De : pce-bounces@lists.ietf.org > >> [mailto:pce-bounces@lists.ietf.org] De la part de Don=20 > Fedyk Envoy=E9 :=20 > >> mardi 2 ao=FBt 2005 15:19 =C0 : Luca Martini; pwe3;=20 > pce@ietf.org Objet :=20 > >> [Pce] RE: [PWE3] Correction of my statement regarding PCE. > >> > >> Luca: > >> > >> Is the PWE Multi-Stitching topology congruent with the=20 > GMPLS IGP/EGP=20 > >> topology? It was my understanding there is no constraint assuming=20 > >> this. > >> Therefore I think you have an additional requirement that=20 > PCE model=20 > >> support multiple Topologies. > >> > >> Just curious, > >> Don > >> > >>> -----Original Message----- > >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >> On Behalf > >>> Of Luca Martini > >>> > >>> Now, If Lou Had not derailed my thoughts ... > >>> > >>> What I meant to say was that neither RSVP-TE nor any > >> flavors of LDP > >>> can properly solve the problem of computing the shortest > >> path between > >>> two domains/AS/areas. We will need PCE to produce the > >> computed path , > >>> which could then be signaled by either RSVP or LDP. > >>> > >>> I believe that we often do not make the distinction between > >> the C-SPF > >>> calculation and RSVP-TE. > >>> > >>> > >>> Luca > >> > >> _______________________________________________ > >> Pce mailing list > >> Pce@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/pce > >> > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 05:17:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bqh-00054d-7H; Thu, 04 Aug 2005 05:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bqf-00053Z-SB for pce@megatron.ietf.org; Thu, 04 Aug 2005 05:17:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15282 for ; Thu, 4 Aug 2005 05:17:05 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm2.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cNU-0007UF-1U for pce@ietf.org; Thu, 04 Aug 2005 05:51:05 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j749Go1j005149 for ; Thu, 4 Aug 2005 05:16:51 -0400 (EDT) Message-Id: <200508040916.j749Go1j005149@tm2.ca.alcatel.com> From: "Andrew Dolganow" To: Date: Thu, 4 Aug 2005 05:16:49 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcWY1QnYtYtTDi7RSMui6XLGRlU2GA== X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Pce] Providing optimization metrics in addition to a computed path in PCE responses 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="===============2057023586==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2057023586== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C598B3.B8946CB0" This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C598B3.B8946CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, It would be highly desirable if a response to a PCE Request contained not only a computed path but also metrics that can be used in a selection of the most optimal path by either a PCE or PCC issuing the original request. For example a PCC (directly or through a PCE) issuing a request for a multi-hop PW may need to go to two independent PCEs to find a path from two border S-PEs towards destination. The PCC (PCE) would then take both responses and compare them with paths to reach each of the S-PEs it can compute. To find the optimal path, the PCC (PCE) needs info to allow such "optimal" path selection (like for example costs for the computed paths). I would like to propose that the protocol requirements draft includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) that a Path Computation Response SHOULD allow return of metrics that can be used by a requesting entity to optimize a path. Andrew ------=_NextPart_000_0086_01C598B3.B8946CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
It = would be highly=20 desirable if a response to a PCE Request contained not only a computed = path but=20 also metrics that can be used in a selection of the = most optimal path=20 by either a PCE or PCC issuing the original request. For example a PCC = (directly=20 or through a PCE) issuing a request for a multi-hop PW may need to = go to=20 two independent PCEs to find a path from two border S-PEs towards=20 destination. The PCC (PCE) would then take both responses and = compare=20 them with paths to reach each of the S-PEs it can compute. To find the = optimal=20 path, the PCC (PCE) needs info to allow such "optimal" path = selection (like=20 for example costs for the computed paths).
 
I = would like to=20 propose that the protocol requirements draft includes a requirement = (section 6=20 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) = that a Path=20 Computation Response SHOULD allow return of metrics that can be used by = a=20 requesting entity to optimize a path.
 
Andrew 
= ------=_NextPart_000_0086_01C598B3.B8946CB0-- --===============2057023586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2057023586==-- From pce-bounces@lists.ietf.org Thu Aug 04 05:27:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c11-0001Jl-VM; Thu, 04 Aug 2005 05:27:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c10-0001Ja-PM; Thu, 04 Aug 2005 05:27:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15978; Thu, 4 Aug 2005 05:27:48 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cXr-00083k-2E; Thu, 04 Aug 2005 06:01:48 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 10:27:39 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 10:27:38 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 10:27:38 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1E96@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWX/eDNk0bm01pPT/i4sE3z2rI2KQAy6zDwAALjfsA= To: , X-OriginalArrivalTime: 04 Aug 2005 09:27:38.0946 (UTC) FILETIME=[C1A97A20:01C598D6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JL wrote 04 August 2005 10:08 > Hi Luca >=20 > Please see inline, >=20 > > -----Message d'origine----- > > De : Luca Martini [mailto:lmartini@cisco.com] > > Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > Cc : Don Fedyk; pwe3; pce@ietf.org > > Objet : Re: [Pce] RE: [PWE3] Correction of my statement > regarding PCE. > >=20 > >=20 > >=20 > > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > Hi Luca, > > >=20 > > >> We will need PCE to produce the computed path , which > > could then be > > >> signaled by either RSVP or LDP. > > >=20 > > > I'm really curious to know how LDP will be used to signal > > an explicit path computed by the PCE... > > > CR-LDP??? > > >=20 > > Not quite. Some kind of explicit PW route object containing some=20 > > addressing ( probably not IP ) does not turn LDP into CR-LDP. We are = > > also still using DU mode not DOD. >=20 > Why not taking leverage of the RSVP-TE explicit routing > machinery, including inter-domain procedures, instead of=20 > introducing significant changes to LDP? Frankly speaking I=20 > don't really see why we should choose between LDP and RSVP-TE=20 > for MH PW sig, why not progressing both approaches? When=20 > explicit routing is not required then use LDP, and if=20 > explicit routing is required use RSVP-TE. This is what we are=20 > doing today for LSP signaling by the way... >=20 > Best Regards, >=20 > JL NH=3D> I largely agree. A signalling protocol is a signalling = protocol....in other words you really only need one of them for = providing this function. Why an operator would wish to run multiple = types of the same functional component seems unclear. A 1 hop trail is = a degenerate case, ie its not a networked entity......but IMO it would = seem rather silly just to have a different signalling protocol for this = special case, one may as well use the one that applies for the general = case. Minimising functional components should also help minimise costs, = at least as a general rule. The other nice thing about using the GMPLS = developed spin of RSVP-TE is that it can be used OOB....and that has to = be a good thing for security/stability design considerations (though I = am well aware MPLS has not been designed like this, and that in GMPLS = the co-cs mode forces good design practice anyway). regards, Neil _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 05:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cBJ-0004HB-8w; Thu, 04 Aug 2005 05:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cBG-0004GV-9n; Thu, 04 Aug 2005 05:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16602; Thu, 4 Aug 2005 05:38:23 -0400 (EDT) Received: from napoleon.monoski.com ([63.225.114.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ci6-00006O-EG; Thu, 04 Aug 2005 06:12:24 -0400 Received: from [2.0.1.6] (rasputin-gw [2.0.1.6]) (authenticated bits=0) by napoleon.monoski.com (8.13.2/8.13.2) with ESMTP id j749bx0c000005; Thu, 4 Aug 2005 03:38:00 -0600 (MDT) Message-ID: <42F1E1E0.1000505@cisco.com> Date: Thu, 04 Aug 2005 03:37:36 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0+ (X11/20050712) MIME-Version: 1.0 To: neil.2.harrison@bt.com Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. References: <0536FC9B908BEC4597EE721BE6A353890A9F1E96@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F1E96@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by napoleon.monoski.com id j749bx0c000005 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Neil, Don't you think that having an appropriate addressing scheme for the=20 multi segment PW is necessary ? If so, it would mean major changes to RSVP-TE which only supports ipv4=20 and ipv6 addressing right now. Luca neil.2.harrison@bt.com wrote: > JL wrote 04 August 2005 10:08 >=20 >> Hi Luca >> >> Please see inline, >> >>> -----Message d'origine----- >>> De : Luca Martini [mailto:lmartini@cisco.com] >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN >>> Cc : Don Fedyk; pwe3; pce@ietf.org >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement >> regarding PCE. >>> >>> >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: >>>> Hi Luca, >>>> >>>>> We will need PCE to produce the computed path , which >>> could then be >>>>> signaled by either RSVP or LDP. >>>> I'm really curious to know how LDP will be used to signal >>> an explicit path computed by the PCE... >>>> CR-LDP??? >>>> >>> Not quite. Some kind of explicit PW route object containing some=20 >>> addressing ( probably not IP ) does not turn LDP into CR-LDP. We are=20 >>> also still using DU mode not DOD. >> Why not taking leverage of the RSVP-TE explicit routing >> machinery, including inter-domain procedures, instead of=20 >> introducing significant changes to LDP? Frankly speaking I=20 >> don't really see why we should choose between LDP and RSVP-TE=20 >> for MH PW sig, why not progressing both approaches? When=20 >> explicit routing is not required then use LDP, and if=20 >> explicit routing is required use RSVP-TE. This is what we are=20 >> doing today for LSP signaling by the way... >> >> Best Regards, >> >> JL > NH=3D> I largely agree. A signalling protocol is a signalling protocol.= ...in other words you really only need one of them for providing this fun= ction. Why an operator would wish to run multiple types of the same func= tional component seems unclear. A 1 hop trail is a degenerate case, ie i= ts not a networked entity......but IMO it would seem rather silly just to= have a different signalling protocol for this special case, one may as w= ell use the one that applies for the general case. Minimising functional= components should also help minimise costs, at least as a general rule. = The other nice thing about using the GMPLS developed spin of RSVP-TE is = that it can be used OOB....and that has to be a good thing for security/s= tability design considerations (though I am well aware MPLS has not been = designed like this, and that in GMPLS the co-cs mode forces good design p= ractice anyway). >=20 > regards, Neil >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 05:43:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cFg-0005jx-4O; Thu, 04 Aug 2005 05:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cFc-0005it-9v for pce@megatron.ietf.org; Thu, 04 Aug 2005 05:42:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17045 for ; Thu, 4 Aug 2005 05:42:53 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cmR-0000P1-Lc for pce@ietf.org; Thu, 04 Aug 2005 06:16:54 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Aug 2005 02:42:43 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208,217"; a="202626386:sNHT43367520" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j749geZ1027954; Thu, 4 Aug 2005 02:42:40 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 05:42:40 -0400 Received: from [86.255.25.69] ([10.86.242.19]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 05:42:39 -0400 In-Reply-To: <200508040916.j749Go1j005149@tm2.ca.alcatel.com> References: <200508040916.j749Go1j005149@tm2.ca.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <3A4F6D51-CD71-4884-879C-6395564AE175@cisco.com> From: JP Vasseur Subject: Re: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Date: Thu, 4 Aug 2005 11:43:04 +0200 To: Andrew Dolganow X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 04 Aug 2005 09:42:39.0628 (UTC) FILETIME=[DA82A4C0:01C598D8] X-Spam-Score: 0.8 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1664017434==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1664017434== Content-Type: multipart/alternative; boundary=Apple-Mail-4-959980052 --Apple-Mail-4-959980052 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote: > Hi, > > It would be highly desirable if a response to a PCE Request > contained not only a computed path but also metrics that can be > used in a selection of the most optimal path by either a PCE or PCC > issuing the original request. The ability for the PCC to provide objective function which could be used by the PCE for path selection is indeed listed as a requirement in the generic PCE communication requirement ID. > For example a PCC (directly or through a PCE) issuing a request for > a multi-hop PW may need to go to two independent PCEs to find a > path from two border S-PEs towards destination. The PCC (PCE) would > then take both responses and compare them with paths to reach each > of the S-PEs it can compute. To find the optimal path, the PCC > (PCE) needs info to allow such "optimal" path selection (like for > example costs for the computed paths). > Two comments: 1) Indeed, the PCC may in some cases send the same requests to multiple PCEs (this is one of the reasons why in PCEP for example we introduced the ability for the PCC to cancel pending requests) 2) Since the objective function will be provided by the PCC, it should get comparable path costs. That said, note that this may require synchronization between PCEs lying in different domains to ensure metric consistency. > I would like to propose that the protocol requirements draft > includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce- > comm-protocol-gen-reqs-01.txt draft) that a Path Computation > Response SHOULD allow return of metrics that can be used by a > requesting entity to optimize a path. Clearly the PCC request will include the ability to specify the objective function. Thus the computed path cost provided by the PCE will be well-understood by the PCC. Are you referring to the requirement for the PCE to provide the computed path cost ? Thanks. JP. > > Andrew > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-4-959980052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew,

On = Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote:

=
Hi,
=A0
It would be = highly desirable if a response to a PCE Request contained not only a = computed path but also metrics that can be used in a selection of=A0the = most=A0optimal path by either a PCE or PCC issuing the original = request.

The ability for the PCC to = provide objective function which could be used by the PCE for path = selection is indeed listed as a requirement in the generic PCE = communication requirement ID.

For example a PCC (directly or through a = PCE)=A0issuing a request for a multi-hop PW may need to go to two = independent PCEs to find a path from two border S-PEs towards = destination.=A0The PCC (PCE)=A0would then take both responses and = compare them with paths to reach each of the S-PEs it can compute. To = find the optimal path, the PCC (PCE)=A0needs info to allow such = "optimal" path selection (like for example costs for=A0the=A0computed = paths).
=A0

Two comments:=A0
1)= Indeed, the PCC may in some cases send the same requests to multiple = PCEs (this is one of the reasons why in PCEP for example we introduced = the ability for the PCC to cancel pending requests)
2) Since = the objective function will be provided by the PCC, it should get = comparable path costs. That said, note that this may require = synchronization between PCEs lying in different domains to ensure metric = consistency.

I would like to propose = that the protocol requirements draft includes a requirement (section 6 = and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) = that a Path Computation Response SHOULD allow return of metrics that can = be used by a requesting entity to optimize a = path.

Clearly the PCC request = will include the ability to specify the objective function. Thus the = computed path cost provided by the PCE will be well-understood by the = PCC. Are you referring to the requirement for the PCE to provide the = computed path cost ?

Thanks.

JP.

=A0
Andrew=A0
Pce mailing list


= --Apple-Mail-4-959980052-- --===============1664017434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1664017434==-- From pce-bounces@lists.ietf.org Thu Aug 04 05:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cM5-0002a1-Kt; Thu, 04 Aug 2005 05:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cM2-0002ZI-Jb; Thu, 04 Aug 2005 05:49:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17784; Thu, 4 Aug 2005 05:49:32 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0css-0000pP-C3; Thu, 04 Aug 2005 06:23:32 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j749nAt06856; Thu, 4 Aug 2005 05:49:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 05:48:54 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D05A28089@zcarhxm0.corp.nortel.com> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWX/ngdkp9N07EoQYitDXj7I011MgA2r2vw From: "Hamid Ould-Brahim" To: "Luca Martini" , "LE ROUX Jean-Louis RD-CORE-LAN" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pwe3 , 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Luca, > > > Not quite. Some kind of explicit PW route object containing some > addressing ( probably not IP ) does not turn LDP into CR-LDP. > We are also still using DU mode not DOD. > PW route object? Are you referring to a route object that contains a list of attachment identifiers that a multi segment pw traverses? Can you be more explicit on this route object? Hamid. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 06:09:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cfb-0007in-JD; Thu, 04 Aug 2005 06:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cfZ-0007iB-Id for pce@megatron.ietf.org; Thu, 04 Aug 2005 06:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18935 for ; Thu, 4 Aug 2005 06:09:43 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm1.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dCR-0001in-64 for pce@ietf.org; Thu, 04 Aug 2005 06:43:43 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm1.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j74A9WwK019363; Thu, 4 Aug 2005 06:09:33 -0400 (EDT) Message-Id: <200508041009.j74A9WwK019363@tm1.ca.alcatel.com> From: "Andrew Dolganow" To: "'JP Vasseur'" Subject: RE: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Date: Thu, 4 Aug 2005 06:09:31 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <3A4F6D51-CD71-4884-879C-6395564AE175@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcWY2OCxmUJi7AvoRhe4DaxbvaKuCQAAjNaw X-Spam-Score: 0.6 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1880160466==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1880160466== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01C598BB.16012FD0" This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C598BB.16012FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit JP, Please see below in bold font: _____ From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, August 04, 2005 5:43 AM To: Andrew Dolganow Cc: pce@ietf.org Subject: Re: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Hi Andrew, On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote: Hi, It would be highly desirable if a response to a PCE Request contained not only a computed path but also metrics that can be used in a selection of the most optimal path by either a PCE or PCC issuing the original request. The ability for the PCC to provide objective function which could be used by the PCE for path selection is indeed listed as a requirement in the generic PCE communication requirement ID. For example a PCC (directly or through a PCE) issuing a request for a multi-hop PW may need to go to two independent PCEs to find a path from two border S-PEs towards destination. The PCC (PCE) would then take both responses and compare them with paths to reach each of the S-PEs it can compute. To find the optimal path, the PCC (PCE) needs info to allow such "optimal" path selection (like for example costs for the computed paths). Two comments: 1) Indeed, the PCC may in some cases send the same requests to multiple PCEs (this is one of the reasons why in PCEP for example we introduced the ability for the PCC to cancel pending requests) 2) Since the objective function will be provided by the PCC, it should get comparable path costs. That said, note that this may require synchronization between PCEs lying in different domains to ensure metric consistency. Alternatively, the requesting PCC (PCE) would now the "mapping" it needs to apply to both costs, but I agree that metric consistency between PCEs would be a better solution. I would like to propose that the protocol requirements draft includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) that a Path Computation Response SHOULD allow return of metrics that can be used by a requesting entity to optimize a path. Clearly the PCC request will include the ability to specify the objective function. Thus the computed path cost provided by the PCE will be well-understood by the PCC. Are you referring to the requirement for the PCE to provide the computed path cost ? That's exactly what I am looking for. In my example two PCEs building partial paths need to provide back an optimization metric in their Path Computation responses to allow the "original" PCC (or a PCE acting for that PCC to build a complete path) to select the optimal path using one of the partial paths computed by the two PCEs. Unless Path Computation Response messages carry back such metrics we won't be able to build an optimal path. Andrew Thanks. JP. Andrew _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_009C_01C598BB.16012FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
JP,
 
Please see below in bold = font:

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Thursday, August 04, 2005 5:43 AM
To: Andrew=20 Dolganow
Cc: pce@ietf.org
Subject: Re: [Pce] = Providing=20 optimization metrics in addition to a computed path in PCE=20 responses

Hi Andrew,

On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote:

Hi,
It = would be highly=20 desirable if a response to a PCE Request contained not only a computed = path=20 but also metrics that can be used in a selection of the most optimal = path by=20 either a PCE or PCC issuing the original=20 request.

The ability for the PCC to provide objective function which could = be used=20 by the PCE for path selection is indeed listed as a requirement in the = generic=20 PCE communication requirement ID.

For = example a PCC=20 (directly or through a PCE) issuing a request for a multi-hop PW may = need to=20 go to two independent PCEs to find a path from two border S-PEs = towards=20 destination. The PCC (PCE) would then take both responses and compare = them=20 with paths to reach each of the S-PEs it can compute. To find the = optimal=20 path, the PCC (PCE) needs info to allow such "optimal" path selection = (like=20 for example costs for the computed paths).

Two comments:
1) Indeed, the PCC may in some cases send the same requests to = multiple=20 PCEs (this is one of the reasons why in PCEP for example we introduced = the=20 ability for the PCC to cancel pending requests)
2) Since the objective function will be provided by the PCC, it = should get=20 comparable path costs. That said, note that this may require = synchronization=20 between PCEs lying in different domains to ensure metric = consistency.
 
Alternatively, the = requesting PCC=20 (PCE) would now the "mapping" it needs to apply to both costs, but = I agree=20 that metric consistency between PCEs would be a better=20 solution. 
I = would like to=20 propose that the protocol requirements draft includes a requirement = (section 6=20 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) = that a=20 Path Computation Response SHOULD allow return of metrics that can be = used by a=20 requesting entity to optimize a path.

Clearly the PCC request will include the ability to specify the = objective=20 function. Thus the computed path cost provided by the PCE will be=20 well-understood by the PCC. Are you referring to the requirement for the = PCE to=20 provide the computed path cost ?

That's exactly what I am looking for. = In my=20 example two PCEs building partial paths need to provide back an=20 optimization metric in their Path Computation responses to allow = the=20 "original" PCC (or a PCE acting for that PCC to build a complete path) = to select=20 the optimal path using one of the partial paths computed by the two = PCEs. Unless=20 Path Computation Response messages carry back such metrics we won't be = able to=20 build an optimal path.
 
Andrew
 
 
Thanks.

JP.

Andrew=20
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

------=_NextPart_000_009C_01C598BB.16012FD0-- --===============1880160466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1880160466==-- From pce-bounces@lists.ietf.org Thu Aug 04 06:19:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cnV-00016O-5E; Thu, 04 Aug 2005 06:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cnR-00015s-Mb; Thu, 04 Aug 2005 06:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19786; Thu, 4 Aug 2005 06:17:51 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dKJ-0002F5-Gq; Thu, 04 Aug 2005 06:51:51 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:17:39 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 11:17:39 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 11:17:38 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1E97@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWY2EVL/LNDIrusT+ybhP3SSB1NOAAATNzg To: X-OriginalArrivalTime: 04 Aug 2005 10:17:39.0077 (UTC) FILETIME=[BDE12350:01C598DD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Luca you wrote 04 August 2005 10:38 > Neil, >=20 > Don't you think that having an appropriate addressing scheme for the=20 > multi segment PW is necessary ? NH=3D> Interesting point you raise here. Every layer network needs an = addressing schema. Indeed, even if you use v4 addressing in GMPLS for = the *traffic* data-plane VC4 layer network in SDH this is not the same = addressing space as the IP layer network v4 address space. And of = course the VC12 layer network also has its own address space, which = could also be v4. And neither of these are the *same* as the data-plane = networks which carry their control/management-plane protocols. So = addressing (like routing) is not a single function spanning all layers. = And I wish this was better understood because I think too many folks = still believe there is a 'common control-plane' running from IP to = Optics.....there can't be, it makes neither technical nor commercial = sense MPLS is an odd-ball here as a layer network, but I don't really want to = get into the nuances of the wrapper here (though its a fairly serious = problem IMO and also lies at the heart of many other problems). However, let me point this out. We should never have created this PW = layer network in the 1st place. cl-ps(eg IP)!=3D co-ps(eg MPLS) !=3D = co-cs (eg GMPLS) and that is just a fact. I know the history of arch = violations/errors why we have arrived here and quite frankly its a = mess....just looking at the stuff regarding the VCCV breakout group = tells you something is very seriously wrong here. However, having = created this unnecessary layer network then yes addressing will have to = be defined for it...and every other functional component that a layer = network requires will also have to be added. >=20 > If so, it would mean major changes to RSVP-TE which only=20 > supports ipv4=20 > and ipv6 addressing right now. NH=3D> What do you want me to say?.....perhaps something like, 'well = done for yet another major error'? I remember when I saw these = 'addresses' being originally cooked-up saying to myself.....this is = going to create a serious problem downstream. Addressing is one thing = you should pay great attention to at t=3D0....if you screw it up you are = stuck with it for a very long time. But hey, this stuff is built on a = whole pile of compounded mistakes so why just pick on this one? If you = really want to fix thing you are going to have to go back quite a long = way. It may simply not be worth it now and perhaps folks should think = of other ways to address (no pun intended) this client/server service = issue. regards, Neil >=20 > Luca >=20 >=20 > neil.2.harrison@bt.com wrote: > > JL wrote 04 August 2005 10:08 > >=20 > >> Hi Luca > >> > >> Please see inline, > >> > >>> -----Message d'origine----- > >>> De : Luca Martini [mailto:lmartini@cisco.com] > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > >> regarding PCE. > >>> > >>> > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > >>>> Hi Luca, > >>>> > >>>>> We will need PCE to produce the computed path , which > >>> could then be > >>>>> signaled by either RSVP or LDP. > >>>> I'm really curious to know how LDP will be used to signal > >>> an explicit path computed by the PCE... > >>>> CR-LDP??? > >>>> > >>> Not quite. Some kind of explicit PW route object containing some > >>> addressing ( probably not IP ) does not turn LDP into=20 > CR-LDP. We are=20 > >>> also still using DU mode not DOD. > >> Why not taking leverage of the RSVP-TE explicit routing machinery,=20 > >> including inter-domain procedures, instead of introducing=20 > significant=20 > >> changes to LDP? Frankly speaking I don't really see why we should=20 > >> choose between LDP and RSVP-TE for MH PW sig, why not progressing=20 > >> both approaches? When explicit routing is not required=20 > then use LDP,=20 > >> and if explicit routing is required use RSVP-TE. This is=20 > what we are > >> doing today for LSP signaling by the way... > >> > >> Best Regards, > >> > >> JL > > NH=3D> I largely agree. A signalling protocol is a signalling=20 > > protocol....in other words you really only need one of them for=20 > > providing this function. Why an operator would wish to run=20 > multiple=20 > > types of the same functional component seems unclear. A 1=20 > hop trail=20 > > is a degenerate case, ie its not a networked entity......but IMO it=20 > > would seem rather silly just to have a different signalling=20 > protocol=20 > > for this special case, one may as well use the one that applies for=20 > > the general case. Minimising functional components should=20 > also help=20 > > minimise costs, at least as a general rule. The other nice thing=20 > > about using the GMPLS developed spin of RSVP-TE is that it=20 > can be used=20 > > OOB....and that has to be a good thing for=20 > security/stability design=20 > > considerations (though I am well aware MPLS has not been=20 > designed like=20 > > this, and that in GMPLS the co-cs mode forces good design practice=20 > > anyway). > >=20 > > regards, Neil > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 06:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d7C-0004VJ-Gj; Thu, 04 Aug 2005 06:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d7A-0004T5-9N; Thu, 04 Aug 2005 06:38:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24836; Thu, 4 Aug 2005 06:38:13 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0de2-0003RS-6Z; Thu, 04 Aug 2005 07:12:14 -0400 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1123151886!3961694!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 8133 invoked from network); 4 Aug 2005 10:38:06 -0000 Received: from unknown (HELO OCCLUST04EVS1.ugd.att.com) (192.128.133.132) by server-3.tower-121.messagelabs.com with SMTP; 4 Aug 2005 10:38:06 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 05:37:30 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0A33C4FB@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWY2EVL/LNDIrusT+ybhP3SSB1NOAAATNzgAAF0qhA= From: "Brungard, Deborah A, ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, pwe3@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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Agree Neil on this address mis-understanding - I have seen it multiple = times. Many are confusing the use of NSAPs by the management plane as = requiring the support in a control protocol. These NSAP addresses are = very specific for the management plane application (user or service = provider), and private. No different than a service provider using = private addressing for their internal network, a user will require the = same. Deborah=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = neil.2.harrison@bt.com Sent: Thursday, August 04, 2005 6:18 AM To: lmartini@cisco.com Cc: pwe3@ietf.org; pce@ietf.org Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Hi Luca you wrote 04 August 2005 10:38 > Neil, >=20 > Don't you think that having an appropriate addressing scheme for the=20 > multi segment PW is necessary ? NH=3D> Interesting point you raise here. Every layer network needs an = addressing schema. Indeed, even if you use v4 addressing in GMPLS for = the *traffic* data-plane VC4 layer network in SDH this is not the same = addressing space as the IP layer network v4 address space. And of = course the VC12 layer network also has its own address space, which = could also be v4. And neither of these are the *same* as the data-plane = networks which carry their control/management-plane protocols. So = addressing (like routing) is not a single function spanning all layers. = And I wish this was better understood because I think too many folks = still believe there is a 'common control-plane' running from IP to = Optics.....there can't be, it makes neither technical nor commercial = sense MPLS is an odd-ball here as a layer network, but I don't really want to = get into the nuances of the wrapper here (though its a fairly serious = problem IMO and also lies at the heart of many other problems). However, let me point this out. We should never have created this PW = layer network in the 1st place. cl-ps(eg IP)!=3D co-ps(eg MPLS) !=3D = co-cs (eg GMPLS) and that is just a fact. I know the history of arch = violations/errors why we have arrived here and quite frankly its a = mess....just looking at the stuff regarding the VCCV breakout group = tells you something is very seriously wrong here. However, having = created this unnecessary layer network then yes addressing will have to = be defined for it...and every other functional component that a layer = network requires will also have to be added. >=20 > If so, it would mean major changes to RSVP-TE which only=20 > supports ipv4=20 > and ipv6 addressing right now. NH=3D> What do you want me to say?.....perhaps something like, 'well = done for yet another major error'? I remember when I saw these = 'addresses' being originally cooked-up saying to myself.....this is = going to create a serious problem downstream. Addressing is one thing = you should pay great attention to at t=3D0....if you screw it up you are = stuck with it for a very long time. But hey, this stuff is built on a = whole pile of compounded mistakes so why just pick on this one? If you = really want to fix thing you are going to have to go back quite a long = way. It may simply not be worth it now and perhaps folks should think = of other ways to address (no pun intended) this client/server service = issue. regards, Neil >=20 > Luca >=20 >=20 > neil.2.harrison@bt.com wrote: > > JL wrote 04 August 2005 10:08 > >=20 > >> Hi Luca > >> > >> Please see inline, > >> > >>> -----Message d'origine----- > >>> De : Luca Martini [mailto:lmartini@cisco.com] > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > >> regarding PCE. > >>> > >>> > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > >>>> Hi Luca, > >>>> > >>>>> We will need PCE to produce the computed path , which > >>> could then be > >>>>> signaled by either RSVP or LDP. > >>>> I'm really curious to know how LDP will be used to signal > >>> an explicit path computed by the PCE... > >>>> CR-LDP??? > >>>> > >>> Not quite. Some kind of explicit PW route object containing some > >>> addressing ( probably not IP ) does not turn LDP into=20 > CR-LDP. We are=20 > >>> also still using DU mode not DOD. > >> Why not taking leverage of the RSVP-TE explicit routing machinery,=20 > >> including inter-domain procedures, instead of introducing=20 > significant=20 > >> changes to LDP? Frankly speaking I don't really see why we should=20 > >> choose between LDP and RSVP-TE for MH PW sig, why not progressing=20 > >> both approaches? When explicit routing is not required=20 > then use LDP,=20 > >> and if explicit routing is required use RSVP-TE. This is=20 > what we are > >> doing today for LSP signaling by the way... > >> > >> Best Regards, > >> > >> JL > > NH=3D> I largely agree. A signalling protocol is a signalling=20 > > protocol....in other words you really only need one of them for=20 > > providing this function. Why an operator would wish to run=20 > multiple=20 > > types of the same functional component seems unclear. A 1=20 > hop trail=20 > > is a degenerate case, ie its not a networked entity......but IMO it=20 > > would seem rather silly just to have a different signalling=20 > protocol=20 > > for this special case, one may as well use the one that applies for=20 > > the general case. Minimising functional components should=20 > also help=20 > > minimise costs, at least as a general rule. The other nice thing=20 > > about using the GMPLS developed spin of RSVP-TE is that it=20 > can be used=20 > > OOB....and that has to be a good thing for=20 > security/stability design=20 > > considerations (though I am well aware MPLS has not been=20 > designed like=20 > > this, and that in GMPLS the co-cs mode forces good design practice=20 > > anyway). > >=20 > > regards, Neil > >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Aug 04 07:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dta-0003ZY-RA; Thu, 04 Aug 2005 07:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dtZ-0003Yv-1W; Thu, 04 Aug 2005 07:28:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28032; Thu, 4 Aug 2005 07:28:15 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0eQQ-0005Zm-V7; Thu, 04 Aug 2005 08:02:15 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 12:28:06 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 12:28:06 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Thu, 4 Aug 2005 12:28:05 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1E99@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWY2EVL/LNDIrusT+ybhP3SSB1NOAAATNzgAAF0qhAAALR3sA== To: , X-OriginalArrivalTime: 04 Aug 2005 11:28:06.0122 (UTC) FILETIME=[956504A0:01C598E7] X-Spam-Score: 0.3 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, pwe3@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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Yes I know Deborah.....but folks were spun some stories many years ago = about 'common-control-planes' and far too many folks got the wrong = understanding of what this means. We've seen these problems coming for = a very long time....and I've had my fair share of flames for trying to = explain them......folks either don't understand what I have been saying = or don't want to understand it, and its not always easy to work out = which is which. But this is more than the point you are picking out....when we are = dealing with the co-cs mode technologies we are FORCED to do many of the = right things, ie OOB control/management is forced, client/server = relationships are always respected (and there can't be a wrapper = behaviour), you can't 'merge' trails nor can you terminate them 1 hop = too short, there are no QoS classes (this is another story of course = about the illusion of DS). However, you can do nasty things to the = co-ps mode....and its from this basis PWs were spawned. Whilst they = stayed 1-hop many of the issues could remain latent......but not when = they go multi-hop and have to be properly networked. This PW layer = network should never have been created......all we really want is a = simple client/server relationship.....but that is not possible because = of how MPLS has been defined. And this is pretty serious = stuff....because one of the (if not THE) key services an operator must = be able to provide is a simple managed BW network builder capability, ie = a functionally decoupled client/server relationship between the layer = networks of 2 different operating parties....and if the client is an = MPLS network and the server is an MPLS network.....well I am sure folks = can figure out where this heads. I'm sorry many IETF folks don't like ITU defined functional = architecture....and that is a real shame. Because if this was better = understood then perhaps less mistakes would be made. I really don't know where this PW stuff is going to end-up.....I've been = of the view it probably passed the event horizon a long time ago and its = too late now. We could fix MPLS (its not PWs that need fixing these are = just a symptom)......but is there the will? But just think about it for = a moment...why can't we have a co-ps mode technology run just like a = co-cs technology as per GMPLS?....and what is THE key observation with = GMPLS, ie there is no IP in the *traffic* data-plane. And if this is = good enough for GMPLS then why not for MPLS? Indeed, the biggest = problem with MPLS is that it treats IP, MPLS and 'other' clients all = differently....and until that is understood then we will never have a = good solution. Its clearly doable, but is there the will? There were 3 organisations = proposing a need to develop 'transport MPLS' at the last SG15 mtg. That = is 1 way out of the current mess. =20 regards, Neil > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: 04 August 2005 11:38 > To: Harrison,N,Neil,JRD1 R; lmartini@cisco.com > Cc: pwe3@ietf.org; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE. >=20 >=20 > Agree Neil on this address mis-understanding - I have seen it > multiple times. Many are confusing the use of NSAPs by the=20 > management plane as requiring the support in a control=20 > protocol. These NSAP addresses are very specific for the=20 > management plane application (user or service provider), and=20 > private. No different than a service provider using private=20 > addressing for their internal network, a user will require the same. >=20 > Deborah >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of neil.2.harrison@bt.com > Sent: Thursday, August 04, 2005 6:18 AM > To: lmartini@cisco.com > Cc: pwe3@ietf.org; pce@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE. >=20 > Hi Luca >=20 > you wrote 04 August 2005 10:38 >=20 > > Neil, > >=20 > > Don't you think that having an appropriate addressing scheme for the = > > multi segment PW is necessary ? > NH=3D> Interesting point you raise here. Every layer network > needs an addressing schema. Indeed, even if you use v4=20 > addressing in GMPLS for the *traffic* data-plane VC4 layer=20 > network in SDH this is not the same addressing space as the=20 > IP layer network v4 address space. And of course the VC12=20 > layer network also has its own address space, which could=20 > also be v4. And neither of these are the *same* as the=20 > data-plane networks which carry their=20 > control/management-plane protocols. So addressing (like=20 > routing) is not a single function spanning all layers. And I=20 > wish this was better understood because I think too many=20 > folks still believe there is a 'common control-plane' running=20 > from IP to Optics.....there can't be, it makes neither=20 > technical nor commercial sense >=20 > MPLS is an odd-ball here as a layer network, but I don't > really want to get into the nuances of the wrapper here=20 > (though its a fairly serious problem IMO and also lies at the=20 > heart of many other problems). >=20 > However, let me point this out. We should never have created > this PW layer network in the 1st place. cl-ps(eg IP)!=3D=20 > co-ps(eg MPLS) !=3D co-cs (eg GMPLS) and that is just a fact. =20 > I know the history of arch violations/errors why we have=20 > arrived here and quite frankly its a mess....just looking at=20 > the stuff regarding the VCCV breakout group tells you=20 > something is very seriously wrong here. However, having=20 > created this unnecessary layer network then yes addressing=20 > will have to be defined for it...and every other functional=20 > component that a layer network requires will also have to be added. > >=20 > > If so, it would mean major changes to RSVP-TE which only > > supports ipv4=20 > > and ipv6 addressing right now. > NH=3D> What do you want me to say?.....perhaps something like, > 'well done for yet another major error'? I remember when I=20 > saw these 'addresses' being originally cooked-up saying to=20 > myself.....this is going to create a serious problem=20 > downstream. Addressing is one thing you should pay great=20 > attention to at t=3D0....if you screw it up you are stuck with=20 > it for a very long time. But hey, this stuff is built on a=20 > whole pile of compounded mistakes so why just pick on this=20 > one? If you really want to fix thing you are going to have=20 > to go back quite a long way. It may simply not be worth it=20 > now and perhaps folks should think of other ways to address=20 > (no pun intended) this client/server service issue. >=20 > regards, Neil > >=20 > > Luca > >=20 > >=20 > > neil.2.harrison@bt.com wrote: > > > JL wrote 04 August 2005 10:08 > > >=20 > > >> Hi Luca > > >> > > >> Please see inline, > > >> > > >>> -----Message d'origine----- > > >>> De : Luca Martini [mailto:lmartini@cisco.com] > > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > > >> regarding PCE. > > >>> > > >>> > > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > > >>>> Hi Luca, > > >>>> > > >>>>> We will need PCE to produce the computed path , which > > >>> could then be > > >>>>> signaled by either RSVP or LDP. > > >>>> I'm really curious to know how LDP will be used to signal > > >>> an explicit path computed by the PCE... > > >>>> CR-LDP??? > > >>>> > > >>> Not quite. Some kind of explicit PW route object containing some = > > >>> addressing ( probably not IP ) does not turn LDP into > > CR-LDP. We are > > >>> also still using DU mode not DOD. > > >> Why not taking leverage of the RSVP-TE explicit routing > machinery, > > >> including inter-domain procedures, instead of introducing > > significant > > >> changes to LDP? Frankly speaking I don't really see why > we should > > >> choose between LDP and RSVP-TE for MH PW sig, why not > progressing > > >> both approaches? When explicit routing is not required > > then use LDP, > > >> and if explicit routing is required use RSVP-TE. This is > > what we are > > >> doing today for LSP signaling by the way... > > >> > > >> Best Regards, > > >> > > >> JL > > > NH=3D> I largely agree. A signalling protocol is a signalling > > > protocol....in other words you really only need one of them for=20 > > > providing this function. Why an operator would wish to run=20 > > multiple > > > types of the same functional component seems unclear. A 1 > > hop trail > > > is a degenerate case, ie its not a networked > entity......but IMO it > > > would seem rather silly just to have a different signalling > > protocol > > > for this special case, one may as well use the one that > applies for > > > the general case. Minimising functional components should > > also help > > > minimise costs, at least as a general rule. The other nice thing > > > about using the GMPLS developed spin of RSVP-TE is that it=20 > > can be used > > > OOB....and that has to be a good thing for > > security/stability design > > > considerations (though I am well aware MPLS has not been > > designed like > > > this, and that in GMPLS the co-cs mode forces good design > practice > > > anyway). > > >=20 > > > regards, Neil > > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 05 05:55:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0yvX-000065-OP; Fri, 05 Aug 2005 05:55:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0yvU-00005u-Pm for pce@megatron.ietf.org; Fri, 05 Aug 2005 05:55:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29852 for ; Fri, 5 Aug 2005 05:55:37 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0zSW-0001rx-9P for pce@ietf.org; Fri, 05 Aug 2005 06:29:51 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 11:54:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Aug 2005 11:54:28 +0200 Message-ID: Thread-Topic: comments to draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWYBRIKj47z72hoRPaCjK/bQmFD6gBnCDyA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Andrew Dolganow" X-OriginalArrivalTime: 05 Aug 2005 09:54:33.0906 (UTC) FILETIME=[AEAA9120:01C599A3] X-Spam-Score: 0.6 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: pce@ietf.org Subject: [Pce] RE: comments to draft-ietf-pce-discovery-reqs-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: , Content-Type: multipart/mixed; boundary="===============1806129927==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1806129927== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C599A3.AA0608AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C599A3.AA0608AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Thanks a lot for these valuable comments. =20 Please see inline, ________________________________ De : Andrew Dolganow [mailto:andrew.dolganow@alcatel.com]=20 Envoy=E9 : mercredi 3 ao=FBt 2005 10:27 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : comments to draft-ietf-pce-discovery-reqs-01.txt=20 =09 =09 Jean Louis et al, =20 Here is few comments/questions to the draft I have: =20 1. Section 6.1: =20 Propose to change the first paragraph (for clarity) with: The PCE discovery mechanism MUST allow disclosing mandatory, PCE = information that will allow PCCs to select appropriate PCEs. The PCE = discovery mechanism MAY allow disclosing optional , as defined below PCE = information that will allow PCCs to select appropriate PCEs.=20 [JLLR] Agreed, we will clarify as per your proposal=20 2. Section 6.4.1 The draft states that a PCE should advertise alternate PCEs. If that's = the case, do you expect those other PCEs to also advertise themselves? = If yes (which I expect) then we should add for clarity at the end of = that section something like ( is required to allow PCCs to select a Main = PCE over an alternate even if the alternate PCE is discovered first by a = PCC. ): =09 The alternate PCEs MUST advertise the main PCE(s) for which they = alternate.=20 =20 [JLLR] OK, we will clarify =20 We could also add a role (Main, alternate) in capabilities summary = section earlier on. [JLLR] Not sure that this can be considered as a capability=20 =20 3 Section 6.3 The section states in the first paragraph that a PCE MUST allow = detection of a change of any information advertised to a PCC = (capabilities). Why is this a MUST, if advertising of capabilities is a = MAY in section 6.1 above? [JLLR]=20 The PCE MUST allow detection of a change of any disclosed PCE = information. This comprises mandatory information and also optional = information that may be disclosed... that is, if the PCE discovery is used so as to disclose optional info = then it MUST allow detecting a change of this optional info... For clarity we should probably add qualification that If a PCE supports = advertising of capabilities, then it MUST allow detection. Here is a = proposed new text: =09 Iff a PCE supports advertising of optional information, then the PCE = discovery mechanism MUST allow a PCC to detect any change in the = information related to a PCE (e.g. capability modifications).=20 [JLLR] OK, we are in sync, this is inline with my above comment =20 We will clarify as per your suggestion 4. Section 6.5 I would like to propose that detection of congestion would happen as = part of PCE-PCC communication protocol.=20 [JLLR] Yes, but one could argue that a PCC may want to be aware of a = PCE congestion even in the absence of a PCC-PCE communication session. = this may be useful with the per-request session mode, if adopted in PCEP = (see also session on required feedback in PCEP) For simplicity we may have a reactive mode (i.e. a failure to a = computation request to a PCC due to congestion would include for example = a time value required for that PCC to back-off before sending a next = request to a given PCE). If we would need something more proactive, then = we could add that in protocol draft and not in here. [JLLR] One may want to be proactive, so as to minimize path computation = service disruption...=20 Again thanks a lot Andrew for these useful comments Best Regards, JL =20 Regards, Andrew=20 =20 ------_=_NextPart_001_01C599A3.AA0608AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Andrew,
 
Thanks a lot for these valuable=20 comments.
 
Please see inline,

De : Andrew Dolganow=20 [mailto:andrew.dolganow@alcatel.com]
Envoy=E9 : = mercredi 3 ao=FBt=20 2005 10:27
=C0 : LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org
Objet : = comments=20 to draft-ietf-pce-discovery-reqs-01.txt

Jean = Louis et=20 al,
 
Here = is few=20 comments/questions to the draft I have:
 
1. = Section=20 6.1:
 
Propose to change=20 the first paragraph (for clarity) with:

The PCE discovery mechanism MUST allow=20 disclosing mandatory, PCE information that will allow PCCs to = select=20 appropriate PCEs. The PCE discovery mechanism MAY = allow=20 disclosing optional , as defined below PCE information that will allow = PCCs to=20 select appropriate PCEs.
[JLLR] Agreed, we will clarify as per your=20 proposal 

2. = Section=20 6.4.1

The draft=20 states that a PCE should advertise alternate PCEs. If that's the case, = do you=20 expect those other PCEs to also advertise themselves? If yes (which I = expect)=20 then we should add for clarity at the end of that section something = like=20 ( is required = to allow PCCs=20 to select a Main PCE over an alternate even if the alternate PCE is = discovered=20 first by a PCC. ):

The alternate PCEs MUST advertise the main = PCE(s) for=20 which they = alternate. 
 
[JLLR] OK, we will=20 = clarify  

We could also=20 add a role (Main, alternate) in capabilities summary section earlier=20 on.
[JLLR] Not sure=20 that this can be considered as a = capability 
  

3 = Section=20 6.3

The section=20 states in the first paragraph that a PCE MUST allow detection of a = change of=20 any information advertised to a PCC (capabilities). Why is this a = MUST, if=20 advertising of capabilities is a MAY in section 6.1 above?
[JLLR] 

The PCE MUST allow=20 detection of a change of any disclosed PCE information. = This comprises mandatory information and also optional=20 information that may be=20 disclosed...

that is, if the PCE = discovery is=20 used so as to disclose optional info then it=20 MUST allow detecting a change of this optional=20 info...

For = clarity we=20 should probably add qualification that If a PCE supports advertising = of=20 capabilities, then it MUST allow detection. Here is a proposed = new=20 text:

Iff a=20 PCE supports advertising of optional information, then = the PCE=20 discovery mechanism MUST allow a PCC to detect any change in the = information=20 related to a PCE (e.g. capability modifications).
[JLLR] OK, we are in sync, = this is=20 inline with my above=20 comment  

We will clarify as per your=20 suggestion

4. Section 6.5

I would like to propose that detection of = congestion=20 would happen as part of PCE-PCC communication protocol.
[JLLR] Yes, but = one could=20 argue that a PCC may want to be aware of a PCE congestion even in = the=20 absence of a PCC-PCE communication session. this may be useful = with the=20 per-request session mode, if adopted in PCEP (see also session on = required feedback in PCEP)

  For simplicity we may have a = reactive=20 mode (i.e. a failure to a computation request to a PCC due to = congestion would=20 include for example a time value required for that PCC to = back-off before=20 sending a next request to a given PCE). If we would need something = more=20 proactive, then we could add that in protocol draft and not in = here.
[JLLR] One may want=20 to be proactive, so as to minimize path computation service=20 = disruption... 

Again=20 thanks a lot Andrew for these useful=20 comments

Best=20 Regards,

JL

&nbs= p;

Regards,

Andrew

 

= ------_=_NextPart_001_01C599A3.AA0608AD-- --===============1806129927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1806129927==-- From pce-bounces@lists.ietf.org Fri Aug 05 06:16:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zDc-0004ZM-Ot; Fri, 05 Aug 2005 06:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zDZ-0004ZH-Vo for pce@megatron.ietf.org; Fri, 05 Aug 2005 06:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00550 for ; Fri, 5 Aug 2005 06:14:19 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0zkc-0002KI-Ff for pce@ietf.org; Fri, 05 Aug 2005 06:48:32 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 12:14:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] About the presentation ofdraft-zhang-pce-comm-app-model-01.txt Date: Fri, 5 Aug 2005 12:14:20 +0200 Message-ID: Thread-Topic: [Pce] About the presentation ofdraft-zhang-pce-comm-app-model-01.txt Thread-Index: AcWYMdu2rwSnrk23QPS7sZa/aO94GgBcg12g From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" , X-OriginalArrivalTime: 05 Aug 2005 10:14:17.0913 (UTC) FILETIME=[7063B290:01C599A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Zhang Please see inline=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Zhang Renhai > Envoy=E9 : mercredi 3 ao=FBt 2005 15:28 > =C0 : pce@ietf.org > Objet : [Pce] About the presentation=20 > ofdraft-zhang-pce-comm-app-model-01.txt >=20 > Hi, all > =20 > Sorry for not all clear about some questions asked to me at=20 > the meeting. > I really appreciate that someone can repeat the question and=20 > we can discuss more here. Sure, here it is: The problem you raise is valuable, race condition issues will increase = in case of distributed-PCE computation with external PCEs, as the delay = between path computation and path setup will increase. But I have some = scalability concerns with your proposed solution: Basically one = objective of PCE distribution would be to reduce the number of requests = to be handled by PCEs, as this could be the bottleneck, and here = actually your proposal requires sending requests to all PCEs. Hence all = PCEs will support the whole PCCs' requests load. IMHO this may significantly disminish the benefits of PCE distribution. Anyway thanks for higlighting this problem, and for initiating = discussion.=20 Regards, JL >=20 > Actually, what I proposed surely is just applied to some=20 > kind of circumstances. For example, if three PCEs are serving=20 > all requests in a domain, and these PCEs are coupled closely,=20 > for instance, they may be located in different box but in the=20 > same tank or room, or located in different place remote to=20 > each other and connected by a high speed line, so based on my=20 > proposal, even only one request is sent to one of these PCE,=20 > and the PCE can forward the request to other two PCEs quickly=20 > to make the two PCEs maintain the request table,and this=20 > delation of transmittion may be ignoed by some tradeoff. > The essential goal of the draft is just to use the table to=20 > solve some known question. > I don't know how the communication for the detailed=20 > discovery will be because the detailed capability is still=20 > not specified now, how complicated a detailed capability=20 > could be for a special request? Can a tradeoff be made=20 > between below two choice for some special application: > =20 > -saving the detailed discovery communication,=20 > correspondingly sending=20 > the same request to all PCEs(or just one of these PCEs=20 > like what I mentioned above) > -performing the detailed discovery communication for each PCC? >=20 > Certainly,this proposal is not intent to became part of the=20 > PCE communication protocol. >=20 > Another concern of this draft is to make the requests=20 > distributed to different PCE more *reasonable*, for example,=20 > three PCEs in a domain, PCE1, PCE2, PCE3, and now PCE3 is=20 > congested with too much requests or other reason, for the PCC=20 > originating the request, which PCE else should it choose?=20 > PCE1 or PCE2? what information should be used to help to=20 > select again more reasonable? Based on the Global Computing=20 > Table, the congesting PCE(PCE3) will know the number of=20 > requests that other PCE is now dealing with, although PCE1 and > PCE2 both are not congested now, based on the mentioned=20 > information, PCE3 can select other PCE with least number of=20 > requests and appropriate capability to make sure the PCC can=20 > get the computation result asap, and I think the time from=20 > sending request to receiving the computing result may be a=20 > important consideration for some application. >=20 > Cheers, > Zhang >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 05 07:09:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E104W-0008So-6G; Fri, 05 Aug 2005 07:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vos-0005vN-FS; Fri, 05 Aug 2005 02:36:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18240; Fri, 5 Aug 2005 02:36:36 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0wLt-0003kd-Vm; Fri, 05 Aug 2005 03:10:47 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j756ZKBm032332; Thu, 4 Aug 2005 23:35:21 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j756ZGG61924; Thu, 4 Aug 2005 23:35:16 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200508050635.j756ZGG61924@merlot.juniper.net> To: Luca Martini Subject: Re: [Pce] RE: [PWE3] Correction of my statement regarding PCE. In-Reply-To: Your message of "Thu, 04 Aug 2005 03:37:36 MDT." <42F1E1E0.1000505@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <87910.1123223716.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 04 Aug 2005 23:35:16 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 05 Aug 2005 07:08:54 -0400 Cc: pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Luca, > Neil, > = > Don't you think that having an appropriate addressing scheme for the = > multi segment PW is necessary ? > = > If so, it would mean major changes to RSVP-TE which only supports ipv4 = > and ipv6 addressing right now. Do you have some facts to support your claim wrt "major changes". Yakov. > = > Luca > = > = > neil.2.harrison@bt.com wrote: > > JL wrote 04 August 2005 10:08 > > = > >> Hi Luca > >> > >> Please see inline, > >> > >>> -----Message d'origine----- > >>> De : Luca Martini [mailto:lmartini@cisco.com] > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > >> regarding PCE. > >>> > >>> > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > >>>> Hi Luca, > >>>> > >>>>> We will need PCE to produce the computed path , which > >>> could then be > >>>>> signaled by either RSVP or LDP. > >>>> I'm really curious to know how LDP will be used to signal > >>> an explicit path computed by the PCE... > >>>> CR-LDP??? > >>>> > >>> Not quite. Some kind of explicit PW route object containing some = > >>> addressing ( probably not IP ) does not turn LDP into CR-LDP. We are= = > >>> also still using DU mode not DOD. > >> Why not taking leverage of the RSVP-TE explicit routing > >> machinery, including inter-domain procedures, instead of = > >> introducing significant changes to LDP? Frankly speaking I = > >> don't really see why we should choose between LDP and RSVP-TE = > >> for MH PW sig, why not progressing both approaches? When = > >> explicit routing is not required then use LDP, and if = > >> explicit routing is required use RSVP-TE. This is what we are = > >> doing today for LSP signaling by the way... > >> > >> Best Regards, > >> > >> JL > > NH=3D> I largely agree. A signalling protocol is a signalling protocol= ....in = other words you really only need one of them for providing this function. = Why = an operator would wish to run multiple types of the same functional compon= ent s eems unclear. A 1 hop trail is a degenerate case, ie its not a networked = entit y......but IMO it would seem rather silly just to have a different signall= ing p rotocol for this special case, one may as well use the one that applies fo= r the general case. Minimising functional components should also help minimise= cost s, at least as a general rule. The other nice thing about using the GMPLS= deve loped spin of RSVP-TE is that it can be used OOB....and that has to be a g= ood t hing for security/stability design considerations (though I am well aware = MPLS = has not been designed like this, and that in GMPLS the co-cs mode forces g= ood d esign practice anyway). > > = > > regards, Neil > > = > = > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > = _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 05 10:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13FZ-0006FQ-V2; Fri, 05 Aug 2005 10:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13FX-0006Er-9e; Fri, 05 Aug 2005 10:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14025; Fri, 5 Aug 2005 10:32:36 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13md-0000ii-Me; Fri, 05 Aug 2005 11:06:52 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 15:32:24 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 15:32:24 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Fri, 5 Aug 2005 15:32:23 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1EA7@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWZh9u1opUiVOhZQmi4fnulyApDpwAQhi8w To: , X-OriginalArrivalTime: 05 Aug 2005 14:32:24.0094 (UTC) FILETIME=[7EDF63E0:01C599CA] X-Spam-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, pwe3@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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Whilst waiting for Luca to respond to Yakov's question I'd like to = expand a little more on what I see are key operator requirements here = and why the current PWE3 direction is really not addressing these. The most important private service for a operator is a network builder = capability. This is, at essence, a client/server relationship where the = client and server layers are functionally decoupled and need to be = because they are owned/operated by 2 different parties. All other = 'value-add' services (such as a rfc2547 VPN say) should be able to build = on this.....or putting this another way, a network builder capability = and rfc2547 should not be mutually exclusive stovepipe solutions. Now, let's look at GMPLS....this adds an OOB IP control-plane to the = co-cs traffic data-plane. And it's a great solution, because = fundamentally GMPLS provides a network builder capability. Note there = is no ambiguity about the traffic data-plane traffic units....IP pkts = (or other) can't suddenly 'materialise' here. And its got all the right = architectural behaviours in other respects too, ie no merging of trails, = no terminating trails in the wrong place, no trail QoS classes (and thus = no complex/worrying performance inheritance issues), true client/server = hierarchy (eg no wrapper), simple fault/traffic/performance management. However, as operators sun-set their old legacy technologies that = provided either a true co-cs network builder capability using nx64k, = E1/T1, etc, and also the facsimiles of these based on ATM and FR, a = serious problem is emerging....we need a co-ps solution for doing co-cs = at lower BW granularity (because ~140M VC4 is going to be the smallest = true co-cs mode technology operating under a GMPLS control-plane). Sadly, MPLS as-is can't step up to this role as it breaks the = client/server decoupling rule, ie clients of MPLS are treated quite = differently if they are IP, MPLS or 'other'. Indeed, a whole new = unnecessary layer network (seems almost like a new industry now!) has = sprung up from this....it's called PWs.....and it's unfortunately = generating a huge amount of erroneous/wasted effort. You don't see any = PWs in GMPLS do you?! And this can carry IP, ethernet, ATM, FR, = etc....anything in fact. And we need exactly the same behaviour from = MPLS....and most critically we need a co-ps_CBR behaviour. I don't have the exact figures to hand, but we have a large and = non-diminishing (growing in fact) customer requirement for this type of = network builder service. Further, its not just end-system = customers....other operators (including ourselves) need this capability = when we extend our networks and don't own the lower layer networks. So = please don't think this is something I'm pushing just for the sake of = it....its a real and important service requirement.=20 We are not the only organisation to spot this issue. 3 parties had = proposals into the last SG15 meeting suggesting 'transport MPLS' should = be developed. This is not some new protocol, it's just careful = selection from the MPLS parts-bin....and it looks a bit like this: - p2p and p2mp trail data-plane constructs only...so no merging (ie no = LDP and PHP) and no stopping the trail 1-hop too short (ie no PHP) - consistent simple OAM irrespective of the client.....Y.1711 is ideal = for the 'always-on' fault-management bits, but if you want to go and = replicate this functionality some other way for the fun of it then fine. = LSP-Ping would now be very simple here and useful for 'on-demand' = diagnostics, eg trail tracing. - given there are no 'misordering problems' in a properly done co = network (like GMPLS say) there is no need for the TTL field.....so we = could use that in more useful ways, eg having 1 bit for traffic or OAM = payload indicate would be rather useful IMO - folks could tinker with lots of QoS/traffic classes if they liked, but = a simple CBR behaviour is the most important (esp when selling a network = builder capability to a customer and then wanting to manage it very = simply). - we could copy the GMPLS model of using v4 addressing of the LSP trail = access points (though I do think v6 should be considered as it is its = own layer network), and run OSPF and RSVP-TE in an OOB control-plane. = Which also solves many security/stability concerns. You could use the = rather bizarre AGI/TAII/SAII addressing that was concocted for 'L2VPNs' = (sic), but why bother?...we don't need to create a new 'PW layer = network' any more so its not required....just copy the GMPLS model. And that's basically it. Now I would be very interested to hear from = any other operators or vendors (esp) who might be interested in working = on this with us. One major vendor is already the editor for this work = in SG15. I can't see any good technical reason not to do this. Folks = who don't fancy this can of course carry on with the current PW stuff. regards, Neil > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net]=20 > Sent: 05 August 2005 07:35 > To: Luca Martini > Cc: Harrison,N,Neil,JRD1 R; pwe3@ietf.org; pce@ietf.org > Subject: Re: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE.=20 >=20 >=20 > Luca, >=20 > > Neil, > >=20 > > Don't you think that having an appropriate addressing scheme for the > > multi segment PW is necessary ? > >=20 > > If so, it would mean major changes to RSVP-TE which only=20 > supports ipv4 > > and ipv6 addressing right now. >=20 > Do you have some facts to support your claim wrt "major changes". >=20 > Yakov. >=20 > >=20 > > Luca > >=20 > >=20 > > neil.2.harrison@bt.com wrote: > > > JL wrote 04 August 2005 10:08 > > >=20 > > >> Hi Luca > > >> > > >> Please see inline, > > >> > > >>> -----Message d'origine----- > > >>> De : Luca Martini [mailto:lmartini@cisco.com] > > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > > >> regarding PCE. > > >>> > > >>> > > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > > >>>> Hi Luca, > > >>>> > > >>>>> We will need PCE to produce the computed path , which > > >>> could then be > > >>>>> signaled by either RSVP or LDP. > > >>>> I'm really curious to know how LDP will be used to signal > > >>> an explicit path computed by the PCE... > > >>>> CR-LDP??? > > >>>> > > >>> Not quite. Some kind of explicit PW route object containing some > > >>> addressing ( probably not IP ) does not turn LDP into=20 > CR-LDP. We are=20 > > >>> also still using DU mode not DOD. > > >> Why not taking leverage of the RSVP-TE explicit routing=20 > machinery,=20 > > >> including inter-domain procedures, instead of introducing=20 > > >> significant changes to LDP? Frankly speaking I don't=20 > really see why=20 > > >> we should choose between LDP and RSVP-TE for MH PW sig, why not=20 > > >> progressing both approaches? When explicit routing is=20 > not required=20 > > >> then use LDP, and if explicit routing is required use=20 > RSVP-TE. This=20 > > >> is what we are doing today for LSP signaling by the way... > > >> > > >> Best Regards, > > >> > > >> JL > > > NH=3D> I largely agree. A signalling protocol is a signalling=20 > > > protocol....in > other words you really only need one of them for providing=20 > this function. Why=20 > an operator would wish to run multiple types of the same=20 > functional component s eems unclear. A 1 hop trail is a=20 > degenerate case, ie its not a networked entit y......but IMO=20 > it would seem rather silly just to have a different=20 > signalling p rotocol for this special case, one may as well=20 > use the one that applies for the general case. Minimising=20 > functional components should also help minimise cost s, at=20 > least as a general rule. The other nice thing about using=20 > the GMPLS deve loped spin of RSVP-TE is that it can be used=20 > OOB....and that has to be a good t hing for=20 > security/stability design considerations (though I am well aware MPLS=20 > has not been designed like this, and that in GMPLS the co-cs=20 > mode forces good d esign practice anyway). > > >=20 > > > regards, Neil > > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 05 11:27:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E146M-0002Ng-JC; Fri, 05 Aug 2005 11:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E146K-0002NQ-Lm; Fri, 05 Aug 2005 11:27:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16479; Fri, 5 Aug 2005 11:27:09 -0400 (EDT) From: neil.2.harrison@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E14dR-00029D-IQ; Fri, 05 Aug 2005 12:01:26 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 16:26:57 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 16:26:57 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Date: Fri, 5 Aug 2005 16:26:57 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1EA9@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [Pce] RE: [PWE3] Correction of my statement regarding PCE. Thread-Index: AcWZh9u1opUiVOhZQmi4fnulyApDpwAQhi8wAAIDnhA= To: , X-OriginalArrivalTime: 05 Aug 2005 15:26:57.0541 (UTC) FILETIME=[1DFFC350:01C599D2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Note - Just 1 slight clarification which is not in what I wrote = below.....if we wanted to keep LSP-Ping as-is we would need to keep the = TTL field of course. I can actually think of other ways to do tracing = without this.....but I'll leave that as an aside for now. regards, neil > -----Original Message----- > From: pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] On Behalf Of=20 > neil.2.harrison@bt.com > Sent: 05 August 2005 15:32 > To: yakov@juniper.net; lmartini@cisco.com > Cc: pce@ietf.org; pwe3@ietf.org > Subject: RE: [Pce] RE: [PWE3] Correction of my statement=20 > regarding PCE.=20 >=20 >=20 > Whilst waiting for Luca to respond to Yakov's question I'd=20 > like to expand a little more on what I see are key operator=20 > requirements here and why the current PWE3 direction is=20 > really not addressing these. >=20 > The most important private service for a operator is a=20 > network builder capability. This is, at essence, a=20 > client/server relationship where the client and server layers=20 > are functionally decoupled and need to be because they are=20 > owned/operated by 2 different parties. All other 'value-add'=20 > services (such as a rfc2547 VPN say) should be able to build=20 > on this.....or putting this another way, a network builder=20 > capability and rfc2547 should not be mutually exclusive=20 > stovepipe solutions. >=20 > Now, let's look at GMPLS....this adds an OOB IP control-plane=20 > to the co-cs traffic data-plane. And it's a great solution,=20 > because fundamentally GMPLS provides a network builder=20 > capability. Note there is no ambiguity about the traffic=20 > data-plane traffic units....IP pkts (or other) can't suddenly=20 > 'materialise' here. And its got all the right architectural=20 > behaviours in other respects too, ie no merging of trails, no=20 > terminating trails in the wrong place, no trail QoS classes=20 > (and thus no complex/worrying performance inheritance=20 > issues), true client/server hierarchy (eg no wrapper), simple=20 > fault/traffic/performance management. >=20 > However, as operators sun-set their old legacy technologies=20 > that provided either a true co-cs network builder capability=20 > using nx64k, E1/T1, etc, and also the facsimiles of these=20 > based on ATM and FR, a serious problem is emerging....we need=20 > a co-ps solution for doing co-cs at lower BW granularity=20 > (because ~140M VC4 is going to be the smallest true co-cs=20 > mode technology operating under a GMPLS control-plane). >=20 > Sadly, MPLS as-is can't step up to this role as it breaks the=20 > client/server decoupling rule, ie clients of MPLS are treated=20 > quite differently if they are IP, MPLS or 'other'. Indeed, a=20 > whole new unnecessary layer network (seems almost like a new=20 > industry now!) has sprung up from this....it's called=20 > PWs.....and it's unfortunately generating a huge amount of=20 > erroneous/wasted effort. You don't see any PWs in GMPLS do=20 > you?! And this can carry IP, ethernet, ATM, FR,=20 > etc....anything in fact. And we need exactly the same=20 > behaviour from MPLS....and most critically we need a=20 > co-ps_CBR behaviour. >=20 > I don't have the exact figures to hand, but we have a large=20 > and non-diminishing (growing in fact) customer requirement=20 > for this type of network builder service. Further, its not=20 > just end-system customers....other operators (including=20 > ourselves) need this capability when we extend our networks=20 > and don't own the lower layer networks. So please don't=20 > think this is something I'm pushing just for the sake of=20 > it....its a real and important service requirement.=20 >=20 > We are not the only organisation to spot this issue. 3=20 > parties had proposals into the last SG15 meeting suggesting=20 > 'transport MPLS' should be developed. This is not some new=20 > protocol, it's just careful selection from the MPLS=20 > parts-bin....and it looks a bit like this: > - p2p and p2mp trail data-plane constructs only...so no=20 > merging (ie no LDP and PHP) and no stopping the trail 1-hop=20 > too short (ie no PHP) > - consistent simple OAM irrespective of the=20 > client.....Y.1711 is ideal for the 'always-on'=20 > fault-management bits, but if you want to go and replicate=20 > this functionality some other way for the fun of it then=20 > fine. LSP-Ping would now be very simple here and useful for=20 > 'on-demand' diagnostics, eg trail tracing. > - given there are no 'misordering problems' in a properly=20 > done co network (like GMPLS say) there is no need for the TTL=20 > field.....so we could use that in more useful ways, eg having=20 > 1 bit for traffic or OAM payload indicate would be rather useful IMO > - folks could tinker with lots of QoS/traffic classes if=20 > they liked, but a simple CBR behaviour is the most important=20 > (esp when selling a network builder capability to a customer=20 > and then wanting to manage it very simply). > - we could copy the GMPLS model of using v4 addressing of=20 > the LSP trail access points (though I do think v6 should be=20 > considered as it is its own layer network), and run OSPF and=20 > RSVP-TE in an OOB control-plane. Which also solves many=20 > security/stability concerns. You could use the rather=20 > bizarre AGI/TAII/SAII addressing that was concocted for=20 > 'L2VPNs' (sic), but why bother?...we don't need to create a=20 > new 'PW layer network' any more so its not required....just=20 > copy the GMPLS model. >=20 > And that's basically it. Now I would be very interested to=20 > hear from any other operators or vendors (esp) who might be=20 > interested in working on this with us. One major vendor is=20 > already the editor for this work in SG15. I can't see any=20 > good technical reason not to do this. Folks who don't fancy=20 > this can of course carry on with the current PW stuff. >=20 > regards, Neil >=20 > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: 05 August 2005 07:35 > > To: Luca Martini > > Cc: Harrison,N,Neil,JRD1 R; pwe3@ietf.org; pce@ietf.org > > Subject: Re: [Pce] RE: [PWE3] Correction of my statement=20 > > regarding PCE.=20 > >=20 > >=20 > > Luca, > >=20 > > > Neil, > > >=20 > > > Don't you think that having an appropriate addressing=20 > scheme for the=20 > > > multi segment PW is necessary ? > > >=20 > > > If so, it would mean major changes to RSVP-TE which only > > supports ipv4 > > > and ipv6 addressing right now. > >=20 > > Do you have some facts to support your claim wrt "major changes". > >=20 > > Yakov. > >=20 > > >=20 > > > Luca > > >=20 > > >=20 > > > neil.2.harrison@bt.com wrote: > > > > JL wrote 04 August 2005 10:08 > > > >=20 > > > >> Hi Luca > > > >> > > > >> Please see inline, > > > >> > > > >>> -----Message d'origine----- > > > >>> De : Luca Martini [mailto:lmartini@cisco.com] > > > >>> Envoy=E9 : mercredi 3 ao=FBt 2005 09:34 > > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > > >>> Cc : Don Fedyk; pwe3; pce@ietf.org > > > >>> Objet : Re: [Pce] RE: [PWE3] Correction of my statement > > > >> regarding PCE. > > > >>> > > > >>> > > > >>> LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > >>>> Hi Luca, > > > >>>> > > > >>>>> We will need PCE to produce the computed path , which > > > >>> could then be > > > >>>>> signaled by either RSVP or LDP. > > > >>>> I'm really curious to know how LDP will be used to signal > > > >>> an explicit path computed by the PCE... > > > >>>> CR-LDP??? > > > >>>> > > > >>> Not quite. Some kind of explicit PW route object=20 > containing some=20 > > > >>> addressing ( probably not IP ) does not turn LDP into > > CR-LDP. We are > > > >>> also still using DU mode not DOD. > > > >> Why not taking leverage of the RSVP-TE explicit routing > > machinery, > > > >> including inter-domain procedures, instead of introducing > > > >> significant changes to LDP? Frankly speaking I don't=20 > > really see why > > > >> we should choose between LDP and RSVP-TE for MH PW sig, why not > > > >> progressing both approaches? When explicit routing is=20 > > not required > > > >> then use LDP, and if explicit routing is required use > > RSVP-TE. This > > > >> is what we are doing today for LSP signaling by the way... > > > >> > > > >> Best Regards, > > > >> > > > >> JL > > > > NH=3D> I largely agree. A signalling protocol is a signalling > > > > protocol....in > > other words you really only need one of them for providing > > this function. Why=20 > > an operator would wish to run multiple types of the same=20 > > functional component s eems unclear. A 1 hop trail is a=20 > > degenerate case, ie its not a networked entit y......but IMO=20 > > it would seem rather silly just to have a different=20 > > signalling p rotocol for this special case, one may as well=20 > > use the one that applies for the general case. Minimising=20 > > functional components should also help minimise cost s, at=20 > > least as a general rule. The other nice thing about using=20 > > the GMPLS deve loped spin of RSVP-TE is that it can be used=20 > > OOB....and that has to be a good t hing for=20 > > security/stability design considerations (though I am well=20 > aware MPLS=20 > > has not been designed like this, and that in GMPLS the co-cs=20 > > mode forces good d esign practice anyway). > > > >=20 > > > > regards, Neil > > > >=20 > > >=20 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Aug 06 09:19:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OaJ-0007tQ-OE; Sat, 06 Aug 2005 09:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1OaH-0007tJ-DC for pce@megatron.ietf.org; Sat, 06 Aug 2005 09:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22311 for ; Sat, 6 Aug 2005 09:19:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1P7Z-0006mL-U8 for pce@ietf.org; Sat, 06 Aug 2005 09:53:54 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2005 06:19:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,172,1120460400"; d="scan'208,217"; a="4948643:sNHT55321560" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j76DJHQl021916; Sat, 6 Aug 2005 09:19:17 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 09:19:24 -0400 Received: from [192.168.1.102] ([10.86.242.212]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 09:19:34 -0400 In-Reply-To: <200508041009.j74A9WwK019363@tm1.ca.alcatel.com> References: <200508041009.j74A9WwK019363@tm1.ca.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: From: JP Vasseur Subject: Re: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Date: Fri, 5 Aug 2005 11:26:45 +0200 To: "Andrew Dolganow" X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 06 Aug 2005 13:19:34.0973 (UTC) FILETIME=[7D162ED0:01C59A89] X-Spam-Score: 0.9 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0765040025==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0765040025== Content-Type: multipart/alternative; boundary=Apple-Mail-5-1045401184 --Apple-Mail-5-1045401184 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On Aug 4, 2005, at 12:09 PM, Andrew Dolganow wrote: > JP, > > Please see below in bold font: > > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Thursday, August 04, 2005 5:43 AM > To: Andrew Dolganow > Cc: pce@ietf.org > Subject: Re: [Pce] Providing optimization metrics in addition to a > computed path in PCE responses > > Hi Andrew, > > On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote: > >> Hi, >> It would be highly desirable if a response to a PCE Request >> contained not only a computed path but also metrics that can be >> used in a selection of the most optimal path by either a PCE or >> PCC issuing the original request. > > The ability for the PCC to provide objective function which could > be used by the PCE for path selection is indeed listed as a > requirement in the generic PCE communication requirement ID. > >> For example a PCC (directly or through a PCE) issuing a request >> for a multi-hop PW may need to go to two independent PCEs to find >> a path from two border S-PEs towards destination. The PCC (PCE) >> would then take both responses and compare them with paths to >> reach each of the S-PEs it can compute. To find the optimal path, >> the PCC (PCE) needs info to allow such "optimal" path selection >> (like for example costs for the computed paths). > > Two comments: > 1) Indeed, the PCC may in some cases send the same requests to > multiple PCEs (this is one of the reasons why in PCEP for example > we introduced the ability for the PCC to cancel pending requests) > 2) Since the objective function will be provided by the PCC, it > should get comparable path costs. That said, note that this may > require synchronization between PCEs lying in different domains to > ensure metric consistency. > > Alternatively, the requesting PCC (PCE) would now the "mapping" it > needs to apply to both costs, but I agree that metric consistency > between PCEs would be a better solution. >> I would like to propose that the protocol requirements draft >> includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce- >> comm-protocol-gen-reqs-01.txt draft) that a Path Computation >> Response SHOULD allow return of metrics that can be used by a >> requesting entity to optimize a path. > > Clearly the PCC request will include the ability to specify the > objective function. Thus the computed path cost provided by the PCE > will be well-understood by the PCC. Are you referring to the > requirement for the PCE to provide the computed path cost ? > > That's exactly what I am looking for. In my example two PCEs > building partial paths need to provide back an optimization metric > in their Path Computation responses to allow the "original" PCC (or > a PCE acting for that PCC to build a complete path) to select the > optimal path using one of the partial paths computed by the two > PCEs. Unless Path Computation Response messages carry back such > metrics we won't be able to build an optimal path. > Absolutely. This is actually detailed in draft-vasseur-ccamp-inter- domain-path-comp-00.txt (expired), the plan being the resurrect scenario-2 at some point (scenario 1 is now draft-ietf-ccamp-inter- domain-pd-path-comp). That said, the required object in this case is slightly different since the cost from a set of entry boundary LSRs to the destination is needed. What I would suggest you is to produce a short ID specifying such object. It is worth having a separate object here (rather than defining the object in the PCE communication protocol) since it could be used to record cost of inter-domain TE LSP in a non PCE-context. Feel free to discuss it in the PCE WG *with* a review from CCAMP. Thanks. JP. > Andrew > > > Thanks. > > JP. > >> Andrew >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > --Apple-Mail-5-1045401184 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew,

On = Aug 4, 2005, at 12:09 PM, Andrew Dolganow wrote:

JP,
=A0
Please see below in bold = font:

From: JP Vasseur [mailto:jvasseur@cisco.com] =
Sent: Thursday, August 04, 2005 5:43 AM
To: Andrew = Dolganow
Cc: pce@ietf.org
Subject: Re: = [Pce] Providing optimization metrics in addition to a computed path in = PCE responses

Hi Andrew,

On Aug 4, 2005, at 11:16 AM, Andrew Dolganow = wrote:

=
Hi,
It would be = highly desirable if a response to a PCE Request contained not only a = computed path but also metrics that can be used in a selection of the = most optimal path by either a PCE or PCC issuing the original = request.

The = ability for the PCC to provide objective function which could be used by = the PCE for path selection is indeed listed as a requirement in the = generic PCE communication requirement ID.

For example = a PCC (directly or through a PCE) issuing a request for a multi-hop PW = may need to go to two independent PCEs to find a path from two border = S-PEs towards destination. The PCC (PCE) would then take both = responses and compare them with paths to reach each of the S-PEs it = can compute. To find the optimal path, the PCC (PCE) needs info to = allow such "optimal" path selection (like for example costs for the = computed paths).
=

Two = comments:
1) Indeed, the PCC may in some cases send the same = requests to multiple PCEs (this is one of the reasons why in PCEP for = example we introduced the ability for the PCC to cancel pending = requests)
2) Since the objective function will be provided by = the PCC, it should get comparable path costs. That said, note that this = may require synchronization between PCEs lying in different domains to = ensure metric consistency.
=A0
Alternatively, the requesting PCC = (PCE)=A0would now the "mapping" it needs to apply to both costs, but I = agree that metric consistency between PCEs would be a better = solution.=A0
=
I = would like to propose that the protocol requirements draft includes a = requirement (section 6 and 6.1.5 of the = draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) that a Path = Computation Response SHOULD allow return of metrics that can be used by = a requesting entity to optimize a = path.

=
Clearly the PCC request will include the ability to specify the = objective function. Thus the computed path cost provided by the PCE will = be well-understood by the PCC. Are you referring to the requirement for = the PCE to provide the computed path cost ?

That's exactly what I am looking for. In=A0my example = two PCEs building partial paths need to=A0provide back an optimization = metric in=A0their Path Computation responses to allow the "original" PCC = (or a PCE acting for that PCC to build a complete path) to select the = optimal path using one of the partial paths computed by the two PCEs. = Unless Path Computation Response messages carry back such metrics we = won't be able to build an optimal path.
=
=A0

Absolutely. This is = actually detailed in=A0draft-vasseur-ccamp-inter-domain-path-comp-00.txt = (expired), the plan being the resurrect scenario-2 at some point = (scenario 1 is now draft-ietf-ccamp-inter-domain-pd-path-comp). That = said, the required object in this case is slightly different since the = cost from a set of entry boundary LSRs to the destination is = needed.

What = I would suggest you is to produce a short ID specifying such object. It = is worth having a separate object here (rather than defining the object = in the PCE communication protocol) since it could be used to record cost = of inter-domain TE LSP in a non PCE-context. Feel free to discuss it in = the PCE WG *with* a review from CCAMP.

Thanks.

JP.

Andrew
=A0
=A0
=
Thanks.

=
JP.

=
Andrew
_______________________________________________
Pce mailing list
=


= --Apple-Mail-5-1045401184-- --===============0765040025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0765040025==-- From pce-bounces@lists.ietf.org Mon Aug 08 04:34:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E235G-0005t3-QH; Mon, 08 Aug 2005 04:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E235E-0005su-Ur for pce@megatron.ietf.org; Mon, 08 Aug 2005 04:34:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07594 for ; Mon, 8 Aug 2005 04:34:06 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E23ct-00008T-Ng for pce@ietf.org; Mon, 08 Aug 2005 05:08:56 -0400 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 <0IKW00E9YAS2YN@szxga02-in.huawei.com> for pce@ietf.org; Mon, 08 Aug 2005 16:40:50 +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 <0IKW00ICQAS14F@szxga02-in.huawei.com> for pce@ietf.org; Mon, 08 Aug 2005 16:40:49 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IKW00GFUARVF2@szxml02-in.huawei.com>; Mon, 08 Aug 2005 16:40:43 +0800 (CST) Date: Mon, 08 Aug 2005 16:10:07 +0800 From: Zhang Renhai Subject: Re: [Pce] About the presentation ofdraft-zhang-pce-comm-app-model-01.txt To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org Message-id: <00cc01c59bf0$96f01560$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 2.2 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785829598==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0785829598== Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 SGksIEplYW4gTG91aXMNCg0KICBOaWNlIHRvIHNlZSB5b3VyIHF1ZXN0aW9uIGFnYWluIGluIG1h aWxpbmcgbGlzdC4gUGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iIDxqZWFubG91 aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tPg0KVG86ICJaaGFuZyBSZW5oYWkiIDx6aGFuZ3Jl bmhhaUBodWF3ZWkuY29tPjsgPHBjZUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDA1 LCAyMDA1IDY6MTQgUE0NClN1YmplY3Q6IFJFOiBbUGNlXSBBYm91dCB0aGUgcHJlc2VudGF0aW9u IG9mZHJhZnQtemhhbmctcGNlLWNvbW0tYXBwLW1vZGVsLTAxLnR4dA0KDQoNCkhpIFpoYW5nDQoN ClBsZWFzZSBzZWUgaW5saW5lIA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZSA6IHBjZS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIA0KPiBbbWFpbHRvOnBjZS1ib3VuY2VzQGxp c3RzLmlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFpoYW5nIFJlbmhhaQ0KPiBFbnZveekgOiBtZXJj cmVkaSAzIGFv+3QgMjAwNSAxNToyOA0KPiDAIDogcGNlQGlldGYub3JnDQo+IE9iamV0IDogW1Bj ZV0gQWJvdXQgdGhlIHByZXNlbnRhdGlvbiANCj4gb2ZkcmFmdC16aGFuZy1wY2UtY29tbS1hcHAt bW9kZWwtMDEudHh0DQo+IA0KPiBIaSwgYWxsDQo+ICANCj4gIFNvcnJ5IGZvciBub3QgYWxsIGNs ZWFyIGFib3V0IHNvbWUgcXVlc3Rpb25zIGFza2VkIHRvIG1lIGF0IA0KPiB0aGUgbWVldGluZy4N Cj4gSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGF0IHNvbWVvbmUgY2FuIHJlcGVhdCB0aGUgcXVlc3Rp b24gYW5kIA0KPiB3ZSBjYW4gZGlzY3VzcyBtb3JlIGhlcmUuDQoNClN1cmUsIGhlcmUgaXQgaXM6 DQoNCkpMLT5UaGUgcHJvYmxlbSB5b3UgcmFpc2UgaXMgdmFsdWFibGUsIHJhY2UgY29uZGl0aW9u IGlzc3VlcyB3aWxsIGluY3JlYXNlIGluIGNhc2Ugb2YgZGlzdHJpYnV0ZWQtUENFIGNvbXB1dGF0 aW9uIHdpdGggZXh0ZXJuYWwgUENFcywgYXMgdGhlIGRlbGF5IGJldHdlZW4gcGF0aCBjb21wdXRh dGlvbiBhbmQgcGF0aCBzZXR1cCB3aWxsIGluY3JlYXNlLiBCdXQgSSBoYXZlIHNvbWUgc2NhbGFi aWxpdHkgY29uY2VybnMgd2l0aCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uOiBCYXNpY2FsbHkgb25l IG9iamVjdGl2ZSBvZiBQQ0UgZGlzdHJpYnV0aW9uIHdvdWxkIGJlIHRvIHJlZHVjZSB0aGUgbnVt YmVyIG9mIHJlcXVlc3RzIHRvIGJlIGhhbmRsZWQgYnkgUENFcywgYXMgdGhpcyBjb3VsZCBiZSB0 aGUgYm90dGxlbmVjaywgYW5kIGhlcmUgYWN0dWFsbHkgeW91ciBwcm9wb3NhbCByZXF1aXJlcyBz ZW5kaW5nIHJlcXVlc3RzIHRvIGFsbCBQQ0VzLiBIZW5jZSBhbGwgUENFcyB3aWxsIHN1cHBvcnQg dGhlIHdob2xlIFBDQ3MnIHJlcXVlc3RzIGxvYWQuDQoNClpSSC0tLS0+U2VuZGluZyByZXF1ZXN0 cyB0byBhbGwgUENFcyBpcyBhIG1ldGhvZCB0byBtYWtlIGl0IHBvc3NpYmxlIHRoYXQgZWFjaCBQ Q0UgY2FuIGtub3cgdGhlIGN1cnJlbnQgcmVzb3VyY2VzIGFwcGxpY2F0aW9uIHN0YXR1cywgYW5k IGFjY29yZGluZ2x5DQpjYW4gc29ydCBvcmRlciBmb3IgdGhlIHJlcXVlc3RzIHdoaWNoIG1heSBi ZSBjb21wdXRlZCBpbiBkaWZmZXJlbnQgUENFcywgZm9yIGV4YW1wbGUsIHJlcTEgYW5kIHJlcTIg YXJlIHNlbmQgcmVwZWN0aXZlbHkgdG8gUENFMSwgUENFMiwgYW5kIHJlcTEgaGFzDQphIGxvd2Vy IHByaW9yaXR5IHRoYW4gcmVxMiwgYnV0IGlmIFBDRTEgZG9lc24ndCBrbm93IHRoYXQgdGhlcmUg aXMgYW5vdGhlciByZXEgd2l0aCBhIGhpZ2hlciBwcmlvcml0eShyZXEyIGlzIHNlbnQgdG8gUENF MiksICBpdCBtYXkgdGFrZSB0aGUgcmVzb3VyY2UgdGhhdCByZXEyDQptYXkgYWxzbyBuZWVkIGFu ZCBvbmx5IHN1ZmZpY2Ugb25lIHJlcXVlc3QuIFRoZW4gd2hlbiBQQ0UyIGlzIGNvbXB1dGluZyB0 aGUgcGF0aCBmb3IgcmVxMiBsYXRlciwgd2hhdCBhYm91dCB0aGUgcmVzdWx0PyB0ZWFyZG93biB0 aGUgZmlyc3QgcGF0aCBjb21wdXRlZCANCmZvciByZXExPyBvciByZXBseSB0aGUgZmFpbHVyZSBv ZiB0aGUgY29tcHV0YXRpb24gZm9yIHJlcTI/DQpTbyBpZiBib3RoIHRoZSBQQ0UxIGFuZCBQQ0Uy IGtub3cgdGhlIGFsbCB0aGUgY3VycmVudCByZXF1ZXN0cywgYmFzZWQgb24gc29tZSBwb2xpY2ll cyBjb25maWd1cmVkIGJ5IG9wZXJhdG9yLCBQQ0UxIGNhbiBkZWxheSB0aGUgY29tcHV0YXRpb24g Zm9yIHJlcTEsDQp0byBnZXQgdGhlIGNvbXB1dGF0aW9uIG9yZGVybHkgYW5kIG1ha2Ugc3VyZSB0 aGUgcmVzb3VyY2VzIGRpc3RyaWJ1dGVkIHJlYXNvbmFibHkuDQoNCg0KSkwtPklNSE8gdGhpcyBt YXkgc2lnbmlmaWNhbnRseSBkaXNtaW5pc2ggdGhlIGJlbmVmaXRzIG9mIFBDRSBkaXN0cmlidXRp b24uDQoNClpSSC0tLT5FYWNoIFBDRSBrbm93aW5nIGFsbCB0aGUgcmVxdWVzdHMgZG9lc24ndCBt ZWFucyB0byBhZGQgdGhlIGxvYWQgb2YgY29tcHV0YXRpb24gdG8gZWFjaCBQQ0UsIGl0J3MganVz dCBnaXZlIGVhY2ggUENFIGVub3VnaCBpbmZvcm1hdGlvbiB0byBtYWtlIHRoZSBQQ0VzIHdvcmtp bmcgY29vcGVyYXRpdmVseS4gU2VlIHRoZSBleGFtcGxlIGFnYWluLCBQQ0UxIGtub3dzIHRoZXJl IGFyZSBiZWluZyB0d28gcmVxdWVzdHMgYnV0IG9ubHkgY29tcHV0ZXMgcmVxMSwgUENFMiBrbm93 cyB0aGVyZSBhcmUgYmVpbmcgdHdvIGJ1dCANCm9ubHkgY29tcHV0ZXMgcmVxMi4NCg0KVGhhbmtz IGFuZCBSZWdhcmRzLA0KWmhhbmcNCg0KDQoNCkpMLT5Bbnl3YXkgdGhhbmtzIGZvciBoaWdsaWdo dGluZyB0aGlzIHByb2JsZW0sIGFuZCBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9uLiANCg0KUmVn YXJkcywNCg0KSkwNCg0KDQo+IA0KPiAgQWN0dWFsbHksIHdoYXQgSSBwcm9wb3NlZCBzdXJlbHkg aXMganVzdCBhcHBsaWVkIHRvIHNvbWUgDQo+IGtpbmQgb2YgY2lyY3Vtc3RhbmNlcy4gRm9yIGV4 YW1wbGUsIGlmIHRocmVlIFBDRXMgYXJlIHNlcnZpbmcgDQo+IGFsbCByZXF1ZXN0cyBpbiBhIGRv bWFpbiwgYW5kIHRoZXNlIFBDRXMgYXJlIGNvdXBsZWQgY2xvc2VseSwgDQo+IGZvciBpbnN0YW5j ZSwgdGhleSBtYXkgYmUgbG9jYXRlZCBpbiBkaWZmZXJlbnQgYm94IGJ1dCBpbiB0aGUgDQo+IHNh bWUgdGFuayBvciByb29tLCBvciBsb2NhdGVkIGluIGRpZmZlcmVudCBwbGFjZSByZW1vdGUgdG8g DQo+IGVhY2ggb3RoZXIgYW5kIGNvbm5lY3RlZCBieSBhIGhpZ2ggc3BlZWQgbGluZSwgc28gYmFz ZWQgb24gbXkgDQo+IHByb3Bvc2FsLCBldmVuIG9ubHkgb25lIHJlcXVlc3QgaXMgc2VudCB0byBv bmUgb2YgdGhlc2UgUENFLCANCj4gYW5kIHRoZSBQQ0UgY2FuIGZvcndhcmQgdGhlIHJlcXVlc3Qg dG8gb3RoZXIgdHdvIFBDRXMgcXVpY2tseSANCj4gdG8gbWFrZSB0aGUgdHdvIFBDRXMgbWFpbnRh aW4gdGhlIHJlcXVlc3QgdGFibGUsYW5kIHRoaXMgDQo+IGRlbGF0aW9uIG9mIHRyYW5zbWl0dGlv biBtYXkgYmUgaWdub2VkICBieSBzb21lIHRyYWRlb2ZmLg0KPiBUaGUgZXNzZW50aWFsIGdvYWwg b2YgdGhlIGRyYWZ0IGlzIGp1c3QgdG8gdXNlIHRoZSB0YWJsZSB0byANCj4gc29sdmUgc29tZSBr bm93biBxdWVzdGlvbi4NCj4gIEkgZG9uJ3Qga25vdyBob3cgdGhlIGNvbW11bmljYXRpb24gZm9y IHRoZSBkZXRhaWxlZCANCj4gZGlzY292ZXJ5IHdpbGwgYmUgYmVjYXVzZSB0aGUgZGV0YWlsZWQg Y2FwYWJpbGl0eSBpcyBzdGlsbCANCj4gbm90IHNwZWNpZmllZCBub3csIGhvdyBjb21wbGljYXRl ZCBhIGRldGFpbGVkIGNhcGFiaWxpdHkgDQo+IGNvdWxkIGJlIGZvciBhIHNwZWNpYWwgcmVxdWVz dD8gQ2FuIGEgdHJhZGVvZmYgYmUgbWFkZSANCj4gYmV0d2VlbiBiZWxvdyB0d28gY2hvaWNlIGZv ciBzb21lIHNwZWNpYWwgYXBwbGljYXRpb246DQo+ICANCj4gICAtc2F2aW5nIHRoZSBkZXRhaWxl ZCBkaXNjb3ZlcnkgY29tbXVuaWNhdGlvbiwgDQo+IGNvcnJlc3BvbmRpbmdseSBzZW5kaW5nIA0K PiAgICB0aGUgc2FtZSByZXF1ZXN0IHRvIGFsbCBQQ0VzKG9yIGp1c3Qgb25lIG9mIHRoZXNlIFBD RXMgDQo+IGxpa2Ugd2hhdCBJIG1lbnRpb25lZCBhYm92ZSkNCj4gICAtcGVyZm9ybWluZyB0aGUg ZGV0YWlsZWQgZGlzY292ZXJ5IGNvbW11bmljYXRpb24gZm9yIGVhY2ggUENDPw0KPiANCj4gICBD ZXJ0YWlubHksdGhpcyBwcm9wb3NhbCBpcyBub3QgaW50ZW50IHRvIGJlY2FtZSBwYXJ0IG9mIHRo ZSANCj4gUENFIGNvbW11bmljYXRpb24gcHJvdG9jb2wuDQo+IA0KPiAgQW5vdGhlciBjb25jZXJu IG9mIHRoaXMgZHJhZnQgaXMgdG8gbWFrZSB0aGUgcmVxdWVzdHMgDQo+IGRpc3RyaWJ1dGVkIHRv IGRpZmZlcmVudCBQQ0UgbW9yZSAqcmVhc29uYWJsZSosIGZvciBleGFtcGxlLCANCj4gdGhyZWUg UENFcyBpbiBhIGRvbWFpbiwgUENFMSwgUENFMiwgUENFMywgYW5kIG5vdyBQQ0UzIGlzIA0KPiBj b25nZXN0ZWQgd2l0aCB0b28gbXVjaCByZXF1ZXN0cyBvciBvdGhlciByZWFzb24sIGZvciB0aGUg UENDIA0KPiBvcmlnaW5hdGluZyB0aGUgcmVxdWVzdCwgd2hpY2ggUENFIGVsc2Ugc2hvdWxkIGl0 IGNob29zZT8gDQo+IFBDRTEgb3IgUENFMj8gd2hhdCBpbmZvcm1hdGlvbiBzaG91bGQgYmUgdXNl ZCB0byBoZWxwIHRvIA0KPiBzZWxlY3QgYWdhaW4gbW9yZSByZWFzb25hYmxlPyBCYXNlZCBvbiB0 aGUgR2xvYmFsIENvbXB1dGluZyANCj4gVGFibGUsIHRoZSBjb25nZXN0aW5nIFBDRShQQ0UzKSB3 aWxsIGtub3cgdGhlIG51bWJlciBvZiANCj4gcmVxdWVzdHMgdGhhdCBvdGhlciBQQ0UgaXMgbm93 IGRlYWxpbmcgd2l0aCwgYWx0aG91Z2ggUENFMSBhbmQNCj4gUENFMiBib3RoIGFyZSBub3QgY29u Z2VzdGVkIG5vdywgYmFzZWQgb24gdGhlIG1lbnRpb25lZCANCj4gaW5mb3JtYXRpb24sIFBDRTMg Y2FuIHNlbGVjdCBvdGhlciBQQ0Ugd2l0aCBsZWFzdCBudW1iZXIgb2YgDQo+IHJlcXVlc3RzIGFu ZCBhcHByb3ByaWF0ZSBjYXBhYmlsaXR5IHRvIG1ha2Ugc3VyZSB0aGUgUENDIGNhbiANCj4gZ2V0 IHRoZSBjb21wdXRhdGlvbiByZXN1bHQgYXNhcCwgYW5kIEkgdGhpbmsgdGhlIHRpbWUgZnJvbSAN Cj4gc2VuZGluZyByZXF1ZXN0IHRvIHJlY2VpdmluZyB0aGUgY29tcHV0aW5nIHJlc3VsdCBtYXkg YmUgYSANCj4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24gZm9yIHNvbWUgYXBwbGljYXRpb24uDQo+ IA0KPiBDaGVlcnMsDQo+IFpoYW5nDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBjZSBtYWlsaW5nIGxpc3QNCj4gUGNlQGxp c3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj ZQ0KPg0K --===============0785829598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0785829598==-- From pce-bounces@lists.ietf.org Mon Aug 08 09:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27O5-0007Fp-JQ; Mon, 08 Aug 2005 09:09:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27O0-0007Fk-2Z for pce@megatron.ietf.org; Mon, 08 Aug 2005 09:09:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19443 for ; Mon, 8 Aug 2005 09:09:46 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm2.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27vh-0007T4-EZ for pce@ietf.org; Mon, 08 Aug 2005 09:44:38 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j78D7Ptv010990; Mon, 8 Aug 2005 09:07:26 -0400 (EDT) Message-Id: <200508081307.j78D7Ptv010990@tm2.ca.alcatel.com> From: "Andrew Dolganow" To: "'JP Vasseur'" Subject: RE: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Date: Mon, 8 Aug 2005 09:07:25 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcWaiXckqxg7spaiR6yARZacwmWXdwBkGC9A X-Spam-Score: 0.6 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404211962==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1404211962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C59BF8.9867C7A0" This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C59BF8.9867C7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit JP, Thanks for your explanation. Based on it and the some history you mention, I agree with you that this may call for a separate ID. Andrew _____ From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Friday, August 05, 2005 5:27 AM To: Andrew Dolganow Cc: pce@ietf.org Subject: Re: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Hi Andrew, On Aug 4, 2005, at 12:09 PM, Andrew Dolganow wrote: JP, Please see below in bold font: _____ From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Thursday, August 04, 2005 5:43 AM To: Andrew Dolganow Cc: pce@ietf.org Subject: Re: [Pce] Providing optimization metrics in addition to a computed path in PCE responses Hi Andrew, On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote: Hi, It would be highly desirable if a response to a PCE Request contained not only a computed path but also metrics that can be used in a selection of the most optimal path by either a PCE or PCC issuing the original request. The ability for the PCC to provide objective function which could be used by the PCE for path selection is indeed listed as a requirement in the generic PCE communication requirement ID. For example a PCC (directly or through a PCE) issuing a request for a multi-hop PW may need to go to two independent PCEs to find a path from two border S-PEs towards destination. The PCC (PCE) would then take both responses and compare them with paths to reach each of the S-PEs it can compute. To find the optimal path, the PCC (PCE) needs info to allow such "optimal" path selection (like for example costs for the computed paths). Two comments: 1) Indeed, the PCC may in some cases send the same requests to multiple PCEs (this is one of the reasons why in PCEP for example we introduced the ability for the PCC to cancel pending requests) 2) Since the objective function will be provided by the PCC, it should get comparable path costs. That said, note that this may require synchronization between PCEs lying in different domains to ensure metric consistency. Alternatively, the requesting PCC (PCE) would now the "mapping" it needs to apply to both costs, but I agree that metric consistency between PCEs would be a better solution. I would like to propose that the protocol requirements draft includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) that a Path Computation Response SHOULD allow return of metrics that can be used by a requesting entity to optimize a path. Clearly the PCC request will include the ability to specify the objective function. Thus the computed path cost provided by the PCE will be well-understood by the PCC. Are you referring to the requirement for the PCE to provide the computed path cost ? That's exactly what I am looking for. In my example two PCEs building partial paths need to provide back an optimization metric in their Path Computation responses to allow the "original" PCC (or a PCE acting for that PCC to build a complete path) to select the optimal path using one of the partial paths computed by the two PCEs. Unless Path Computation Response messages carry back such metrics we won't be able to build an optimal path. Absolutely. This is actually detailed in draft-vasseur-ccamp-inter-domain-path-comp-00.txt (expired), the plan being the resurrect scenario-2 at some point (scenario 1 is now draft-ietf-ccamp-inter-domain-pd-path-comp). That said, the required object in this case is slightly different since the cost from a set of entry boundary LSRs to the destination is needed. What I would suggest you is to produce a short ID specifying such object. It is worth having a separate object here (rather than defining the object in the PCE communication protocol) since it could be used to record cost of inter-domain TE LSP in a non PCE-context. Feel free to discuss it in the PCE WG *with* a review from CCAMP. Thanks. JP. Andrew Thanks. JP. Andrew _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0048_01C59BF8.9867C7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
JP,
 
Thanks for your explanation. Based on it and = the some=20 history you mention, I agree with you that this may call for a separate=20 ID.
 
Andrew

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: Friday, August 05, 2005 5:27 AM
To: Andrew=20 Dolganow
Cc: pce@ietf.org
Subject: Re: [Pce] = Providing=20 optimization metrics in addition to a computed path in PCE=20 responses

Hi Andrew,

On Aug 4, 2005, at 12:09 PM, Andrew Dolganow wrote:
JP,
Please see below in bold = font:

From: JP Vasseur [mailto:jvasseur@cisco.com]=20
Sent: Thursday, August 04, 2005 5:43 AM
To: = Andrew=20 Dolganow
Cc: pce@ietf.org
Subject: Re: = [Pce]=20 Providing optimization metrics in addition to a computed path in PCE=20 responses

Hi Andrew,=20

On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote:

Hi,
It = would be=20 highly desirable if a response to a PCE Request contained not only a = computed path but also metrics that can be used in a selection of = the most=20 optimal path by either a PCE or PCC issuing the original=20 request.
The ability for the PCC to provide objective function which could = be used=20 by the PCE for path selection is indeed listed as a requirement in the = generic=20 PCE communication requirement ID.

For example a=20 PCC (directly or through a PCE) issuing a request for a multi-hop PW = may=20 need to go to two independent PCEs to find a path from two border = S-PEs=20 towards destination. The PCC (PCE) would then take both responses = and=20 compare them with paths to reach each of the S-PEs it can compute. = To find=20 the optimal path, the PCC (PCE) needs info to allow such "optimal" = path=20 selection (like for example costs for the computed=20 paths).
Two comments:
1) Indeed, the PCC may in some cases send the same requests to = multiple=20 PCEs (this is one of the reasons why in PCEP for example we introduced = the=20 ability for the PCC to cancel pending requests)
2) Since the objective function will be provided by the PCC, it = should=20 get comparable path costs. That said, note that this may require=20 synchronization between PCEs lying in different domains to ensure = metric=20 consistency.
Alternatively, the = requesting PCC=20 (PCE) would now the "mapping" it needs to apply to both costs, but I = agree=20 that metric consistency between PCEs would be a better solution.=20
I = would like to=20 propose that the protocol requirements draft includes a requirement = (section=20 6 and 6.1.5 of the draft-ietf-pce-comm-protocol-gen-reqs-01.txt = draft) that=20 a Path Computation Response SHOULD allow return of metrics that can = be used=20 by a requesting entity to optimize a = path.

Clearly the PCC request will include the ability to specify the = objective=20 function. Thus the computed path cost provided by the PCE will be=20 well-understood by the PCC. Are you referring to the requirement for = the PCE=20 to provide the computed path cost ?

That's exactly what I am looking for. In = my example=20 two PCEs building partial paths need to provide back an optimization = metric in=20 their Path Computation responses to allow the "original" PCC (or a PCE = acting=20 for that PCC to build a complete path) to select the optimal path = using one of=20 the partial paths computed by the two PCEs. Unless Path Computation = Response=20 messages carry back such metrics we won't be able to build an optimal=20 path.

Absolutely. This is actually detailed in=20 draft-vasseur-ccamp-inter-domain-path-comp-00.txt (expired), the plan = being the=20 resurrect scenario-2 at some point (scenario 1 is now=20 draft-ietf-ccamp-inter-domain-pd-path-comp). That said, the required = object in=20 this case is slightly different since the cost from a set of entry = boundary LSRs=20 to the destination is needed.

What I would suggest you is to produce a short ID specifying such = object.=20 It is worth having a separate object here (rather than defining the = object in=20 the PCE communication protocol) since it could be used to record cost of = inter-domain TE LSP in a non PCE-context. Feel free to discuss it in the = PCE WG=20 *with* a review from CCAMP.

Thanks.

JP.

Andrew
Thanks.

JP.

Andrew=20
_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce


------=_NextPart_000_0048_01C59BF8.9867C7A0-- --===============1404211962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1404211962==-- From pce-bounces@lists.ietf.org Mon Aug 08 09:10:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27P9-0007LG-KA; Mon, 08 Aug 2005 09:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27P7-0007L7-GO for pce@megatron.ietf.org; Mon, 08 Aug 2005 09:10:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19471 for ; Mon, 8 Aug 2005 09:10:55 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27wp-0007V5-5G for pce@ietf.org; Mon, 08 Aug 2005 09:45:47 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j78DAjQb028476; Mon, 8 Aug 2005 09:10:45 -0400 (EDT) Message-Id: <200508081310.j78DAjQb028476@tm3.ca.alcatel.com> From: "Andrew Dolganow" To: "'LE ROUX Jean-Louis RD-CORE-LAN'" Date: Mon, 8 Aug 2005 09:10:44 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcWYBRIKj47z72hoRPaCjK/bQmFD6gBnCDyAAJ44CJA= X-Spam-Score: 0.6 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: pce@ietf.org Subject: [Pce] RE: comments to draft-ietf-pce-discovery-reqs-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: , Content-Type: multipart/mixed; boundary="===============1967887693==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1967887693== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C59BF9.0F45ECD0" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C59BF9.0F45ECD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jean-Louis, =20 I believe we are in synch functionally and the only thing we are = discussing what is the place to describe such proactive congestion mechanism. If = this ID will change into a session-control (which we could probably do considering content) than I agree with you that this should be here. A = more reactive way can then also be described in the protocol itself. =20 Andrew _____ =20 From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@francetelecom.com]=20 Sent: Friday, August 05, 2005 5:54 AM To: Andrew Dolganow Cc: pce@ietf.org Subject: RE: comments to draft-ietf-pce-discovery-reqs-01.txt Hi Andrew, =20 Thanks a lot for these valuable comments. =20 Please see inline, _____ =20 De : Andrew Dolganow [mailto:andrew.dolganow@alcatel.com]=20 Envoy=E9 : mercredi 3 ao=FBt 2005 10:27 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc : pce@ietf.org Objet : comments to draft-ietf-pce-discovery-reqs-01.txt=20 Jean Louis et al, =20 Here is few comments/questions to the draft I have: =20 1. Section 6.1: =20 Propose to change the first paragraph (for clarity) with: The PCE discovery mechanism MUST allow disclosing mandatory, PCE = information that will allow PCCs to select appropriate PCEs. The PCE discovery = mechanism MAY allow disclosing optional , as defined below PCE information that = will allow PCCs to select appropriate PCEs.=20 [JLLR] Agreed, we will clarify as per your proposal=20 2. Section 6.4.1 The draft states that a PCE should advertise alternate PCEs. If that's = the case, do you expect those other PCEs to also advertise themselves? If = yes (which I expect) then we should add for clarity at the end of that = section something like ( is required to allow PCCs to select a Main PCE over an alternate even if the alternate PCE is discovered first by a PCC. ): The alternate PCEs MUST advertise the main PCE(s) for which they = alternate.=20 =20 [JLLR] OK, we will clarify =20 We could also add a role (Main, alternate) in capabilities summary = section earlier on. [JLLR] Not sure that this can be considered as a capability=20 =20 3 Section 6.3 The section states in the first paragraph that a PCE MUST allow = detection of a change of any information advertised to a PCC (capabilities). Why is = this a MUST, if advertising of capabilities is a MAY in section 6.1 above? [JLLR]=20 The PCE MUST allow detection of a change of any disclosed PCE = information. This comprises mandatory information and also optional information that = may be disclosed... that is, if the PCE discovery is used so as to disclose optional info = then it MUST allow detecting a change of this optional info... For clarity we should probably add qualification that If a PCE supports advertising of capabilities, then it MUST allow detection. Here is a proposed new text: Iff a PCE supports advertising of optional information, then the PCE discovery mechanism MUST allow a PCC to detect any change in the = information related to a PCE (e.g. capability modifications).=20 [JLLR] OK, we are in sync, this is inline with my above comment =20 We will clarify as per your suggestion 4. Section 6.5 I would like to propose that detection of congestion would happen as = part of PCE-PCC communication protocol.=20 [JLLR] Yes, but one could argue that a PCC may want to be aware of a PCE congestion even in the absence of a PCC-PCE communication session. this = may be useful with the per-request session mode, if adopted in PCEP (see = also session on required feedback in PCEP) For simplicity we may have a reactive mode (i.e. a failure to a computation request to a PCC due to congestion would include for example = a time value required for that PCC to back-off before sending a next = request to a given PCE). If we would need something more proactive, then we = could add that in protocol draft and not in here. [JLLR] One may want to be proactive, so as to minimize path computation service disruption...=20 Again thanks a lot Andrew for these useful comments Best Regards, JL =20 Regards, Andrew=20 =20 ------=_NextPart_000_004C_01C59BF9.0F45ECD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jean-Louis,
 
I believe we are in synch functionally and the = only thing=20 we are discussing what is the place to describe such proactive = congestion=20 mechanism. If this ID will change into a session-control (which we could = probably do considering content) than I agree with you that this should = be here.=20 A more reactive way can then also be described in the protocol=20 itself.
 
Andrew

From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]
Sent: Friday, = August 05,=20 2005 5:54 AM
To: Andrew Dolganow
Cc:=20 pce@ietf.org
Subject: RE: comments to=20 draft-ietf-pce-discovery-reqs-01.txt

Hi Andrew,
 
Thanks a lot for these valuable=20 comments.
 
Please see inline,

De : Andrew Dolganow=20 [mailto:andrew.dolganow@alcatel.com]
Envoy=E9 : = mercredi 3 ao=FBt=20 2005 10:27
=C0 : LE ROUX Jean-Louis=20 RD-CORE-LAN
Cc : pce@ietf.org
Objet : = comments=20 to draft-ietf-pce-discovery-reqs-01.txt

Jean = Louis et=20 al,
 
Here = is few=20 comments/questions to the draft I have:
 
1. = Section=20 6.1:
 
Propose to change=20 the first paragraph (for clarity) with:

The PCE discovery mechanism MUST allow=20 disclosing mandatory, PCE information that will allow PCCs to = select=20 appropriate PCEs. The PCE discovery mechanism MAY = allow=20 disclosing optional , as defined below PCE information that will allow = PCCs to=20 select appropriate PCEs.
[JLLR] Agreed, we will clarify as per your=20 proposal 

2. = Section=20 6.4.1

The draft=20 states that a PCE should advertise alternate PCEs. If that's the case, = do you=20 expect those other PCEs to also advertise themselves? If yes (which I = expect)=20 then we should add for clarity at the end of that section something = like=20 ( is required = to allow PCCs=20 to select a Main PCE over an alternate even if the alternate PCE is = discovered=20 first by a PCC. ):

The alternate PCEs MUST advertise the main = PCE(s) for=20 which they = alternate. 
 
[JLLR] OK, we will=20 = clarify  

We could also=20 add a role (Main, alternate) in capabilities summary section earlier=20 on.
[JLLR] Not sure=20 that this can be considered as a = capability 
  

3 = Section=20 6.3

The section=20 states in the first paragraph that a PCE MUST allow detection of a = change of=20 any information advertised to a PCC (capabilities). Why is this a = MUST, if=20 advertising of capabilities is a MAY in section 6.1 above?
[JLLR] 

The PCE MUST allow=20 detection of a change of any disclosed PCE information. = This comprises mandatory information and also optional=20 information that may be=20 disclosed...

that is, if the PCE = discovery is=20 used so as to disclose optional info then it=20 MUST allow detecting a change of this optional=20 info...

For = clarity we=20 should probably add qualification that If a PCE supports advertising = of=20 capabilities, then it MUST allow detection. Here is a proposed = new=20 text:

Iff a=20 PCE supports advertising of optional information, then = the PCE=20 discovery mechanism MUST allow a PCC to detect any change in the = information=20 related to a PCE (e.g. capability modifications).
[JLLR] OK, we are in sync, = this is=20 inline with my above=20 comment  

We will clarify as per your=20 suggestion

4. Section 6.5

I would like to propose that detection of = congestion=20 would happen as part of PCE-PCC communication protocol.
[JLLR] Yes, but = one could=20 argue that a PCC may want to be aware of a PCE congestion even in = the=20 absence of a PCC-PCE communication session. this may be useful = with the=20 per-request session mode, if adopted in PCEP (see also session on = required feedback in PCEP)

  For=20 simplicity we may have a reactive mode (i.e. a failure to a = computation=20 request to a PCC due to congestion would include for example a time = value=20 required for that PCC to back-off before sending a next request = to a=20 given PCE). If we would need something more proactive, then we could = add that=20 in protocol draft and not in here.
[JLLR] One may want to be proactive, so = as to=20 minimize path computation service=20 = disruption... 

Again thanks a lot Andrew for these useful=20 comments

Best=20 Regards,

JL

&nbs= p;

Regards,

Andrew

 

= ------=_NextPart_000_004C_01C59BF9.0F45ECD0-- --===============1967887693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1967887693==-- From pce-bounces@lists.ietf.org Tue Aug 09 09:30:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UBI-0005xa-QO; Tue, 09 Aug 2005 09:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26t7-0006rG-3x for pce@megatron.ietf.org; Mon, 08 Aug 2005 08:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17824 for ; Mon, 8 Aug 2005 08:37:51 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27Qn-0006du-Tv for pce@ietf.org; Mon, 08 Aug 2005 09:12:43 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 08 Aug 2005 08:37:43 -0400 id 0056420A.42F75217.00000400 From: "Scott Hollenbeck" To: "'Adrian Farrel'" , hardie@qualcomm.com Date: Mon, 8 Aug 2005 08:38:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWYCzTtV5T/stkHT4isVhBoxiG3KgECrvtA In-reply-to: <01cf01c5980b$8e3bc0b0$7619ff56@Puppy> Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Aug 2005 09:30:10 -0400 Cc: 'Bill Fenner' , pce@ietf.org Subject: [Pce] RE: Applications Area assistance in PCE working group 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org I've sent a request for assistance to the apparea discuss list. Hopefully someone will be able to help. -Scott- > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, August 03, 2005 5:13 AM > To: hardie@qualcomm.com; sah@428cobrajet.net > Cc: pce@ietf.org; 'Jean Philippe Vasseur'; zinin@psg.com; Bill Fenner > Subject: Applications Area assistance in PCE working group > > Hi, > > The PCE working group > (http://www.ietf.org/html.charters/pce-charter.html) > has developed a set of requirements for a protocol that will > be used to > request path computations and provide responses. The requirements are > essentially for a client/server request/response protocol > with specific > (but not alarming) characteristics. > > We know that the Applications Area has a little experience with > client/server protocols and we would appreciate some > consultation from you > or from someone you can nominate (do you have an Applications Area > Directorate?). Can you please say whether you know of an > existing protocol > that closely matches our requirements. > > Our Architecture is draft-ietf-pce-architecture-01.txt This is pretty > cooked. > The protocol requirements are in > draft-ietf-pce-comm-protocol-gen-reqs-01.txt and are stable, but not > complete. > > The PCE working group has some very tight deadlines on this > work, so we > would appreciate feedback and suggestions by the end of > August. Comments > back to the chairs or direct to the PCE mailing list. > > Thanks for any help. > > Adrian and JP (PCE chairs) > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 10 14:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vSE-0004vD-46; Wed, 10 Aug 2005 14:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vSD-0004uw-9D for pce@megatron.ietf.org; Wed, 10 Aug 2005 14:37:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16166 for ; Wed, 10 Aug 2005 14:37:27 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2w0M-0007Bj-6K for pce@ietf.org; Wed, 10 Aug 2005 15:12:46 -0400 Received: from du-069-0215.access.clara.net ([217.158.132.215] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E2vS4-0009qi-GF for pce@ietf.org; Wed, 10 Aug 2005 19:37:24 +0100 Message-ID: <075f01c59dda$e962ba00$08849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 10 Aug 2005 18:47:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.6 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Subject: [Pce] PCEP ENCAP object X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1792668904==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1792668904== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0743_01C59DDB.EF67C0C0" This is a multi-part message in MIME format. ------=_NextPart_000_0743_01C59DDB.EF67C0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a question remaining about the PCEP spec, and I would appreciate = input from the WG and from the DT. There is clearly considerable overlap between the information that needs = to be carried by PCEP and that which is signaled by RSVP-TE. This is not = a surprise because many of the constraints are identical. As a result, = when deriving ways to encode this information it makes sense (to me and = apparently to the DT) to re-use encodings that already exist. This takes care of many of the details, but it leaves a high-level = question. We should choose between the three options listed below. 1. Re-use RSVP-TE objects entirely unchanged In this option, PCEP messages can carry objects encoded as RSVP-TE objects using the same C-Num and C-Type as defined for RSVP-TE. The disadvantages of this mechanism are: a. RSVP and PCEP share the same code-point space with the possible result that the space will become depleted. b. Changes to the RSVP-TE object will result in the receipt=20 of unexpected variants to the PCEP object. I don't know=20 whether this will matter since the RSVP processing rules will require backward compatibility. c. Fields that are not required in PCE will be transported=20 but not used. d. Subobjects that are not required in PCE are ambiguous. This option would be documented as follows: My_Object C-Num and C-Type as for RSVP-TE [RFCwxyz] The content of this object is defined in [RFCwxyz] In the context of PCE the fields of this object are=20 interpreted as follows: Field 1: Blah, blah, blah Field 2: etc. 2. Encapsulate RSVP-TE objects entirely unchanged As currently documented, the ENCAP object solves problem 1a. Encapsulation keeps the code points separate. There is the further (significant) advantage that objects=20 from other protocols can also be encapsulated which provides great future extensibility. We should note, however, that there is no impact on issues 1b, 1c, or 1d. There is also no change to the mechanism for documentation. In particular, it is still necessary to document the meaning of the fields in the context of PCE, and this would mean that as new objects (from any protocol) are made available for=20 encapsulation new I-Ds would be needed to describe how they identify constraints or response information. Further, if an existing object is modified in an I-D for some other=20 protocol, a new I-D would be needed for PCEP to explain how the new fields are used (if they are used).=20 There might be limited exceptions to this when interpretation is obvious and unambiguous. =20 3. Define new objects within PCEP In this option new objects are defined specifically for PCEP. Where the contents of the object are identical to those in=20 some other protocol, this can be documented by reference, but the PCEP I-D has to describe how they are used in the PCE=20 context. Where only some of the fields are identical to those in an=20 object (or several objects) in another protocol they need to be documented, but unused protocol fields do not need to be=20 reproduced in PCEP. This option solves all of the issues 1a, 1b, 1c and 1d, but introduces the need for new source code that cannot be common with the protocol code used in some other component. There are no documentation requirements for changes to other =20 protocols, but there may be more to do when new information=20 is added to PCEP. [Note that this option says much less about how the=20 information is actually encoded.] =20 Discuss. Thanks, Adrian ------=_NextPart_000_0743_01C59DDB.EF67C0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I have a question = remaining about the=20 PCEP spec, and I would appreciate input from the WG and from the=20 DT.

There is clearly considerable overlap between the information = that=20 needs to be carried by PCEP and that which is signaled by RSVP-TE. = This is=20 not a surprise because many of the constraints are identical. As = a result,=20 when deriving ways to encode this information it makes sense (to me and=20 apparently to the DT) to re-use encodings that already = exist.

This takes=20 care of many of the details, but it leaves a high-level question. We = should=20 choose between the three options listed below.

1. Re-use RSVP-TE = objects=20 entirely unchanged
   In this option, PCEP messages can = carry=20 objects encoded as
   RSVP-TE objects using = the same C-Num=20 and C-Type as defined
   for RSVP-TE.
  =  The=20 disadvantages of this mechanism are:
   a. RSVP and PCEP = share the=20 same code-point space with the
      possible = result that=20 the space will become depleted.
   b. Changes to the = RSVP-TE object=20 will result in the receipt
      of = unexpected=20 variants to the PCEP object. I don't know
      = whether this will=20 matter since the RSVP processing rules
      will = require=20 backward compatibility.
   c. Fields that are not required = in PCE=20 will be transported
      = but not=20 used.
   d. Subobjects that are not required in PCE are=20 ambiguous.
      This option would be = documented as=20 follows:
       =20 My_Object
        C-Num and C-Type as = for=20 RSVP-TE [RFCwxyz]
        The content = of this=20 object is defined in=20 [RFCwxyz]
        In the = context of=20 PCE the fields of this object are
       =20 interpreted as follows:

      =    =20 Field 1:
      =       =20 Blah, blah, = blah

         =20 Field 2:
   =          =20 etc.

2. Encapsulate RSVP-TE objects entirely unchanged
  =  As=20 currently documented, the ENCAP object solves problem = 1a.
  =20 Encapsulation keeps the code points separate.
   There is = the=20 further (significant) advantage that objects
   from = other protocols can also=20 be encapsulated which provides
   great future=20 extensibility.
   We should note, however, that there is no = impact=20 on issues
   1b, 1c, or = 1d.
 =20  There is also no change to the mechanism for = documentation.
   In particular, it = is still=20 necessary to document the meaning
   of the fields in = the context of=20 PCE, and this would mean that
   as new objects (from any = protocol) are made available for
   encapsulation new I-Ds = would be=20 needed to  describe how
   they identify = constraints or=20 response information. Further,
   if an existing = object is=20 modified in an I-D for some other
   protocol, a new = I-D would be=20 needed for PCEP to explain how
   the new fields are used = (if they=20 are used).
   There might be limited=20 exceptions to this when interpretation
   is obvious and=20 unambiguous.
 
3. Define new objects within PCEP
  =  In=20 this option new objects are defined specifically for PCEP.
  =  Where=20 the contents of the object are identical to those in
   some other protocol, = this can be=20 documented by reference, but
   the PCEP I-D has to = describe how=20 they are used in the PCE
   context.
  =  Where only=20 some of the fields are identical to those in an
   object (or several = objects) in=20 another protocol they need to
   be documented, but = unused protocol=20 fields do not need to be
   reproduced in = PCEP.
 =20  This option solves all of the issues 1a, 1b, 1c and 1d,=20 but
   introduces the need for new source code that = cannot be=20 common
   with the = protocol code used in=20 some other component.
   There are no documentation = requirements=20 for changes to other  
   protocols, but there = may be=20 more to do when new information
   is added to = PCEP.
   [Note that this option = says much=20 less about how the
    information is = actually=20 encoded.]

 
Discuss.
 
Thanks,
Adrian
------=_NextPart_000_0743_01C59DDB.EF67C0C0-- --===============1792668904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1792668904==-- From pce-bounces@lists.ietf.org Wed Aug 10 14:56:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vkN-00045P-3l; Wed, 10 Aug 2005 14:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vkL-00044C-MK for pce@megatron.ietf.org; Wed, 10 Aug 2005 14:56:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19007 for ; Wed, 10 Aug 2005 14:56:10 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wIU-0008O7-GA for pce@ietf.org; Wed, 10 Aug 2005 15:31:30 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7AIttx05011 for ; Wed, 10 Aug 2005 14:55:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Pce] PCEP ENCAP object Date: Wed, 10 Aug 2005 14:54:52 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403846944@zrtphxm2> Thread-Topic: [Pce] PCEP ENCAP object Thread-Index: AcWd2ujFYI32lMbUQy6w7f1vkp3x3wAAKX2A From: "Don Fedyk" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian I would vote for option 3. Reason decoupling and restarting is better. While there may be short term reuse I think PCEP should start from a clean slate and clean documentation. Regards, Don -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, August 10, 2005 1:47 PM To: pce@ietf.org Subject: [Pce] PCEP ENCAP object Hi, I have a question remaining about the PCEP spec, and I would appreciate input from the WG and from the DT. There is clearly considerable overlap between the information that needs to be carried by PCEP and that which is signaled by RSVP-TE. This is not a surprise because many of the constraints are identical. As a result, when deriving ways to encode this information it makes sense (to me and apparently to the DT) to re-use encodings that already exist. This takes care of many of the details, but it leaves a high-level question. We should choose between the three options listed below. 1. Re-use RSVP-TE objects entirely unchanged In this option, PCEP messages can carry objects encoded as RSVP-TE objects using the same C-Num and C-Type as defined for RSVP-TE. The disadvantages of this mechanism are: a. RSVP and PCEP share the same code-point space with the possible result that the space will become depleted. b. Changes to the RSVP-TE object will result in the receipt of unexpected variants to the PCEP object. I don't know whether this will matter since the RSVP processing rules will require backward compatibility. c. Fields that are not required in PCE will be transported but not used. d. Subobjects that are not required in PCE are ambiguous. This option would be documented as follows: My_Object C-Num and C-Type as for RSVP-TE [RFCwxyz] The content of this object is defined in [RFCwxyz] In the context of PCE the fields of this object are interpreted as follows: Field 1: Blah, blah, blah Field 2: etc. 2. Encapsulate RSVP-TE objects entirely unchanged As currently documented, the ENCAP object solves problem 1a. Encapsulation keeps the code points separate. There is the further (significant) advantage that objects from other protocols can also be encapsulated which provides great future extensibility. We should note, however, that there is no impact on issues 1b, 1c, or 1d. There is also no change to the mechanism for documentation. In particular, it is still necessary to document the meaning of the fields in the context of PCE, and this would mean that as new objects (from any protocol) are made available for encapsulation new I-Ds would be needed to describe how they identify constraints or response information. Further, if an existing object is modified in an I-D for some other protocol, a new I-D would be needed for PCEP to explain how the new fields are used (if they are used). There might be limited exceptions to this when interpretation is obvious and unambiguous. 3. Define new objects within PCEP In this option new objects are defined specifically for PCEP. Where the contents of the object are identical to those in some other protocol, this can be documented by reference, but the PCEP I-D has to describe how they are used in the PCE context. Where only some of the fields are identical to those in an object (or several objects) in another protocol they need to be documented, but unused protocol fields do not need to be reproduced in PCEP. This option solves all of the issues 1a, 1b, 1c and 1d, but introduces the need for new source code that cannot be common with the protocol code used in some other component. There are no documentation requirements for changes to other protocols, but there may be more to do when new information is added to PCEP. [Note that this option says much less about how the information is actually encoded.] Discuss. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 10 16:54:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xae-0002k9-DP; Wed, 10 Aug 2005 16:54:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xaX-0002k4-3X for pce@megatron.ietf.org; Wed, 10 Aug 2005 16:54:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03192 for ; Wed, 10 Aug 2005 16:54:10 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2y8i-0005hK-8t for pce@ietf.org; Wed, 10 Aug 2005 17:29:32 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 46929C5A6; Wed, 10 Aug 2005 16:53:59 -0400 (EDT) Message-ID: <006201c59ded$a18efdc0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Don Fedyk" , "Adrian Farrel" , References: <34B3EAA5B3066A42914D28C5ECF5FEA403846944@zrtphxm2> Subject: Re: [Pce] PCEP ENCAP object Date: Wed, 10 Aug 2005 16:53:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I agree with Don completely. PCEP and RSVP never communicate directly, rather, through some application. For instance, EROs received from a remote PCE are needed to go through some processing before they will be inserted into the Path message. No one would do the processing in the ERO wire format, there will be a need for some host representation. Hence it is almost irrelevant whether PCEP and RSVP EROs are encoded 100% identically or completely differently. The benefits of sharing parsers and decoding tools are too minor to justify the unnecessary IMO dependency between PCEP and RSVP object encoding. Besides, one can argue that it is both unrealistic and unnecessary to attempt to signal all possible PCE constraints, objection functions, diversity types, etc. in the RSVP Path message (that's why the requirement for PCEP flexibility is so much higher compared to one of the RSVP). Also LSRs are not the only ultimate users of the PCEP. It is easy to imagine that NMSs, network builders, simulators, etc. (that is, not RSVP speakers) will make use of remote PCE. Also, what if PWE3 folks would like to include the remote PCE into their architecture but refuse using RSVP? The bottom line: PCEP and RSVP should be completely decoupled in my opinion. Cheers, Igor ----- Original Message ----- From: "Don Fedyk" To: "Adrian Farrel" ; Sent: Wednesday, August 10, 2005 2:54 PM Subject: RE: [Pce] PCEP ENCAP object > Hi Adrian > > I would vote for option 3. > Reason decoupling and restarting is better. While there may be short > term reuse I think PCEP should start from a clean slate and clean > documentation. > > Regards, > Don > -----Original Message----- > From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On > Behalf Of Adrian Farrel > Sent: Wednesday, August 10, 2005 1:47 PM > To: pce@ietf.org > Subject: [Pce] PCEP ENCAP object > > > > Hi, > > I have a question remaining about the PCEP spec, and I would appreciate > input from the WG and from the DT. > > There is clearly considerable overlap between the information that needs > to be carried by PCEP and that which is signaled by RSVP-TE. This is not > a surprise because many of the constraints are identical. As a result, > when deriving ways to encode this information it makes sense (to me and > apparently to the DT) to re-use encodings that already exist. > > This takes care of many of the details, but it leaves a high-level > question. We should choose between the three options listed below. > > 1. Re-use RSVP-TE objects entirely unchanged > In this option, PCEP messages can carry objects encoded as > RSVP-TE objects using the same C-Num and C-Type as defined > for RSVP-TE. > The disadvantages of this mechanism are: > a. RSVP and PCEP share the same code-point space with the > possible result that the space will become depleted. > b. Changes to the RSVP-TE object will result in the receipt > of unexpected variants to the PCEP object. I don't know > whether this will matter since the RSVP processing rules > will require backward compatibility. > c. Fields that are not required in PCE will be transported > but not used. > d. Subobjects that are not required in PCE are ambiguous. > This option would be documented as follows: > My_Object > C-Num and C-Type as for RSVP-TE [RFCwxyz] > The content of this object is defined in [RFCwxyz] > In the context of PCE the fields of this object are > interpreted as follows: > > Field 1: > Blah, blah, blah > > Field 2: > etc. > > 2. Encapsulate RSVP-TE objects entirely unchanged > As currently documented, the ENCAP object solves problem 1a. > Encapsulation keeps the code points separate. > There is the further (significant) advantage that objects > from other protocols can also be encapsulated which provides > great future extensibility. > We should note, however, that there is no impact on issues > 1b, 1c, or 1d. > There is also no change to the mechanism for documentation. > In particular, it is still necessary to document the meaning > of the fields in the context of PCE, and this would mean that > as new objects (from any protocol) are made available for > encapsulation new I-Ds would be needed to describe how > they identify constraints or response information. Further, > if an existing object is modified in an I-D for some other > protocol, a new I-D would be needed for PCEP to explain how > the new fields are used (if they are used). > There might be limited exceptions to this when interpretation > is obvious and unambiguous. > > 3. Define new objects within PCEP > In this option new objects are defined specifically for PCEP. > Where the contents of the object are identical to those in > some other protocol, this can be documented by reference, but > the PCEP I-D has to describe how they are used in the PCE > context. > Where only some of the fields are identical to those in an > object (or several objects) in another protocol they need to > be documented, but unused protocol fields do not need to be > reproduced in PCEP. > This option solves all of the issues 1a, 1b, 1c and 1d, but > introduces the need for new source code that cannot be common > with the protocol code used in some other component. > There are no documentation requirements for changes to other > protocols, but there may be more to do when new information > is added to PCEP. > [Note that this option says much less about how the > information is actually encoded.] > > > Discuss. > > Thanks, > Adrian > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 10 17:40:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2yJD-0004Zd-7J; Wed, 10 Aug 2005 17:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2yJB-0004ZM-BE for pce@megatron.ietf.org; Wed, 10 Aug 2005 17:40:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05220 for ; Wed, 10 Aug 2005 17:40:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2yrM-0006mF-RR for pce@ietf.org; Wed, 10 Aug 2005 18:15:41 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2yJ6-0000oV-JB; Wed, 10 Aug 2005 21:40:16 +0000 Message-ID: <42FA743A.7040302@psg.com> Date: Wed, 10 Aug 2005 23:40:10 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] PCEP ENCAP object References: <075f01c59dda$e962ba00$08849ed9@Puppy> In-Reply-To: <075f01c59dda$e962ba00$08849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org adrian even if the syntax of some of the objects can be maintained their processing is going to be different anyway so independently of their encoding the PCEP I-D has to describe how these objects are going to be used in the PCE context - the reason for this is pretty clear having a protocol for signaling end-to-end traffic parameters and perform resource reservation is radically different from having a client-server protocol for requesting path computation based on a set of specific constraints (by the way reducing the set of constraints and focus on a restricted set of strictly required constraints and not a desirable set of constraint would also help in assessing the problem) the re-use of parsers is in any case going to imply introduction of masks for subobjects or fields that do not have a specific semantic (i should also point out that these objects will be processed in the context of the message into which they are received and afaik PCEP defines a new set of messages) but in addition one will require to carry them over since the protocol is also meant for the PCE-PCE communication or even worst have another semantic in the context of PCEP (rather than the current RSVP-TE implementation) therefore the re-usability argument is going to fall short after a small couple of cycles on the other way, if option 1 is selected what is going to happen when the PCEP protocol will need additional specific subobject(s) or value(s) ? are we going to also have to update the corresponding RSVP-TE object ? forget about you are simply going to put in place "yet another" flavor for the interpretation of the RSVP-TE objects and the last thing that is desirable is to reduce the genericity of their applicability option 2 is also not going to provide any specific help from this perspective simply because instead of having to deal with one set of objects (i.e. those defined in the RSVP context) one is potentially going to face a set of set of such objects and related issues therefore, only option 3 remains, it is imho the only viable solution thanks, - dimitri. Adrian Farrel wrote: > Hi, > > I have a question remaining about the PCEP spec, and I would > appreciate input from the WG and from the DT. > > There is clearly considerable overlap between the information that > needs to be carried by PCEP and that which is signaled by RSVP-TE. > This is not a surprise because many of the constraints are identical. > As a result, when deriving ways to encode this information it makes > sense (to me and apparently to the DT) to re-use encodings that > already exist. > > This takes care of many of the details, but it leaves a high-level > question. We should choose between the three options listed below. > > 1. Re-use RSVP-TE objects entirely unchanged In this option, PCEP > messages can carry objects encoded as RSVP-TE objects using the same > C-Num and C-Type as defined for RSVP-TE. The disadvantages of this > mechanism are: a. RSVP and PCEP share the same code-point space with > the possible result that the space will become depleted. b. Changes > to the RSVP-TE object will result in the receipt of unexpected > variants to the PCEP object. I don't know whether this will matter > since the RSVP processing rules will require backward compatibility. > c. Fields that are not required in PCE will be transported but not > used. d. Subobjects that are not required in PCE are ambiguous. This > option would be documented as follows: My_Object C-Num and C-Type as > for RSVP-TE [RFCwxyz] The content of this object is defined in > [RFCwxyz] In the context of PCE the fields of this object are > interpreted as follows: > > Field 1: Blah, blah, blah > > Field 2: etc. > > 2. Encapsulate RSVP-TE objects entirely unchanged As currently > documented, the ENCAP object solves problem 1a. Encapsulation keeps > the code points separate. There is the further (significant) > advantage that objects from other protocols can also be encapsulated > which provides great future extensibility. We should note, however, > that there is no impact on issues 1b, 1c, or 1d. There is also no > change to the mechanism for documentation. In particular, it is still > necessary to document the meaning of the fields in the context of > PCE, and this would mean that as new objects (from any protocol) are > made available for encapsulation new I-Ds would be needed to > describe how they identify constraints or response information. > Further, if an existing object is modified in an I-D for some other > protocol, a new I-D would be needed for PCEP to explain how the new > fields are used (if they are used). There might be limited exceptions > to this when interpretation is obvious and unambiguous. > > 3. Define new objects within PCEP In this option new objects are > defined specifically for PCEP. Where the contents of the object are > identical to those in some other protocol, this can be documented by > reference, but the PCEP I-D has to describe how they are used in the > PCE context. Where only some of the fields are identical to those in > an object (or several objects) in another protocol they need to be > documented, but unused protocol fields do not need to be reproduced > in PCEP. This option solves all of the issues 1a, 1b, 1c and 1d, but > introduces the need for new source code that cannot be common with > the protocol code used in some other component. There are no > documentation requirements for changes to other protocols, but there > may be more to do when new information is added to PCEP. [Note that > this option says much less about how the information is actually > encoded.] > > > Discuss. > > Thanks, Adrian > > > ------------------------------------------------------------------------ > > > _______________________________________________ Pce mailing list > Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 12 11:40:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3beN-0004Cx-Lm; Fri, 12 Aug 2005 11:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3beM-0004Cj-14 for pce@megatron.ietf.org; Fri, 12 Aug 2005 11:40:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01767 for ; Fri, 12 Aug 2005 11:40:47 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cCs-0005Cj-TN for pce@ietf.org; Fri, 12 Aug 2005 12:16:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2005 08:40:40 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="654575973:sNHT28524520" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFeIp6018086; Fri, 12 Aug 2005 08:40:37 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:40:36 -0400 Received: from [161.44.70.216] ([161.44.70.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:40:36 -0400 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 12 Aug 2005 11:41:06 -0400 To: ccamp@ops.ietf.org X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 12 Aug 2005 15:40:36.0715 (UTC) FILETIME=[2F280BB0:01C59F54] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] PCE Requirement in CCAMP X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, CCAMP proposed to work on GMPLS requirements for PCE as necessary. Considering the work which has been done by the PCE WG on requirements, it looks now more natural to move this work exclusively to the PCE WG. That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, any requirements for PCE-based Inter-domain LSP computation should be discussed in the PCE WG *with* the review of the CCAMP WG. Similarly, non-packet networks may result in specific additional requirements for PCE. We propose that these requirements are also raised within the PCE working group and reviewed by CCAMP. Let us know if you have any opinion on or objection to these proposals. JP and Adrian (wearing PCE chair hat) _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 12 12:18:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cC7-0007RU-5M; Fri, 12 Aug 2005 12:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cC5-0007RN-QW for pce@megatron.ietf.org; Fri, 12 Aug 2005 12:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03859 for ; Fri, 12 Aug 2005 12:15:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ckd-0006GX-0U for pce@ietf.org; Fri, 12 Aug 2005 12:51:24 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3cC2-000JZN-V1; Fri, 12 Aug 2005 16:15:39 +0000 Message-ID: <42FCCB29.8060309@psg.com> Date: Fri, 12 Aug 2005 18:15:37 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, pce@ietf.org Subject: [Pce] Re: PCE Requirement in CCAMP X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jp, adrian it depends on the perspective, as such this document is meant to address the following item of the charter (last part) "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models." therefore, it was my understanding that the PCE WG would be waiting for the need wrt signaling for detailing its applicability; you (and adrian) seems to say we will define the requirement for PCE-based inter-domain path computation and resulting signaling behaviour/mechanisms would then need to be adapted in CCAMP in brief, with your proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself, as an analogy RSVP-TE operations are decoupled from the routing topology; so here, the same relationship should be kept with respect to the computational scope/capabilities and behaviour of PCE(s) thanks, - dimitri. JP Vasseur wrote: > Dear WG, > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > Considering the work which has been done by the PCE WG on requirements, it > looks now more natural to move this work exclusively to the PCE WG. > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > any requirements for PCE-based Inter-domain LSP computation should be > discussed in the PCE WG *with* the review of the CCAMP WG. > > Similarly, non-packet networks may result in specific additional > requirements for PCE. We propose that these requirements are also raised > within the PCE working group and reviewed by CCAMP. > > Let us know if you have any opinion on or objection to these proposals. > > JP and Adrian (wearing PCE chair hat) > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 12 14:06:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dvT-0003G7-PD; Fri, 12 Aug 2005 14:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dvS-0003Fx-DU for pce@megatron.ietf.org; Fri, 12 Aug 2005 14:06:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08426 for ; Fri, 12 Aug 2005 14:06:36 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eTy-0000h0-9J for pce@ietf.org; Fri, 12 Aug 2005 14:42:21 -0400 Received: from du-069-0154.access.clara.net ([217.158.132.154] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E3dvA-000Bnf-90; Fri, 12 Aug 2005 19:06:22 +0100 Message-ID: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> From: "Adrian Farrel" To: , , "JP Vasseur" References: <42FCCB29.8060309@psg.com> Date: Fri, 12 Aug 2005 19:08:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, pce@ietf.org Subject: [Pce] Re: PCE Requirement in CCAMP 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, > it depends on the perspective, as such this document is meant to address > the following item of the charter (last part) > > "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models." No, it is not meant to address that part of the charter. That item remains unchanged by this discussion. JP's email is clearly specific to the documentation of requirements for PCE placed by the GMPLS protocols and non-packet networks under the control of GMPLS protocols. Our proposal is to develop all requirements for PCE within the PCE working group with review by the appropriate external working group. In practice, this only a small change since it is likely to be the same people involved in the work. It is, however, a formal change in CCAMP which previously had a commitment to work on these requirements. > therefore, it was my understanding that the PCE WG would be waiting for > the need wrt signaling for detailing its applicability; you (and adrian) > seems to say we will define the requirement for PCE-based inter-domain > path computation and resulting signaling behaviour/mechanisms would then > need to be adapted in CCAMP > > in brief, with your proposal PCE WG would be entering into a mode where > the computational capabilities are going to drive LSP signaling itself, > as an analogy RSVP-TE operations are decoupled from the routing > topology; so here, the same relationship should be kept with respect to > the computational scope/capabilities and behaviour of PCE(s) If you are objecting to the specific item on the PCE charter then now may be a little late, but let me explain the sort of thing that the charter item is intended to cover by giving a couple of examples. - PCE discovery may be achieved through the presence of information withing IGP advertisements. This would require changes to the IGPs and such changes MUST be reviewed by the appropriate WGs. - The use of a fully computed path that crosses multiple domains raises confidentiality issues. These issues can be solved by inserting new sub-objects into an RSVP-TE Explicit Route object (for example a cookie and PCE ID, or an encrypted hop). The normal way in which such small protocol changes are made (witness GMPLS additions to the IGPs) is either: a. An I-D is written and taken to the "owning" WG b. An I-D is written in the WG that needs the solutions and is reviewed in the "owning" WG. This process is usually refered to as "cooperation between WGs". The PCE charter proposes business as usual. Thanks, Adrian > > Dear WG, > > > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > > > Considering the work which has been done by the PCE WG on requirements, it > > looks now more natural to move this work exclusively to the PCE WG. > > > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > > any requirements for PCE-based Inter-domain LSP computation should be > > discussed in the PCE WG *with* the review of the CCAMP WG. > > > > Similarly, non-packet networks may result in specific additional > > requirements for PCE. We propose that these requirements are also raised > > within the PCE working group and reviewed by CCAMP. > > > > Let us know if you have any opinion on or objection to these proposals. > > > > JP and Adrian (wearing PCE chair hat) > > > > > > . > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 12 15:01:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3em6-00040E-Ne; Fri, 12 Aug 2005 15:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3em3-0003zZ-6W for pce@megatron.ietf.org; Fri, 12 Aug 2005 15:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11465 for ; Fri, 12 Aug 2005 15:00:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fKc-0002Kl-Ju for pce@ietf.org; Fri, 12 Aug 2005 15:36:43 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3ekn-0006AD-8K; Fri, 12 Aug 2005 18:59:42 +0000 Message-ID: <42FCF19B.2010007@psg.com> Date: Fri, 12 Aug 2005 20:59:39 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel References: <42FCCB29.8060309@psg.com> <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> In-Reply-To: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, pce@ietf.org Subject: [Pce] Re: PCE Requirement in CCAMP X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi adrian i perfectly understand the need from the PCE perspective but that's not the real question (even if one might question under which charter item this work would be initiated - something not clear to me from your reply here below) the real issue is that with such proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself - please note here the difference with the discovery process through IGP extensions that is going to be put in place - but the impact of the global PCE architecture on the independence wrt path computation of the RSVP-TE protocol; hence, i always thought that the CCAMP WG would have initially provided "guidelines" to the PCE WG before such work would start in the PCE WG i hope you see that the issue is not about the "owning WG" or the "reviewing WG" or their cooperation but the need to know more about the acceptable level of integration/cooperation of the PCE architecture with the operations on signaling LSP before deciding from where the wind will come from hope this clarifies (at least a bit), - dimitri. Adrian Farrel wrote: > Hi Dimitri, > > >>it depends on the perspective, as such this document is meant to address >>the following item of the charter (last part) >> >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP >>signaling (RSVP-TE) extensions required to support PCE-based path >>computation models." > > > No, it is not meant to address that part of the charter. That item remains > unchanged by this discussion. > > JP's email is clearly specific to the documentation of requirements for > PCE placed by the GMPLS protocols and non-packet networks under the > control of GMPLS protocols. > > Our proposal is to develop all requirements for PCE within the PCE working > group with review by the appropriate external working group. > > In practice, this only a small change since it is likely to be the same > people involved in the work. It is, however, a formal change in CCAMP > which previously had a commitment to work on these requirements. > > >>therefore, it was my understanding that the PCE WG would be waiting for >>the need wrt signaling for detailing its applicability; you (and adrian) >>seems to say we will define the requirement for PCE-based inter-domain >>path computation and resulting signaling behaviour/mechanisms would then >>need to be adapted in CCAMP >> >>in brief, with your proposal PCE WG would be entering into a mode where >>the computational capabilities are going to drive LSP signaling itself, >>as an analogy RSVP-TE operations are decoupled from the routing >>topology; so here, the same relationship should be kept with respect to >>the computational scope/capabilities and behaviour of PCE(s) > > > If you are objecting to the specific item on the PCE charter then now may > be a little late, but let me explain the sort of thing that the charter > item is intended to cover by giving a couple of examples. > > - PCE discovery may be achieved through the presence of > information withing IGP advertisements. This would require changes > to the IGPs and such changes MUST be reviewed by the > appropriate WGs. > > - The use of a fully computed path that crosses multiple domains > raises confidentiality issues. These issues can be solved by > inserting new sub-objects into an RSVP-TE Explicit Route > object (for example a cookie and PCE ID, or an encrypted > hop). > > The normal way in which such small protocol changes are made (witness > GMPLS additions to the IGPs) is either: > a. An I-D is written and taken to the "owning" WG > b. An I-D is written in the WG that needs the solutions and > is reviewed in the "owning" WG. > This process is usually refered to as "cooperation between WGs". > The PCE charter proposes business as usual. > > Thanks, > Adrian > > > >>>Dear WG, >>> >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. >>> >>>Considering the work which has been done by the PCE WG on > > requirements, it > >>>looks now more natural to move this work exclusively to the PCE WG. >>> >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > CCAMP, > >>>any requirements for PCE-based Inter-domain LSP computation should be >>>discussed in the PCE WG *with* the review of the CCAMP WG. >>> >>>Similarly, non-packet networks may result in specific additional >>>requirements for PCE. We propose that these requirements are also > > raised > >>>within the PCE working group and reviewed by CCAMP. >>> >>>Let us know if you have any opinion on or objection to these > > proposals. > >>>JP and Adrian (wearing PCE chair hat) >>> >>> >>>. >>> >> >> >> > > > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Aug 13 10:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ws1-0000x4-28; Sat, 13 Aug 2005 10:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3wry-0000wz-59 for pce@megatron.ietf.org; Sat, 13 Aug 2005 10:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24060 for ; Sat, 13 Aug 2005 10:20:16 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3xQf-0007oP-Ct for pce@ietf.org; Sat, 13 Aug 2005 10:56:12 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2005 07:20:06 -0700 X-IronPort-AV: i="3.96,104,1122879600"; d="scan'208"; a="331940059:sNHT36120758" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7DEJtQO012286 for ; Sat, 13 Aug 2005 07:19:58 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 Aug 2005 10:20:03 -0400 Received: from [192.168.1.102] ([10.86.240.69]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 Aug 2005 10:20:02 -0400 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: quoted-printable Message-Id: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Sat, 13 Aug 2005 10:20:32 -0400 X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 13 Aug 2005 14:20:02.0983 (UTC) FILETIME=[1870D370:01C5A012] X-Spam-Score: 0.0 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Content-Transfer-Encoding: quoted-printable Cc: Subject: [Pce] Draft PCE WG Minutes - IETF-63 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org (Please comment by August 27th) ---------------------------------- PCE Working Group meeting minutes ---------------------------------- IETF-63 - Paris, France - Tuesday, August 2, 2005. (Thanks to Jaudelice and Deborah for having taken the minutes) ------------------ 1. Agenda (Adrian) ------------------ 1) Agenda/Admin (10mn) 2) Progress against milestones (5mn) 3) Drafts (55mn) - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) - draft-ietf-pce-discovery-reqs-01.txt (Le Roux =82=C4=EC 10mn) - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) 4) Working Group next steps (20mn) ----------------------------------- 2. Progress against Milestones (JP) ----------------------------------- 1. Submit first draft of PCE architecture document: done 2. Submit first draft of PCE discovery requirements and protocol =20 extensions documents (half-done: PCE discovery requirements ID is done) 3. Submit first draft of the PCE communication protocol requirements =20 (done) 4. Definition of the objective metrics (to be done later - more =20 progress required on other IDs first) 5. PCE communication protocol specification (decision to be made by =20 the WG soon) ----------------------------------------------------------------- PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) ----------------------------------------------------------------- Adrian thanked everyone that contributed to help get this version out Mainly editorial revisions resulting from Minneapolis meeting have =20 been done (Clarifications, but nothing major) More a framework, and an architecture overview and deployment scenarios. Describes the architectural overview and building blocks Many mailing list comments and private comments Not any major substantial changes Plan to add discussion of policy, will separate exchange of policy =20 info in the PCE communication and the use of policy within the =20 architecture Question (?): present a functional view as well as component view? Adrian: currently view point is third dimension Arthi: policy =96 how will it be addressed in the document? Adrian: the current doc will only have something high level =96 Lou =20 will provide draft text Igor: when I issue a path request, can I disallow paths requiring =20 distributed computation, Adrian: that=92s something for the computation Dimitri: is this the only document for policy or we will do something =20= else ? JP: we need requirements and solution detailed in a separate ID. Lou: we had discussion, as Adrian said, we will have later a =20 standalone document with more details after we have more discussion =20 in the WG Dimitri: in other WG, are discussing policy for interdomain, need =20 that for this group Adrian =96 agree Plans: architecture is believed to be stable but needs discussions =20 resulting from emails on the list. ------------------------------------------------------------------------=20= ---------- Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt =20 (Jean-Louis) ------------------------------------------------------------------------=20= ---------- Set of requiretments for automatic pce discovery comments and discussions on the list have been addressed in the new =20 version -01 * multi-area example * application scenario * reorganized PCE info to be disclosed (mandatory versus optional) It must be noted that this is optional in the pce discovery =20 mechanism, not necessarily optional for pce architecture, * extensibility section * security requirements * PCE capabilities definition is out of the scope (should be in a =20 separate document) Open issues: - two stage discovery ? should limit to basic or include more =20 detailed - all as part of this document - security trust model- need to detail requirements - need feedback on discovery of pce power and congestion status =96 =20 should be part of this discovery mechanism or as part of a more =20 detailed requirements phase? Next steps: * address open issues Discussion Dimitri: the question on one or two stage, for me it=92s the question =20= how many pces will we have =96 if only a small group, then number of =20 sessions, with more detailed information, can be supported. Tradeoffs =20= if small set, and all receive information, or if a lot of PCEs, may =20 want only the subset that needs to know. JP: could use a flooding based mechanism Dimitri: but what is expected then on the use of this information ? Arthi: It is premature to talk about solution. Do we have a sense of =20 what direction we might be taking? On the section on scalability: =20 number of pce pccs are factors but also should consider the load on a =20= pce. The details that you have might not be relevant to a PCE. Dimitri: should say if the info is of interest to all the pces or not Arthi: I=92m less concerned with the PCE if the PCE is itself a PCC Igor: Flooding is good, but it has problems: scalability and =20 security. You still want to know the capabilities of pce so you may =20 need to establish a session. JP: we may now be discussing solutions on how to do basic =20 capabilities and additional capabilities Igor: we will need this discussion though JP: I don=92t see this as pce discovery, this is a capabilities = exchange JL: Do you have an idea of a communication protocol Igor: It should not be flooding. JL: For general discovery we should use flooding. JL: You must be able to control to which pcc you will be disclosing =20 the information: all pccs in an area, etc. Adrian: the draft though today does include some capabilities Dimitri: can you provide requirements on more the dynamics needed for =20= these capabilities JP: A limited number of capabilities such as the congestion parameter =20= is likely to be dynamic Richard: propose discuss possible solutions over email exchange, even =20= though it=92s not to be included in the requirements, the discussion =20 helps to understand Arthi: agree should discuss to an extend some of the solutions JP: thanks to quickly resolve the set of open issues. The draft =20 should then be ready for Working Group LC. ------------------------------------------------ PCE Communication Protocol=0B Generic Requirements draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Jerry) ----------------------------------------------- Generic requirements applicable to all PCEs application-specific requirements to be addressed in separate =20 requirements documents A table with a summary is included. Open Issues * requirements for less constrained path requests/response * requirements for responsiveness & session maintenance * detailed requirements on throttling messages under overload * specify =91boundary=92 numbers on scalability * clearly state supported policy models & corresponding requirements/=20 implications * avoid feature creep * need to progress application-specific requirements * PCE protocol proposal needs to identify how generic & application-=20 specific requirements are met Discussion: JP: Detailed scalability issues are related to implementation. Adrian: we need a range as don=92t want protocol to provide the limit JP: on the less-constrained path computation topic, we don=92t have a =20= consensus yet, we should have a separate document Arthi: we had a discussion in the pwe group that there may be =20 requirements for pce Adrian: by us splitting the document between generic and extended =20 reqs (more application specific) we could handle this better Arthi: also though may not be in scope Adrian: yes we should say if it=92s out of scope Arthi: Some new requirements may come up for PCE, we need to have a =20 plan on how to address that. Adrian: The document is extensible. Arthi: We might see other consumers of PCE JP: Sure and the protocol should be designed to handle extensions so =20 as to meet new requirements but we may need to recharter --------------------------------------------- PCE Communication Protocol Application Model draft-zhang-pce-comm-app-model-01.txt (Zhang) -------------------------------------------- * how to avoid contention with TE link fails * how to load balance among PCEs * how to update the PCEs about resource allocation JP asked who has read the draft: good show of hands Adrian: rather than saying this is the way forward, would prefer =20 emphasis on what are the requirements (coauthor of the draft ??): this draft addresses a way to ... Adrian: yes, this draft has requirements on an implementation, would =20 like first to see top level requirements and architecture Igor: one of the requirements for the protocol is getting updates, etc, Adrian: first need requirements Igor: my view this is not a signaling protocol, not rsvp, we =20 shouldn=92t go thru the process of using a signaling protocol JL: I have a major concern on scalability with the draft=92s approach, =20= one major bottleneck is on the PCE-PCE signaling, we should minimize =20 the signaling, the objective is to have distribution to reduce this, =20 whereas this draft re-introduces this overhead for synchronization. =20 You are redefining the concept of cluster. Why not use the PCE engine? One major bottleneck on the PCE architecture is the pcc-pce =20 signalling. To ensure path computation, reduce the number of path =20 computation requirements received by a pce. Author: it does not consume much bandwidth. JL: It is not a problem of bandwidth but communication overhead. JP: I have similar concerns. Have you tried to evaluate what would be =20= the overhead in term of extra signaling due to this mechanism? One =20 way to roughly evaluate would be by using simulations. Adrian: best for us to discuss over email to provide adequate time =20 for the discussion. ------------------------------------------------------------- Path Computation Element (PCE) communication Protocol (PCEP)=0B draft-vasseur-pce-pcep-01.txt (JP) -------------------------------------------------------------- PCC-PCE and between PCEs communication There were two proposals in the past which were discontinued and a =20 completely new protocol has been designed (PCEP) highly driven by the =20= PCE WG requirement document. Chief objective was to make it =20 extensible to cope with future requirements. Major changes from 00 to 01: * rewritten for clarity * few sections removed * new section on protocol model * added security consideration * very rough manageability consideration section added (to be fleshed =20= out) * two new objects defined Unique communication protocol for PCC-PCE and PCE-PCE. Summary =96 pcep meets most of the requirements. Open issues (need inputs from the working group) * Objective functions needs to be defined (next revision) * Protocol recovery: requires more detailed requirements * Policy: requires more discussion Discussion Bijan Jabbari: What was the reason for TCP? JP: reliability and flow control. TCP was a very good candidate for =20 that. Bijan: Question of scalability of TCP. JP (vendor hat): We do not see any scalability issue with TCP. =20 Current TCP implementations can support a very high number of TCP =20 sessions. Question (?). You are creating a new protocol. Did you do an analisys =20= on existing protocols and reaons for not using them? Adrian: yes we did , but here formal requirement for the WG to take =20 reqs to other groups to ask if have anything, so this draft =20 progressing depends on answer. Lou: Many protocols have been worked on. Instead of reinventing the =20 weel, why not use one already existing. What we are doing here in =20 path computation is a new application, but session application (keep =20 alive, discovery) have been resolved before and it would be great to =20 concentrate on what is related to pce. Adrian: great if we can learn lessons Lou: and reuse Adrian: agree Dimitri: agree as Lou said Lou: session management, keep alives, etc have been done already JP: the question is, is there anything specifics to PCE that we need =20 a new protocol Dimitri: With a new solution we will have to pass all the stages the =20 others have passed to achieve a robust solution. JP: That's why we have the question here. Adrian: yes, this protocol in this draft has not been selected Bijan: If this is IP only, was DNS discussed? Adrian: this is IP only Bijan: have we looked at DNS ? Adrian: bring it to the list to suggest Lou: Comment on need to go back and use an existing mechanism =20 whenever you can. JP: yes, whenever you can. Loa: if we have TCP, then we have a basis, to do more, we need =20 justification, JP: agree Jerry: can you include what is met and not met on requirements into =20 the draft ? JP: ok, will do. Jerry: if we do not have a list of requirements, how can we proceed? Yakov: Comment on the need for protocol specific keep-alive: we need =20 a PCE specific keep-alive protocol since TCP will not take care of it. JP: fully agree. Lou: You need keep-alive (TCP-based solutions already have keep-=20 alives). Find out what's the requirement, then lift the existing =20 solution. Lou: my comment is to look at experience =96 e.g. if need keepalives, =20= it=92s a mistake to look at this again without considering previous =20 work, and do all the requirements all over again, should look at =20 existing protocols, transaction semantics Adrian: yes, persistency should be addressed in the requirements Sue: keepalives in a protocol is needed in addition to tcp, need to =20 pay careful attention to the state machine interaction between the =20 two =96 pcc-pce. Need to ensure handle failure scenarios, noticed =20 missing here some of what protocol has to solve, should feed back =20 into requirements JP: Sometimes you do not want a permanent session, and sometimes you =20 do. Do we need two modes? Adrian: question should be asked to the requirements team. JL: we should be more flexible and support both request and permanent =20= as it will depend on the request, and number of pces to maintain, may =20= have a full mesh and may not want to maintain a permanent JP: this is what we heard =96 may only need on request, other times =20 will need permanent, so may want both modes, and negotiate upon =20 session establishment. Adrian: when doing the solutions and have a question, should take =20 back to the requirements folks JP: Less-constrained path computation aspects will be removed from =20 this draft and be worked out in a separate ID. ------------------------------------------------ Path Computation Element Metric Protocol (PCEMP)=0B draft-choi-pce-metric-protocol-02.txt (Dipnarayan Guha) ------------------------------------------------ PCE metric protocol (PCEMP): generic routing and path computation =20 protocol targeted towards inter-domain pce peers. Reviewed slides JP: we encourage you to provide simulation results to the mailing =20 list it will help No discussion ------------------------------ working group next steps (JP) ------------------------------ - new revision of the PCE architecture ID to be published soon (WG =20 last call soon after this ietf) - new revision of the generic pce communication requirement ID (WG =20 last call soon after this ietf) - submit a new ID for pce discovery protocol extensions (minor =20 protocol work only) Start application-specific requirements IDs for PCE based computation *Inter-area: Jean-Louis *Inter-As: Raymond, Nabil JP: note that such ID must be PCE-specific (take into account RFC4105 =20= and inter-as requirements ID produced by the TE WG). Adrian: WG to decide on which pce communication protocol solution to =20 pursue - two proposals presented - selection of one solution as a basis now does not imply rejecting =20 good points of other solution nor accepting bad points of selected =20 solutions. If pick one, that does not prevent us from taking the best of other =20 one also, and also other ietf protocols. email will be sent to the =20 application ADs to ask their input. - New ID on the less contrained path problem comprising the =20 requirement + solution - Need to verify the solution model for inter-domain pce with CCAMP, =20 MPLS working groups Adrian =96 other application specific requirements IDs (interlayer, =20 p2mp) should continue their work, just realize other work needs to be =20= done first: inter-layer: Eiji, Kenji P2MP: Seisho (currently out of scope of PCE WG charter) Thanks. JP.= _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Aug 13 10:37:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3x8S-0003PK-1H; Sat, 13 Aug 2005 10:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3x8Q-0003O2-44 for pce@megatron.ietf.org; Sat, 13 Aug 2005 10:37:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25011 for ; Sat, 13 Aug 2005 10:37:16 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3xh9-0008CO-O7 for pce@ietf.org; Sat, 13 Aug 2005 11:13:12 -0400 Received: from du-069-0107.access.clara.net ([217.158.132.107] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E3x81-000627-E1; Sat, 13 Aug 2005 15:37:01 +0100 Message-ID: <0dd501c5a014$d27d8a40$08849ed9@Puppy> From: "Adrian Farrel" To: , References: <42FCCB29.8060309@psg.com> <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> <42FCF19B.2010007@psg.com> Date: Sat, 13 Aug 2005 15:34:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org, pce@ietf.org Subject: [Pce] Re: PCE Requirement in CCAMP 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, GMPLS and non-packet requirements for PCE are likely to include the specification of protection types, switching types, encoding types, optical constraints, and so forth. While you could argue that CCAMP has best knowledge of these items, it does not seem to me to matter if the corresponding requirements I-D (that describes what constraints PCE must be able to receive and satisfy) is developed in the PCE working group. The question that JP's email asks is: "Is it OK with the CCAMP WG if that requirements I-D is developed in the PCE WG with review from the CCAMP WG?" If we can answer this question in isolation of your other point, this would be helpful. We can then move on to discuss you other point as follows... While I understand your concern (that the computational architecture should not force signaling behavior) I do not believe that it can be addressed by limiting the discussion to the CCAMP working group. It is clear that the PCE working group is responsible for the PCE architecture and should suggest applicability to specific environments including multi-domain MPLS-TE and GMPLS. The questions then arise: if the application of PCE to a specific environment requires additions to the MPLS-TE or GMPLS signaling protocols: 1. which working group should decide that the applicability of PCE in this environment is valid? 2. which working group should identify the requirement for these protocol extensions? 3. which working group should validate the requirements for these protocol extensions? 4. which working group should develop the protocol extensions? 5. which working group should review the protocol extensions? *My* answers to these questions are: 1 PCE and CCAMP 2 PCE 3 CCAMP 4 PCE 5 CCAMP My reasoning is: - the purpose of PCE is to do this work - CCAMP cannot (and should not) do everything - CCAMP must keep "supervision" of protocol extensions I would like to hear other people's opinion on both issues - that raised by JP and that raised by Dimitri. Thanks, Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: ; "JP Vasseur" ; ; Sent: Friday, August 12, 2005 7:59 PM Subject: Re: PCE Requirement in CCAMP > hi adrian > > i perfectly understand the need from the PCE perspective but that's not > the real question (even if one might question under which charter item > this work would be initiated - something not clear to me from your reply > here below) > > the real issue is that with such proposal PCE WG would be entering into > a mode where the computational capabilities are going to drive LSP > signaling itself - please note here the difference with the discovery > process through IGP extensions that is going to be put in place - but > the impact of the global PCE architecture on the independence wrt path > computation of the RSVP-TE protocol; hence, i always thought that the > CCAMP WG would have initially provided "guidelines" to the PCE WG before > such work would start in the PCE WG > > i hope you see that the issue is not about the "owning WG" or the > "reviewing WG" or their cooperation but the need to know more about the > acceptable level of integration/cooperation of the PCE architecture with > the operations on signaling LSP before deciding from where the wind will > come from > > hope this clarifies (at least a bit), > - dimitri. > > Adrian Farrel wrote: > > > Hi Dimitri, > > > > > >>it depends on the perspective, as such this document is meant to address > >>the following item of the charter (last part) > >> > >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > >>signaling (RSVP-TE) extensions required to support PCE-based path > >>computation models." > > > > > > No, it is not meant to address that part of the charter. That item remains > > unchanged by this discussion. > > > > JP's email is clearly specific to the documentation of requirements for > > PCE placed by the GMPLS protocols and non-packet networks under the > > control of GMPLS protocols. > > > > Our proposal is to develop all requirements for PCE within the PCE working > > group with review by the appropriate external working group. > > > > In practice, this only a small change since it is likely to be the same > > people involved in the work. It is, however, a formal change in CCAMP > > which previously had a commitment to work on these requirements. > > > > > >>therefore, it was my understanding that the PCE WG would be waiting for > >>the need wrt signaling for detailing its applicability; you (and adrian) > >>seems to say we will define the requirement for PCE-based inter-domain > >>path computation and resulting signaling behaviour/mechanisms would then > >>need to be adapted in CCAMP > >> > >>in brief, with your proposal PCE WG would be entering into a mode where > >>the computational capabilities are going to drive LSP signaling itself, > >>as an analogy RSVP-TE operations are decoupled from the routing > >>topology; so here, the same relationship should be kept with respect to > >>the computational scope/capabilities and behaviour of PCE(s) > > > > > > If you are objecting to the specific item on the PCE charter then now may > > be a little late, but let me explain the sort of thing that the charter > > item is intended to cover by giving a couple of examples. > > > > - PCE discovery may be achieved through the presence of > > information withing IGP advertisements. This would require changes > > to the IGPs and such changes MUST be reviewed by the > > appropriate WGs. > > > > - The use of a fully computed path that crosses multiple domains > > raises confidentiality issues. These issues can be solved by > > inserting new sub-objects into an RSVP-TE Explicit Route > > object (for example a cookie and PCE ID, or an encrypted > > hop). > > > > The normal way in which such small protocol changes are made (witness > > GMPLS additions to the IGPs) is either: > > a. An I-D is written and taken to the "owning" WG > > b. An I-D is written in the WG that needs the solutions and > > is reviewed in the "owning" WG. > > This process is usually refered to as "cooperation between WGs". > > The PCE charter proposes business as usual. > > > > Thanks, > > Adrian > > > > > > > >>>Dear WG, > >>> > >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. > >>> > >>>Considering the work which has been done by the PCE WG on > > > > requirements, it > > > >>>looks now more natural to move this work exclusively to the PCE WG. > >>> > >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > > > CCAMP, > > > >>>any requirements for PCE-based Inter-domain LSP computation should be > >>>discussed in the PCE WG *with* the review of the CCAMP WG. > >>> > >>>Similarly, non-packet networks may result in specific additional > >>>requirements for PCE. We propose that these requirements are also > > > > raised > > > >>>within the PCE working group and reviewed by CCAMP. > >>> > >>>Let us know if you have any opinion on or objection to these > > > > proposals. > > > >>>JP and Adrian (wearing PCE chair hat) > >>> > >>> > >>>. > >>> > >> > >> > >> > > > > > > > > . > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Aug 13 10:46:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xGq-0004Yb-9n; Sat, 13 Aug 2005 10:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xGo-0004YP-Qg for pce@megatron.ietf.org; Sat, 13 Aug 2005 10:45:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25326 for ; Sat, 13 Aug 2005 10:45:57 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3xpZ-0008Ol-0q for pce@ietf.org; Sat, 13 Aug 2005 11:21:53 -0400 Received: from du-069-0107.access.clara.net ([217.158.132.107] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E3xGn-0007Ny-DJ; Sat, 13 Aug 2005 15:45:57 +0100 Message-ID: <0dde01c5a016$16297eb0$08849ed9@Puppy> From: "Adrian Farrel" To: , "JP Vasseur" References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Sat, 13 Aug 2005 15:48:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks JP and scribes... Question (?). You are creating a new protocol. Did you do an analisys on existing protocols and reaons for not using them? ---> I believe this was Richard Rabbat (Oh, and that is "analysis" and "reasons" :-) Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Aug 13 11:27:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xuu-0002I3-Go; Sat, 13 Aug 2005 11:27:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xus-0002GE-DZ for pce@megatron.ietf.org; Sat, 13 Aug 2005 11:27:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26410 for ; Sat, 13 Aug 2005 11:27:20 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3yTa-0000im-C6 for pce@ietf.org; Sat, 13 Aug 2005 12:03:17 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id 53B71C4CC; Sat, 13 Aug 2005 11:27:06 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 13 Aug 2005 11:27:05 -0400 (EDT) Message-ID: <3917.68.100.80.11.1123946825.squirrel@webmail.movaz.com> In-Reply-To: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> Date: Sat, 13 Aug 2005 11:27:05 -0400 (EDT) Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 To: "JP Vasseur" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Score: 1.2 (+) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA26410 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, I have a couple of corrections. 1. Architecture document I made a comment that I disagree with the current definition of the distributed path computation. In the document: centralized path computation =3D computation performed by a single PCE distributed path computation =3D computation performed by multiple PCEs In my opinion: centralized path computation =3D path computation that returns all reques= ted paths in the *explicit* form in the first response, so that no more requests will be needed neither from the original requestor nor from any other PCCs for the service in question distributed path computation is when the original path computation reques= t is responded with at least one non-explicit path, so that more path computations will be issued from the original or some other PCCs. In other words from the original requestor point of view (which is ultimate user of the PCE service) it does not matter how many PCEs will b= e involved to satisfy its request, what is important is how many additional path computations is needed (0 -centralised path computation, >0 - distributed path computation). 2. WRT proposed PCEP solutions I made a comment that neither of them satisfies the requirement of the extensibility. Introducing new constraints, objection functions, diversity types, etc will be extreamely painful. Hence a meta-language style protocol should be considered Igor > (Please comment by August 27th) > > ---------------------------------- > PCE Working Group meeting minutes > ---------------------------------- > > IETF-63 - Paris, France - Tuesday, August 2, 2005. > > (Thanks to Jaudelice and Deborah for having taken the minutes) > > ------------------ > 1. Agenda (Adrian) > ------------------ > 1) Agenda/Admin (10mn) > 2) Progress against milestones (5mn) > 3) Drafts (55mn) > - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) > - draft-ietf-pce-discovery-reqs-01.txt (Le Roux =82=C4=EC 10mn) > - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) > - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) > - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) > - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) > 4) Working Group next steps (20mn) > > ----------------------------------- > 2. Progress against Milestones (JP) > ----------------------------------- > > 1. Submit first draft of PCE architecture document: done > 2. Submit first draft of PCE discovery requirements and protocol > extensions documents > (half-done: PCE discovery requirements ID is done) > 3. Submit first draft of the PCE communication protocol requirements > (done) > 4. Definition of the objective metrics (to be done later - more > progress required on other > IDs first) > 5. PCE communication protocol specification (decision to be made by > the WG soon) > > ----------------------------------------------------------------- > PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) > ----------------------------------------------------------------- > > Adrian thanked everyone that contributed to help get this version out > Mainly editorial revisions resulting from Minneapolis meeting have > been done (Clarifications, but nothing major) > More a framework, and an architecture overview and deployment scenarios. > Describes the architectural overview and building blocks > Many mailing list comments and private comments > Not any major substantial changes > Plan to add discussion of policy, will separate exchange of policy > info in the PCE communication and the use of policy within the > architecture > > Question (?): present a functional view as well as component view? > > Adrian: currently view point is third dimension > > Arthi: policy =96 how will it be addressed in the document? > > Adrian: the current doc will only have something high level =96 Lou > will provide draft text > > Igor: when I issue a path request, can I disallow paths requiring > distributed computation, > > Adrian: that=92s something for the computation > > Dimitri: is this the only document for policy or we will do something > else ? > > JP: we need requirements and solution detailed in a separate ID. > > Lou: we had discussion, as Adrian said, we will have later a > standalone document with more details after we have more discussion > in the WG > > Dimitri: in other WG, are discussing policy for interdomain, need > that for this group > > Adrian =96 agree > > Plans: architecture is believed to be stable but needs discussions > resulting from emails on the list. > > -----------------------------------------------------------------------= - > ---------- > Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt > (Jean-Louis) > -----------------------------------------------------------------------= - > ---------- > > Set of requiretments for automatic pce discovery > > comments and discussions on the list have been addressed in the new > version -01 > * multi-area example > * application scenario > * reorganized PCE info to be disclosed (mandatory versus optional) > > It must be noted that this is optional in the pce discovery > mechanism, not necessarily optional for pce architecture, > * extensibility section > * security requirements > * PCE capabilities definition is out of the scope (should be in a > separate document) > > Open issues: > - two stage discovery ? should limit to basic or include more > detailed - all as part of this document > - security trust model- need to detail requirements > - need feedback on discovery of pce power and congestion status =96 > should be part of this discovery mechanism or as part of a more > detailed requirements phase? > > Next steps: > > * address open issues > > Discussion > > Dimitri: the question on one or two stage, for me it=92s the question > how many pces will we have =96 if only a small group, then number of > sessions, with more detailed information, can be supported. Tradeoffs > if small set, and all receive information, or if a lot of PCEs, may > want only the subset that needs to know. > > JP: could use a flooding based mechanism > > Dimitri: but what is expected then on the use of this information ? > > Arthi: It is premature to talk about solution. Do we have a sense of > what direction we might be taking? On the section on scalability: > number of pce pccs are factors but also should consider the load on a > pce. > The details that you have might not be relevant to a PCE. > > Dimitri: should say if the info is of interest to all the pces or not > > Arthi: I=92m less concerned with the PCE if the PCE is itself a PCC > > Igor: Flooding is good, but it has problems: scalability and > security. You still want to know the capabilities of pce so you may > need to establish a session. > > JP: we may now be discussing solutions on how to do basic > capabilities and additional capabilities > > Igor: we will need this discussion though > > JP: I don=92t see this as pce discovery, this is a capabilities exchan= ge > > JL: Do you have an idea of a communication protocol > > Igor: It should not be flooding. > > JL: For general discovery we should use flooding. > > JL: You must be able to control to which pcc you will be disclosing > the information: all pccs in an area, etc. > > Adrian: the draft though today does include some capabilities > > Dimitri: can you provide requirements on more the dynamics needed for > these capabilities > > JP: A limited number of capabilities such as the congestion parameter > is likely to be dynamic > > Richard: propose discuss possible solutions over email exchange, even > though it=92s not to be included in the requirements, the discussion > helps to understand > > Arthi: agree should discuss to an extend some of the solutions > > JP: thanks to quickly resolve the set of open issues. The draft > should then be ready for Working Group LC. > > ------------------------------------------------ > PCE Communication Protocol=0B Generic Requirements > draft-ietf-pce-comm-protocol-gen-reqs-01.txt > (Jerry) > ----------------------------------------------- > > Generic requirements applicable to all PCEs > > application-specific requirements to be addressed in separate > requirements documents > > A table with a summary is included. > > Open Issues > > * requirements for less constrained path requests/response > * requirements for responsiveness & session maintenance > * detailed requirements on throttling messages under overload > * specify =91boundary=92 numbers on scalability > * clearly state supported policy models & corresponding requirements/ > implications > * avoid feature creep > * need to progress application-specific requirements > * PCE protocol proposal needs to identify how generic & application- > specific requirements are met > > Discussion: > > JP: Detailed scalability issues are related to implementation. > > Adrian: we need a range as don=92t want protocol to provide the limit > > JP: on the less-constrained path computation topic, we don=92t have a > consensus yet, we should have a separate document > > Arthi: we had a discussion in the pwe group that there may be > requirements for pce > > Adrian: by us splitting the document between generic and extended > reqs (more application specific) we could handle this better > > Arthi: also though may not be in scope > > Adrian: yes we should say if it=92s out of scope > > Arthi: Some new requirements may come up for PCE, we need to have a > plan on how to address that. > > Adrian: The document is extensible. > > Arthi: We might see other consumers of PCE > > JP: Sure and the protocol should be designed to handle extensions so > as to meet new requirements but we may need to recharter > > --------------------------------------------- > PCE Communication Protocol Application Model > draft-zhang-pce-comm-app-model-01.txt > (Zhang) > -------------------------------------------- > > * how to avoid contention with TE link fails > * how to load balance among PCEs > * how to update the PCEs about resource allocation > > JP asked who has read the draft: good show of hands > > Adrian: rather than saying this is the way forward, would prefer > emphasis on what are the requirements > > (coauthor of the draft ??): this draft addresses a way to ... > > Adrian: yes, this draft has requirements on an implementation, would > like first to see top level requirements and architecture > > Igor: one of the requirements for the protocol is getting updates, etc, > > Adrian: first need requirements > > Igor: my view this is not a signaling protocol, not rsvp, we > shouldn=92t go thru the process of using a signaling protocol > > JL: I have a major concern on scalability with the draft=92s approach, > one major bottleneck is on the PCE-PCE signaling, we should minimize > the signaling, the objective is to have distribution to reduce this, > whereas this draft re-introduces this overhead for synchronization. > You are redefining the concept of cluster. Why not use the PCE engine? > One major bottleneck on the PCE architecture is the pcc-pce > signalling. To ensure path computation, reduce the number of path > computation requirements received by a pce. > > Author: it does not consume much bandwidth. > > JL: It is not a problem of bandwidth but communication overhead. > > JP: I have similar concerns. Have you tried to evaluate what would be > the overhead in term of extra signaling due to this mechanism? One > way to roughly evaluate would be by using simulations. > > Adrian: best for us to discuss over email to provide adequate time > for the discussion. > > ------------------------------------------------------------- > Path Computation Element (PCE) communication Protocol (PCEP) > draft-vasseur-pce-pcep-01.txt > (JP) > -------------------------------------------------------------- > > PCC-PCE and between PCEs communication > > There were two proposals in the past which were discontinued and a > completely new protocol has been designed (PCEP) highly driven by the > PCE WG requirement document. Chief objective was to make it > extensible to cope with future requirements. > > Major changes from 00 to 01: > * rewritten for clarity > * few sections removed > * new section on protocol model > * added security consideration > * very rough manageability consideration section added (to be fleshed > out) > * two new objects defined > > Unique communication protocol for PCC-PCE and PCE-PCE. > > Summary =96 pcep meets most of the requirements. > > Open issues (need inputs from the working group) > > * Objective functions needs to be defined (next revision) > * Protocol recovery: requires more detailed requirements > * Policy: requires more discussion > > Discussion > > Bijan Jabbari: What was the reason for TCP? > > JP: reliability and flow control. TCP was a very good candidate for > that. > > Bijan: Question of scalability of TCP. > > JP (vendor hat): We do not see any scalability issue with TCP. > Current TCP implementations can support a very high number of TCP > sessions. > > Question (?). You are creating a new protocol. Did you do an analisys > on existing protocols and reaons for not using them? > > Adrian: yes we did , but here formal requirement for the WG to take > reqs to other groups to ask if have anything, so this draft > progressing depends on answer. > > Lou: Many protocols have been worked on. Instead of reinventing the > weel, why not use one already existing. What we are doing here in > path computation is a new application, but session application (keep > alive, discovery) have been resolved before and it would be great to > concentrate on what is related to pce. > > Adrian: great if we can learn lessons > > Lou: and reuse > > Adrian: agree > > Dimitri: agree as Lou said > > Lou: session management, keep alives, etc have been done already > > JP: the question is, is there anything specifics to PCE that we need > a new protocol > > Dimitri: With a new solution we will have to pass all the stages the > others have passed to achieve a robust solution. > > JP: That's why we have the question here. > > Adrian: yes, this protocol in this draft has not been selected > > Bijan: If this is IP only, was DNS discussed? > > Adrian: this is IP only > > Bijan: have we looked at DNS ? > > Adrian: bring it to the list to suggest > > Lou: Comment on need to go back and use an existing mechanism > whenever you can. > > JP: yes, whenever you can. > > Loa: if we have TCP, then we have a basis, to do more, we need > justification, > JP: agree > > Jerry: can you include what is met and not met on requirements into > the draft ? > > JP: ok, will do. > > Jerry: if we do not have a list of requirements, how can we proceed? > > Yakov: Comment on the need for protocol specific keep-alive: we need > a PCE specific keep-alive protocol since TCP will not take care of it. > > JP: fully agree. > > Lou: You need keep-alive (TCP-based solutions already have keep- > alives). Find out what's the requirement, then lift the existing > solution. > > Lou: my comment is to look at experience =96 e.g. if need keepalives, > it=92s a mistake to look at this again without considering previous > work, and do all the requirements all over again, should look at > existing protocols, transaction semantics > > Adrian: yes, persistency should be addressed in the requirements > > Sue: keepalives in a protocol is needed in addition to tcp, need to > pay careful attention to the state machine interaction between the > two =96 pcc-pce. Need to ensure handle failure scenarios, noticed > missing here some of what protocol has to solve, should feed back > into requirements > > JP: Sometimes you do not want a permanent session, and sometimes you > do. Do we need two modes? > > Adrian: question should be asked to the requirements team. > > JL: we should be more flexible and support both request and permanent > as it will depend on the request, and number of pces to maintain, may > have a full mesh and may not want to maintain a permanent > > JP: this is what we heard =96 may only need on request, other times > will need permanent, so may want both modes, and negotiate upon > session establishment. > > Adrian: when doing the solutions and have a question, should take > back to the requirements folks > > JP: Less-constrained path computation aspects will be removed from > this draft and be worked out in a separate ID. > > ------------------------------------------------ > Path Computation Element Metric Protocol (PCEMP) > draft-choi-pce-metric-protocol-02.txt > (Dipnarayan Guha) > ------------------------------------------------ > > PCE metric protocol (PCEMP): generic routing and path computation > protocol targeted towards inter-domain pce peers. > > Reviewed slides > > JP: we encourage you to provide simulation results to the mailing > list it will help > > No discussion > > ------------------------------ > working group next steps (JP) > ------------------------------ > > - new revision of the PCE architecture ID to be published soon (WG > last call soon after this ietf) > - new revision of the generic pce communication requirement ID (WG > last call soon after this ietf) > - submit a new ID for pce discovery protocol extensions (minor > protocol work only) > > Start application-specific requirements IDs for PCE based computation > > *Inter-area: Jean-Louis > *Inter-As: Raymond, Nabil > > JP: note that such ID must be PCE-specific (take into account RFC4105 > and inter-as requirements ID produced by the TE WG). > > Adrian: WG to decide on which pce communication protocol solution to > pursue > - two proposals presented > - selection of one solution as a basis now does not imply rejecting > good points of other solution nor accepting bad points of selected > solutions. > If pick one, that does not prevent us from taking the best of other > one also, and also other ietf protocols. email will be sent to the > application ADs to ask their input. > > - New ID on the less contrained path problem comprising the > requirement + solution > > - Need to verify the solution model for inter-domain pce with CCAMP, > MPLS working groups > > Adrian =96 other application specific requirements IDs (interlayer, > p2mp) should continue their work, just realize other work needs to be > done first: > inter-layer: Eiji, Kenji > P2MP: Seisho (currently out of scope of PCE WG charter) > > Thanks. > > JP. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 14 07:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4GEL-0006kl-9w; Sun, 14 Aug 2005 07:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4GEJ-0006kg-NI for pce@megatron.ietf.org; Sun, 14 Aug 2005 07:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21011 for ; Sun, 14 Aug 2005 07:00:36 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4GnB-0002Sp-DX for pce@ietf.org; Sun, 14 Aug 2005 07:36:44 -0400 Received: from du-069-0169.access.clara.net ([217.158.132.169] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E4GE1-00082Y-Gh; Sun, 14 Aug 2005 12:00:23 +0100 Message-ID: <0e2701c5a0bf$bca14350$08849ed9@Puppy> From: "Adrian Farrel" To: , "JP Vasseur" References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> <3917.68.100.80.11.1123946825.squirrel@webmail.movaz.com> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Sun, 14 Aug 2005 10:50:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Yes, we should record Igor's comments in the minutes as he made them. However, I would like to tackle them here. > 1. Architecture document > > I made a comment that I disagree with the current definition of the > distributed path computation. > > In the document: > centralized path computation = computation performed by a single PCE > distributed path computation = computation performed by multiple PCEs > > In my opinion: > centralized path computation = path computation that returns all requested > paths in the *explicit* form in the first response, so that no more > requests will be needed neither from the original requestor nor from any > other PCCs for the service in question Hmmm. So in this model a single PCE would be responsible for returning the complete path and no other PCE would be invoked. This is, of course, very close to the existing definition of "centralized path computation" since if there is only one PCE there is no option but to compute the entire path on that PCE. However, your definition would allow more than one PCE in the network, but still have only one PCE consulted for any individual path. This mode of operation is called "single PCE path computation" to contrast with "multiple PCE path computation" in the draft. > distributed path computation is when the original path computation request > is responded with at least one non-explicit path, so that more path > computations will be issued from the original or some other PCCs. This, of course, is strikingly similar to the definition of distributed path computation in the draft. That is, the path is computed by more than one PCE. However, your definition states that a path will be computed by multiple PCE consultation, while the current definition of distributed path computation states that multiple PCEs are servicing the requests in the network. Your definition matches the definition of "multiple PCE path computation" in the draft. I see absolutely zero value in quibbling about the name given to a concept when the concepts are identical and are all covered by the existing I-D. > In other words from the original requestor point of view (which is > ultimate user of the PCE service) it does not matter how many PCEs will be > involved to satisfy its request, what is important is how many additional > path computations is needed (0 -centralised > path computation, >0 - distributed path computation). We agree that there may be some value in distinguishing the behavior from the point of view of the requester. There are exactly three cases for the requester: 1. The requester sends a single request to exactly one PCE and gets enough information to make use of the response. 2. The requester must send more than one request to exactly one PCE in order to get enough information to make use of the responses. 3. The requester must send requests to more than one PCE to get enough information to make use of the responses. In none of these case is the requester, the PCC, aware of whether some other LSR in the network will subsequently need to consult other PCEs. Arhcitecturally, it should not be aware of this fact. From a protocol perspective it must not be aware of this fact. Adding a description of the behavior from the persepective of the PCC can be done. However, it will not change the definitions of the terms that describe the overall architecture. It will introduce new terms to describe the behavior. > 2. WRT proposed PCEP solutions I made a comment that neither of them > satisfies the requirement of the extensibility. Introducing new > constraints, objection functions, diversity types, etc will be extreamely > painful. Hence a meta-language style protocol should be considered You are correct that we should consider a meta-language style protocol although unless someone brings a draft to the table we will not consider one. That is, you cannot mandate that the working group must develop a particular style of protocol - we can only consider what we have in front of us in terms of proposals that people are prepared to develop and implement. I do not believe that you are correct to state that a TLV-based protocol is extremely painful to extend. Our experience of very many such protocols show that they are fairly simple to extend. It is possible that you could supply a specific example of an extension that you think is both likely to be required and which you consider would be hard to encode in a TLV. To do this you would need to supply a detailed description of the information that you want to encode - it would not be enough to say "diversity types". Other people could then demonstrate that such an extension could be encoded. I should point out, however, that a TLV is capable of encoding a text string - this means that pretty much anything can be encoded within a TLV. Whatever, such a proof-by-example style of reasoning is unlikely to get us very far. If a meta-language style protocol is to be considered, we need to see it and know that it is being implemented. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 14 07:47:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Gy3-0004K3-BC; Sun, 14 Aug 2005 07:47:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Gy2-0004Jy-Ha for pce@megatron.ietf.org; Sun, 14 Aug 2005 07:47:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22479 for ; Sun, 14 Aug 2005 07:47:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4HWx-0003Rl-1N for pce@ietf.org; Sun, 14 Aug 2005 08:23:59 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4Gxt-000MST-Cn; Sun, 14 Aug 2005 11:47:46 +0000 Message-ID: <42FF2F5C.1070107@psg.com> Date: Sun, 14 Aug 2005 13:47:40 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> In-Reply-To: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 233de1b21593fc0f4cdf285406dca0da Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA22479 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jp - some clarifications here below JP Vasseur wrote: > (Please comment by August 27th) >=20 > ---------------------------------- > PCE Working Group meeting minutes > ---------------------------------- >=20 > IETF-63 - Paris, France - Tuesday, August 2, 2005. >=20 > (Thanks to Jaudelice and Deborah for having taken the minutes) >=20 > ------------------ > 1. Agenda (Adrian) > ------------------ > 1) Agenda/Admin (10mn) > 2) Progress against milestones (5mn) > 3) Drafts (55mn) > - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) > - draft-ietf-pce-discovery-reqs-01.txt (Le Roux =82=C4=EC 10mn) > - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) > - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) > - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) > - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) > 4) Working Group next steps (20mn) >=20 > ----------------------------------- > 2. Progress against Milestones (JP) > ----------------------------------- >=20 > 1. Submit first draft of PCE architecture document: done > 2. Submit first draft of PCE discovery requirements and protocol =20 > extensions documents > (half-done: PCE discovery requirements ID is done) > 3. Submit first draft of the PCE communication protocol requirements =20 > (done) > 4. Definition of the objective metrics (to be done later - more =20 > progress required on other > IDs first) > 5. PCE communication protocol specification (decision to be made by th= e=20 > WG soon) >=20 > ----------------------------------------------------------------- > PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) > ----------------------------------------------------------------- >=20 > Adrian thanked everyone that contributed to help get this version out > Mainly editorial revisions resulting from Minneapolis meeting have bee= n=20 > done (Clarifications, but nothing major) > More a framework, and an architecture overview and deployment scenarios. > Describes the architectural overview and building blocks > Many mailing list comments and private comments > Not any major substantial changes > Plan to add discussion of policy, will separate exchange of policy inf= o=20 > in the PCE communication and the use of policy within the architecture >=20 > Question (?): present a functional view as well as component view? >=20 > Adrian: currently view point is third dimension >=20 > Arthi: policy =96 how will it be addressed in the document? >=20 > Adrian: the current doc will only have something high level =96 Lou wi= ll=20 > provide draft text >=20 > Igor: when I issue a path request, can I disallow paths requiring =20 > distributed computation, >=20 > Adrian: that=92s something for the computation >=20 > Dimitri: is this the only document for policy or we will do something =20 > else ? >=20 > JP: we need requirements and solution detailed in a separate ID. >=20 > Lou: we had discussion, as Adrian said, we will have later a standalon= e=20 > document with more details after we have more discussion in the WG >=20 > Dimitri: in other WG, are discussing policy for interdomain, need that= =20 > for this group -> "Other WG have shown that the main pre-occupation for RSVP-TE as=20 inter-domain signaling protocol is the policy at the domain boundaries=20 therefore is it an essential element this WG must address" > Adrian =96 agree >=20 > Plans: architecture is believed to be stable but needs discussions =20 > resulting from emails on the list. >=20 > -----------------------------------------------------------------------= -=20 > ---------- > Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt =20 > (Jean-Louis) > -----------------------------------------------------------------------= -=20 > ---------- >=20 > Set of requiretments for automatic pce discovery >=20 > comments and discussions on the list have been addressed in the new =20 > version -01 > * multi-area example > * application scenario > * reorganized PCE info to be disclosed (mandatory versus optional) >=20 > It must be noted that this is optional in the pce discovery mechanism,= =20 > not necessarily optional for pce architecture, > * extensibility section > * security requirements > * PCE capabilities definition is out of the scope (should be in a =20 > separate document) >=20 > Open issues: > - two stage discovery ? should limit to basic or include more detailed= =20 > - all as part of this document > - security trust model- need to detail requirements > - need feedback on discovery of pce power and congestion status =96 =20 > should be part of this discovery mechanism or as part of a more =20 > detailed requirements phase? >=20 > Next steps: >=20 > * address open issues >=20 > Discussion >=20 > Dimitri: the question on one or two stage, for me it=92s the question = how=20 > many pces will we have =96 if only a small group, then number of =20 > sessions, with more detailed information, can be supported. Tradeoffs =20 > if small set, and all receive information, or if a lot of PCEs, may =20 > want only the subset that needs to know. -> "Dimitri: the question on one or two stage, for me it=92s the question= =20 how many PCCs will subscribe to the initial PCE advertisement =96 if=20 only a small group of PCCs at each point in time, then a certain number=20 of sessions, with more detailed information, can be supported. Hence,=20 there is a tradeoff, with a small set, a two stage approach with a=20 dedicated for exchanging more detailed information can be used". > JP: could use a flooding based mechanism >=20 > Dimitri: but what is expected then on the use of this information ? >=20 > Arthi: It is premature to talk about solution. Do we have a sense of =20 > what direction we might be taking? On the section on scalability: =20 > number of pce pccs are factors but also should consider the load on a = pce. > The details that you have might not be relevant to a PCE. >=20 > Dimitri: should say if the info is of interest to all the pces or not replace PCEs by PCCs > Arthi: I=92m less concerned with the PCE if the PCE is itself a PCC >=20 > Igor: Flooding is good, but it has problems: scalability and security.= =20 > You still want to know the capabilities of pce so you may need to=20 > establish a session. >=20 > JP: we may now be discussing solutions on how to do basic capabilities= =20 > and additional capabilities >=20 > Igor: we will need this discussion though >=20 > JP: I don=92t see this as pce discovery, this is a capabilities exchan= ge >=20 > JL: Do you have an idea of a communication protocol >=20 > Igor: It should not be flooding. >=20 > JL: For general discovery we should use flooding. >=20 > JL: You must be able to control to which pcc you will be disclosing th= e=20 > information: all pccs in an area, etc. >=20 > Adrian: the draft though today does include some capabilities >=20 > Dimitri: can you provide requirements on more the dynamics needed for =20 > these capabilities -> "Dimitri: can you provide more detailed requirements on the dynamics=20 needed for these capabilities" > JP: A limited number of capabilities such as the congestion parameter =20 > is likely to be dynamic >=20 > Richard: propose discuss possible solutions over email exchange, even =20 > though it=92s not to be included in the requirements, the discussion =20 > helps to understand >=20 > Arthi: agree should discuss to an extend some of the solutions >=20 > JP: thanks to quickly resolve the set of open issues. The draft should= =20 > then be ready for Working Group LC. >=20 > ------------------------------------------------ > PCE Communication Protocol=0B Generic Requirements > draft-ietf-pce-comm-protocol-gen-reqs-01.txt > (Jerry) > ----------------------------------------------- >=20 > Generic requirements applicable to all PCEs >=20 > application-specific requirements to be addressed in separate =20 > requirements documents >=20 > A table with a summary is included. >=20 > Open Issues >=20 > * requirements for less constrained path requests/response > * requirements for responsiveness & session maintenance > * detailed requirements on throttling messages under overload > * specify =91boundary=92 numbers on scalability > * clearly state supported policy models & corresponding requirements/=20 > implications > * avoid feature creep > * need to progress application-specific requirements > * PCE protocol proposal needs to identify how generic & application-=20 > specific requirements are met >=20 > Discussion: >=20 > JP: Detailed scalability issues are related to implementation. >=20 > Adrian: we need a range as don=92t want protocol to provide the limit >=20 > JP: on the less-constrained path computation topic, we don=92t have a =20 > consensus yet, we should have a separate document >=20 > Arthi: we had a discussion in the pwe group that there may be =20 > requirements for pce >=20 > Adrian: by us splitting the document between generic and extended reqs= =20 > (more application specific) we could handle this better >=20 > Arthi: also though may not be in scope >=20 > Adrian: yes we should say if it=92s out of scope >=20 > Arthi: Some new requirements may come up for PCE, we need to have a =20 > plan on how to address that. >=20 > Adrian: The document is extensible. >=20 > Arthi: We might see other consumers of PCE >=20 > JP: Sure and the protocol should be designed to handle extensions so a= s=20 > to meet new requirements but we may need to recharter >=20 > --------------------------------------------- > PCE Communication Protocol Application Model > draft-zhang-pce-comm-app-model-01.txt > (Zhang) > -------------------------------------------- >=20 > * how to avoid contention with TE link fails > * how to load balance among PCEs > * how to update the PCEs about resource allocation >=20 > JP asked who has read the draft: good show of hands >=20 > Adrian: rather than saying this is the way forward, would prefer =20 > emphasis on what are the requirements >=20 > (coauthor of the draft ??): this draft addresses a way to ... >=20 > Adrian: yes, this draft has requirements on an implementation, would =20 > like first to see top level requirements and architecture >=20 > Igor: one of the requirements for the protocol is getting updates, etc, >=20 > Adrian: first need requirements >=20 > Igor: my view this is not a signaling protocol, not rsvp, we shouldn=92= t=20 > go thru the process of using a signaling protocol >=20 > JL: I have a major concern on scalability with the draft=92s approach, = =20 > one major bottleneck is on the PCE-PCE signaling, we should minimize =20 > the signaling, the objective is to have distribution to reduce this, =20 > whereas this draft re-introduces this overhead for synchronization. Yo= u=20 > are redefining the concept of cluster. Why not use the PCE engine? > One major bottleneck on the PCE architecture is the pcc-pce signalling= .=20 > To ensure path computation, reduce the number of path computation=20 > requirements received by a pce. >=20 > Author: it does not consume much bandwidth. >=20 > JL: It is not a problem of bandwidth but communication overhead. >=20 > JP: I have similar concerns. Have you tried to evaluate what would be =20 > the overhead in term of extra signaling due to this mechanism? One way= =20 > to roughly evaluate would be by using simulations. >=20 > Adrian: best for us to discuss over email to provide adequate time for= =20 > the discussion. >=20 > ------------------------------------------------------------- > Path Computation Element (PCE) communication Protocol (PCEP)=0B > draft-vasseur-pce-pcep-01.txt > (JP) > -------------------------------------------------------------- >=20 > PCC-PCE and between PCEs communication >=20 > There were two proposals in the past which were discontinued and a =20 > completely new protocol has been designed (PCEP) highly driven by the =20 > PCE WG requirement document. Chief objective was to make it extensible= =20 > to cope with future requirements. >=20 > Major changes from 00 to 01: > * rewritten for clarity > * few sections removed > * new section on protocol model > * added security consideration > * very rough manageability consideration section added (to be fleshed = out) > * two new objects defined >=20 > Unique communication protocol for PCC-PCE and PCE-PCE. >=20 > Summary =96 pcep meets most of the requirements. >=20 > Open issues (need inputs from the working group) >=20 > * Objective functions needs to be defined (next revision) > * Protocol recovery: requires more detailed requirements > * Policy: requires more discussion >=20 > Discussion >=20 > Bijan Jabbari: What was the reason for TCP? >=20 > JP: reliability and flow control. TCP was a very good candidate for th= at. >=20 > Bijan: Question of scalability of TCP. >=20 > JP (vendor hat): We do not see any scalability issue with TCP. Current= =20 > TCP implementations can support a very high number of TCP sessions. >=20 > Question (?). You are creating a new protocol. Did you do an analisys =20 > on existing protocols and reaons for not using them? >=20 > Adrian: yes we did , but here formal requirement for the WG to take =20 > reqs to other groups to ask if have anything, so this draft progressin= g=20 > depends on answer. >=20 > Lou: Many protocols have been worked on. Instead of reinventing the =20 > weel, why not use one already existing. What we are doing here in path= =20 > computation is a new application, but session application (keep alive,= =20 > discovery) have been resolved before and it would be great to =20 > concentrate on what is related to pce. >=20 > Adrian: great if we can learn lessons >=20 > Lou: and reuse >=20 > Adrian: agree >=20 > Dimitri: agree as Lou said >=20 > Lou: session management, keep alives, etc have been done already >=20 > JP: the question is, is there anything specifics to PCE that we need a= =20 > new protocol >=20 > Dimitri: With a new solution we will have to pass all the stages the =20 > others have passed to achieve a robust solution. -> Add: "Therefore, protocol solutions already developed by other WGs=20 should be considered and evaluated wrt requirements provided by this=20 working group so as to concentrate on the PCE specifics" > JP: That's why we have the question here. >=20 > Adrian: yes, this protocol in this draft has not been selected >=20 > Bijan: If this is IP only, was DNS discussed? >=20 > Adrian: this is IP only >=20 > Bijan: have we looked at DNS ? >=20 > Adrian: bring it to the list to suggest >=20 > Lou: Comment on need to go back and use an existing mechanism whenever= =20 > you can. >=20 > JP: yes, whenever you can. >=20 > Loa: if we have TCP, then we have a basis, to do more, we need =20 > justification, > JP: agree >=20 > Jerry: can you include what is met and not met on requirements into th= e=20 > draft ? >=20 > JP: ok, will do. >=20 > Jerry: if we do not have a list of requirements, how can we proceed? >=20 > Yakov: Comment on the need for protocol specific keep-alive: we need a= =20 > PCE specific keep-alive protocol since TCP will not take care of it. >=20 > JP: fully agree. >=20 > Lou: You need keep-alive (TCP-based solutions already have keep-=20 > alives). Find out what's the requirement, then lift the existing solut= ion. >=20 > Lou: my comment is to look at experience =96 e.g. if need keepalives, =20 > it=92s a mistake to look at this again without considering previous wo= rk,=20 > and do all the requirements all over again, should look at existing=20 > protocols, transaction semantics >=20 > Adrian: yes, persistency should be addressed in the requirements >=20 > Sue: keepalives in a protocol is needed in addition to tcp, need to pa= y=20 > careful attention to the state machine interaction between the two =96= =20 > pcc-pce. Need to ensure handle failure scenarios, noticed missing here= =20 > some of what protocol has to solve, should feed back into requirements >=20 > JP: Sometimes you do not want a permanent session, and sometimes you =20 > do. Do we need two modes? >=20 > Adrian: question should be asked to the requirements team. >=20 > JL: we should be more flexible and support both request and permanent =20 > as it will depend on the request, and number of pces to maintain, may =20 > have a full mesh and may not want to maintain a permanent >=20 > JP: this is what we heard =96 may only need on request, other times wi= ll=20 > need permanent, so may want both modes, and negotiate upon session=20 > establishment. >=20 > Adrian: when doing the solutions and have a question, should take back= =20 > to the requirements folks >=20 > JP: Less-constrained path computation aspects will be removed from thi= s=20 > draft and be worked out in a separate ID. >=20 > ------------------------------------------------ > Path Computation Element Metric Protocol (PCEMP)=0B > draft-choi-pce-metric-protocol-02.txt > (Dipnarayan Guha) > ------------------------------------------------ >=20 > PCE metric protocol (PCEMP): generic routing and path computation =20 > protocol targeted towards inter-domain pce peers. >=20 > Reviewed slides >=20 > JP: we encourage you to provide simulation results to the mailing list= =20 > it will help >=20 > No discussion >=20 > ------------------------------ > working group next steps (JP) > ------------------------------ >=20 > - new revision of the PCE architecture ID to be published soon (WG las= t=20 > call soon after this ietf) > - new revision of the generic pce communication requirement ID (WG las= t=20 > call soon after this ietf) > - submit a new ID for pce discovery protocol extensions (minor protoco= l=20 > work only) >=20 > Start application-specific requirements IDs for PCE based computation >=20 > *Inter-area: Jean-Louis > *Inter-As: Raymond, Nabil >=20 > JP: note that such ID must be PCE-specific (take into account RFC4105 =20 > and inter-as requirements ID produced by the TE WG). >=20 > Adrian: WG to decide on which pce communication protocol solution to =20 > pursue > - two proposals presented > - selection of one solution as a basis now does not imply rejecting =20 > good points of other solution nor accepting bad points of selected =20 > solutions. > If pick one, that does not prevent us from taking the best of other on= e=20 > also, and also other ietf protocols. email will be sent to the =20 > application ADs to ask their input. >=20 > - New ID on the less contrained path problem comprising the requiremen= t=20 > + solution >=20 > - Need to verify the solution model for inter-domain pce with CCAMP, =20 > MPLS working groups >=20 > Adrian =96 other application specific requirements IDs (interlayer, p2= mp)=20 > should continue their work, just realize other work needs to be done=20 > first: > inter-layer: Eiji, Kenji > P2MP: Seisho (currently out of scope of PCE WG charter) >=20 > Thanks. >=20 > JP. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 > . >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 14 11:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4KEJ-0006TV-Sh; Sun, 14 Aug 2005 11:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4KEH-0006TM-T8 for pce@megatron.ietf.org; Sun, 14 Aug 2005 11:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00079 for ; Sun, 14 Aug 2005 11:16:51 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4KnE-00072B-Cq for pce@ietf.org; Sun, 14 Aug 2005 11:53:01 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2005 11:16:44 -0400 X-IronPort-AV: i="3.96,105,1122868800"; d="scan'208"; a="66434831:sNHT38179776" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7EFGdQn029808; Sun, 14 Aug 2005 11:16:41 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Aug 2005 11:16:41 -0400 Received: from [192.168.1.102] ([10.86.240.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Aug 2005 11:16:40 -0400 In-Reply-To: <42FF2F5C.1070107@psg.com> References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> <42FF2F5C.1070107@psg.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <4FBDAA17-5A8B-4FD0-BCE8-8A6E95D76BC7@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Sun, 14 Aug 2005 11:17:08 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 14 Aug 2005 15:16:40.0443 (UTC) FILETIME=[2BE5D4B0:01C5A0E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Thanks. Minutes will be updated accordingly. JP. On Aug 14, 2005, at 7:47 AM, dimitri papadimitriou wrote: > hi jp - some clarifications here below > > JP Vasseur wrote: > > >> (Please comment by August 27th) >> ---------------------------------- >> PCE Working Group meeting minutes >> ---------------------------------- >> IETF-63 - Paris, France - Tuesday, August 2, 2005. >> (Thanks to Jaudelice and Deborah for having taken the minutes) >> ------------------ >> 1. Agenda (Adrian) >> ------------------ >> 1) Agenda/Admin (10mn) >> 2) Progress against milestones (5mn) >> 3) Drafts (55mn) >> - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) >> - draft-ietf-pce-discovery-reqs-01.txt (Le Roux =82=C4=EC 10mn) >> - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) >> - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) >> - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) >> - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) >> 4) Working Group next steps (20mn) >> ----------------------------------- >> 2. Progress against Milestones (JP) >> ----------------------------------- >> 1. Submit first draft of PCE architecture document: done >> 2. Submit first draft of PCE discovery requirements and protocol =20 >> extensions documents >> (half-done: PCE discovery requirements ID is done) >> 3. Submit first draft of the PCE communication protocol =20 >> requirements (done) >> 4. Definition of the objective metrics (to be done later - more =20 >> progress required on other >> IDs first) >> 5. PCE communication protocol specification (decision to be made =20 >> by the WG soon) >> ----------------------------------------------------------------- >> PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) >> ----------------------------------------------------------------- >> Adrian thanked everyone that contributed to help get this version out >> Mainly editorial revisions resulting from Minneapolis meeting =20 >> have been done (Clarifications, but nothing major) >> More a framework, and an architecture overview and deployment =20 >> scenarios. >> Describes the architectural overview and building blocks >> Many mailing list comments and private comments >> Not any major substantial changes >> Plan to add discussion of policy, will separate exchange of =20 >> policy info in the PCE communication and the use of policy within =20= >> the architecture >> Question (?): present a functional view as well as component view? >> Adrian: currently view point is third dimension >> Arthi: policy =96 how will it be addressed in the document? >> Adrian: the current doc will only have something high level =96 Lou =20= >> will provide draft text >> Igor: when I issue a path request, can I disallow paths requiring =20= >> distributed computation, >> Adrian: that=92s something for the computation >> Dimitri: is this the only document for policy or we will do =20 >> something else ? >> JP: we need requirements and solution detailed in a separate ID. >> Lou: we had discussion, as Adrian said, we will have later a =20 >> standalone document with more details after we have more =20 >> discussion in the WG >> Dimitri: in other WG, are discussing policy for interdomain, need =20= >> that for this group >> > > -> "Other WG have shown that the main pre-occupation for RSVP-TE as =20= > inter-domain signaling protocol is the policy at the domain =20 > boundaries therefore is it an essential element this WG must address" > > >> Adrian =96 agree >> Plans: architecture is believed to be stable but needs =20 >> discussions resulting from emails on the list. >> ---------------------------------------------------------------------=20= >> --- ---------- >> Requirements for PCE Discovery: draft-ietf-pce-discovery-=20 >> reqs-01.txt (Jean-Louis) >> ---------------------------------------------------------------------=20= >> --- ---------- >> Set of requiretments for automatic pce discovery >> comments and discussions on the list have been addressed in the =20 >> new version -01 >> * multi-area example >> * application scenario >> * reorganized PCE info to be disclosed (mandatory versus optional) >> It must be noted that this is optional in the pce discovery =20 >> mechanism, not necessarily optional for pce architecture, >> * extensibility section >> * security requirements >> * PCE capabilities definition is out of the scope (should be in a =20= >> separate document) >> Open issues: >> - two stage discovery ? should limit to basic or include more =20 >> detailed - all as part of this document >> - security trust model- need to detail requirements >> - need feedback on discovery of pce power and congestion status =96 =20= >> should be part of this discovery mechanism or as part of a more =20 >> detailed requirements phase? >> Next steps: >> * address open issues >> Discussion >> Dimitri: the question on one or two stage, for me it=92s the =20 >> question how many pces will we have =96 if only a small group, then =20= >> number of sessions, with more detailed information, can be =20 >> supported. Tradeoffs if small set, and all receive information, =20 >> or if a lot of PCEs, may want only the subset that needs to know. >> > > -> "Dimitri: the question on one or two stage, for me it=92s the =20 > question how many PCCs will subscribe to the initial PCE =20 > advertisement =96 if only a small group of PCCs at each point in =20 > time, then a certain number of sessions, with more detailed =20 > information, can be supported. Hence, there is a tradeoff, with a =20 > small set, a two stage approach with a dedicated for exchanging =20 > more detailed information can be used". > > >> JP: could use a flooding based mechanism >> Dimitri: but what is expected then on the use of this information ? >> Arthi: It is premature to talk about solution. Do we have a sense =20 >> of what direction we might be taking? On the section on =20 >> scalability: number of pce pccs are factors but also should =20 >> consider the load on a pce. >> The details that you have might not be relevant to a PCE. >> Dimitri: should say if the info is of interest to all the pces or not >> > > replace PCEs by PCCs > > >> Arthi: I=92m less concerned with the PCE if the PCE is itself a PCC >> Igor: Flooding is good, but it has problems: scalability and =20 >> security. You still want to know the capabilities of pce so you =20 >> may need to establish a session. >> JP: we may now be discussing solutions on how to do basic =20 >> capabilities and additional capabilities >> Igor: we will need this discussion though >> JP: I don=92t see this as pce discovery, this is a capabilities =20 >> exchange >> JL: Do you have an idea of a communication protocol >> Igor: It should not be flooding. >> JL: For general discovery we should use flooding. >> JL: You must be able to control to which pcc you will be =20 >> disclosing the information: all pccs in an area, etc. >> Adrian: the draft though today does include some capabilities >> Dimitri: can you provide requirements on more the dynamics needed =20 >> for these capabilities >> > > -> "Dimitri: can you provide more detailed requirements on the =20 > dynamics needed for these capabilities" > > >> JP: A limited number of capabilities such as the congestion =20 >> parameter is likely to be dynamic >> Richard: propose discuss possible solutions over email exchange, =20 >> even though it=92s not to be included in the requirements, the =20 >> discussion helps to understand >> Arthi: agree should discuss to an extend some of the solutions >> JP: thanks to quickly resolve the set of open issues. The draft =20 >> should then be ready for Working Group LC. >> ------------------------------------------------ >> PCE Communication Protocol=0B Generic Requirements >> draft-ietf-pce-comm-protocol-gen-reqs-01.txt >> (Jerry) >> ----------------------------------------------- >> Generic requirements applicable to all PCEs >> application-specific requirements to be addressed in separate =20 >> requirements documents >> A table with a summary is included. >> Open Issues >> * requirements for less constrained path requests/response >> * requirements for responsiveness & session maintenance >> * detailed requirements on throttling messages under overload >> * specify =91boundary=92 numbers on scalability >> * clearly state supported policy models & corresponding =20 >> requirements/ implications >> * avoid feature creep >> * need to progress application-specific requirements >> * PCE protocol proposal needs to identify how generic & =20 >> application- specific requirements are met >> Discussion: >> JP: Detailed scalability issues are related to implementation. >> Adrian: we need a range as don=92t want protocol to provide the limit >> JP: on the less-constrained path computation topic, we don=92t have =20= >> a consensus yet, we should have a separate document >> Arthi: we had a discussion in the pwe group that there may be =20 >> requirements for pce >> Adrian: by us splitting the document between generic and extended =20= >> reqs (more application specific) we could handle this better >> Arthi: also though may not be in scope >> Adrian: yes we should say if it=92s out of scope >> Arthi: Some new requirements may come up for PCE, we need to have =20 >> a plan on how to address that. >> Adrian: The document is extensible. >> Arthi: We might see other consumers of PCE >> JP: Sure and the protocol should be designed to handle extensions =20 >> so as to meet new requirements but we may need to recharter >> --------------------------------------------- >> PCE Communication Protocol Application Model >> draft-zhang-pce-comm-app-model-01.txt >> (Zhang) >> -------------------------------------------- >> * how to avoid contention with TE link fails >> * how to load balance among PCEs >> * how to update the PCEs about resource allocation >> JP asked who has read the draft: good show of hands >> Adrian: rather than saying this is the way forward, would prefer =20 >> emphasis on what are the requirements >> (coauthor of the draft ??): this draft addresses a way to ... >> Adrian: yes, this draft has requirements on an implementation, =20 >> would like first to see top level requirements and architecture >> Igor: one of the requirements for the protocol is getting updates, =20= >> etc, >> Adrian: first need requirements >> Igor: my view this is not a signaling protocol, not rsvp, we =20 >> shouldn=92t go thru the process of using a signaling protocol >> JL: I have a major concern on scalability with the draft=92s =20 >> approach, one major bottleneck is on the PCE-PCE signaling, we =20 >> should minimize the signaling, the objective is to have =20 >> distribution to reduce this, whereas this draft re-introduces =20 >> this overhead for synchronization. You are redefining the concept =20= >> of cluster. Why not use the PCE engine? >> One major bottleneck on the PCE architecture is the pcc-pce =20 >> signalling. To ensure path computation, reduce the number of path =20= >> computation requirements received by a pce. >> Author: it does not consume much bandwidth. >> JL: It is not a problem of bandwidth but communication overhead. >> JP: I have similar concerns. Have you tried to evaluate what would =20= >> be the overhead in term of extra signaling due to this mechanism? =20= >> One way to roughly evaluate would be by using simulations. >> Adrian: best for us to discuss over email to provide adequate =20 >> time for the discussion. >> ------------------------------------------------------------- >> Path Computation Element (PCE) communication Protocol (PCEP)=0B >> draft-vasseur-pce-pcep-01.txt >> (JP) >> -------------------------------------------------------------- >> PCC-PCE and between PCEs communication >> There were two proposals in the past which were discontinued and =20 >> a completely new protocol has been designed (PCEP) highly driven =20 >> by the PCE WG requirement document. Chief objective was to make =20 >> it extensible to cope with future requirements. >> Major changes from 00 to 01: >> * rewritten for clarity >> * few sections removed >> * new section on protocol model >> * added security consideration >> * very rough manageability consideration section added (to be =20 >> fleshed out) >> * two new objects defined >> Unique communication protocol for PCC-PCE and PCE-PCE. >> Summary =96 pcep meets most of the requirements. >> Open issues (need inputs from the working group) >> * Objective functions needs to be defined (next revision) >> * Protocol recovery: requires more detailed requirements >> * Policy: requires more discussion >> Discussion >> Bijan Jabbari: What was the reason for TCP? >> JP: reliability and flow control. TCP was a very good candidate =20 >> for that. >> Bijan: Question of scalability of TCP. >> JP (vendor hat): We do not see any scalability issue with TCP. =20 >> Current TCP implementations can support a very high number of TCP =20= >> sessions. >> Question (?). You are creating a new protocol. Did you do an =20 >> analisys on existing protocols and reaons for not using them? >> Adrian: yes we did , but here formal requirement for the WG to =20 >> take reqs to other groups to ask if have anything, so this draft =20= >> progressing depends on answer. >> Lou: Many protocols have been worked on. Instead of reinventing =20 >> the weel, why not use one already existing. What we are doing =20 >> here in path computation is a new application, but session =20 >> application (keep alive, discovery) have been resolved before and =20= >> it would be great to concentrate on what is related to pce. >> Adrian: great if we can learn lessons >> Lou: and reuse >> Adrian: agree >> Dimitri: agree as Lou said >> Lou: session management, keep alives, etc have been done already >> JP: the question is, is there anything specifics to PCE that we =20 >> need a new protocol >> Dimitri: With a new solution we will have to pass all the stages =20 >> the others have passed to achieve a robust solution. >> > > -> Add: "Therefore, protocol solutions already developed by other =20 > WGs should be considered and evaluated wrt requirements provided by =20= > this working group so as to concentrate on the PCE specifics" > > >> JP: That's why we have the question here. >> Adrian: yes, this protocol in this draft has not been selected >> Bijan: If this is IP only, was DNS discussed? >> Adrian: this is IP only >> Bijan: have we looked at DNS ? >> Adrian: bring it to the list to suggest >> Lou: Comment on need to go back and use an existing mechanism =20 >> whenever you can. >> JP: yes, whenever you can. >> Loa: if we have TCP, then we have a basis, to do more, we need =20 >> justification, >> JP: agree >> Jerry: can you include what is met and not met on requirements =20 >> into the draft ? >> JP: ok, will do. >> Jerry: if we do not have a list of requirements, how can we proceed? >> Yakov: Comment on the need for protocol specific keep-alive: we =20 >> need a PCE specific keep-alive protocol since TCP will not take =20 >> care of it. >> JP: fully agree. >> Lou: You need keep-alive (TCP-based solutions already have keep- =20 >> alives). Find out what's the requirement, then lift the existing =20 >> solution. >> Lou: my comment is to look at experience =96 e.g. if need =20 >> keepalives, it=92s a mistake to look at this again without =20 >> considering previous work, and do all the requirements all over =20 >> again, should look at existing protocols, transaction semantics >> Adrian: yes, persistency should be addressed in the requirements >> Sue: keepalives in a protocol is needed in addition to tcp, need =20 >> to pay careful attention to the state machine interaction between =20= >> the two =96 pcc-pce. Need to ensure handle failure scenarios, =20 >> noticed missing here some of what protocol has to solve, should =20 >> feed back into requirements >> JP: Sometimes you do not want a permanent session, and sometimes =20 >> you do. Do we need two modes? >> Adrian: question should be asked to the requirements team. >> JL: we should be more flexible and support both request and =20 >> permanent as it will depend on the request, and number of pces to =20= >> maintain, may have a full mesh and may not want to maintain a =20 >> permanent >> JP: this is what we heard =96 may only need on request, other times =20= >> will need permanent, so may want both modes, and negotiate upon =20 >> session establishment. >> Adrian: when doing the solutions and have a question, should take =20= >> back to the requirements folks >> JP: Less-constrained path computation aspects will be removed =20 >> from this draft and be worked out in a separate ID. >> ------------------------------------------------ >> Path Computation Element Metric Protocol (PCEMP)=0B >> draft-choi-pce-metric-protocol-02.txt >> (Dipnarayan Guha) >> ------------------------------------------------ >> PCE metric protocol (PCEMP): generic routing and path computation =20= >> protocol targeted towards inter-domain pce peers. >> Reviewed slides >> JP: we encourage you to provide simulation results to the mailing =20= >> list it will help >> No discussion >> ------------------------------ >> working group next steps (JP) >> ------------------------------ >> - new revision of the PCE architecture ID to be published soon =20 >> (WG last call soon after this ietf) >> - new revision of the generic pce communication requirement ID =20 >> (WG last call soon after this ietf) >> - submit a new ID for pce discovery protocol extensions (minor =20 >> protocol work only) >> Start application-specific requirements IDs for PCE based computation >> *Inter-area: Jean-Louis >> *Inter-As: Raymond, Nabil >> JP: note that such ID must be PCE-specific (take into account =20 >> RFC4105 and inter-as requirements ID produced by the TE WG). >> Adrian: WG to decide on which pce communication protocol solution =20 >> to pursue >> - two proposals presented >> - selection of one solution as a basis now does not imply =20 >> rejecting good points of other solution nor accepting bad points =20 >> of selected solutions. >> If pick one, that does not prevent us from taking the best of =20 >> other one also, and also other ietf protocols. email will be sent =20= >> to the application ADs to ask their input. >> - New ID on the less contrained path problem comprising the =20 >> requirement + solution >> - Need to verify the solution model for inter-domain pce with =20 >> CCAMP, MPLS working groups >> Adrian =96 other application specific requirements IDs (interlayer, =20= >> p2mp) should continue their work, just realize other work needs to =20= >> be done first: >> inter-layer: Eiji, Kenji >> P2MP: Seisho (currently out of scope of PCE WG charter) >> Thanks. >> JP. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 14 16:30:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4P7z-0004bu-9p; Sun, 14 Aug 2005 16:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4P7t-0004bp-SO for pce@megatron.ietf.org; Sun, 14 Aug 2005 16:30:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10997 for ; Sun, 14 Aug 2005 16:30:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4Pgt-0004FG-Im for pce@ietf.org; Sun, 14 Aug 2005 17:06:48 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4P7j-0007R3-Hu; Sun, 14 Aug 2005 20:30:28 +0000 Message-ID: <42FFA9DD.1020409@psg.com> Date: Sun, 14 Aug 2005 22:30:21 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> <3917.68.100.80.11.1123946825.squirrel@webmail.movaz.com> <0e2701c5a0bf$bca14350$08849ed9@Puppy> In-Reply-To: <0e2701c5a0bf$bca14350$08849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi adrian - i don't think there is a need to introduce new terminology to address this comment, which is sensible imho, just a need to revisit the notion of centralized/distributed vs single/multiple PCE computation you can ask why ... well the below tries to clarify by definition (section 3) "distributed computation model" refers to a domain or network that may include multiple PCEs, and where computation of paths is shared among the PCEs." since so far there is no specific issue - if one take your viewpoint - until reaching the corrolary: "From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model which uses multiple PCEs." we fall into the situation if the first alternative is used what really distinguishes the distributed single PCE computation from a centralized computation (so these definitions allow to described a centralized computation model to as "distributed") and on the other side, if you have an AS with a single PCE and its backup (which is also a specific case of sharing) it must be referred to as "distributed" because the notion of centralized model implies single PCE per domain ? therefore, some re-phrasing of the definitions may help here to wipe out some confusion thanks, - dimitri. Adrian Farrel wrote: > Hi, > > Yes, we should record Igor's comments in the minutes as he made them. > > However, I would like to tackle them here. > > >>1. Architecture document >> >>I made a comment that I disagree with the current definition of the >>distributed path computation. >> >>In the document: >>centralized path computation = computation performed by a single PCE >>distributed path computation = computation performed by multiple PCEs >> >>In my opinion: >>centralized path computation = path computation that returns all > > requested > >>paths in the *explicit* form in the first response, so that no more >>requests will be needed neither from the original requestor nor from any >>other PCCs for the service in question > > > Hmmm. So in this model a single PCE would be responsible for returning the > complete path and no other PCE would be invoked. This is, of course, very > close to the existing definition of "centralized path computation" since > if there is only one PCE there is no option but to compute the entire path > on that PCE. > > However, your definition would allow more than one PCE in the network, but > still have only one PCE consulted for any individual path. This mode of > operation is called "single PCE path computation" to contrast with > "multiple PCE path computation" in the draft. > > >>distributed path computation is when the original path computation > > request > >>is responded with at least one non-explicit path, so that more path >>computations will be issued from the original or some other PCCs. > > > This, of course, is strikingly similar to the definition of distributed > path computation in the draft. That is, the path is computed by more than > one PCE. > > However, your definition states that a path will be computed by multiple > PCE consultation, while the current definition of distributed path > computation states that multiple PCEs are servicing the requests in the > network. Your definition matches the definition of "multiple PCE path > computation" in the draft. > > I see absolutely zero value in quibbling about the name given to a concept > when the concepts are identical and are all covered by the existing I-D. > > >>In other words from the original requestor point of view (which is >>ultimate user of the PCE service) it does not matter how many PCEs will > > be > >>involved to satisfy its request, what is important is how many > > additional > >>path computations is needed (0 -centralised >>path computation, >0 - distributed path computation). > > > We agree that there may be some value in distinguishing the behavior from > the point of view of the requester. There are exactly three cases for the > requester: > 1. The requester sends a single request to exactly one PCE and gets > enough information to make use of the response. > 2. The requester must send more than one request to exactly one > PCE in order to get enough information to make use of the > responses. > 3. The requester must send requests to more than one PCE to > get enough information to make use of the responses. > In none of these case is the requester, the PCC, aware of whether some > other LSR in the network will subsequently need to consult other PCEs. > Arhcitecturally, it should not be aware of this fact. From a protocol > perspective it must not be aware of this fact. > > Adding a description of the behavior from the persepective of the PCC can > be done. However, it will not change the definitions of the terms that > describe the overall architecture. It will introduce new terms to describe > the behavior. > > >>2. WRT proposed PCEP solutions I made a comment that neither of them >>satisfies the requirement of the extensibility. Introducing new >>constraints, objection functions, diversity types, etc will be > > extreamely > >>painful. Hence a meta-language style protocol should be considered > > > You are correct that we should consider a meta-language style protocol > although unless someone brings a draft to the table we will not consider > one. That is, you cannot mandate that the working group must develop a > particular style of protocol - we can only consider what we have in front > of us in terms of proposals that people are prepared to develop and > implement. > > I do not believe that you are correct to state that a TLV-based protocol > is extremely painful to extend. Our experience of very many such protocols > show that they are fairly simple to extend. > > It is possible that you could supply a specific example of an extension > that you think is both likely to be required and which you consider would > be hard to encode in a TLV. To do this you would need to supply a detailed > description of the information that you want to encode - it would not be > enough to say "diversity types". Other people could then demonstrate that > such an extension could be encoded. I should point out, however, that a > TLV is capable of encoding a text string - this means that pretty much > anything can be encoded within a TLV. > > Whatever, such a proof-by-example style of reasoning is unlikely to get us > very far. If a meta-language style protocol is to be considered, we need > to see it and know that it is being implemented. > > Cheers, > Adrian > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 15 09:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fUk-0003tn-CT; Mon, 15 Aug 2005 09:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fUg-0003tb-Ec for pce@megatron.ietf.org; Mon, 15 Aug 2005 09:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03752 for ; Mon, 15 Aug 2005 09:59:12 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4g3p-0007ol-5Q for pce@ietf.org; Mon, 15 Aug 2005 10:35:33 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id A4235CF9; Mon, 15 Aug 2005 09:58:59 -0400 (EDT) Message-ID: <002601c5a1a1$7c5fb1e0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "JP Vasseur" References: <6205DED6-22D5-46E0-AD8E-22B47F11E1A0@cisco.com> <3917.68.100.80.11.1123946825.squirrel@webmail.movaz.com> <0e2701c5a0bf$bca14350$08849ed9@Puppy> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Mon, 15 Aug 2005 09:58:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian, Thanks for taking my comments into consideration. See my responses in-line. Cheers, Igor ----- Original Message ----- From: "Adrian Farrel" To: ; "JP Vasseur" Cc: Sent: Sunday, August 14, 2005 5:50 AM Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 > Hi, > > Yes, we should record Igor's comments in the minutes as he made them. > > However, I would like to tackle them here. > > > 1. Architecture document > > > > I made a comment that I disagree with the current definition of the > > distributed path computation. > > > > In the document: > > centralized path computation = computation performed by a single PCE > > distributed path computation = computation performed by multiple PCEs > > > > In my opinion: > > centralized path computation = path computation that returns all > requested > > paths in the *explicit* form in the first response, so that no more > > requests will be needed neither from the original requestor nor from any > > other PCCs for the service in question > > Hmmm. So in this model a single PCE would be responsible for returning the > complete path and no other PCE would be invoked. IB>> Nope, a PCE can involve as many other PCEs as it wants. The important thing is that it responses with all paths in explicit form, and this would be the centralized path computation as far as original PCC is concerned This is, of course, very > close to the existing definition of "centralized path computation" since > if there is only one PCE there is no option but to compute the entire path > on that PCE. > > However, your definition would allow more than one PCE in the network, but > still have only one PCE consulted for any individual path. This mode of > operation is called "single PCE path computation" to contrast with > "multiple PCE path computation" in the draft. IB>> My point is/was that whether path computation is centralized or distributed is orthogonal to how many PCEs are involved. A domain can contain a single PCE and a path computation could be distributed: multiple LSRs along the path request path computations from the same PCE. Likewise, a path computation can be performed by a cooperation of multiple PCEs, and the computation will still be centralized as long as the first response to the original PCC contains *all* paths in the *explicit* form (so that no other path computations will be requested > > > distributed path computation is when the original path computation > request > > is responded with at least one non-explicit path, so that more path > > computations will be issued from the original or some other PCCs. > > This, of course, is strikingly similar to the definition of distributed > path computation in the draft. That is, the path is computed by more than > one PCE. IB>> No, see my comment above. > > However, your definition states that a path will be computed by multiple > PCE consultation, while the current definition of distributed path > computation states that multiple PCEs are servicing the requests in the > network. Your definition matches the definition of "multiple PCE path > computation" in the draft. > > I see absolutely zero value in quibbling about the name given to a concept > when the concepts are identical and are all covered by the existing I-D. > > > In other words from the original requestor point of view (which is > > ultimate user of the PCE service) it does not matter how many PCEs will > be > > involved to satisfy its request, what is important is how many > additional > > path computations is needed (0 -centralised > > path computation, >0 - distributed path computation). > > We agree that there may be some value in distinguishing the behavior from > the point of view of the requester. There are exactly three cases for the > requester: > 1. The requester sends a single request to exactly one PCE and gets > enough information to make use of the response. IB>> this is a case of the centralized path computation as long as all paths are returned in the explicit form > 2. The requester must send more than one request to exactly one > PCE in order to get enough information to make use of the > responses. IB>> this is a case of distributed path computation > 3. The requester must send requests to more than one PCE to > get enough information to make use of the responses. IB>> this is a case of distributed path computation. IB>> You also forget one more very important case: a requestor sends a single request to a PCE and receives at least one path in non-explicit form. When the path(s) are signaled at least one more requestor will request a PCE (the same or different one) to perform more path computation(s) to detailize the non-explicit path(s). This is also a case of the distributed path computation despite each of the requestors might issue a single request. > In none of these case is the requester, the PCC, aware of whether some > other LSR in the network will subsequently need to consult other PCEs. IB>> Disagree. If the responded paths are in the explicit form, no other LSRs will issue additional path computations. The explicit paths are conceptually the best possible paths. In fact, as a PCC I'd like to have an option to mandate the computed paths to be explicit. > Arhcitecturally, it should not be aware of this fact. From a protocol > perspective it must not be aware of this fact. > > Adding a description of the behavior from the persepective of the PCC can > be done. However, it will not change the definitions of the terms that > describe the overall architecture. It will introduce new terms to describe > the behavior. > > > 2. WRT proposed PCEP solutions I made a comment that neither of them > > satisfies the requirement of the extensibility. Introducing new > > constraints, objection functions, diversity types, etc will be > extreamely > > painful. Hence a meta-language style protocol should be considered > > You are correct that we should consider a meta-language style protocol > although unless someone brings a draft to the table we will not consider > one. That is, you cannot mandate that the working group must develop a > particular style of protocol - we can only consider what we have in front > of us in terms of proposals that people are prepared to develop and > implement. IB>> Agree. However, there is one important observation I wanted to make: originally PCE was an intrinsic part of an LSR's control plane. That is, the routing, signaling and PCE subsystems where interconnected within the LSR's control plane via APIs. Hence a PCE used to have an unlimited flexibility to introduce new constraints, optimizations and diversity - all that was needed is a simple recompilation of the control plane software. The PCE architecture has decoupled the PCE from the signaling sub-system and made LSR an PCE separate logical (and possibly physical) entities. Therefore, whenever somebody comes up with extensions to a PCE, there should be a way to advertise the new capabilities and for the PCC to take advantage of them without introducing new TLVs. TLV-style protocol is for signaling and routing, not for the client-server protocol such as PCEP. I am afraid the effort to develop PCEP as a TLV-style protocol might prove to be too rigid to be useful. I'd like my point of view to be recorded in the minutes correctly. I'd also like to hear who would like to join me in designing a meta-style PCEP (for instance, based on COPS). Cheers, Igor > > I do not believe that you are correct to state that a TLV-based protocol > is extremely painful to extend. Our experience of very many such protocols > show that they are fairly simple to extend. > > It is possible that you could supply a specific example of an extension > that you think is both likely to be required and which you consider would > be hard to encode in a TLV. To do this you would need to supply a detailed > description of the information that you want to encode - it would not be > enough to say "diversity types". Other people could then demonstrate that > such an extension could be encoded. I should point out, however, that a > TLV is capable of encoding a text string - this means that pretty much > anything can be encoded within a TLV. > > Whatever, such a proof-by-example style of reasoning is unlikely to get us > very far. If a meta-language style protocol is to be considered, we need > to see it and know that it is being implemented. > > Cheers, > Adrian > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 15 10:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gG6-0002Fg-8Y; Mon, 15 Aug 2005 10:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gG5-0002FM-E1 for pce@megatron.ietf.org; Mon, 15 Aug 2005 10:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07191 for ; Mon, 15 Aug 2005 10:48:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gpE-0000Un-1z for pce@ietf.org; Mon, 15 Aug 2005 11:24:32 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j7FEm2FV017157; Mon, 15 Aug 2005 10:48:02 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05603; Mon, 15 Aug 2005 10:48:02 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Aug 2005 10:48:01 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885DDF@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Adrian Farrel'" , ibryskin@movaz.com, JP Vasseur Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63 Date: Mon, 15 Aug 2005 10:47:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian, Igor, et al - Are we considering the option to have a PCC need to serially consult multiple PCE in order to obtain a complete path computation for a single path? That is what it sounds like Igor said and Adrian included in his list of options. And - if we are considering this - are we doing so out of some sort of "completeness criteria" or because there is someone who thinks this is either a good idea or a necessary evil? If we are considering this option out of a need to be thorough, that's okay - but I hope we can quickly put this one to bed in analysis. The one justification for this is if it is more important to authenticate the requester than it is to authenticate the request for extended path setup. Just a few drawbacks to this approach revolve around the complexity of: o PCC having to have contact information, authentication tokens, etc. for extensive networks of remote PCE - at least on an as needed basis. o Protocol "tokens" to indicate to the PCC where to go for the next part of the path computation - and possibly how to contact (and possibly be authenticated by) that (or those) PCE. o Protocol mechanisms to notify each consulted PCE if the path ultimately cannot be computed. o Complexity in the PCE to support partial path allocation - possibly on a temporary basis - and mechanisms to get back resources if a PCC becomes non-respondent. o Complexity in the PCC to support partial path allocation at multiple PCE and reliable delivery of non-completion notification. --> -----Original Message----- --> From: pce-bounces@lists.ietf.org --> [mailto:pce-bounces@lists.ietf.org]On --> Behalf Of Adrian Farrel --> Sent: Sunday, August 14, 2005 5:51 AM --> To: ibryskin@movaz.com; JP Vasseur --> Cc: pce@ietf.org --> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 --> --> --> Hi, --> --> Yes, we should record Igor's comments in the minutes as he --> made them. --> --> However, I would like to tackle them here. --> --> > 1. Architecture document --> > --> > I made a comment that I disagree with the current --> definition of the --> > distributed path computation. --> > --> > In the document: --> > centralized path computation = computation performed by a --> single PCE --> > distributed path computation = computation performed by --> multiple PCEs --> > --> > In my opinion: --> > centralized path computation = path computation that returns all --> requested --> > paths in the *explicit* form in the first response, so --> that no more --> > requests will be needed neither from the original --> requestor nor from any --> > other PCCs for the service in question --> --> Hmmm. So in this model a single PCE would be responsible --> for returning the --> complete path and no other PCE would be invoked. This is, --> of course, very --> close to the existing definition of "centralized path --> computation" since --> if there is only one PCE there is no option but to compute --> the entire path --> on that PCE. --> --> However, your definition would allow more than one PCE in --> the network, but --> still have only one PCE consulted for any individual path. --> This mode of --> operation is called "single PCE path computation" to contrast with --> "multiple PCE path computation" in the draft. --> --> > distributed path computation is when the original path computation --> request --> > is responded with at least one non-explicit path, so that --> more path --> > computations will be issued from the original or some other PCCs. --> --> This, of course, is strikingly similar to the definition of --> distributed --> path computation in the draft. That is, the path is --> computed by more than --> one PCE. --> --> However, your definition states that a path will be --> computed by multiple --> PCE consultation, while the current definition of distributed path --> computation states that multiple PCEs are servicing the --> requests in the --> network. Your definition matches the definition of --> "multiple PCE path --> computation" in the draft. --> --> I see absolutely zero value in quibbling about the name --> given to a concept --> when the concepts are identical and are all covered by the --> existing I-D. --> --> > In other words from the original requestor point of view (which is --> > ultimate user of the PCE service) it does not matter how --> many PCEs will --> be --> > involved to satisfy its request, what is important is how many --> additional --> > path computations is needed (0 -centralised --> > path computation, >0 - distributed path computation). --> --> We agree that there may be some value in distinguishing the --> behavior from --> the point of view of the requester. There are exactly three --> cases for the --> requester: --> 1. The requester sends a single request to exactly one PCE and gets --> enough information to make use of the response. --> 2. The requester must send more than one request to exactly one --> PCE in order to get enough information to make use of the --> responses. --> 3. The requester must send requests to more than one PCE to --> get enough information to make use of the responses. --> In none of these case is the requester, the PCC, aware of --> whether some --> other LSR in the network will subsequently need to consult --> other PCEs. --> Arhcitecturally, it should not be aware of this fact. From --> a protocol --> perspective it must not be aware of this fact. --> --> Adding a description of the behavior from the persepective --> of the PCC can --> be done. However, it will not change the definitions of the --> terms that --> describe the overall architecture. It will introduce new --> terms to describe --> the behavior. --> --> > 2. WRT proposed PCEP solutions I made a comment that --> neither of them --> > satisfies the requirement of the extensibility. Introducing new --> > constraints, objection functions, diversity types, etc will be --> extreamely --> > painful. Hence a meta-language style protocol should be considered --> --> You are correct that we should consider a meta-language --> style protocol --> although unless someone brings a draft to the table we will --> not consider --> one. That is, you cannot mandate that the working group --> must develop a --> particular style of protocol - we can only consider what we --> have in front --> of us in terms of proposals that people are prepared to develop and --> implement. --> --> I do not believe that you are correct to state that a --> TLV-based protocol --> is extremely painful to extend. Our experience of very many --> such protocols --> show that they are fairly simple to extend. --> --> It is possible that you could supply a specific example of --> an extension --> that you think is both likely to be required and which you --> consider would --> be hard to encode in a TLV. To do this you would need to --> supply a detailed --> description of the information that you want to encode - it --> would not be --> enough to say "diversity types". Other people could then --> demonstrate that --> such an extension could be encoded. I should point out, --> however, that a --> TLV is capable of encoding a text string - this means that --> pretty much --> anything can be encoded within a TLV. --> --> Whatever, such a proof-by-example style of reasoning is --> unlikely to get us --> very far. If a meta-language style protocol is to be --> considered, we need --> to see it and know that it is being implemented. --> --> Cheers, --> Adrian --> --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 15 11:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hAM-0000QU-2e; Mon, 15 Aug 2005 11:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hAK-0000QP-7L for pce@megatron.ietf.org; Mon, 15 Aug 2005 11:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09499 for ; Mon, 15 Aug 2005 11:46:16 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hjQ-0001mE-Kf for pce@ietf.org; Mon, 15 Aug 2005 12:22:39 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 2717A98B2; Mon, 15 Aug 2005 11:46:06 -0400 (EDT) Message-ID: <004901c5a1b0$72e51920$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Gray, Eric" , "'Adrian Farrel'" , "JP Vasseur" References: <313680C9A886D511A06000204840E1CF0C885DDF@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Mon, 15 Aug 2005 11:46:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Eric, See my comments in-line. Igor ----- Original Message ----- From: "Gray, Eric" To: "'Adrian Farrel'" ; ; "JP Vasseur" Cc: Sent: Monday, August 15, 2005 10:47 AM Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63 > Adrian, Igor, et al - > > Are we considering the option to have a PCC need to > serially consult multiple PCE in order to obtain a complete > path computation for a single path? That is what it sounds > like Igor said and Adrian included in his list of options. IB>> This scenario is possible but IMO is not typical. What I was referring to are the following scenarios: a) a PCC on the service ingress LSR requests a path computation from a single PCE. The latter involves in the path computation 0 or more other PCEs. Eventually, the first PCE responds with one or several paths. If the paths are explicit, than no more additional path computations will be requested neither from the ingress LSR nor from any transit LSRs. As far as the ingress LSR is concerned this is the centralized path computation no matter how many PCEs actually participated in the path computation; b) a PCC on the service ingress LSR requests a path computation from a single PCE. The latter returns one or several paths with at least one of them in the the non-explicit form, that is, containing loose hops and/or abstract node subobjects. This is the case of the distributed path computation, because somewhere downstream one or more transit LSRs will have to request additional path computations (possibly from the same PCE) > > And - if we are considering this - are we doing so out > of some sort of "completeness criteria" or because there is > someone who thinks this is either a good idea or a necessary > evil? IB>> I personally think this is for the sake of completeness with an exception of the off-line path computation. > > If we are considering this option out of a need to be > thorough, that's okay - but I hope we can quickly put this > one to bed in analysis. The one justification for this is if > it is more important to authenticate the requester than it is > to authenticate the request for extended path setup. > > Just a few drawbacks to this approach revolve around the > complexity of: > > o PCC having to have contact information, authentication > tokens, etc. for extensive networks of remote PCE - at > least on an as needed basis. > o Protocol "tokens" to indicate to the PCC where to go for > the next part of the path computation - and possibly how > to contact (and possibly be authenticated by) that (or > those) PCE. > o Protocol mechanisms to notify each consulted PCE if the > path ultimately cannot be computed. > o Complexity in the PCE to support partial path allocation > - possibly on a temporary basis - and mechanisms to get > back resources if a PCC becomes non-respondent. > o Complexity in the PCC to support partial path allocation > at multiple PCE and reliable delivery of non-completion > notification. IB>> Well, all these issues are also true wrt the scenario: PCC->PCE1->PCE2->PCE1->PCC (multi-PCE path computation), and since they have to be addressed anyway I don't see how this scenario is different from the point of view of complexities you described above compared to the scenario: PCC->PCE1->PCC->PCE2->PCC. Cheers, Igor > > > --> -----Original Message----- > --> From: pce-bounces@lists.ietf.org > --> [mailto:pce-bounces@lists.ietf.org]On > --> Behalf Of Adrian Farrel > --> Sent: Sunday, August 14, 2005 5:51 AM > --> To: ibryskin@movaz.com; JP Vasseur > --> Cc: pce@ietf.org > --> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 > --> > --> > --> Hi, > --> > --> Yes, we should record Igor's comments in the minutes as he > --> made them. > --> > --> However, I would like to tackle them here. > --> > --> > 1. Architecture document > --> > > --> > I made a comment that I disagree with the current > --> definition of the > --> > distributed path computation. > --> > > --> > In the document: > --> > centralized path computation = computation performed by a > --> single PCE > --> > distributed path computation = computation performed by > --> multiple PCEs > --> > > --> > In my opinion: > --> > centralized path computation = path computation that returns all > --> requested > --> > paths in the *explicit* form in the first response, so > --> that no more > --> > requests will be needed neither from the original > --> requestor nor from any > --> > other PCCs for the service in question > --> > --> Hmmm. So in this model a single PCE would be responsible > --> for returning the > --> complete path and no other PCE would be invoked. This is, > --> of course, very > --> close to the existing definition of "centralized path > --> computation" since > --> if there is only one PCE there is no option but to compute > --> the entire path > --> on that PCE. > --> > --> However, your definition would allow more than one PCE in > --> the network, but > --> still have only one PCE consulted for any individual path. > --> This mode of > --> operation is called "single PCE path computation" to contrast with > --> "multiple PCE path computation" in the draft. > --> > --> > distributed path computation is when the original path computation > --> request > --> > is responded with at least one non-explicit path, so that > --> more path > --> > computations will be issued from the original or some other PCCs. > --> > --> This, of course, is strikingly similar to the definition of > --> distributed > --> path computation in the draft. That is, the path is > --> computed by more than > --> one PCE. > --> > --> However, your definition states that a path will be > --> computed by multiple > --> PCE consultation, while the current definition of distributed path > --> computation states that multiple PCEs are servicing the > --> requests in the > --> network. Your definition matches the definition of > --> "multiple PCE path > --> computation" in the draft. > --> > --> I see absolutely zero value in quibbling about the name > --> given to a concept > --> when the concepts are identical and are all covered by the > --> existing I-D. > --> > --> > In other words from the original requestor point of view (which is > --> > ultimate user of the PCE service) it does not matter how > --> many PCEs will > --> be > --> > involved to satisfy its request, what is important is how many > --> additional > --> > path computations is needed (0 -centralised > --> > path computation, >0 - distributed path computation). > --> > --> We agree that there may be some value in distinguishing the > --> behavior from > --> the point of view of the requester. There are exactly three > --> cases for the > --> requester: > --> 1. The requester sends a single request to exactly one PCE and gets > --> enough information to make use of the response. > --> 2. The requester must send more than one request to exactly one > --> PCE in order to get enough information to make use of the > --> responses. > --> 3. The requester must send requests to more than one PCE to > --> get enough information to make use of the responses. > --> In none of these case is the requester, the PCC, aware of > --> whether some > --> other LSR in the network will subsequently need to consult > --> other PCEs. > --> Arhcitecturally, it should not be aware of this fact. From > --> a protocol > --> perspective it must not be aware of this fact. > --> > --> Adding a description of the behavior from the persepective > --> of the PCC can > --> be done. However, it will not change the definitions of the > --> terms that > --> describe the overall architecture. It will introduce new > --> terms to describe > --> the behavior. > --> > --> > 2. WRT proposed PCEP solutions I made a comment that > --> neither of them > --> > satisfies the requirement of the extensibility. Introducing new > --> > constraints, objection functions, diversity types, etc will be > --> extreamely > --> > painful. Hence a meta-language style protocol should be considered > --> > --> You are correct that we should consider a meta-language > --> style protocol > --> although unless someone brings a draft to the table we will > --> not consider > --> one. That is, you cannot mandate that the working group > --> must develop a > --> particular style of protocol - we can only consider what we > --> have in front > --> of us in terms of proposals that people are prepared to develop and > --> implement. > --> > --> I do not believe that you are correct to state that a > --> TLV-based protocol > --> is extremely painful to extend. Our experience of very many > --> such protocols > --> show that they are fairly simple to extend. > --> > --> It is possible that you could supply a specific example of > --> an extension > --> that you think is both likely to be required and which you > --> consider would > --> be hard to encode in a TLV. To do this you would need to > --> supply a detailed > --> description of the information that you want to encode - it > --> would not be > --> enough to say "diversity types". Other people could then > --> demonstrate that > --> such an extension could be encoded. I should point out, > --> however, that a > --> TLV is capable of encoding a text string - this means that > --> pretty much > --> anything can be encoded within a TLV. > --> > --> Whatever, such a proof-by-example style of reasoning is > --> unlikely to get us > --> very far. If a meta-language style protocol is to be > --> considered, we need > --> to see it and know that it is being implemented. > --> > --> Cheers, > --> Adrian > --> > --> > --> _______________________________________________ > --> Pce mailing list > --> Pce@lists.ietf.org > --> https://www1.ietf.org/mailman/listinfo/pce > --> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 16 10:34:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52Wa-0001KB-TQ; Tue, 16 Aug 2005 10:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52WY-0001Ji-6W for pce@megatron.ietf.org; Tue, 16 Aug 2005 10:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15233 for ; Tue, 16 Aug 2005 10:34:39 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E535s-0002rj-MW for pce@ietf.org; Tue, 16 Aug 2005 11:11:14 -0400 Received: from du-069-0016.access.clara.net ([217.158.132.16] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E52WC-000FcL-8c; Tue, 16 Aug 2005 15:34:22 +0100 Message-ID: <011101c5a26f$f80a6eb0$4f849ed9@Puppy> From: "Adrian Farrel" To: "Igor Bryskin" , "Gray, Eric" , "JP Vasseur" References: <313680C9A886D511A06000204840E1CF0C885DDF@whq-msgusr-02.pit.comms.marconi.com> <004901c5a1b0$72e51920$7a1810ac@movaz.com> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Tue, 16 Aug 2005 13:23:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Igor... > > Are we considering the option to have a PCC need to > > serially consult multiple PCE in order to obtain a complete > > path computation for a single path? That is what it sounds > > like Igor said and Adrian included in his list of options. > > IB>> This scenario is possible but IMO is not typical. What I was referring > to are the following scenarios: > > a) a PCC on the service ingress LSR requests a path computation from a > single PCE. The latter involves in the path computation 0 or more other > PCEs. > Eventually, the first PCE responds with one or several paths. If the paths > are explicit, than no more additional path computations will be requested > neither from the ingress LSR nor from any transit LSRs. As far as the > ingress LSR is concerned this is the centralized path computation no > matter how many PCEs actually participated in the path computation; I repeat that it does not help to take an existing term that already applies to an existing scenario and apply that term to another scenario. Your scenario is valid and needs to be in the architecture I-D. But you cannot use the term "centralized path computation" to describe it. > b) a PCC on the service ingress LSR requests a path computation from a > single PCE. The latter returns one or several paths with at least one of > them in the the non-explicit form, that is, containing loose hops and/or > abstract node subobjects. This is the case of the distributed path > computation, because somewhere downstream one or more transit LSRs > will have to request additional path computations (possibly from the same > PCE) Again, a valid scenario, but an unhelpful re-use of an existing term. > > And - if we are considering this - are we doing so out > > of some sort of "completeness criteria" or because there is > > someone who thinks this is either a good idea or a necessary > > evil? > > IB>> I personally think this is for the sake of completeness with an > exception of the off-line path computation. Hmmm. Well, we do not do things for the sake of completeness. We do things to be implemented and deployed. Nevertheless, we will include a section in the Architecture to describe "The view from the PCC" that should cover your scenarios to your satisfaction. > > If we are considering this option out of a need to be > > thorough, that's okay - but I hope we can quickly put this > > one to bed in analysis. The one justification for this is if > > it is more important to authenticate the requester than it is > > to authenticate the request for extended path setup. > > > > Just a few drawbacks to this approach revolve around the > > complexity of: > > > > o PCC having to have contact information, authentication > > tokens, etc. for extensive networks of remote PCE - at > > least on an as needed basis. > > o Protocol "tokens" to indicate to the PCC where to go for > > the next part of the path computation - and possibly how > > to contact (and possibly be authenticated by) that (or > > those) PCE. > > o Protocol mechanisms to notify each consulted PCE if the > > path ultimately cannot be computed. > > o Complexity in the PCE to support partial path allocation > > - possibly on a temporary basis - and mechanisms to get > > back resources if a PCC becomes non-respondent. > > o Complexity in the PCC to support partial path allocation > > at multiple PCE and reliable delivery of non-completion > > notification. > > IB>> Well, all these issues are also true wrt the scenario: > PCC->PCE1->PCE2->PCE1->PCC (multi-PCE path computation), Or, to more precisely use the language of the Architecture I-D, "Multiple PCE Path Computation with Inter-PCE Communication" > and since they have > to be addressed anyway I don't see how this scenario is different from the > point of view of complexities you described above compared to the scenario: > PCC->PCE1->PCC->PCE2->PCC. Well you should think about implementation complexity for the PCC. A first question might be "How does the PCC in your second example know that it needs to invoke PCE2?" If the answer is that it must parse the returned path and understand: - that the path is not complete - that PCE2 is responsible for completing part of the path - the location of PCE2 then you have considerably increased the function that the PCC must include. For inter-domain cases, you are also significantly increasing the complexity of policy. I also wonder about the consequences for scaling. But these are the points that Eric raised and you seem to think are not important. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 16 11:43:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53bR-0005hg-73; Tue, 16 Aug 2005 11:43:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53bP-0005hb-EF for pce@megatron.ietf.org; Tue, 16 Aug 2005 11:43:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18974 for ; Tue, 16 Aug 2005 11:43:44 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54Aj-0004bg-Pf for pce@ietf.org; Tue, 16 Aug 2005 12:20:20 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 251B713AB5; Tue, 16 Aug 2005 11:43:26 -0400 (EDT) Message-ID: <005301c5a279$3de900f0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Gray, Eric" , "JP Vasseur" References: <313680C9A886D511A06000204840E1CF0C885DDF@whq-msgusr-02.pit.comms.marconi.com> <004901c5a1b0$72e51920$7a1810ac@movaz.com> <011101c5a26f$f80a6eb0$4f849ed9@Puppy> Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Tue, 16 Aug 2005 11:43:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian, See in-line. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Igor Bryskin" ; "Gray, Eric" ; "JP Vasseur" Cc: Sent: Tuesday, August 16, 2005 8:23 AM Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 > Hi Igor... > > > > Are we considering the option to have a PCC need to > > > serially consult multiple PCE in order to obtain a complete > > > path computation for a single path? That is what it sounds > > > like Igor said and Adrian included in his list of options. > > > > IB>> This scenario is possible but IMO is not typical. What I was > referring > > to are the following scenarios: > > > > a) a PCC on the service ingress LSR requests a path computation from a > > single PCE. The latter involves in the path computation 0 or more other > > PCEs. > > Eventually, the first PCE responds with one or several paths. If the > paths > > are explicit, than no more additional path computations will be > requested > > neither from the ingress LSR nor from any transit LSRs. As far as the > > ingress LSR is concerned this is the centralized path computation no > > matter how many PCEs actually participated in the path computation; > > I repeat that it does not help to take an existing term that already > applies to an existing scenario and apply that term to another scenario. > > Your scenario is valid and needs to be in the architecture I-D. But you > cannot use the term "centralized path computation" to describe it. IB>> But this is the whole point of the discussion. I repeat that current definitions for centralized and distributed path computation are too one-sided. Note that the terms did exist *before* the PCE architecture was introduced: when a PCE is a part of an LSR's control plane, it is pretty clear what does distributed path computation mean: it comes down to how many additional path computation will be *requested* for the service. From the TE and LSP setup blocking probability point of view it is important not because that the additional path computations will be *performed*, rather, that the resulting paths will be worse compared to ones produced by a single path computation performed on the ingress LSR (which is/was the case of the centralized path computation). I don't see a reason why the terms needed to be redefined. > > > b) a PCC on the service ingress LSR requests a path computation from a > > single PCE. The latter returns one or several paths with at least one of > > them in the the non-explicit form, that is, containing loose hops and/or > > abstract node subobjects. This is the case of the distributed path > > computation, because somewhere downstream one or more transit LSRs > > will have to request additional path computations (possibly from the > same > > PCE) > > Again, a valid scenario, but an unhelpful re-use of an existing term. > IB>> the same comment > > > And - if we are considering this - are we doing so out > > > of some sort of "completeness criteria" or because there is > > > someone who thinks this is either a good idea or a necessary > > > evil? > > > > IB>> I personally think this is for the sake of completeness with an > > exception of the off-line path computation. > > Hmmm. > Well, we do not do things for the sake of completeness. We do things to be > implemented and deployed. > > Nevertheless, we will include a section in the Architecture to describe > "The view from the PCC" that should cover your scenarios to your > satisfaction. > > > > If we are considering this option out of a need to be > > > thorough, that's okay - but I hope we can quickly put this > > > one to bed in analysis. The one justification for this is if > > > it is more important to authenticate the requester than it is > > > to authenticate the request for extended path setup. > > > > > > Just a few drawbacks to this approach revolve around the > > > complexity of: > > > > > > o PCC having to have contact information, authentication > > > tokens, etc. for extensive networks of remote PCE - at > > > least on an as needed basis. > > > o Protocol "tokens" to indicate to the PCC where to go for > > > the next part of the path computation - and possibly how > > > to contact (and possibly be authenticated by) that (or > > > those) PCE. > > > o Protocol mechanisms to notify each consulted PCE if the > > > path ultimately cannot be computed. > > > o Complexity in the PCE to support partial path allocation > > > - possibly on a temporary basis - and mechanisms to get > > > back resources if a PCC becomes non-respondent. > > > o Complexity in the PCC to support partial path allocation > > > at multiple PCE and reliable delivery of non-completion > > > notification. > > > > IB>> Well, all these issues are also true wrt the scenario: > > PCC->PCE1->PCE2->PCE1->PCC (multi-PCE path computation), > > Or, to more precisely use the language of the Architecture I-D, "Multiple > PCE Path Computation with Inter-PCE Communication" > > > and since they have > > to be addressed anyway I don't see how this scenario is different from > the > > point of view of complexities you described above compared to the > scenario: > > PCC->PCE1->PCC->PCE2->PCC. > > Well you should think about implementation complexity for the PCC. > A first question might be "How does the PCC in your second example know > that it needs to invoke PCE2?" > If the answer is that it must parse the returned path and understand: > - that the path is not complete > - that PCE2 is responsible for completing part of the path > - the location of PCE2 > then you have considerably increased the function that the PCC must > include. > For inter-domain cases, you are also significantly increasing the > complexity of policy. > I also wonder about the consequences for scaling. > IB>> Completely agree with you. For the very same reasons that you just described I (as a PCC) wouldn't use this mode for an on-line path computation. However, for the off-line path computation when I don't have time limitations - why not? I have discovered two PCEs in the domain, so I send identical requests simultaneously to both of them. Once I get responses I compare the returned paths - costs, diversities, expliticity, constraints that were honored, etc. - and select the better set. Note that Eric has not raised the issue of scalability, his concerns were, as I understood, security and additional complexity for coordination of partial path computations. I am not worried about that because when a federation of PCEs collectively satisfy a path computation request (example 1), the PCEs will have to address these issues anyway, and a PCC requesting computations from several PCEs could use the same solution(s). > But these are the points that Eric raised and you seem to think are not > important. IB>> exactly. Cheers, Igor > > Adrian > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 16 12:15:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5426-0001ei-1u; Tue, 16 Aug 2005 12:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5424-0001eL-Ek for pce@megatron.ietf.org; Tue, 16 Aug 2005 12:11:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20422 for ; Tue, 16 Aug 2005 12:11:17 -0400 (EDT) From: E.T.Metz@telecom.tno.nl Received: from ds07.tnoase.telecom.tno.nl ([139.63.192.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54bQ-0005O5-F2 for pce@ietf.org; Tue, 16 Aug 2005 12:47:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Date: Tue, 16 Aug 2005 18:11:00 +0200 Message-ID: <81FEC275650AE14EBD5245E624762B9701ACED55@ds07.tnoase.telecom.tno.nl> Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWMWE9wD7yTCTGzRvqSs+ZPDOTcQAWH+59g To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis (and others), I have a few questions related to PCE discovery that hopefully you can clarify. - The PCE architecture drafts suggests to reuse existing protocols for PCE discovery, yet it does not mandate that the PCE actually participate in these protocols. Does this mean that automated PCE discovery is limited to specific scenarios, or should it be applicable to any scenario (composite node, external node, IGP/BGP participant, or not ..). I can imagine it is not useful or feasible to cover every possible scenario. - PCE can advertise their capabilities in order for PCC to select the appropriate PCE for their path computation. Does this also require or assume that PCCs must understand the advertised capabilities and make the right choice? For example, a PCE may have limited scope, yet a PCC may not understand the scope of its path computation request and direct it to the 'wrong' PCE. (follow-up actions could e.g. be re-direct or forward, which is probably beyond the scope of PCE discovery) cheers, Eduard _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 21 17:35:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6xTN-0000he-S7; Sun, 21 Aug 2005 17:35:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6xTN-0000hW-9o for pce@megatron.ietf.org; Sun, 21 Aug 2005 17:35:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20067 for ; Sun, 21 Aug 2005 17:35:18 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6y3l-0001IU-7e for pce@ietf.org; Sun, 21 Aug 2005 18:13:00 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1124660047!4569791!7 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 22228 invoked from network); 21 Aug 2005 21:35:07 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-7.tower-121.messagelabs.com with SMTP; 21 Aug 2005 21:35:07 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00E0B1AD; Sun, 21 Aug 2005 17:35:06 -0400 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 Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63 Date: Sun, 21 Aug 2005 16:35:06 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9227@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Draft PCE WG Minutes - IETF-63 Thread-Index: AcWgEozyW6vrfWHGS323Wonl/oWzygGhPucQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, Small clarification and comment. > ------------------------------------------------------------- > Path Computation Element (PCE) communication Protocol (PCEP) > > draft-vasseur-pce-pcep-01.txt > (JP) > -------------------------------------------------------------- ... > Jerry: if we do not have a list of requirements=20 > *including application-specific requirements*, > how can we proceed *with pcep*? You provided an answer to this question in the meeting, it would be good to include the answer. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 21 19:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6zDl-0001YH-22; Sun, 21 Aug 2005 19:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6zDj-0001YC-Np for pce@megatron.ietf.org; Sun, 21 Aug 2005 19:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25431 for ; Sun, 21 Aug 2005 19:27:16 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6zo9-0003rd-St for pce@ietf.org; Sun, 21 Aug 2005 20:05:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2005 19:27:08 -0400 X-IronPort-AV: i="3.96,129,1122868800"; d="scan'208"; a="67316093:sNHT29082972" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7LNR5Ql003362; Sun, 21 Aug 2005 19:27:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 19:27:21 -0400 Received: from [192.168.1.101] ([10.86.242.101]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 19:27:04 -0400 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9227@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA09FA9227@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AAC909F-3725-4B1B-964E-A437CADD0F3A@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Sun, 21 Aug 2005 19:27:30 -0400 To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 21 Aug 2005 23:27:04.0842 (UTC) FILETIME=[D7190EA0:01C5A6A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Sure, will do. Thanks Jerry. JP. On Aug 21, 2005, at 5:35 PM, Ash, Gerald R ((Jerry)), ALABS wrote: > Hi JP, > > Small clarification and comment. > > >> ------------------------------------------------------------- >> Path Computation Element (PCE) communication Protocol (PCEP) >> >> draft-vasseur-pce-pcep-01.txt >> (JP) >> -------------------------------------------------------------- >> > > ... > > >> Jerry: if we do not have a list of requirements >> *including application-specific requirements*, >> how can we proceed *with pcep*? >> > > You provided an answer to this question in the meeting, it would be > good > to include the answer. > > Thanks, > Jerry > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 23 05:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Uz0-0004W8-RE; Tue, 23 Aug 2005 05:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Uyz-0004W3-Of for pce@megatron.ietf.org; Tue, 23 Aug 2005 05:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22918 for ; Tue, 23 Aug 2005 05:22:10 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Uz2-0005wR-2q for pce@ietf.org; Tue, 23 Aug 2005 05:22:18 -0400 Received: from du-069-0139.access.clara.net ([217.158.132.139] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E7Uyc-000LVC-Gl for pce@ietf.org; Tue, 23 Aug 2005 10:21:52 +0100 Message-ID: <00be01c5a7c4$7774d060$c5919ed9@Puppy> From: "Adrian Farrel" To: References: <075f01c59dda$e962ba00$08849ed9@Puppy> Subject: Re: [Pce] PCEP ENCAP object Date: Mon, 22 Aug 2005 23:37:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.7 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Well, we weren't exactly flooded with responses on this issue, but there seemed to be a slight preference for option 3 with no-one speaking up for options 1 and 2. Since the current PCEP I-D uses option 2 and only introduces option 3 for entirely new or very significantly different objects, it would be interesting to hear the views of the authors on this issue. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, August 10, 2005 6:47 PM Subject: [Pce] PCEP ENCAP object Hi, I have a question remaining about the PCEP spec, and I would appreciate input from the WG and from the DT. There is clearly considerable overlap between the information that needs to be carried by PCEP and that which is signaled by RSVP-TE. This is not a surprise because many of the constraints are identical. As a result, when deriving ways to encode this information it makes sense (to me and apparently to the DT) to re-use encodings that already exist. This takes care of many of the details, but it leaves a high-level question. We should choose between the three options listed below. 1. Re-use RSVP-TE objects entirely unchanged In this option, PCEP messages can carry objects encoded as RSVP-TE objects using the same C-Num and C-Type as defined for RSVP-TE. The disadvantages of this mechanism are: a. RSVP and PCEP share the same code-point space with the possible result that the space will become depleted. b. Changes to the RSVP-TE object will result in the receipt of unexpected variants to the PCEP object. I don't know whether this will matter since the RSVP processing rules will require backward compatibility. c. Fields that are not required in PCE will be transported but not used. d. Subobjects that are not required in PCE are ambiguous. This option would be documented as follows: My_Object C-Num and C-Type as for RSVP-TE [RFCwxyz] The content of this object is defined in [RFCwxyz] In the context of PCE the fields of this object are interpreted as follows: Field 1: Blah, blah, blah Field 2: etc. 2. Encapsulate RSVP-TE objects entirely unchanged As currently documented, the ENCAP object solves problem 1a. Encapsulation keeps the code points separate. There is the further (significant) advantage that objects from other protocols can also be encapsulated which provides great future extensibility. We should note, however, that there is no impact on issues 1b, 1c, or 1d. There is also no change to the mechanism for documentation. In particular, it is still necessary to document the meaning of the fields in the context of PCE, and this would mean that as new objects (from any protocol) are made available for encapsulation new I-Ds would be needed to describe how they identify constraints or response information. Further, if an existing object is modified in an I-D for some other protocol, a new I-D would be needed for PCEP to explain how the new fields are used (if they are used). There might be limited exceptions to this when interpretation is obvious and unambiguous. 3. Define new objects within PCEP In this option new objects are defined specifically for PCEP. Where the contents of the object are identical to those in some other protocol, this can be documented by reference, but the PCEP I-D has to describe how they are used in the PCE context. Where only some of the fields are identical to those in an object (or several objects) in another protocol they need to be documented, but unused protocol fields do not need to be reproduced in PCEP. This option solves all of the issues 1a, 1b, 1c and 1d, but introduces the need for new source code that cannot be common with the protocol code used in some other component. There are no documentation requirements for changes to other protocols, but there may be more to do when new information is added to PCEP. [Note that this option says much less about how the information is actually encoded.] Discuss. Thanks, Adrian -------------------------------------------------------------------------- ------ > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 23 05:43:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7VJb-0000JP-BT; Tue, 23 Aug 2005 05:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7VJa-0000JF-Mj for pce@megatron.ietf.org; Tue, 23 Aug 2005 05:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23506 for ; Tue, 23 Aug 2005 05:43:28 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7VJg-0006SK-4D for pce@ietf.org; Tue, 23 Aug 2005 05:43:36 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 11:43:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] PCEP ENCAP object Date: Tue, 23 Aug 2005 11:43:32 +0200 Message-ID: Thread-Topic: [Pce] PCEP ENCAP object Thread-Index: AcWnxF8n6ka0bQt6RReI+1kCAZ4yzAAANfNg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 23 Aug 2005 09:43:21.0817 (UTC) FILETIME=[19816C90:01C5A7C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian, all Option 2+3 sounds the best way to progress, as it provides a good = flexibility. Option 3 only could, for some objects, be really heavy... take ERO for = instance and think about redocumenting all ERO subobjects types from = 3902, 3473, 3477... Note that in current PCEP version we carefully use option 2 only when = useful (4 of 13 objects),=20 and this is not the default option. Note that option 2 must be used only when there is a significant gain = (e.g. ERO). Regards, JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel > Envoy=E9 : mardi 23 ao=FBt 2005 00:38 > =C0 : pce@ietf.org > Objet : Re: [Pce] PCEP ENCAP object >=20 > Well, we weren't exactly flooded with responses on this=20 > issue, but there seemed to be a slight preference for option=20 > 3 with no-one speaking up for options 1 and 2. >=20 > Since the current PCEP I-D uses option 2 and only introduces=20 > option 3 for entirely new or very significantly different=20 > objects, it would be interesting to hear the views of the=20 > authors on this issue. >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Wednesday, August 10, 2005 6:47 PM > Subject: [Pce] PCEP ENCAP object >=20 >=20 > Hi, >=20 > I have a question remaining about the PCEP spec, and I would=20 > appreciate > input from the WG and from the DT. >=20 > There is clearly considerable overlap between the information=20 > that needs > to be carried by PCEP and that which is signaled by RSVP-TE.=20 > This is not a > surprise because many of the constraints are identical. As a=20 > result, when > deriving ways to encode this information it makes sense (to me and > apparently to the DT) to re-use encodings that already exist. >=20 > This takes care of many of the details, but it leaves a high-level > question. We should choose between the three options listed below. >=20 > 1. Re-use RSVP-TE objects entirely unchanged > In this option, PCEP messages can carry objects encoded as > RSVP-TE objects using the same C-Num and C-Type as defined > for RSVP-TE. > The disadvantages of this mechanism are: > a. RSVP and PCEP share the same code-point space with the > possible result that the space will become depleted. > b. Changes to the RSVP-TE object will result in the receipt > of unexpected variants to the PCEP object. I don't know > whether this will matter since the RSVP processing rules > will require backward compatibility. > c. Fields that are not required in PCE will be transported > but not used. > d. Subobjects that are not required in PCE are ambiguous. > This option would be documented as follows: > My_Object > C-Num and C-Type as for RSVP-TE [RFCwxyz] > The content of this object is defined in [RFCwxyz] > In the context of PCE the fields of this object are > interpreted as follows: >=20 > Field 1: > Blah, blah, blah >=20 > Field 2: > etc. >=20 > 2. Encapsulate RSVP-TE objects entirely unchanged > As currently documented, the ENCAP object solves problem 1a. > Encapsulation keeps the code points separate. > There is the further (significant) advantage that objects > from other protocols can also be encapsulated which provides > great future extensibility. > We should note, however, that there is no impact on issues > 1b, 1c, or 1d. > There is also no change to the mechanism for documentation. > In particular, it is still necessary to document the meaning > of the fields in the context of PCE, and this would mean that > as new objects (from any protocol) are made available for > encapsulation new I-Ds would be needed to describe how > they identify constraints or response information. Further, > if an existing object is modified in an I-D for some other > protocol, a new I-D would be needed for PCEP to explain how > the new fields are used (if they are used). > There might be limited exceptions to this when interpretation > is obvious and unambiguous. >=20 > 3. Define new objects within PCEP > In this option new objects are defined specifically for PCEP. > Where the contents of the object are identical to those in > some other protocol, this can be documented by reference, but > the PCEP I-D has to describe how they are used in the PCE > context. > Where only some of the fields are identical to those in an > object (or several objects) in another protocol they need to > be documented, but unused protocol fields do not need to be > reproduced in PCEP. > This option solves all of the issues 1a, 1b, 1c and 1d, but > introduces the need for new source code that cannot be common > with the protocol code used in some other component. > There are no documentation requirements for changes to other > protocols, but there may be more to do when new information > is added to PCEP. > [Note that this option says much less about how the > information is actually encoded.] >=20 >=20 > Discuss. >=20 > Thanks, > Adrian >=20 >=20 > -------------------------------------------------------------- > ------------ > ------ >=20 >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 23 07:12:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WhI-0001uC-MU; Tue, 23 Aug 2005 07:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WhG-0001tu-S9 for pce@megatron.ietf.org; Tue, 23 Aug 2005 07:12:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27617 for ; Tue, 23 Aug 2005 07:12:00 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7WhM-0000ii-J4 for pce@ietf.org; Tue, 23 Aug 2005 07:12:09 -0400 Received: from du-069-0073.access.clara.net ([217.158.132.73] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E7Wh1-0003WE-HL; Tue, 23 Aug 2005 12:11:55 +0100 Message-ID: <011f01c5a7d3$d3555490$c5919ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: [Pce] PCEP ENCAP object Date: Tue, 23 Aug 2005 12:14:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.6 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010524378==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2010524378== Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01C5A7DC.2AD9FCE0" This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C5A7DC.2AD9FCE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JL, Thanks for responding. I think I need to draw your attention to the precise wording that I put = in option 3. >> In this option new objects are defined specifically for PCEP. >> Where the contents of the object are identical to those in >> some other protocol, this can be documented by reference, but >> the PCEP I-D has to describe how they are used in the PCE >> context. That is, to use your example of the ERO, the PCEP text would define a = new object and would state something like... The contents of this object are identical in encoding to the contents of the RSVP-TE Explicit Route Object. That is, the object is constructed from a series of sub-objects. Any=20 sub-object defined for use in the ERO is acceptable in this object. This object is used to report an explicit path that has been computed by a PCE. Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO. This is not particularly heavy IMHO, and does not represent a = significant gain from the ENCAPs object. Thanks, Adrian ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" = To: ; Sent: Tuesday, August 23, 2005 10:43 AM Subject: RE: [Pce] PCEP ENCAP object Hi Adrian, all Option 2+3 sounds the best way to progress, as it provides a good = flexibility. Option 3 only could, for some objects, be really heavy... take ERO for = instance and think about redocumenting all ERO subobjects types from = 3902, 3473, 3477... Note that in current PCEP version we carefully use option 2 only when = useful (4 of 13 objects),=20 and this is not the default option. Note that option 2 must be used only when there is a significant gain = (e.g. ERO). Regards, JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel > Envoy=E9 : mardi 23 ao=FBt 2005 00:38 > =C0 : pce@ietf.org > Objet : Re: [Pce] PCEP ENCAP object >=20 > Well, we weren't exactly flooded with responses on this=20 > issue, but there seemed to be a slight preference for option=20 > 3 with no-one speaking up for options 1 and 2. >=20 > Since the current PCEP I-D uses option 2 and only introduces=20 > option 3 for entirely new or very significantly different=20 > objects, it would be interesting to hear the views of the=20 > authors on this issue. >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Wednesday, August 10, 2005 6:47 PM > Subject: [Pce] PCEP ENCAP object >=20 >=20 > Hi, >=20 > I have a question remaining about the PCEP spec, and I would=20 > appreciate > input from the WG and from the DT. >=20 > There is clearly considerable overlap between the information=20 > that needs > to be carried by PCEP and that which is signaled by RSVP-TE.=20 > This is not a > surprise because many of the constraints are identical. As a=20 > result, when > deriving ways to encode this information it makes sense (to me and > apparently to the DT) to re-use encodings that already exist. >=20 > This takes care of many of the details, but it leaves a high-level > question. We should choose between the three options listed below. >=20 > 1. Re-use RSVP-TE objects entirely unchanged > In this option, PCEP messages can carry objects encoded as > RSVP-TE objects using the same C-Num and C-Type as defined > for RSVP-TE. > The disadvantages of this mechanism are: > a. RSVP and PCEP share the same code-point space with the > possible result that the space will become depleted. > b. Changes to the RSVP-TE object will result in the receipt > of unexpected variants to the PCEP object. I don't know > whether this will matter since the RSVP processing rules > will require backward compatibility. > c. Fields that are not required in PCE will be transported > but not used. > d. Subobjects that are not required in PCE are ambiguous. > This option would be documented as follows: > My_Object > C-Num and C-Type as for RSVP-TE [RFCwxyz] > The content of this object is defined in [RFCwxyz] > In the context of PCE the fields of this object are > interpreted as follows: >=20 > Field 1: > Blah, blah, blah >=20 > Field 2: > etc. >=20 > 2. Encapsulate RSVP-TE objects entirely unchanged > As currently documented, the ENCAP object solves problem 1a. > Encapsulation keeps the code points separate. > There is the further (significant) advantage that objects > from other protocols can also be encapsulated which provides > great future extensibility. > We should note, however, that there is no impact on issues > 1b, 1c, or 1d. > There is also no change to the mechanism for documentation. > In particular, it is still necessary to document the meaning > of the fields in the context of PCE, and this would mean that > as new objects (from any protocol) are made available for > encapsulation new I-Ds would be needed to describe how > they identify constraints or response information. Further, > if an existing object is modified in an I-D for some other > protocol, a new I-D would be needed for PCEP to explain how > the new fields are used (if they are used). > There might be limited exceptions to this when interpretation > is obvious and unambiguous. >=20 > 3. Define new objects within PCEP > In this option new objects are defined specifically for PCEP. > Where the contents of the object are identical to those in > some other protocol, this can be documented by reference, but > the PCEP I-D has to describe how they are used in the PCE > context. > Where only some of the fields are identical to those in an > object (or several objects) in another protocol they need to > be documented, but unused protocol fields do not need to be > reproduced in PCEP. > This option solves all of the issues 1a, 1b, 1c and 1d, but > introduces the need for new source code that cannot be common > with the protocol code used in some other component. > There are no documentation requirements for changes to other > protocols, but there may be more to do when new information > is added to PCEP. > [Note that this option says much less about how the > information is actually encoded.] >=20 >=20 > Discuss. >=20 > Thanks, > Adrian >=20 >=20 > -------------------------------------------------------------- > ------------ > ------ >=20 >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 ------=_NextPart_000_011C_01C5A7DC.2AD9FCE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JL,
 
Thanks for responding.
 
I think I need to draw your attention = to the=20 precise wording that I put in option 3.
 
>>    In this = option new=20 objects are defined specifically for PCEP.
>>    = Where=20 the contents of the object are identical to those=20 in
>>    some other protocol, this can be = documented by=20 reference, but
>>    the PCEP I-D has to = describe how=20 they are used in the PCE
>>    = context.
 
That is, to use your example of the = ERO, the PCEP=20 text would define a new object and would state something = like...
   The contents of this = object are=20 identical in encoding to the
   contents of the RSVP-TE = Explicit=20 Route Object. That is, the
   object is constructed = from a series=20 of sub-objects. Any
   sub-object defined for = use in the=20 ERO is acceptable in this
   object.
   This object is used to = report an=20 explicit path that has been
   computed by a PCE. Since = the=20 explicit path is available for
   immediate signaling by = the MPLS or=20 GMPLS control plane, the
   meanings of all of the = sub-objects=20 and fields in this object
   are identical to those = defined for=20 the ERO.
This is not particularly heavy IMHO, = and does not=20 represent a significant gain from the ENCAPs object.
 
Thanks,
Adrian
 
----- Original Message -----
From: "LE ROUX Jean-Louis = RD-CORE-LAN"=20 <jeanlouis.leroux@francetelecom.com>
To: <adrian@olddog.co.uk>;=20 <pce@ietf.org>
Sent: Tuesday, August 23, 2005 10:43=20 AM
Subject: RE: [Pce] PCEP ENCAP=20 object

Hi Adrian, all

Option 2+3 = sounds the best=20 way to progress, as it provides a good flexibility.
Option 3 only = could, for=20 some objects, be really heavy... take ERO for instance and think about=20 redocumenting all ERO subobjects types from 3902, 3473, = 3477...

Note that=20 in current PCEP version we carefully use option 2 only when useful (4 of = 13=20 objects),
and this is not the default option.

Note that = option 2 must=20 be used only when there is a significant gain (e.g.=20 ERO).

Regards,

JL



> -----Message=20 d'origine-----
> De : pce-bounces@lists.ietf.org=20
> = [mailto:pce-bounces@lists.ietf.org] De la=20 part de Adrian Farrel
> Envoy=E9 : mardi 23 ao=FBt 2005 = 00:38
> =C0 :=20 pce@ietf.org
> = Objet : Re:=20 [Pce] PCEP ENCAP object
>
> Well, we weren't exactly = flooded with=20 responses on this
> issue, but there seemed to be a slight = preference for=20 option
> 3 with no-one speaking up for options 1 and 2.
> =
>=20 Since the current PCEP I-D uses option 2 and only introduces
> = option 3=20 for entirely new or very significantly different
> objects, it = would be=20 interesting to hear the views of the
> authors on this = issue.
>=20
> Thanks,
> Adrian
>
> ----- Original Message=20 -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To:=20 <pce@ietf.org>
> Sent:=20 Wednesday, August 10, 2005 6:47 PM
> Subject: [Pce] PCEP ENCAP=20 object
>
>
> Hi,
>
> I have a question=20 remaining about the PCEP spec, and I would
> appreciate
> = input=20 from the WG and from the DT.
>
> There is clearly = considerable=20 overlap between the information
> that needs
> to be = carried by=20 PCEP and that which is signaled by RSVP-TE.
> This is not = a
>=20 surprise because many of the constraints are identical. As a
> = result,=20 when
> deriving ways to encode this information it makes sense (to = me=20 and
> apparently to the DT) to re-use encodings that already=20 exist.
>
> This takes care of many of the details, but it = leaves a=20 high-level
> question. We should choose between the three options = listed=20 below.
>
> 1. Re-use RSVP-TE objects entirely=20 unchanged
>    In this option, PCEP messages can = carry=20 objects encoded as
>    RSVP-TE objects using the = same=20 C-Num and C-Type as defined
>    for=20 RSVP-TE.
>    The disadvantages of this mechanism=20 are:
>    a. RSVP and PCEP share the same = code-point space=20 with the
>       possible result = that the=20 space will become depleted.
>    b. Changes to the = RSVP-TE=20 object will result in the = receipt
>       of=20 unexpected variants to the PCEP object. I don't=20 know
>       whether this will = matter since=20 the RSVP processing rules
>       = will=20 require backward compatibility.
>    c. Fields that = are not=20 required in PCE will be = transported
>      =20 but not used.
>    d. Subobjects that are not = required in=20 PCE are ambiguous.
>       This = option would=20 be documented as=20 follows:
>        =20 My_Object
>         C-Num = and=20 C-Type as for RSVP-TE=20 [RFCwxyz]
>         The = content of=20 this object is defined in=20 [RFCwxyz]
>         In the = context=20 of PCE the fields of this object=20 are
>         interpreted = as=20 follows:
>=20
>           = Field=20 1:
>          &nb= sp;  =20 Blah, blah, blah
>=20
>           = Field=20 2:
>          &nb= sp;  =20 etc.
>
> 2. Encapsulate RSVP-TE objects entirely=20 unchanged
>    As currently documented, the ENCAP = object=20 solves problem 1a.
>    Encapsulation keeps the = code points=20 separate.
>    There is the further (significant) = advantage=20 that objects
>    from other protocols can also be=20 encapsulated which provides
>    great future=20 extensibility.
>    We should note, however, that = there is=20 no impact on issues
>    1b, 1c, or=20 1d.
>    There is also no change to the mechanism = for=20 documentation.
>    In particular, it is still = necessary to=20 document the meaning
>    of the fields in the = context of=20 PCE, and this would mean that
>    as new objects = (from any=20 protocol) are made available for
>    encapsulation = new=20 I-Ds would be needed to  describe how
>    = they=20 identify constraints or response information. = Further,
>   =20 if an existing object is modified in an I-D for some=20 other
>    protocol, a new I-D would be needed for = PCEP to=20 explain how
>    the new fields are used (if they = are=20 used).
>    There might be limited exceptions to = this when=20 interpretation
>    is obvious and = unambiguous.
>=20
>  3. Define new objects within = PCEP
>    In=20 this option new objects are defined specifically for=20 PCEP.
>    Where the contents of the object are = identical=20 to those in
>    some other protocol, this can be=20 documented by reference, but
>    the PCEP I-D has = to=20 describe how they are used in the PCE
>   =20 context.
>    Where only some of the fields are = identical=20 to those in an
>    object (or several objects) in = another=20 protocol they need to
>    be documented, but = unused=20 protocol fields do not need to be
>    reproduced = in=20 PCEP.
>    This option solves all of the issues 1a, = 1b, 1c=20 and 1d, but
>    introduces the need for new source = code=20 that cannot be common
>    with the protocol code = used in=20 some other component.
>    There are no = documentation=20 requirements for changes to other
>    protocols, = but there=20 may be more to do when new information
>    is = added to=20 PCEP.
>    [Note that this option says much less = about how=20 the
>     information is actually = encoded.]
>=20
>
> Discuss.
>
> Thanks,
> = Adrian
>=20
>
>=20 --------------------------------------------------------------
>=20 ------------
> ------
>
>
> >=20 _______________________________________________
> > Pce mailing = list
> > Pce@lists.ietf.org
> >=20 https://www1.ietf.org/mailman/listinfo/pce
> >
>
>
>=20 _______________________________________________
> Pce mailing = list
>=20 Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
>

------=_NextPart_000_011C_01C5A7DC.2AD9FCE0-- --===============2010524378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2010524378==-- From pce-bounces@lists.ietf.org Tue Aug 23 12:16:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bLo-00064f-6t; Tue, 23 Aug 2005 12:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bLk-000649-NR for pce@megatron.ietf.org; Tue, 23 Aug 2005 12:10:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12481 for ; Tue, 23 Aug 2005 12:10:06 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bLq-0000ne-Jn for pce@ietf.org; Tue, 23 Aug 2005 12:10:17 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 18:10:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] PCEP ENCAP object Date: Tue, 23 Aug 2005 18:10:13 +0200 Message-ID: Thread-Topic: [Pce] PCEP ENCAP object Thread-Index: AcWn03nl4se4KXJwRSOtDAIwH2SImwAFGJOA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 23 Aug 2005 16:10:03.0170 (UTC) FILETIME=[1E96F020:01C5A7FD] X-Spam-Score: 0.9 (/) X-Scan-Signature: fbb024a763f81fc20bcc0df70457576f Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1266312895==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1266312895== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A7FD.1E61FBE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A7FD.1E61FBE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adrian, =20 Please see inline ________________________________ De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Envoy=E9 : mardi 23 ao=FBt 2005 13:14 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] PCEP ENCAP object =09 =09 Hi JL, =20 Thanks for responding. =20 I think I need to draw your attention to the precise wording that I put = in option 3.=20 =09 >> In this option new objects are defined specifically for PCEP. >> Where the contents of the object are identical to those in >> some other protocol, this can be documented by reference, but >> the PCEP I-D has to describe how they are used in the PCE >> context. =20 That is, to use your example of the ERO, the PCEP text would define a = new object and would state something like... The contents of this object are identical in encoding to the contents of the RSVP-TE Explicit Route Object. That is, the object is constructed from a series of sub-objects. Any=20 sub-object defined for use in the ERO is acceptable in this object. [JLLR] You would end up with PCEP objects made of RSVP sub-objects, and = from a pure protocol design point of view this sounds quite ugly :-( =20 =20 This object is used to report an explicit path that has been computed by a PCE. Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO. =09 This is not particularly heavy IMHO, and does not represent a = significant gain from the ENCAPs object. =09 [JLLR]=20 With option 3 you solve option 1 issues by having separate name spaces = and actually by introducing a mapping between RSVP name space and PCEP = name space (i.e. PCEP object x content =3D RSVP object y content). =20 The rationale for option 2 is to avoid such mapping.=20 By the way the ENCAP object saves PCEP name space and maybe in 10 years = we may face PCEP name space saturation :-) (see what happens with RSVP = name space...) =20 Regards, =20 JL =20 =20 Thanks, Adrian =20 ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" = > To: >; > Sent: Tuesday, August 23, 2005 10:43 AM Subject: RE: [Pce] PCEP ENCAP object =09 =09 Hi Adrian, all =09 Option 2+3 sounds the best way to progress, as it provides a good = flexibility. Option 3 only could, for some objects, be really heavy... take ERO for = instance and think about redocumenting all ERO subobjects types from = 3902, 3473, 3477... =09 Note that in current PCEP version we carefully use option 2 only when = useful (4 of 13 objects),=20 and this is not the default option. =09 Note that option 2 must be used only when there is a significant gain = (e.g. ERO). =09 Regards, =09 JL =09 =09 =09 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org =20 =09 > [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel > Envoy=E9 : mardi 23 ao=FBt 2005 00:38 > =C0 : pce@ietf.org =20 > Objet : Re: [Pce] PCEP ENCAP object >=20 > Well, we weren't exactly flooded with responses on this=20 > issue, but there seemed to be a slight preference for option=20 > 3 with no-one speaking up for options 1 and 2. >=20 > Since the current PCEP I-D uses option 2 and only introduces=20 > option 3 for entirely new or very significantly different=20 > objects, it would be interesting to hear the views of the=20 > authors on this issue. >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Adrian Farrel" > > To: > > Sent: Wednesday, August 10, 2005 6:47 PM > Subject: [Pce] PCEP ENCAP object >=20 >=20 > Hi, >=20 > I have a question remaining about the PCEP spec, and I would=20 > appreciate > input from the WG and from the DT. >=20 > There is clearly considerable overlap between the information=20 > that needs > to be carried by PCEP and that which is signaled by RSVP-TE.=20 > This is not a > surprise because many of the constraints are identical. As a=20 > result, when > deriving ways to encode this information it makes sense (to me and > apparently to the DT) to re-use encodings that already exist. >=20 > This takes care of many of the details, but it leaves a high-level > question. We should choose between the three options listed below. >=20 > 1. Re-use RSVP-TE objects entirely unchanged > In this option, PCEP messages can carry objects encoded as > RSVP-TE objects using the same C-Num and C-Type as defined > for RSVP-TE. > The disadvantages of this mechanism are: > a. RSVP and PCEP share the same code-point space with the > possible result that the space will become depleted. > b. Changes to the RSVP-TE object will result in the receipt > of unexpected variants to the PCEP object. I don't know > whether this will matter since the RSVP processing rules > will require backward compatibility. > c. Fields that are not required in PCE will be transported > but not used. > d. Subobjects that are not required in PCE are ambiguous. > This option would be documented as follows: > My_Object > C-Num and C-Type as for RSVP-TE [RFCwxyz] > The content of this object is defined in [RFCwxyz] > In the context of PCE the fields of this object are > interpreted as follows: >=20 > Field 1: > Blah, blah, blah >=20 > Field 2: > etc. >=20 > 2. Encapsulate RSVP-TE objects entirely unchanged > As currently documented, the ENCAP object solves problem 1a. > Encapsulation keeps the code points separate. > There is the further (significant) advantage that objects > from other protocols can also be encapsulated which provides > great future extensibility. > We should note, however, that there is no impact on issues > 1b, 1c, or 1d. > There is also no change to the mechanism for documentation. > In particular, it is still necessary to document the meaning > of the fields in the context of PCE, and this would mean that > as new objects (from any protocol) are made available for > encapsulation new I-Ds would be needed to describe how > they identify constraints or response information. Further, > if an existing object is modified in an I-D for some other > protocol, a new I-D would be needed for PCEP to explain how > the new fields are used (if they are used). > There might be limited exceptions to this when interpretation > is obvious and unambiguous. >=20 > 3. Define new objects within PCEP > In this option new objects are defined specifically for PCEP. > Where the contents of the object are identical to those in > some other protocol, this can be documented by reference, but > the PCEP I-D has to describe how they are used in the PCE > context. > Where only some of the fields are identical to those in an > object (or several objects) in another protocol they need to > be documented, but unused protocol fields do not need to be > reproduced in PCEP. > This option solves all of the issues 1a, 1b, 1c and 1d, but > introduces the need for new source code that cannot be common > with the protocol code used in some other component. > There are no documentation requirements for changes to other > protocols, but there may be more to do when new information > is added to PCEP. > [Note that this option says much less about how the > information is actually encoded.] >=20 >=20 > Discuss. >=20 > Thanks, > Adrian >=20 >=20 > -------------------------------------------------------------- > ------------ > ------ >=20 >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org =20 > > https://www1.ietf.org/mailman/listinfo/pce = =20 > > >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org =20 > https://www1.ietf.org/mailman/listinfo/pce = =20 >=20 =09 =09 ------_=_NextPart_001_01C5A7FD.1E61FBE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
 
Please see inline

De : Adrian Farrel=20 [mailto:adrian@olddog.co.uk]
Envoy=E9 : mardi 23 = ao=FBt 2005=20 13:14
=C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20 pce@ietf.org
Objet : Re: [Pce] PCEP ENCAP=20 object

Hi JL,
 
Thanks for responding.
 
I think I need to draw your = attention to the=20 precise wording that I put in option 3. 
>>    In this = option new=20 objects are defined specifically for = PCEP.
>>    Where=20 the contents of the object are identical to those=20 in
>>    some other protocol, this can be = documented=20 by reference, but
>>    the PCEP I-D has to = describe=20 how they are used in the PCE
>>   =20 context.
 
That is, to use your example of the = ERO, the=20 PCEP text would define a new object and would state something=20 like...
   The contents of this = object are=20 identical in encoding to the
   contents of the = RSVP-TE Explicit=20 Route Object. That is, the
   object is constructed = from a=20 series of sub-objects. Any
   sub-object defined for = use in the=20 ERO is acceptable in this
   object.
[JLLR] You would=20 end up with PCEP objects made of RSVP sub-objects, and from = a pure=20 protocol design point of view this sounds quite ugly=20 :-(
 
 
   This object is used to = report an=20 explicit path that has been
   computed by a PCE. = Since the=20 explicit path is available for
   immediate signaling by = the MPLS or=20 GMPLS control plane, the
   meanings of all of the = sub-objects=20 and fields in this object
   are identical to those = defined for=20 the ERO.
This is not particularly = heavy IMHO, and=20 does not represent a significant gain from the ENCAPs=20 object.
[JLLR] 
With option 3 you solve option 1 issues=20 by having separate name spaces and actually by=20 introducing a mapping between RSVP name space and PCEP = name=20 space (i.e. PCEP object x content =3D RSVP object y=20 content).
&nbs= p;
The rationale for=20 option 2 is = to avoid such=20 mapping.
By the way the ENCAP object saves PCEP = name=20 space and maybe in 10 years we may face PCEP name space saturation :-) = (see=20 what happens with RSVP name=20 space...)
&nbs= p;
Regards,
&nbs= p;
JL
&nbs= p;
 
Thanks,
Adrian
 
----- Original Message ----- =
From: "LE ROUX Jean-Louis = RD-CORE-LAN"=20 <jeanlouis.leroux@francetelecom.com>
To: <adrian@olddog.co.uk>;=20 <pce@ietf.org>
Sent: Tuesday, August 23, 2005 = 10:43=20 AM
Subject: RE: [Pce] PCEP ENCAP=20 object

Hi Adrian, all

Option 2+3 = sounds the=20 best way to progress, as it provides a good flexibility.
Option 3 = only=20 could, for some objects, be really heavy... take ERO for instance and = think=20 about redocumenting all ERO subobjects types from 3902, 3473,=20 3477...

Note that in current PCEP version we carefully use = option 2=20 only when useful (4 of 13 objects),
and this is not the default=20 option.

Note that option 2 must be used only when there is a=20 significant gain (e.g. = ERO).

Regards,

JL



>=20 -----Message d'origine-----
> De : pce-bounces@lists.ietf.org=20
> = [mailto:pce-bounces@lists.ietf.org] De la=20 part de Adrian Farrel
> Envoy=E9 : mardi 23 ao=FBt 2005 = 00:38
> =C0 :=20 pce@ietf.org
> = Objet : Re:=20 [Pce] PCEP ENCAP object
>
> Well, we weren't exactly = flooded with=20 responses on this
> issue, but there seemed to be a slight = preference=20 for option
> 3 with no-one speaking up for options 1 and = 2.
>=20
> Since the current PCEP I-D uses option 2 and only introduces =
>=20 option 3 for entirely new or very significantly different
> = objects, it=20 would be interesting to hear the views of the
> authors on this = issue.
>
> Thanks,
> Adrian
>
> ----- = Original=20 Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
>=20 To: <pce@ietf.org>
> Sent:=20 Wednesday, August 10, 2005 6:47 PM
> Subject: [Pce] PCEP ENCAP=20 object
>
>
> Hi,
>
> I have a = question=20 remaining about the PCEP spec, and I would
> appreciate
> = input=20 from the WG and from the DT.
>
> There is clearly = considerable=20 overlap between the information
> that needs
> to be = carried by=20 PCEP and that which is signaled by RSVP-TE.
> This is not = a
>=20 surprise because many of the constraints are identical. As a
> = result,=20 when
> deriving ways to encode this information it makes sense = (to me=20 and
> apparently to the DT) to re-use encodings that already=20 exist.
>
> This takes care of many of the details, but it = leaves=20 a high-level
> question. We should choose between the three = options=20 listed below.
>
> 1. Re-use RSVP-TE objects entirely=20 unchanged
>    In this option, PCEP messages can = carry=20 objects encoded as
>    RSVP-TE objects using the = same=20 C-Num and C-Type as defined
>    for=20 RSVP-TE.
>    The disadvantages of this mechanism = are:
>    a. RSVP and PCEP share the same = code-point=20 space with the
>       possible = result=20 that the space will become depleted.
>    b. = Changes to=20 the RSVP-TE object will result in the=20 receipt
>       of unexpected = variants to=20 the PCEP object. I don't = know
>      =20 whether this will matter since the RSVP processing=20 rules
>       will require = backward=20 compatibility.
>    c. Fields that are not = required in=20 PCE will be transported
>       = but not=20 used.
>    d. Subobjects that are not required in = PCE are=20 ambiguous.
>       This option = would be=20 documented as = follows:
>        =20 My_Object
>         = C-Num and=20 C-Type as for RSVP-TE=20 [RFCwxyz]
>         The = content=20 of this object is defined in=20 [RFCwxyz]
>         In = the=20 context of PCE the fields of this object=20 are
>         = interpreted as=20 follows:
>=20
>           = Field=20 = 1:
>          &nb= sp;  =20 Blah, blah, blah
>=20
>           = Field=20 = 2:
>          &nb= sp;  =20 etc.
>
> 2. Encapsulate RSVP-TE objects entirely=20 unchanged
>    As currently documented, the ENCAP = object=20 solves problem 1a.
>    Encapsulation keeps the = code=20 points separate.
>    There is the further = (significant)=20 advantage that objects
>    from other protocols = can also=20 be encapsulated which provides
>    great future=20 extensibility.
>    We should note, however, that = there=20 is no impact on issues
>    1b, 1c, or=20 1d.
>    There is also no change to the mechanism = for=20 documentation.
>    In particular, it is still = necessary=20 to document the meaning
>    of the fields in the = context=20 of PCE, and this would mean that
>    as new = objects=20 (from any protocol) are made available for
>   =20 encapsulation new I-Ds would be needed to  describe=20 how
>    they identify constraints or response=20 information. Further,
>    if an existing object = is=20 modified in an I-D for some other
>    protocol, = a new=20 I-D would be needed for PCEP to explain how
>    = the new=20 fields are used (if they are used).
>    There = might be=20 limited exceptions to this when = interpretation
>    is=20 obvious and unambiguous.
>
>  3. Define new objects = within=20 PCEP
>    In this option new objects are defined=20 specifically for PCEP.
>    Where the contents of = the=20 object are identical to those in
>    some other=20 protocol, this can be documented by reference, = but
>   =20 the PCEP I-D has to describe how they are used in the=20 PCE
>    context.
>    Where = only=20 some of the fields are identical to those in = an
>   =20 object (or several objects) in another protocol they need=20 to
>    be documented, but unused protocol fields = do not=20 need to be
>    reproduced in=20 PCEP.
>    This option solves all of the issues = 1a, 1b,=20 1c and 1d, but
>    introduces the need for new = source=20 code that cannot be common
>    with the protocol = code=20 used in some other component.
>    There are no=20 documentation requirements for changes to = other
>   =20 protocols, but there may be more to do when new=20 information
>    is added to=20 PCEP.
>    [Note that this option says much less = about=20 how the
>     information is actually=20 encoded.]
>
>
> Discuss.
>
> = Thanks,
>=20 Adrian
>
>
>=20 --------------------------------------------------------------
> = ------------
> ------
>
>
> >=20 _______________________________________________
> > Pce = mailing=20 list
> > Pce@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/pce
> >
>
>
>=20 _______________________________________________
> Pce mailing=20 list
> Pce@lists.ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/pce
> =

------_=_NextPart_001_01C5A7FD.1E61FBE9-- --===============1266312895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1266312895==-- From pce-bounces@lists.ietf.org Tue Aug 23 19:45:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iS7-0000Fs-Te; Tue, 23 Aug 2005 19:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iS7-0000Fn-0P for pce@megatron.ietf.org; Tue, 23 Aug 2005 19:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20195 for ; Tue, 23 Aug 2005 19:45:07 -0400 (EDT) Received: from web30507.mail.mud.yahoo.com ([68.142.200.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7iS5-000215-N9 for pce@ietf.org; Tue, 23 Aug 2005 19:45:24 -0400 Received: (qmail 79397 invoked by uid 60001); 23 Aug 2005 23:44:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AhV4R90n73yp47FhgHrBLCdIRDj2UX3m58MVEKkhImRuOliL1QTvrR+IFuIwPAn2OEI4wkUZ0+DKVIBXuZNqelKSZQWDa/UXV1cMtNMSdUIp+JMIYb1He3uRf1SguAIPR4St38NnQ3KmqSAgyxrvAxvgUYoa7oEV0t9ywv1PDdQ= ; Message-ID: <20050823234445.79395.qmail@web30507.mail.mud.yahoo.com> Received: from [213.94.134.204] by web30507.mail.mud.yahoo.com via HTTP; Wed, 24 Aug 2005 00:44:45 BST Date: Wed, 24 Aug 2005 00:44:45 +0100 (BST) From: Stephen Morris To: pce@ietf.org In-Reply-To: <00be01c5a7c4$7774d060$c5919ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Cc: Subject: [Pce] Management Issues 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi All I have a few comments/suggestions about the architecture document sections 8.1, 8.3, & 10: (1) Section 8.1 I suggest we allow path computations to be initiated using SNMP (e.g., set a variable). This potentially opens up PCE technology to existing NMS/OSS products. Just a new (PCE) MIB module and some backend code is needed to integrate PCE technology in this case. Path computation completion might be indicated by an informational notification or an SNMP response. Another approach might be the use of polling to allow a PCC to query PCE completion of a path request. (2) Section 8.3 Correctness - maybe provide ping access through SNMP? (3) Section 10 IANA might be needed for the MIB module? (4) A further manageability item is deployment or software distribution. Let's say I have LSR X from vendor Y and I want to upgrade LSR X to include PCE capability. Or let's say I want to upgrade a number of LSRs to support PCE. While this is mostly an NMS/OSS issue (ftp, tftp etc.), the PCE element can help by supporting software version data (i.e., deployment data). Best wishes Stephen Morris ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 26 05:16:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8aJn-0005NB-Qf; Fri, 26 Aug 2005 05:16:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8aJl-0005N1-01 for pce@megatron.ietf.org; Fri, 26 Aug 2005 05:16:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06443 for ; Fri, 26 Aug 2005 05:16:06 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8aKR-0006kJ-9X for pce@ietf.org; Fri, 26 Aug 2005 05:16:52 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 11:16:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt Date: Fri, 26 Aug 2005 11:16:19 +0200 Message-ID: Thread-Topic: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt Thread-Index: AcWcDUbUzLCBOLUhQ1C+6j8KL28fwgODYW/w From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" , X-OriginalArrivalTime: 26 Aug 2005 09:16:00.0209 (UTC) FILETIME=[C6452C10:01C5AA1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Zhang Sorry for replying so late... Please see inline,=20 > -----Message d'origine----- > De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 > Envoy=E9 : lundi 8 ao=FBt 2005 10:10 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Objet : Re: [Pce] About the=20 > presentationofdraft-zhang-pce-comm-app-model-01.txt >=20 > Hi, Jean Louis >=20 > Nice to see your question again in mailing list. Please see inline. >=20 >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Zhang Renhai" ; > Sent: Friday, August 05, 2005 6:14 PM > Subject: RE: [Pce] About the presentation=20 > ofdraft-zhang-pce-comm-app-model-01.txt >=20 >=20 > Hi Zhang >=20 > Please see inline=20 >=20 > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org=20 > > [mailto:pce-bounces@lists.ietf.org] De la part de Zhang Renhai > > Envoy=E9 : mercredi 3 ao=FBt 2005 15:28 > > =C0 : pce@ietf.org > > Objet : [Pce] About the presentation=20 > > ofdraft-zhang-pce-comm-app-model-01.txt > >=20 > > Hi, all > > =20 > > Sorry for not all clear about some questions asked to me at=20 > > the meeting. > > I really appreciate that someone can repeat the question and=20 > > we can discuss more here. >=20 > Sure, here it is: >=20 > JL->The problem you raise is valuable, race condition issues=20 > will increase in case of distributed-PCE computation with=20 > external PCEs, as the delay between path computation and path=20 > setup will increase. But I have some scalability concerns=20 > with your proposed solution: Basically one objective of PCE=20 > distribution would be to reduce the number of requests to be=20 > handled by PCEs, as this could be the bottleneck, and here=20 > actually your proposal requires sending requests to all PCEs.=20 > Hence all PCEs will support the whole PCCs' requests load. >=20 > ZRH---->Sending requests to all PCEs is a method to make it=20 > possible that each PCE can know the current resources=20 > application status,=20 Yes I understand this point, but the issue is that the request messages = load is no longer distributed, a PCE will reveive all requests, and IMHO = this may significantly diminish the benefits of PCE distribution. This may be OK in steady state but let's take an emergency condition: = For instance let's take a Link/node failure in the core, which impacts a = large number of TE-LSPs. Many PCCs are going to simultaneously send a = request to all PCEs.=20 This raises a scalability issue regarding the number of messages to be = handled by each PCE and also regarding the size of the request table to = be maintained on each PCE (# failed LSPs). and accordingly > can sort order for the requests which may be computed in=20 > different PCEs, for example, req1 and req2 are send=20 > repectively to PCE1, PCE2, and req1 has > a lower priority than req2, but if PCE1 doesn't know that=20 > there is another req with a higher priority(req2 is sent to=20 > PCE2), it may take the resource that req2 > may also need and only suffice one request.=20 Yes I clearly agree that your proposal would help solving the race = condition issue, but to my mind the complexity introduced significantly = reduces the benefits of this aproach. Then when PCE2 is=20 > computing the path for req2 later, what about the result?=20 > teardown the first path computed=20 > for req1? or reply the failure of the computation for req2? > So if both the PCE1 and PCE2 know the all the current=20 > requests, based on some policies configured by operator, PCE1=20 > can delay the computation for req1, > to get the computation orderly and make sure the resources=20 > distributed reasonably. >=20 >=20 > JL->IMHO this may significantly disminish the benefits of PCE=20 > distribution. >=20 > ZRH--->Each PCE knowing all the requests doesn't means to add=20 > the load of computation to each PCE, it's just give each PCE=20 > enough information to make the PCEs working cooperatively.=20 The issue is that the bootleneck does not only rely on the load of = computation, but also, and above all, on the load of messages to be = handled and on the amount of information to be maintained... > See the example again, PCE1 knows there are being two=20 > requests but only computes req1, PCE2 knows there are being two but=20 > only computes req2. Yes I clearly understand that, but it has at least to parse req1 message = and store related information. In some emergency conditions this may = lead to a large number of request to be handled and a huge amount of = information to be maintained... Anyway the race condition problem you raised is highly valuable, but = IMHO we need more discussions on the way to address it... Thanks, JL >=20 > Thanks and Regards, > Zhang >=20 >=20 >=20 > JL->Anyway thanks for higlighting this problem, and for=20 > initiating discussion.=20 >=20 > Regards, >=20 > JL >=20 >=20 > >=20 > > Actually, what I proposed surely is just applied to some=20 > > kind of circumstances. For example, if three PCEs are serving=20 > > all requests in a domain, and these PCEs are coupled closely,=20 > > for instance, they may be located in different box but in the=20 > > same tank or room, or located in different place remote to=20 > > each other and connected by a high speed line, so based on my=20 > > proposal, even only one request is sent to one of these PCE,=20 > > and the PCE can forward the request to other two PCEs quickly=20 > > to make the two PCEs maintain the request table,and this=20 > > delation of transmittion may be ignoed by some tradeoff. > > The essential goal of the draft is just to use the table to=20 > > solve some known question. > > I don't know how the communication for the detailed=20 > > discovery will be because the detailed capability is still=20 > > not specified now, how complicated a detailed capability=20 > > could be for a special request? Can a tradeoff be made=20 > > between below two choice for some special application: > > =20 > > -saving the detailed discovery communication,=20 > > correspondingly sending=20 > > the same request to all PCEs(or just one of these PCEs=20 > > like what I mentioned above) > > -performing the detailed discovery communication for each PCC? > >=20 > > Certainly,this proposal is not intent to became part of the=20 > > PCE communication protocol. > >=20 > > Another concern of this draft is to make the requests=20 > > distributed to different PCE more *reasonable*, for example,=20 > > three PCEs in a domain, PCE1, PCE2, PCE3, and now PCE3 is=20 > > congested with too much requests or other reason, for the PCC=20 > > originating the request, which PCE else should it choose?=20 > > PCE1 or PCE2? what information should be used to help to=20 > > select again more reasonable? Based on the Global Computing=20 > > Table, the congesting PCE(PCE3) will know the number of=20 > > requests that other PCE is now dealing with, although PCE1 and > > PCE2 both are not congested now, based on the mentioned=20 > > information, PCE3 can select other PCE with least number of=20 > > requests and appropriate capability to make sure the PCC can=20 > > get the computation result asap, and I think the time from=20 > > sending request to receiving the computing result may be a=20 > > important consideration for some application. > >=20 > > Cheers, > > Zhang > >=20 > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 26 05:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8aef-0003RP-Te; Fri, 26 Aug 2005 05:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8aed-0003QB-HH for pce@megatron.ietf.org; Fri, 26 Aug 2005 05:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07412 for ; Fri, 26 Aug 2005 05:37:41 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8afK-0007Uo-RO for pce@ietf.org; Fri, 26 Aug 2005 05:38:27 -0400 Received: from du-069-0045.access.clara.net ([217.158.132.45] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E8aeb-00088H-D6 for pce@ietf.org; Fri, 26 Aug 2005 10:37:42 +0100 Message-ID: <0b9a01c5aa22$2d272fc0$c5919ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 26 Aug 2005 10:28:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: Applications Area help requested by PCE Working Group 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, A response from the Applications Area to our enquiry about existing protocols that we might use for PCC-PCE communications. Your thoughts and comments please. Thanks, Adrian ----- Original Message ----- From: "Martin Duerst" To: "Adrian Farrel" ; Cc: "'Jean Philippe Vasseur'" Sent: Thursday, August 25, 2005 10:53 AM Subject: Re: Applications Area help requested by PCE Working Group > What about just defining an XML format and send it > over HTTP? From a first look, your stuff looks extremely > request/response-oriented. HTTP comes with a lot of what > you need already built in, such as security,... It's > probably not a perfect fit, but the fact that it's > already very widely implemented will help a lot. > If you are concerned about sending everything over > port 80 (or are concerned that the IESG may be concerned), > then using another port would solve that problem. > > If you have looked at HTTP and don't think it works, > then telling us where you see problems will help us > maybe come up with a better idea. > > Regards, Martin. > > At 02:44 05/08/24, Adrian Farrel wrote: > >Hi, > > > >Scott helpfully forwarded my mail > >http://www1.ietf.org/mail-archive/web/discuss/current/msg00263.html on 8th > >August. > > > >We've had no responses. > > > >We believe that we need to go ahead and invent our own protocol for this > >work, but we want to be sure that you folk don't think there is something > >that does what we want that we should we re-use or modify slightly. Hence > >this mail. > > > >Giving it until the end of the month before we go our own way. > > > >Cheers, > >Adrian and JP (PCE WG chairs) > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 26 06:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8b51-0003jT-3k; Fri, 26 Aug 2005 06:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8b4z-0003jO-K7 for pce@megatron.ietf.org; Fri, 26 Aug 2005 06:04:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08635 for ; Fri, 26 Aug 2005 06:04:55 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8b5g-0008Ol-PR for pce@ietf.org; Fri, 26 Aug 2005 06:05:41 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 12:04:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63 Date: Fri, 26 Aug 2005 12:05:07 +0200 Message-ID: Thread-Topic: [Pce] Draft PCE WG Minutes - IETF-63 Thread-Index: AcWgEowZnPgaaiYlRHKar/P2J7Zi0gKEY8UQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 26 Aug 2005 10:04:48.0271 (UTC) FILETIME=[9787F9F0:01C5AA25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d53b06eede2bb6b618e318c7466f38f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, all A few minor edits in the minutes > JL: I have a major concern on scalability with the draft's=20 > approach, one major bottleneck is on the PCE-PCE signaling, on the PCC-PCE signaling =20 > we should minimize the signaling, the objective is to have=20 > distribution to reduce this, whereas this draft re-introduces=20 > this overhead for synchronization. =20 > You are redefining the concept of cluster. Why not use the PCE=20 >engine? Why not rather use a single PCE and clusterize the PCE engine? > One major bottleneck on the PCE architecture is the pcc-pce=20 > signalling. To ensure path computation, reduce the number of=20 > path computation requirements received by a pce. the number of path computation requests Regards, JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de JP Vasseur > Envoy=E9 : samedi 13 ao=FBt 2005 16:21 > =C0 : pce@ietf.org > Objet : [Pce] Draft PCE WG Minutes - IETF-63 >=20 > (Please comment by August 27th) >=20 > ---------------------------------- > PCE Working Group meeting minutes > ---------------------------------- >=20 > IETF-63 - Paris, France - Tuesday, August 2, 2005. >=20 > (Thanks to Jaudelice and Deborah for having taken the minutes) >=20 > ------------------ > 1. Agenda (Adrian) > ------------------ > 1) Agenda/Admin (10mn) > 2) Progress against milestones (5mn) > 3) Drafts (55mn) > - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) > - draft-ietf-pce-discovery-reqs-01.txt (Le Roux '=C4=EC 10mn) > - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) > - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) > - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) > - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) > 4) Working Group next steps (20mn) >=20 > ----------------------------------- > 2. Progress against Milestones (JP) > ----------------------------------- >=20 > 1. Submit first draft of PCE architecture document: done 2.=20 > Submit first draft of PCE discovery requirements and protocol=20 > extensions documents > (half-done: PCE discovery requirements ID is done) 3.=20 > Submit first draft of the PCE communication protocol requirements > (done) > 4. Definition of the objective metrics (to be done later -=20 > more progress required on other IDs first) 5. PCE=20 > communication protocol specification (decision to be made by=20 > the WG soon) >=20 > ----------------------------------------------------------------- > PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) > ----------------------------------------------------------------- >=20 > Adrian thanked everyone that contributed to help get this=20 > version out Mainly editorial revisions resulting from=20 > Minneapolis meeting have been done (Clarifications, but=20 > nothing major) More a framework, and an architecture overview=20 > and deployment scenarios. > Describes the architectural overview and building blocks Many=20 > mailing list comments and private comments Not any major=20 > substantial changes Plan to add discussion of policy, will=20 > separate exchange of policy info in the PCE communication and=20 > the use of policy within the architecture >=20 > Question (?): present a functional view as well as component view? >=20 > Adrian: currently view point is third dimension >=20 > Arthi: policy - how will it be addressed in the document? >=20 > Adrian: the current doc will only have something high level -=20 > Lou will provide draft text >=20 > Igor: when I issue a path request, can I disallow paths=20 > requiring distributed computation, >=20 > Adrian: that's something for the computation >=20 > Dimitri: is this the only document for policy or we will do=20 > something else ? >=20 > JP: we need requirements and solution detailed in a separate ID. >=20 > Lou: we had discussion, as Adrian said, we will have later a=20 > standalone document with more details after we have more=20 > discussion in the WG >=20 > Dimitri: in other WG, are discussing policy for interdomain,=20 > need that for this group >=20 > Adrian - agree >=20 > Plans: architecture is believed to be stable but needs=20 > discussions resulting from emails on the list. >=20 > -------------------------------------------------------------- > ---------- > ---------- > Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt > (Jean-Louis) > -------------------------------------------------------------- > ---------- > ---------- >=20 > Set of requiretments for automatic pce discovery >=20 > comments and discussions on the list have been addressed in=20 > the new version -01 > * multi-area example > * application scenario > * reorganized PCE info to be disclosed (mandatory versus optional) >=20 > It must be noted that this is optional in the pce discovery=20 > mechanism, not necessarily optional for pce architecture, > * extensibility section > * security requirements > * PCE capabilities definition is out of the scope (should be=20 > in a separate document) >=20 > Open issues: > - two stage discovery ? should limit to basic or include more=20 > detailed - all as part of this document > - security trust model- need to detail requirements > - need feedback on discovery of pce power and congestion=20 > status - should be part of this discovery mechanism or as=20 > part of a more detailed requirements phase? >=20 > Next steps: >=20 > * address open issues >=20 > Discussion >=20 > Dimitri: the question on one or two stage, for me it's the=20 > question how many pces will we have - if only a small group,=20 > then number of sessions, with more detailed information, can=20 > be supported. Tradeoffs if small set, and all receive=20 > information, or if a lot of PCEs, may want only the subset=20 > that needs to know. >=20 > JP: could use a flooding based mechanism >=20 > Dimitri: but what is expected then on the use of this information ? >=20 > Arthi: It is premature to talk about solution. Do we have a=20 > sense of what direction we might be taking? On the section on=20 > scalability: =20 > number of pce pccs are factors but also should consider the=20 > load on a pce. > The details that you have might not be relevant to a PCE. >=20 > Dimitri: should say if the info is of interest to all the pces or not >=20 > Arthi: I'm less concerned with the PCE if the PCE is itself a PCC >=20 > Igor: Flooding is good, but it has problems: scalability and=20 > security. You still want to know the capabilities of pce so=20 > you may need to establish a session. >=20 > JP: we may now be discussing solutions on how to do basic=20 > capabilities and additional capabilities >=20 > Igor: we will need this discussion though >=20 > JP: I don't see this as pce discovery, this is a=20 > capabilities exchange >=20 > JL: Do you have an idea of a communication protocol >=20 > Igor: It should not be flooding. >=20 > JL: For general discovery we should use flooding. >=20 > JL: You must be able to control to which pcc you will be=20 > disclosing the information: all pccs in an area, etc. >=20 > Adrian: the draft though today does include some capabilities >=20 > Dimitri: can you provide requirements on more the dynamics=20 > needed for these capabilities >=20 > JP: A limited number of capabilities such as the congestion=20 > parameter is likely to be dynamic >=20 > Richard: propose discuss possible solutions over email=20 > exchange, even though it's not to be included in the=20 > requirements, the discussion helps to understand >=20 > Arthi: agree should discuss to an extend some of the solutions >=20 > JP: thanks to quickly resolve the set of open issues. The=20 > draft should then be ready for Working Group LC. >=20 > ------------------------------------------------ > PCE Communication Protocol > Generic Requirements > draft-ietf-pce-comm-protocol-gen-reqs-01.txt > (Jerry) > ----------------------------------------------- >=20 > Generic requirements applicable to all PCEs >=20 > application-specific requirements to be addressed in separate=20 > requirements documents >=20 > A table with a summary is included. >=20 > Open Issues >=20 > * requirements for less constrained path requests/response > * requirements for responsiveness & session maintenance > * detailed requirements on throttling messages under overload > * specify 'boundary' numbers on scalability > * clearly state supported policy models & corresponding=20 > requirements/ implications > * avoid feature creep > * need to progress application-specific requirements > * PCE protocol proposal needs to identify how generic &=20 > application- specific requirements are met >=20 > Discussion: >=20 > JP: Detailed scalability issues are related to implementation. >=20 > Adrian: we need a range as don't want protocol to provide the limit >=20 > JP: on the less-constrained path computation topic, we don't=20 > have a consensus yet, we should have a separate document >=20 > Arthi: we had a discussion in the pwe group that there may be=20 > requirements for pce >=20 > Adrian: by us splitting the document between generic and=20 > extended reqs (more application specific) we could handle this better >=20 > Arthi: also though may not be in scope >=20 > Adrian: yes we should say if it's out of scope >=20 > Arthi: Some new requirements may come up for PCE, we need to=20 > have a plan on how to address that. >=20 > Adrian: The document is extensible. >=20 > Arthi: We might see other consumers of PCE >=20 > JP: Sure and the protocol should be designed to handle=20 > extensions so as to meet new requirements but we may need to recharter >=20 > --------------------------------------------- > PCE Communication Protocol Application Model=20 > draft-zhang-pce-comm-app-model-01.txt > (Zhang) > -------------------------------------------- >=20 > * how to avoid contention with TE link fails > * how to load balance among PCEs > * how to update the PCEs about resource allocation >=20 > JP asked who has read the draft: good show of hands >=20 > Adrian: rather than saying this is the way forward, would=20 > prefer emphasis on what are the requirements >=20 > (coauthor of the draft ??): this draft addresses a way to ... >=20 > Adrian: yes, this draft has requirements on an=20 > implementation, would like first to see top level=20 > requirements and architecture >=20 > Igor: one of the requirements for the protocol is getting=20 > updates, etc, >=20 > Adrian: first need requirements >=20 > Igor: my view this is not a signaling protocol, not rsvp, we=20 > shouldn't go thru the process of using a signaling protocol >=20 > JL: I have a major concern on scalability with the draft's=20 > approach, one major bottleneck is on the PCE-PCE signaling,=20 > we should minimize the signaling, the objective is to have=20 > distribution to reduce this, whereas this draft re-introduces=20 > this overhead for synchronization. =20 > You are redefining the concept of cluster. Why not use the PCE engine? > One major bottleneck on the PCE architecture is the pcc-pce=20 > signalling. To ensure path computation, reduce the number of=20 > path computation requirements received by a pce. >=20 > Author: it does not consume much bandwidth. >=20 > JL: It is not a problem of bandwidth but communication overhead. >=20 > JP: I have similar concerns. Have you tried to evaluate what=20 > would be the overhead in term of extra signaling due to this=20 > mechanism? One way to roughly evaluate would be by using simulations. >=20 > Adrian: best for us to discuss over email to provide adequate=20 > time for the discussion. >=20 > ------------------------------------------------------------- > Path Computation Element (PCE) communication Protocol (PCEP) >=20 > draft-vasseur-pce-pcep-01.txt > (JP) > -------------------------------------------------------------- >=20 > PCC-PCE and between PCEs communication >=20 > There were two proposals in the past which were discontinued=20 > and a completely new protocol has been designed (PCEP) highly=20 > driven by the PCE WG requirement document. Chief objective=20 > was to make it extensible to cope with future requirements. >=20 > Major changes from 00 to 01: > * rewritten for clarity > * few sections removed > * new section on protocol model > * added security consideration > * very rough manageability consideration section added (to be fleshed > out) > * two new objects defined >=20 > Unique communication protocol for PCC-PCE and PCE-PCE. >=20 > Summary - pcep meets most of the requirements. >=20 > Open issues (need inputs from the working group) >=20 > * Objective functions needs to be defined (next revision) > * Protocol recovery: requires more detailed requirements > * Policy: requires more discussion >=20 > Discussion >=20 > Bijan Jabbari: What was the reason for TCP? >=20 > JP: reliability and flow control. TCP was a very good=20 > candidate for that. >=20 > Bijan: Question of scalability of TCP. >=20 > JP (vendor hat): We do not see any scalability issue with TCP. =20 > Current TCP implementations can support a very high number of=20 > TCP sessions. >=20 > Question (?). You are creating a new protocol. Did you do an=20 > analisys on existing protocols and reaons for not using them? >=20 > Adrian: yes we did , but here formal requirement for the WG=20 > to take reqs to other groups to ask if have anything, so this=20 > draft progressing depends on answer. >=20 > Lou: Many protocols have been worked on. Instead of=20 > reinventing the weel, why not use one already existing. What=20 > we are doing here in path computation is a new application,=20 > but session application (keep alive, discovery) have been=20 > resolved before and it would be great to concentrate on what=20 > is related to pce. >=20 > Adrian: great if we can learn lessons >=20 > Lou: and reuse >=20 > Adrian: agree >=20 > Dimitri: agree as Lou said >=20 > Lou: session management, keep alives, etc have been done already >=20 > JP: the question is, is there anything specifics to PCE that=20 > we need a new protocol >=20 > Dimitri: With a new solution we will have to pass all the=20 > stages the others have passed to achieve a robust solution. >=20 > JP: That's why we have the question here. >=20 > Adrian: yes, this protocol in this draft has not been selected >=20 > Bijan: If this is IP only, was DNS discussed? >=20 > Adrian: this is IP only >=20 > Bijan: have we looked at DNS ? >=20 > Adrian: bring it to the list to suggest >=20 > Lou: Comment on need to go back and use an existing mechanism=20 > whenever you can. >=20 > JP: yes, whenever you can. >=20 > Loa: if we have TCP, then we have a basis, to do more, we=20 > need justification, > JP: agree >=20 > Jerry: can you include what is met and not met on=20 > requirements into the draft ? >=20 > JP: ok, will do. >=20 > Jerry: if we do not have a list of requirements, how can we proceed? >=20 > Yakov: Comment on the need for protocol specific keep-alive:=20 > we need a PCE specific keep-alive protocol since TCP will not=20 > take care of it. >=20 > JP: fully agree. >=20 > Lou: You need keep-alive (TCP-based solutions already have=20 > keep- alives). Find out what's the requirement, then lift the=20 > existing solution. >=20 > Lou: my comment is to look at experience - e.g. if need=20 > keepalives, it's a mistake to look at this again without=20 > considering previous work, and do all the requirements all=20 > over again, should look at existing protocols, transaction semantics >=20 > Adrian: yes, persistency should be addressed in the requirements >=20 > Sue: keepalives in a protocol is needed in addition to tcp,=20 > need to pay careful attention to the state machine=20 > interaction between the two - pcc-pce. Need to ensure handle=20 > failure scenarios, noticed missing here some of what protocol=20 > has to solve, should feed back into requirements >=20 > JP: Sometimes you do not want a permanent session, and=20 > sometimes you do. Do we need two modes? >=20 > Adrian: question should be asked to the requirements team. >=20 > JL: we should be more flexible and support both request and=20 > permanent as it will depend on the request, and number of=20 > pces to maintain, may have a full mesh and may not want to=20 > maintain a permanent >=20 > JP: this is what we heard - may only need on request, other=20 > times will need permanent, so may want both modes, and=20 > negotiate upon session establishment. >=20 > Adrian: when doing the solutions and have a question, should=20 > take back to the requirements folks >=20 > JP: Less-constrained path computation aspects will be removed=20 > from this draft and be worked out in a separate ID. >=20 > ------------------------------------------------ > Path Computation Element Metric Protocol (PCEMP) >=20 > draft-choi-pce-metric-protocol-02.txt > (Dipnarayan Guha) > ------------------------------------------------ >=20 > PCE metric protocol (PCEMP): generic routing and path=20 > computation protocol targeted towards inter-domain pce peers. >=20 > Reviewed slides >=20 > JP: we encourage you to provide simulation results to the=20 > mailing list it will help >=20 > No discussion >=20 > ------------------------------ > working group next steps (JP) > ------------------------------ >=20 > - new revision of the PCE architecture ID to be published=20 > soon (WG last call soon after this ietf) > - new revision of the generic pce communication requirement=20 > ID (WG last call soon after this ietf) > - submit a new ID for pce discovery protocol extensions=20 > (minor protocol work only) >=20 > Start application-specific requirements IDs for PCE based computation >=20 > *Inter-area: Jean-Louis > *Inter-As: Raymond, Nabil >=20 > JP: note that such ID must be PCE-specific (take into account=20 > RFC4105 and inter-as requirements ID produced by the TE WG). >=20 > Adrian: WG to decide on which pce communication protocol=20 > solution to pursue > - two proposals presented > - selection of one solution as a basis now does not imply=20 > rejecting good points of other solution nor accepting bad=20 > points of selected solutions. > If pick one, that does not prevent us from taking the best of=20 > other one also, and also other ietf protocols. email will be=20 > sent to the application ADs to ask their input. >=20 > - New ID on the less contrained path problem comprising the=20 > requirement + solution >=20 > - Need to verify the solution model for inter-domain pce with=20 > CCAMP, MPLS working groups >=20 > Adrian - other application specific requirements IDs (interlayer, > p2mp) should continue their work, just realize other work=20 > needs to be done first: > inter-layer: Eiji, Kenji > P2MP: Seisho (currently out of scope of PCE WG charter) >=20 > Thanks. >=20 > JP. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Aug 26 08:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dnu-0006rr-9x; Fri, 26 Aug 2005 08:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dnr-0006px-7v for pce@megatron.ietf.org; Fri, 26 Aug 2005 08:59:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17476 for ; Fri, 26 Aug 2005 08:59:25 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8doZ-0005ZP-3E for pce@ietf.org; Fri, 26 Aug 2005 09:00:12 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 14:59:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Date: Fri, 26 Aug 2005 14:59:33 +0200 Message-ID: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWMWE9wD7yTCTGzRvqSs+ZPDOTcQAWH+59gAfC25JA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 26 Aug 2005 12:59:15.0428 (UTC) FILETIME=[F6716240:01C5AA3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Eduard Sorry for replying a bit late. Please see inline,=20 > -----Message d'origine----- > De : E.T.Metz@telecom.tno.nl [mailto:E.T.Metz@telecom.tno.nl]=20 > Envoy=E9 : mardi 16 ao=FBt 2005 18:11 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : RE: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-01.txt=20 >=20 > Hi Jean-Louis (and others), >=20 > I have a few questions related to PCE discovery that=20 > hopefully you can clarify. >=20 > - The PCE architecture drafts suggests to reuse existing=20 > protocols for PCE discovery, yet it does not mandate that the=20 > PCE actually participate in these protocols. Does this mean=20 > that automated PCE discovery is limited to specific=20 > scenarios, or should it be applicable to any scenario=20 > (composite node, external node, IGP/BGP participant, or not=20 > ..).=20 PCE discovery is not limited to specific scenarii.=20 It applies to external PCEs, regardless whether they are IGP/BGP = participant or not. However, PCE discovery is of course not required for composite PCEs, as = in this case PCC and PCE are located on the same box... but this is not = precluded, it may be used for internal service discovery within a box! I can imagine it is not useful or feasible to cover=20 > every possible scenario. Which specific scenarii have you in mind? >=20 > - PCE can advertise their capabilities in order for PCC to=20 > select the appropriate PCE for their path computation. Does=20 > this also require or assume that PCCs must understand the=20 > advertised capabilities and make the right choice? > For=20 > example, a PCE may have limited scope, yet a PCC may not=20 > understand the scope of its path computation request and=20 > direct it to the 'wrong' PCE.=20 Yes, a PCC should understand PCE information disclosed,=20 this is required for accurate PCE selection... (follow-up actions could e.g.=20 > be re-direct or forward, which is probably beyond the scope=20 > of PCE discovery) Yes in case of wrong selection, there could be various options: -simply reject the request, indicating the reasons for the rejection -reject the request an indicate a relevant PCE -forward the request to a relevant PCE -... But as you mention this is beyond the scope of PCE discovery. Thanks for these comments, Regards JL >=20 > cheers, > Eduard >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Aug 28 11:05:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9OjJ-0004BM-A4; Sun, 28 Aug 2005 11:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9OjH-0004BH-UK for pce@megatron.ietf.org; Sun, 28 Aug 2005 11:05:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24747 for ; Sun, 28 Aug 2005 11:05:49 -0400 (EDT) Received: from web30503.mail.mud.yahoo.com ([68.142.200.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9OkM-0006H9-L4 for pce@ietf.org; Sun, 28 Aug 2005 11:07:04 -0400 Received: (qmail 91928 invoked by uid 60001); 28 Aug 2005 15:05:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VyhKbWdK+zvkBCg7C2wFR5bZzWtLjNlk6dBh/Yyv87xx0BhxMtM6b3HCSi2UdRHnQlDWlvJ5Se6BIF4SdjpLqhYo5PhugNh1KpRp4WzTSJ0LwBJsqZ8Rp67S0TA+NiumcXLYAV5ReZqQRnS2olJlsgHVdRkgziRGd5iseL21dAM= ; Message-ID: <20050828150535.91926.qmail@web30503.mail.mud.yahoo.com> Received: from [213.94.133.138] by web30503.mail.mud.yahoo.com via HTTP; Sun, 28 Aug 2005 16:05:35 BST Date: Sun, 28 Aug 2005 16:05:35 +0100 (BST) From: Stephen Morris Subject: Re: [Pce] Fw: Applications Area help requested by PCE Working Group To: Adrian Farrel , pce@ietf.org In-Reply-To: <0b9a01c5aa22$2d272fc0$c5919ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 8bit Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Adrian There is also an option for employing a web services approach. In this, the PCE would implement a web service. This is also very much the direction software is taking generally (service oriented architecture, J2EE, etc.). Best wishes Stephen --- Adrian Farrel wrote: > Hi, > > A response from the Applications Area to our enquiry > about existing > protocols that we might use for PCC-PCE > communications. > > Your thoughts and comments please. > > Thanks, > Adrian > > ----- Original Message ----- > From: "Martin Duerst" > To: "Adrian Farrel" ; > > Cc: "'Jean Philippe Vasseur'" > Sent: Thursday, August 25, 2005 10:53 AM > Subject: Re: Applications Area help requested by PCE > Working Group > > > > What about just defining an XML format and send it > > over HTTP? From a first look, your stuff looks > extremely > > request/response-oriented. HTTP comes with a lot > of what > > you need already built in, such as security,... > It's > > probably not a perfect fit, but the fact that it's > > already very widely implemented will help a lot. > > If you are concerned about sending everything over > > port 80 (or are concerned that the IESG may be > concerned), > > then using another port would solve that problem. > > > > If you have looked at HTTP and don't think it > works, > > then telling us where you see problems will help > us > > maybe come up with a better idea. > > > > Regards, Martin. > > > > At 02:44 05/08/24, Adrian Farrel wrote: > > >Hi, > > > > > >Scott helpfully forwarded my mail > > > >http://www1.ietf.org/mail-archive/web/discuss/current/msg00263.html > on > 8th > > >August. > > > > > >We've had no responses. > > > > > >We believe that we need to go ahead and invent > our own protocol for > this > > >work, but we want to be sure that you folk don't > think there is > something > > >that does what we want that we should we re-use > or modify slightly. > Hence > > >this mail. > > > > > >Giving it until the end of the month before we > go our own way. > > > > > >Cheers, > > >Adrian and JP (PCE WG chairs) > > > > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Aug 29 00:03:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9aro-0003cF-Tv; Mon, 29 Aug 2005 00:03:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9arm-0003bp-Rg for pce@megatron.ietf.org; Mon, 29 Aug 2005 00:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29660 for ; Mon, 29 Aug 2005 00:03:24 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9at2-0000RU-DB for pce@ietf.org; Mon, 29 Aug 2005 00:04:45 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILY0026VU76Y4@szxga01-in.huawei.com> for pce@ietf.org; Mon, 29 Aug 2005 12:09:06 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILY00KV1U75RQ@szxga01-in.huawei.com> for pce@ietf.org; Mon, 29 Aug 2005 12:09:06 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILY00IK5U9J5Y@szxml02-in.huawei.com>; Mon, 29 Aug 2005 12:10:31 +0800 (CST) Date: Mon, 29 Aug 2005 11:38:47 +0800 From: Zhang Renhai Subject: Re: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <001101c5ac4b$2aae0720$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 2.2 (++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053465496==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1053465496== Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 SGksIEplYW4gTG91aXMNCg0KIEZyb20gd2hhdCB5b3Ugc2FpZCBiZWxvdywgY291bGQgSSBjb25j bHVkZSB0aGF0IHRoZXJlIGlzIGEgdHJhZGVvZmYgb24gd2hhdCB3ZSBkaXNjdXNzZWQ6DQpUaGUg dHdvIHNpZGVzIG9mIHRoZSB0cmFkZW9mZiBhcmUgcmVzb3VyY2UgY29udGVudGlvbnMgYW5kIHJl Y2VpdmluZyBhbGwgcmVxdWVzdHMgZm9yIGEgUENFLg0KQW5kIGluIG15IG9waW5pb24sIHJlY2Vp dmluZyBhbmQgcGFyc2luZyBwYWNrZXRzIGNvbnN1bWUgbXVjaCBsZXNzIENQVSBjYXBhYmlsaXR5 IHRoYW4gDQpwYXRoIGNvbXB1dGF0aW9uIHdoaWNoIGFyZSBiZWNvbWluZyBtb3JlIGFuZCBtb3Jl IGNvbXBsZXgsIFNvIEkgdGhpbmsgdGhlIHBhdGggY29tcHV0YXRpb24NCndpbGwgYmUgdGhlIHJl YWwgYm90dGxlbmVjay5UbyBtYWtlIG1haW50YWluaW5nIG9mIGFsbCByZXF1ZXN0cyBmb3IgYSBQ Q0UgZWFzaWVyLCBhIHByaW9yaXR5IA0KZm9yIGFwcGx5aW5nIHJlc291cmNlcyBpbiB0aGUgcmVx dWVzdCBtZXNzYWdlIG1heSBiZSBlbm91Z2guDQoNCiBBbm90aGVyIHB1cnBvc2Ugb2YgdGhlIHBy b3Bvc2FsIGlzIHRvIGRlY3JlYXNlIHRoZSBQQ0UgZGlzY292ZXJ5J3MgY29tcGxleGl0eS4gQmVm b3JlIGEgDQpQQ0MgZGVjaWRlcyB0byBzZW5kIGEgcmVxdWVzdCB0byBhIHByb3BlciBQQ0UsIGl0 IG11c3QgbGVhcm4gYSBsb3Qgb2YgbWVzc2FnZXMgZnJvbSB0aGUgDQpkaWZmZXJlbnQgUENFcyB0 aHJvdWdoIFBDRSBkaXNjb3ZlcnkgcHJvdG9jb2wsIGFuYWx5c2UgYWxsIGtpbmtzIG9mIGNhcGFi aWxpdGllcy9wb2xpY2llcw0KY29udGFpbmVkIGluIHRoZSBtZXNzYWdlcywgZG8gc29tZSBtYWlu dGFpbmluZyB3b3JrLCB0aGVzZSBwZXJoYXBzIHdpbGwgbWFrZSB0aGUgUENDIA0KZmFsbCBpbnRv IGEgcGFpbmZ1bCBzaXR1YXRpb24gd2hpY2ggZ29lcyBiYWNrIG9uIHRoZSBpbnRlbnRpb24gb2Yg UENFIGFyY2guIFRvIHJlbGF4IHRoZSBQQ0Mncw0Kd29yaywgd2l0aCB0aGlzIHByb3Bvc2FsLCBq dXN0IGdldCB0aGUgZGljaXNpb24gb2YgdGhlIGV4YWN0IFBDRSBmb3IgYSByZXF1ZXN0IGRvbmUg aW4gUENFLg0KZm9yIHRoZSBQQ0MsIG9ubHkgZ2VuZXJpYyBjYXBhYmlsaXRpZXMgb2YgUENFcyBh cmUgbGVhcm5lZCwgYmFzZWQgb24gd2hpY2ggUENDcyB3aWxsDQpob3BmdWxseSBjaG9vc2UgdGhl IHJpZ2h0IFBDRSwgaW4gY2FzZSBvZiBmYWlsdXJlIG9mIHRoZSBjaG9pY2UsIFBDRSBjYW4gZ2V0 IGl0IGRvbmUuIA0KSSBhbHNvIGhvcGUgdG8gaGVhciB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhv dWdodC4NCg0KQ2hlZXJzLA0KWmhhbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iIDxqZWFubG91aXMubGVyb3V4 QGZyYW5jZXRlbGVjb20uY29tPg0KVG86ICJaaGFuZyBSZW5oYWkiIDx6aGFuZ3JlbmhhaUBodWF3 ZWkuY29tPjsgPHBjZUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDI2LCAyMDA1IDU6 MTYgUE0NClN1YmplY3Q6IFJFOiBbUGNlXSBBYm91dCB0aGUgcHJlc2VudGF0aW9ub2ZkcmFmdC16 aGFuZy1wY2UtY29tbS1hcHAtbW9kZWwtMDEudHh0DQoNCg0KSGkgWmhhbmcNCg0KU29ycnkgZm9y IHJlcGx5aW5nIHNvIGxhdGUuLi4NCg0KUGxlYXNlIHNlZSBpbmxpbmUsIA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IFpoYW5nIFJlbmhhaSBbbWFpbHRvOnpoYW5ncmVu aGFpQGh1YXdlaS5jb21dIA0KPiBFbnZveekgOiBsdW5kaSA4IGFv+3QgMjAwNSAxMDoxMA0KPiDA IDogTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOOyBwY2VAaWV0Zi5vcmcNCj4gT2JqZXQg OiBSZTogW1BjZV0gQWJvdXQgdGhlIA0KPiBwcmVzZW50YXRpb25vZmRyYWZ0LXpoYW5nLXBjZS1j b21tLWFwcC1tb2RlbC0wMS50eHQNCj4gDQo+IEhpLCBKZWFuIExvdWlzDQo+IA0KPiAgIE5pY2Ug dG8gc2VlIHlvdXIgcXVlc3Rpb24gYWdhaW4gaW4gbWFpbGluZyBsaXN0LiBQbGVhc2Ugc2VlIGlu bGluZS4NCj4gDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJM RSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iIA0KPiA8amVhbmxvdWlzLmxlcm91eEBmcmFu Y2V0ZWxlY29tLmNvbT4NCj4gVG86ICJaaGFuZyBSZW5oYWkiIDx6aGFuZ3JlbmhhaUBodWF3ZWku Y29tPjsgPHBjZUBpZXRmLm9yZz4NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMDUsIDIwMDUgNjox NCBQTQ0KPiBTdWJqZWN0OiBSRTogW1BjZV0gQWJvdXQgdGhlIHByZXNlbnRhdGlvbiANCj4gb2Zk cmFmdC16aGFuZy1wY2UtY29tbS1hcHAtbW9kZWwtMDEudHh0DQo+IA0KPiANCj4gSGkgWmhhbmcN Cj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lIA0KPiANCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gPiBEZSA6IHBjZS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIA0KPiA+IFttYWlsdG86 cGNlLWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgWmhhbmcgUmVuaGFpDQo+ ID4gRW52b3npIDogbWVyY3JlZGkgMyBhb/t0IDIwMDUgMTU6MjgNCj4gPiDAIDogcGNlQGlldGYu b3JnDQo+ID4gT2JqZXQgOiBbUGNlXSBBYm91dCB0aGUgcHJlc2VudGF0aW9uIA0KPiA+IG9mZHJh ZnQtemhhbmctcGNlLWNvbW0tYXBwLW1vZGVsLTAxLnR4dA0KPiA+IA0KPiA+IEhpLCBhbGwNCj4g PiAgDQo+ID4gIFNvcnJ5IGZvciBub3QgYWxsIGNsZWFyIGFib3V0IHNvbWUgcXVlc3Rpb25zIGFz a2VkIHRvIG1lIGF0IA0KPiA+IHRoZSBtZWV0aW5nLg0KPiA+IEkgcmVhbGx5IGFwcHJlY2lhdGUg dGhhdCBzb21lb25lIGNhbiByZXBlYXQgdGhlIHF1ZXN0aW9uIGFuZCANCj4gPiB3ZSBjYW4gZGlz Y3VzcyBtb3JlIGhlcmUuDQo+IA0KPiBTdXJlLCBoZXJlIGl0IGlzOg0KPiANCj4gSkwtPlRoZSBw cm9ibGVtIHlvdSByYWlzZSBpcyB2YWx1YWJsZSwgcmFjZSBjb25kaXRpb24gaXNzdWVzIA0KPiB3 aWxsIGluY3JlYXNlIGluIGNhc2Ugb2YgZGlzdHJpYnV0ZWQtUENFIGNvbXB1dGF0aW9uIHdpdGgg DQo+IGV4dGVybmFsIFBDRXMsIGFzIHRoZSBkZWxheSBiZXR3ZWVuIHBhdGggY29tcHV0YXRpb24g YW5kIHBhdGggDQo+IHNldHVwIHdpbGwgaW5jcmVhc2UuIEJ1dCBJIGhhdmUgc29tZSBzY2FsYWJp bGl0eSBjb25jZXJucyANCj4gd2l0aCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uOiBCYXNpY2FsbHkg b25lIG9iamVjdGl2ZSBvZiBQQ0UgDQo+IGRpc3RyaWJ1dGlvbiB3b3VsZCBiZSB0byByZWR1Y2Ug dGhlIG51bWJlciBvZiByZXF1ZXN0cyB0byBiZSANCj4gaGFuZGxlZCBieSBQQ0VzLCBhcyB0aGlz IGNvdWxkIGJlIHRoZSBib3R0bGVuZWNrLCBhbmQgaGVyZSANCj4gYWN0dWFsbHkgeW91ciBwcm9w b3NhbCByZXF1aXJlcyBzZW5kaW5nIHJlcXVlc3RzIHRvIGFsbCBQQ0VzLiANCj4gSGVuY2UgYWxs IFBDRXMgd2lsbCBzdXBwb3J0IHRoZSB3aG9sZSBQQ0NzJyByZXF1ZXN0cyBsb2FkLg0KPiANCj4g WlJILS0tLT5TZW5kaW5nIHJlcXVlc3RzIHRvIGFsbCBQQ0VzIGlzIGEgbWV0aG9kIHRvIG1ha2Ug aXQgDQo+IHBvc3NpYmxlIHRoYXQgZWFjaCBQQ0UgY2FuIGtub3cgdGhlIGN1cnJlbnQgcmVzb3Vy Y2VzIA0KPiBhcHBsaWNhdGlvbiBzdGF0dXMsIA0KDQpZZXMgSSB1bmRlcnN0YW5kIHRoaXMgcG9p bnQsIGJ1dCB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgcmVxdWVzdCBtZXNzYWdlcyBsb2FkIGlzIG5v IGxvbmdlciBkaXN0cmlidXRlZCwgYSBQQ0Ugd2lsbCByZXZlaXZlIGFsbCByZXF1ZXN0cywgYW5k IElNSE8gdGhpcyBtYXkgc2lnbmlmaWNhbnRseSBkaW1pbmlzaCB0aGUgYmVuZWZpdHMgb2YgUENF IGRpc3RyaWJ1dGlvbi4NClRoaXMgbWF5IGJlIE9LIGluIHN0ZWFkeSBzdGF0ZSBidXQgbGV0J3Mg dGFrZSBhbiBlbWVyZ2VuY3kgY29uZGl0aW9uOiBGb3IgaW5zdGFuY2UgbGV0J3MgdGFrZSBhIExp bmsvbm9kZSBmYWlsdXJlIGluIHRoZSBjb3JlLCB3aGljaCBpbXBhY3RzIGEgbGFyZ2UgbnVtYmVy IG9mIFRFLUxTUHMuIE1hbnkgUENDcyBhcmUgZ29pbmcgdG8gc2ltdWx0YW5lb3VzbHkgc2VuZCBh IHJlcXVlc3QgdG8gYWxsIFBDRXMuIA0KVGhpcyByYWlzZXMgYSBzY2FsYWJpbGl0eSBpc3N1ZSBy ZWdhcmRpbmcgdGhlIG51bWJlciBvZiBtZXNzYWdlcyB0byBiZSBoYW5kbGVkIGJ5IGVhY2ggUENF IGFuZCBhbHNvIHJlZ2FyZGluZyB0aGUgc2l6ZSBvZiB0aGUgcmVxdWVzdCB0YWJsZSB0byBiZSBt YWludGFpbmVkIG9uIGVhY2ggUENFICgjIGZhaWxlZCBMU1BzKS4NCg0KDQphbmQgYWNjb3JkaW5n bHkNCj4gY2FuIHNvcnQgb3JkZXIgZm9yIHRoZSByZXF1ZXN0cyB3aGljaCBtYXkgYmUgY29tcHV0 ZWQgaW4gDQo+IGRpZmZlcmVudCBQQ0VzLCBmb3IgZXhhbXBsZSwgcmVxMSBhbmQgcmVxMiBhcmUg c2VuZCANCj4gcmVwZWN0aXZlbHkgdG8gUENFMSwgUENFMiwgYW5kIHJlcTEgaGFzDQo+IGEgbG93 ZXIgcHJpb3JpdHkgdGhhbiByZXEyLCBidXQgaWYgUENFMSBkb2Vzbid0IGtub3cgdGhhdCANCj4g dGhlcmUgaXMgYW5vdGhlciByZXEgd2l0aCBhIGhpZ2hlciBwcmlvcml0eShyZXEyIGlzIHNlbnQg dG8gDQo+IFBDRTIpLCAgaXQgbWF5IHRha2UgdGhlIHJlc291cmNlIHRoYXQgcmVxMg0KPiBtYXkg YWxzbyBuZWVkIGFuZCBvbmx5IHN1ZmZpY2Ugb25lIHJlcXVlc3QuIA0KDQpZZXMgSSBjbGVhcmx5 IGFncmVlIHRoYXQgeW91ciBwcm9wb3NhbCB3b3VsZCBoZWxwIHNvbHZpbmcgdGhlIHJhY2UgY29u ZGl0aW9uIGlzc3VlLCBidXQgdG8gbXkgbWluZCB0aGUgY29tcGxleGl0eSBpbnRyb2R1Y2VkIHNp Z25pZmljYW50bHkgIHJlZHVjZXMgdGhlIGJlbmVmaXRzIG9mIHRoaXMgYXByb2FjaC4NCg0KDQpU aGVuIHdoZW4gUENFMiBpcyANCj4gY29tcHV0aW5nIHRoZSBwYXRoIGZvciByZXEyIGxhdGVyLCB3 aGF0IGFib3V0IHRoZSByZXN1bHQ/IA0KPiB0ZWFyZG93biB0aGUgZmlyc3QgcGF0aCBjb21wdXRl ZCANCj4gZm9yIHJlcTE/IG9yIHJlcGx5IHRoZSBmYWlsdXJlIG9mIHRoZSBjb21wdXRhdGlvbiBm b3IgcmVxMj8NCj4gU28gaWYgYm90aCB0aGUgUENFMSBhbmQgUENFMiBrbm93IHRoZSBhbGwgdGhl IGN1cnJlbnQgDQo+IHJlcXVlc3RzLCBiYXNlZCBvbiBzb21lIHBvbGljaWVzIGNvbmZpZ3VyZWQg Ynkgb3BlcmF0b3IsIFBDRTEgDQo+IGNhbiBkZWxheSB0aGUgY29tcHV0YXRpb24gZm9yIHJlcTEs DQoNCj4gdG8gZ2V0IHRoZSBjb21wdXRhdGlvbiBvcmRlcmx5IGFuZCBtYWtlIHN1cmUgdGhlIHJl c291cmNlcyANCj4gZGlzdHJpYnV0ZWQgcmVhc29uYWJseS4NCj4gDQo+IA0KPiBKTC0+SU1ITyB0 aGlzIG1heSBzaWduaWZpY2FudGx5IGRpc21pbmlzaCB0aGUgYmVuZWZpdHMgb2YgUENFIA0KPiBk aXN0cmlidXRpb24uDQo+IA0KPiBaUkgtLS0+RWFjaCBQQ0Uga25vd2luZyBhbGwgdGhlIHJlcXVl c3RzIGRvZXNuJ3QgbWVhbnMgdG8gYWRkIA0KPiB0aGUgbG9hZCBvZiBjb21wdXRhdGlvbiB0byBl YWNoIFBDRSwgaXQncyBqdXN0IGdpdmUgZWFjaCBQQ0UgDQo+IGVub3VnaCBpbmZvcm1hdGlvbiB0 byBtYWtlIHRoZSBQQ0VzIHdvcmtpbmcgY29vcGVyYXRpdmVseS4gDQoNClRoZSBpc3N1ZSBpcyB0 aGF0IHRoZSBib290bGVuZWNrIGRvZXMgbm90IG9ubHkgcmVseSBvbiB0aGUgbG9hZCBvZiBjb21w dXRhdGlvbiwgYnV0IGFsc28sIGFuZCBhYm92ZSBhbGwsIG9uIHRoZSBsb2FkIG9mIG1lc3NhZ2Vz IHRvIGJlIGhhbmRsZWQgYW5kIG9uIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gYmUgbWFp bnRhaW5lZC4uLg0KDQo+IFNlZSB0aGUgZXhhbXBsZSBhZ2FpbiwgUENFMSBrbm93cyB0aGVyZSBh cmUgYmVpbmcgdHdvIA0KPiByZXF1ZXN0cyBidXQgb25seSBjb21wdXRlcyByZXExLCBQQ0UyIGtu b3dzIHRoZXJlIGFyZSBiZWluZyB0d28gYnV0IA0KPiBvbmx5IGNvbXB1dGVzIHJlcTIuDQoNClll cyBJIGNsZWFybHkgdW5kZXJzdGFuZCB0aGF0LCBidXQgaXQgaGFzIGF0IGxlYXN0IHRvIHBhcnNl IHJlcTEgbWVzc2FnZSBhbmQgc3RvcmUgcmVsYXRlZCBpbmZvcm1hdGlvbi4gSW4gc29tZSBlbWVy Z2VuY3kgY29uZGl0aW9ucyB0aGlzIG1heSBsZWFkIHRvIGEgbGFyZ2UgbnVtYmVyIG9mIHJlcXVl c3QgdG8gYmUgaGFuZGxlZCBhbmQgYSBodWdlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0byBiZSBt YWludGFpbmVkLi4uDQoNCkFueXdheSB0aGUgcmFjZSBjb25kaXRpb24gcHJvYmxlbSB5b3UgcmFp c2VkIGlzIGhpZ2hseSB2YWx1YWJsZSwgYnV0IElNSE8gd2UgbmVlZCBtb3JlIGRpc2N1c3Npb25z IG9uIHRoZSB3YXkgdG8gYWRkcmVzcyBpdC4uLg0KDQpUaGFua3MsDQoNCkpMDQoNCj4gDQo+IFRo YW5rcyBhbmQgUmVnYXJkcywNCj4gWmhhbmcNCj4gDQo+IA0KPiANCj4gSkwtPkFueXdheSB0aGFu a3MgZm9yIGhpZ2xpZ2h0aW5nIHRoaXMgcHJvYmxlbSwgYW5kIGZvciANCj4gaW5pdGlhdGluZyBk aXNjdXNzaW9uLiANCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBKTA0KPiANCj4gDQo+ID4gDQo+ID4g IEFjdHVhbGx5LCB3aGF0IEkgcHJvcG9zZWQgc3VyZWx5IGlzIGp1c3QgYXBwbGllZCB0byBzb21l IA0KPiA+IGtpbmQgb2YgY2lyY3Vtc3RhbmNlcy4gRm9yIGV4YW1wbGUsIGlmIHRocmVlIFBDRXMg YXJlIHNlcnZpbmcgDQo+ID4gYWxsIHJlcXVlc3RzIGluIGEgZG9tYWluLCBhbmQgdGhlc2UgUENF cyBhcmUgY291cGxlZCBjbG9zZWx5LCANCj4gPiBmb3IgaW5zdGFuY2UsIHRoZXkgbWF5IGJlIGxv Y2F0ZWQgaW4gZGlmZmVyZW50IGJveCBidXQgaW4gdGhlIA0KPiA+IHNhbWUgdGFuayBvciByb29t LCBvciBsb2NhdGVkIGluIGRpZmZlcmVudCBwbGFjZSByZW1vdGUgdG8gDQo+ID4gZWFjaCBvdGhl ciBhbmQgY29ubmVjdGVkIGJ5IGEgaGlnaCBzcGVlZCBsaW5lLCBzbyBiYXNlZCBvbiBteSANCj4g PiBwcm9wb3NhbCwgZXZlbiBvbmx5IG9uZSByZXF1ZXN0IGlzIHNlbnQgdG8gb25lIG9mIHRoZXNl IFBDRSwgDQo+ID4gYW5kIHRoZSBQQ0UgY2FuIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gb3RoZXIg dHdvIFBDRXMgcXVpY2tseSANCj4gPiB0byBtYWtlIHRoZSB0d28gUENFcyBtYWludGFpbiB0aGUg cmVxdWVzdCB0YWJsZSxhbmQgdGhpcyANCj4gPiBkZWxhdGlvbiBvZiB0cmFuc21pdHRpb24gbWF5 IGJlIGlnbm9lZCAgYnkgc29tZSB0cmFkZW9mZi4NCj4gPiBUaGUgZXNzZW50aWFsIGdvYWwgb2Yg dGhlIGRyYWZ0IGlzIGp1c3QgdG8gdXNlIHRoZSB0YWJsZSB0byANCj4gPiBzb2x2ZSBzb21lIGtu b3duIHF1ZXN0aW9uLg0KPiA+ICBJIGRvbid0IGtub3cgaG93IHRoZSBjb21tdW5pY2F0aW9uIGZv ciB0aGUgZGV0YWlsZWQgDQo+ID4gZGlzY292ZXJ5IHdpbGwgYmUgYmVjYXVzZSB0aGUgZGV0YWls ZWQgY2FwYWJpbGl0eSBpcyBzdGlsbCANCj4gPiBub3Qgc3BlY2lmaWVkIG5vdywgaG93IGNvbXBs aWNhdGVkIGEgZGV0YWlsZWQgY2FwYWJpbGl0eSANCj4gPiBjb3VsZCBiZSBmb3IgYSBzcGVjaWFs IHJlcXVlc3Q/IENhbiBhIHRyYWRlb2ZmIGJlIG1hZGUgDQo+ID4gYmV0d2VlbiBiZWxvdyB0d28g Y2hvaWNlIGZvciBzb21lIHNwZWNpYWwgYXBwbGljYXRpb246DQo+ID4gIA0KPiA+ICAgLXNhdmlu ZyB0aGUgZGV0YWlsZWQgZGlzY292ZXJ5IGNvbW11bmljYXRpb24sIA0KPiA+IGNvcnJlc3BvbmRp bmdseSBzZW5kaW5nIA0KPiA+ICAgIHRoZSBzYW1lIHJlcXVlc3QgdG8gYWxsIFBDRXMob3IganVz dCBvbmUgb2YgdGhlc2UgUENFcyANCj4gPiBsaWtlIHdoYXQgSSBtZW50aW9uZWQgYWJvdmUpDQo+ ID4gICAtcGVyZm9ybWluZyB0aGUgZGV0YWlsZWQgZGlzY292ZXJ5IGNvbW11bmljYXRpb24gZm9y IGVhY2ggUENDPw0KPiA+IA0KPiA+ICAgQ2VydGFpbmx5LHRoaXMgcHJvcG9zYWwgaXMgbm90IGlu dGVudCB0byBiZWNhbWUgcGFydCBvZiB0aGUgDQo+ID4gUENFIGNvbW11bmljYXRpb24gcHJvdG9j b2wuDQo+ID4gDQo+ID4gIEFub3RoZXIgY29uY2VybiBvZiB0aGlzIGRyYWZ0IGlzIHRvIG1ha2Ug dGhlIHJlcXVlc3RzIA0KPiA+IGRpc3RyaWJ1dGVkIHRvIGRpZmZlcmVudCBQQ0UgbW9yZSAqcmVh c29uYWJsZSosIGZvciBleGFtcGxlLCANCj4gPiB0aHJlZSBQQ0VzIGluIGEgZG9tYWluLCBQQ0Ux LCBQQ0UyLCBQQ0UzLCBhbmQgbm93IFBDRTMgaXMgDQo+ID4gY29uZ2VzdGVkIHdpdGggdG9vIG11 Y2ggcmVxdWVzdHMgb3Igb3RoZXIgcmVhc29uLCBmb3IgdGhlIFBDQyANCj4gPiBvcmlnaW5hdGlu ZyB0aGUgcmVxdWVzdCwgd2hpY2ggUENFIGVsc2Ugc2hvdWxkIGl0IGNob29zZT8gDQo+ID4gUENF MSBvciBQQ0UyPyB3aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSB1c2VkIHRvIGhlbHAgdG8gDQo+ ID4gc2VsZWN0IGFnYWluIG1vcmUgcmVhc29uYWJsZT8gQmFzZWQgb24gdGhlIEdsb2JhbCBDb21w dXRpbmcgDQo+ID4gVGFibGUsIHRoZSBjb25nZXN0aW5nIFBDRShQQ0UzKSB3aWxsIGtub3cgdGhl IG51bWJlciBvZiANCj4gPiByZXF1ZXN0cyB0aGF0IG90aGVyIFBDRSBpcyBub3cgZGVhbGluZyB3 aXRoLCBhbHRob3VnaCBQQ0UxIGFuZA0KPiA+IFBDRTIgYm90aCBhcmUgbm90IGNvbmdlc3RlZCBu b3csIGJhc2VkIG9uIHRoZSBtZW50aW9uZWQgDQo+ID4gaW5mb3JtYXRpb24sIFBDRTMgY2FuIHNl bGVjdCBvdGhlciBQQ0Ugd2l0aCBsZWFzdCBudW1iZXIgb2YgDQo+ID4gcmVxdWVzdHMgYW5kIGFw cHJvcHJpYXRlIGNhcGFiaWxpdHkgdG8gbWFrZSBzdXJlIHRoZSBQQ0MgY2FuIA0KPiA+IGdldCB0 aGUgY29tcHV0YXRpb24gcmVzdWx0IGFzYXAsIGFuZCBJIHRoaW5rIHRoZSB0aW1lIGZyb20gDQo+ ID4gc2VuZGluZyByZXF1ZXN0IHRvIHJlY2VpdmluZyB0aGUgY29tcHV0aW5nIHJlc3VsdCBtYXkg YmUgYSANCj4gPiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiBmb3Igc29tZSBhcHBsaWNhdGlvbi4N Cj4gPiANCj4gPiBDaGVlcnMsDQo+ID4gWmhhbmcNCj4gPiANCj4gPiANCj4gPiANCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFBjZSBtYWls aW5nIGxpc3QNCj4gPiBQY2VAbGlzdHMuaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCj4gPg0KPg0K --===============1053465496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1053465496==-- From pce-bounces@lists.ietf.org Tue Aug 30 11:14:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7oK-0007Ey-0q; Tue, 30 Aug 2005 11:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7oI-0007Er-GX for pce@megatron.ietf.org; Tue, 30 Aug 2005 11:14:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18302 for ; Tue, 30 Aug 2005 11:13:59 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA7pq-0003uM-PT for pce@ietf.org; Tue, 30 Aug 2005 11:15:39 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Aug 2005 08:13:51 -0700 X-IronPort-AV: i="3.96,154,1122879600"; d="scan'208"; a="337128533:sNHT1590981120" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7UFDfou022076; Tue, 30 Aug 2005 08:13:49 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 11:13:43 -0400 Received: from [192.168.1.100] ([10.86.242.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 11:13:42 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0C962CEB-5FC1-4BC1-8685-8457EBCA62BE@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63 Date: Tue, 30 Aug 2005 11:14:16 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 30 Aug 2005 15:13:42.0797 (UTC) FILETIME=[689F33D0:01C5AD75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis, Thanks for the modifications, they will be incorporated. JP. On Aug 26, 2005, at 6:05 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi JP, all > > A few minor edits in the minutes > > >> JL: I have a major concern on scalability with the draft's >> approach, one major bottleneck is on the PCE-PCE signaling, >> > > on the PCC-PCE signaling > > >> we should minimize the signaling, the objective is to have >> distribution to reduce this, whereas this draft re-introduces >> this overhead for synchronization. >> > > >> You are redefining the concept of cluster. Why not use the PCE >> engine? >> > > Why not rather use a single PCE and clusterize the PCE engine? > > >> One major bottleneck on the PCE architecture is the pcc-pce >> signalling. To ensure path computation, reduce the number of >> path computation requirements received by a pce. >> > > the number of path computation requests > > Regards, > > JL > > >> -----Message d'origine----- >> De : pce-bounces@lists.ietf.org >> [mailto:pce-bounces@lists.ietf.org] De la part de JP Vasseur >> Envoy=E9 : samedi 13 ao=FBt 2005 16:21 >> =C0 : pce@ietf.org >> Objet : [Pce] Draft PCE WG Minutes - IETF-63 >> >> (Please comment by August 27th) >> >> ---------------------------------- >> PCE Working Group meeting minutes >> ---------------------------------- >> >> IETF-63 - Paris, France - Tuesday, August 2, 2005. >> >> (Thanks to Jaudelice and Deborah for having taken the minutes) >> >> ------------------ >> 1. Agenda (Adrian) >> ------------------ >> 1) Agenda/Admin (10mn) >> 2) Progress against milestones (5mn) >> 3) Drafts (55mn) >> - draft-ietf-pce-architecture-01.txt (Farrel - 10mn) >> - draft-ietf-pce-discovery-reqs-01.txt (Le Roux '=C4=EC 10mn) >> - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn) >> - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn) >> - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn) >> - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn) >> 4) Working Group next steps (20mn) >> >> ----------------------------------- >> 2. Progress against Milestones (JP) >> ----------------------------------- >> >> 1. Submit first draft of PCE architecture document: done 2. >> Submit first draft of PCE discovery requirements and protocol >> extensions documents >> (half-done: PCE discovery requirements ID is done) 3. >> Submit first draft of the PCE communication protocol requirements >> (done) >> 4. Definition of the objective metrics (to be done later - >> more progress required on other IDs first) 5. PCE >> communication protocol specification (decision to be made by >> the WG soon) >> >> ----------------------------------------------------------------- >> PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian) >> ----------------------------------------------------------------- >> >> Adrian thanked everyone that contributed to help get this >> version out Mainly editorial revisions resulting from >> Minneapolis meeting have been done (Clarifications, but >> nothing major) More a framework, and an architecture overview >> and deployment scenarios. >> Describes the architectural overview and building blocks Many >> mailing list comments and private comments Not any major >> substantial changes Plan to add discussion of policy, will >> separate exchange of policy info in the PCE communication and >> the use of policy within the architecture >> >> Question (?): present a functional view as well as component view? >> >> Adrian: currently view point is third dimension >> >> Arthi: policy - how will it be addressed in the document? >> >> Adrian: the current doc will only have something high level - >> Lou will provide draft text >> >> Igor: when I issue a path request, can I disallow paths >> requiring distributed computation, >> >> Adrian: that's something for the computation >> >> Dimitri: is this the only document for policy or we will do >> something else ? >> >> JP: we need requirements and solution detailed in a separate ID. >> >> Lou: we had discussion, as Adrian said, we will have later a >> standalone document with more details after we have more >> discussion in the WG >> >> Dimitri: in other WG, are discussing policy for interdomain, >> need that for this group >> >> Adrian - agree >> >> Plans: architecture is believed to be stable but needs >> discussions resulting from emails on the list. >> >> -------------------------------------------------------------- >> ---------- >> ---------- >> Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt >> (Jean-Louis) >> -------------------------------------------------------------- >> ---------- >> ---------- >> >> Set of requiretments for automatic pce discovery >> >> comments and discussions on the list have been addressed in >> the new version -01 >> * multi-area example >> * application scenario >> * reorganized PCE info to be disclosed (mandatory versus optional) >> >> It must be noted that this is optional in the pce discovery >> mechanism, not necessarily optional for pce architecture, >> * extensibility section >> * security requirements >> * PCE capabilities definition is out of the scope (should be >> in a separate document) >> >> Open issues: >> - two stage discovery ? should limit to basic or include more >> detailed - all as part of this document >> - security trust model- need to detail requirements >> - need feedback on discovery of pce power and congestion >> status - should be part of this discovery mechanism or as >> part of a more detailed requirements phase? >> >> Next steps: >> >> * address open issues >> >> Discussion >> >> Dimitri: the question on one or two stage, for me it's the >> question how many pces will we have - if only a small group, >> then number of sessions, with more detailed information, can >> be supported. Tradeoffs if small set, and all receive >> information, or if a lot of PCEs, may want only the subset >> that needs to know. >> >> JP: could use a flooding based mechanism >> >> Dimitri: but what is expected then on the use of this information ? >> >> Arthi: It is premature to talk about solution. Do we have a >> sense of what direction we might be taking? On the section on >> scalability: >> number of pce pccs are factors but also should consider the >> load on a pce. >> The details that you have might not be relevant to a PCE. >> >> Dimitri: should say if the info is of interest to all the pces or not >> >> Arthi: I'm less concerned with the PCE if the PCE is itself a PCC >> >> Igor: Flooding is good, but it has problems: scalability and >> security. You still want to know the capabilities of pce so >> you may need to establish a session. >> >> JP: we may now be discussing solutions on how to do basic >> capabilities and additional capabilities >> >> Igor: we will need this discussion though >> >> JP: I don't see this as pce discovery, this is a >> capabilities exchange >> >> JL: Do you have an idea of a communication protocol >> >> Igor: It should not be flooding. >> >> JL: For general discovery we should use flooding. >> >> JL: You must be able to control to which pcc you will be >> disclosing the information: all pccs in an area, etc. >> >> Adrian: the draft though today does include some capabilities >> >> Dimitri: can you provide requirements on more the dynamics >> needed for these capabilities >> >> JP: A limited number of capabilities such as the congestion >> parameter is likely to be dynamic >> >> Richard: propose discuss possible solutions over email >> exchange, even though it's not to be included in the >> requirements, the discussion helps to understand >> >> Arthi: agree should discuss to an extend some of the solutions >> >> JP: thanks to quickly resolve the set of open issues. The >> draft should then be ready for Working Group LC. >> >> ------------------------------------------------ >> PCE Communication Protocol >> Generic Requirements >> draft-ietf-pce-comm-protocol-gen-reqs-01.txt >> (Jerry) >> ----------------------------------------------- >> >> Generic requirements applicable to all PCEs >> >> application-specific requirements to be addressed in separate >> requirements documents >> >> A table with a summary is included. >> >> Open Issues >> >> * requirements for less constrained path requests/response >> * requirements for responsiveness & session maintenance >> * detailed requirements on throttling messages under overload >> * specify 'boundary' numbers on scalability >> * clearly state supported policy models & corresponding >> requirements/ implications >> * avoid feature creep >> * need to progress application-specific requirements >> * PCE protocol proposal needs to identify how generic & >> application- specific requirements are met >> >> Discussion: >> >> JP: Detailed scalability issues are related to implementation. >> >> Adrian: we need a range as don't want protocol to provide the limit >> >> JP: on the less-constrained path computation topic, we don't >> have a consensus yet, we should have a separate document >> >> Arthi: we had a discussion in the pwe group that there may be >> requirements for pce >> >> Adrian: by us splitting the document between generic and >> extended reqs (more application specific) we could handle this better >> >> Arthi: also though may not be in scope >> >> Adrian: yes we should say if it's out of scope >> >> Arthi: Some new requirements may come up for PCE, we need to >> have a plan on how to address that. >> >> Adrian: The document is extensible. >> >> Arthi: We might see other consumers of PCE >> >> JP: Sure and the protocol should be designed to handle >> extensions so as to meet new requirements but we may need to =20 >> recharter >> >> --------------------------------------------- >> PCE Communication Protocol Application Model >> draft-zhang-pce-comm-app-model-01.txt >> (Zhang) >> -------------------------------------------- >> >> * how to avoid contention with TE link fails >> * how to load balance among PCEs >> * how to update the PCEs about resource allocation >> >> JP asked who has read the draft: good show of hands >> >> Adrian: rather than saying this is the way forward, would >> prefer emphasis on what are the requirements >> >> (coauthor of the draft ??): this draft addresses a way to ... >> >> Adrian: yes, this draft has requirements on an >> implementation, would like first to see top level >> requirements and architecture >> >> Igor: one of the requirements for the protocol is getting >> updates, etc, >> >> Adrian: first need requirements >> >> Igor: my view this is not a signaling protocol, not rsvp, we >> shouldn't go thru the process of using a signaling protocol >> >> JL: I have a major concern on scalability with the draft's >> approach, one major bottleneck is on the PCE-PCE signaling, >> we should minimize the signaling, the objective is to have >> distribution to reduce this, whereas this draft re-introduces >> this overhead for synchronization. >> You are redefining the concept of cluster. Why not use the PCE =20 >> engine? >> One major bottleneck on the PCE architecture is the pcc-pce >> signalling. To ensure path computation, reduce the number of >> path computation requirements received by a pce. >> >> Author: it does not consume much bandwidth. >> >> JL: It is not a problem of bandwidth but communication overhead. >> >> JP: I have similar concerns. Have you tried to evaluate what >> would be the overhead in term of extra signaling due to this >> mechanism? One way to roughly evaluate would be by using simulations. >> >> Adrian: best for us to discuss over email to provide adequate >> time for the discussion. >> >> ------------------------------------------------------------- >> Path Computation Element (PCE) communication Protocol (PCEP) >> >> draft-vasseur-pce-pcep-01.txt >> (JP) >> -------------------------------------------------------------- >> >> PCC-PCE and between PCEs communication >> >> There were two proposals in the past which were discontinued >> and a completely new protocol has been designed (PCEP) highly >> driven by the PCE WG requirement document. Chief objective >> was to make it extensible to cope with future requirements. >> >> Major changes from 00 to 01: >> * rewritten for clarity >> * few sections removed >> * new section on protocol model >> * added security consideration >> * very rough manageability consideration section added (to be fleshed >> out) >> * two new objects defined >> >> Unique communication protocol for PCC-PCE and PCE-PCE. >> >> Summary - pcep meets most of the requirements. >> >> Open issues (need inputs from the working group) >> >> * Objective functions needs to be defined (next revision) >> * Protocol recovery: requires more detailed requirements >> * Policy: requires more discussion >> >> Discussion >> >> Bijan Jabbari: What was the reason for TCP? >> >> JP: reliability and flow control. TCP was a very good >> candidate for that. >> >> Bijan: Question of scalability of TCP. >> >> JP (vendor hat): We do not see any scalability issue with TCP. >> Current TCP implementations can support a very high number of >> TCP sessions. >> >> Question (?). You are creating a new protocol. Did you do an >> analisys on existing protocols and reaons for not using them? >> >> Adrian: yes we did , but here formal requirement for the WG >> to take reqs to other groups to ask if have anything, so this >> draft progressing depends on answer. >> >> Lou: Many protocols have been worked on. Instead of >> reinventing the weel, why not use one already existing. What >> we are doing here in path computation is a new application, >> but session application (keep alive, discovery) have been >> resolved before and it would be great to concentrate on what >> is related to pce. >> >> Adrian: great if we can learn lessons >> >> Lou: and reuse >> >> Adrian: agree >> >> Dimitri: agree as Lou said >> >> Lou: session management, keep alives, etc have been done already >> >> JP: the question is, is there anything specifics to PCE that >> we need a new protocol >> >> Dimitri: With a new solution we will have to pass all the >> stages the others have passed to achieve a robust solution. >> >> JP: That's why we have the question here. >> >> Adrian: yes, this protocol in this draft has not been selected >> >> Bijan: If this is IP only, was DNS discussed? >> >> Adrian: this is IP only >> >> Bijan: have we looked at DNS ? >> >> Adrian: bring it to the list to suggest >> >> Lou: Comment on need to go back and use an existing mechanism >> whenever you can. >> >> JP: yes, whenever you can. >> >> Loa: if we have TCP, then we have a basis, to do more, we >> need justification, >> JP: agree >> >> Jerry: can you include what is met and not met on >> requirements into the draft ? >> >> JP: ok, will do. >> >> Jerry: if we do not have a list of requirements, how can we proceed? >> >> Yakov: Comment on the need for protocol specific keep-alive: >> we need a PCE specific keep-alive protocol since TCP will not >> take care of it. >> >> JP: fully agree. >> >> Lou: You need keep-alive (TCP-based solutions already have >> keep- alives). Find out what's the requirement, then lift the >> existing solution. >> >> Lou: my comment is to look at experience - e.g. if need >> keepalives, it's a mistake to look at this again without >> considering previous work, and do all the requirements all >> over again, should look at existing protocols, transaction semantics >> >> Adrian: yes, persistency should be addressed in the requirements >> >> Sue: keepalives in a protocol is needed in addition to tcp, >> need to pay careful attention to the state machine >> interaction between the two - pcc-pce. Need to ensure handle >> failure scenarios, noticed missing here some of what protocol >> has to solve, should feed back into requirements >> >> JP: Sometimes you do not want a permanent session, and >> sometimes you do. Do we need two modes? >> >> Adrian: question should be asked to the requirements team. >> >> JL: we should be more flexible and support both request and >> permanent as it will depend on the request, and number of >> pces to maintain, may have a full mesh and may not want to >> maintain a permanent >> >> JP: this is what we heard - may only need on request, other >> times will need permanent, so may want both modes, and >> negotiate upon session establishment. >> >> Adrian: when doing the solutions and have a question, should >> take back to the requirements folks >> >> JP: Less-constrained path computation aspects will be removed >> from this draft and be worked out in a separate ID. >> >> ------------------------------------------------ >> Path Computation Element Metric Protocol (PCEMP) >> >> draft-choi-pce-metric-protocol-02.txt >> (Dipnarayan Guha) >> ------------------------------------------------ >> >> PCE metric protocol (PCEMP): generic routing and path >> computation protocol targeted towards inter-domain pce peers. >> >> Reviewed slides >> >> JP: we encourage you to provide simulation results to the >> mailing list it will help >> >> No discussion >> >> ------------------------------ >> working group next steps (JP) >> ------------------------------ >> >> - new revision of the PCE architecture ID to be published >> soon (WG last call soon after this ietf) >> - new revision of the generic pce communication requirement >> ID (WG last call soon after this ietf) >> - submit a new ID for pce discovery protocol extensions >> (minor protocol work only) >> >> Start application-specific requirements IDs for PCE based computation >> >> *Inter-area: Jean-Louis >> *Inter-As: Raymond, Nabil >> >> JP: note that such ID must be PCE-specific (take into account >> RFC4105 and inter-as requirements ID produced by the TE WG). >> >> Adrian: WG to decide on which pce communication protocol >> solution to pursue >> - two proposals presented >> - selection of one solution as a basis now does not imply >> rejecting good points of other solution nor accepting bad >> points of selected solutions. >> If pick one, that does not prevent us from taking the best of >> other one also, and also other ietf protocols. email will be >> sent to the application ADs to ask their input. >> >> - New ID on the less contrained path problem comprising the >> requirement + solution >> >> - Need to verify the solution model for inter-domain pce with >> CCAMP, MPLS working groups >> >> Adrian - other application specific requirements IDs (interlayer, >> p2mp) should continue their work, just realize other work >> needs to be done first: >> inter-layer: Eiji, Kenji >> P2MP: Seisho (currently out of scope of PCE WG charter) >> >> Thanks. >> >> JP. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Aug 30 11:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Or-00082O-Dv; Tue, 30 Aug 2005 11:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Op-00082G-8k for pce@megatron.ietf.org; Tue, 30 Aug 2005 11:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19959 for ; Tue, 30 Aug 2005 11:51:44 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8QL-0004lN-Qk for pce@ietf.org; Tue, 30 Aug 2005 11:53:25 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2005 08:51:35 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7UFow0j012919; Tue, 30 Aug 2005 08:51:29 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 11:51:26 -0400 Received: from [192.168.1.100] ([10.86.242.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 11:51:26 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 30 Aug 2005 11:52:00 -0400 To: LE ROUX Jean-Louis FTRD/DAC/LAN , Paul Mabey , Eiji Oki , Richard Rabbat , Ting_Wo Chung , "raymond.zhang" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 30 Aug 2005 15:51:26.0594 (UTC) FILETIME=[ADF33620:01C5AD7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: pce@ietf.org Subject: [Pce] Progress on draft-ietf-pce-discovery-reqs-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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, First of all, thanks for the very significant progress which has been made on this ID over the past 6 months. As discussed during the last meeting in Paris, there are still a few issues to be sorted out. Could we try to close on these remaining issues so as to quickly start the protocol work (we're a bit late on this Milestone) ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 31 03:14:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAMng-00073T-AY; Wed, 31 Aug 2005 03:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAMnd-00073O-RD for pce@megatron.ietf.org; Wed, 31 Aug 2005 03:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05087 for ; Wed, 31 Aug 2005 03:14:19 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAMpK-0004Ed-1V for pce@ietf.org; Wed, 31 Aug 2005 03:16:07 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 09:13:51 +0200 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: Wed, 31 Aug 2005 09:13:49 +0200 Message-ID: Thread-Topic: Progress on draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWterPiuFaiE12HTUOLpLsGq9Q7DQAf7nIg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Paul Mabey" , "Eiji Oki" , "Richard Rabbat" , "Ting_Wo Chung" , "raymond.zhang" X-OriginalArrivalTime: 31 Aug 2005 07:13:51.0230 (UTC) FILETIME=[89EC79E0:01C5ADFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org Subject: [Pce] RE: Progress on draft-ietf-pce-discovery-reqs-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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Philippe, =20 we plan to post a new revision by mid-september. Is that OK? Regards, JL =20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; Eiji Oki;=20 > Richard Rabbat; Ting_Wo Chung; raymond.zhang > Cc : pce@ietf.org > Objet : Progress on draft-ietf-pce-discovery-reqs-01.txt=20 >=20 > Hi, >=20 > First of all, thanks for the very significant progress which=20 > has been made on this ID over the past 6 months. As discussed=20 > during the last meeting in Paris, there are still a few=20 > issues to be sorted out. =20 > Could we try to close on these remaining issues so as to=20 > quickly start the protocol work (we're a bit late on this Milestone) ? >=20 > Thanks. >=20 > JP. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 31 06:27:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPoi-000806-Oi; Wed, 31 Aug 2005 06:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPoh-000801-I5 for pce@megatron.ietf.org; Wed, 31 Aug 2005 06:27:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12072 for ; Wed, 31 Aug 2005 06:27:36 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAPqP-0000ux-5e for pce@ietf.org; Wed, 31 Aug 2005 06:29:26 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 12:27:34 +0200 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 Subject: RE: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt Date: Wed, 31 Aug 2005 12:27:33 +0200 Message-ID: Thread-Topic: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt Thread-Index: AcWsTp2UOa/p473ZQ72M3PdJ9gdPpABvcFNw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" X-OriginalArrivalTime: 31 Aug 2005 10:27:34.0261 (UTC) FILETIME=[99CA4250:01C5AE16] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Zhang, Please see inline,=20 > -----Message d'origine----- > De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 > Envoy=E9 : lundi 29 ao=FBt 2005 05:39 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : pce@ietf.org > Objet : Re: [Pce] About the=20 > presentationofdraft-zhang-pce-comm-app-model-01.txt >=20 > Hi, Jean Louis >=20 > From what you said below, could I conclude that there is a=20 > tradeoff on what we discussed: > The two sides of the tradeoff are resource contentions and=20 > receiving all requests for a PCE. > And in my opinion, receiving and parsing packets consume much=20 > less CPU capability than path computation which are becoming=20 > more and more complex, So I think the path computation will=20 > be the real bottleneck.To make maintaining of all requests=20 > for a PCE easier, a priority for applying resources in the=20 > request message may be enough. I think that the number of requests to be handled by a PCE is an important parameter when evaluating the scalability of a PCE = architecture.=20 What worries me in your proposal is that you distribute the computation = load, which is a good point, but in return you introduce significant = complexity on PCEs that will have to maintain a request table and = exchange some significant amount of state (think about emergency = conditions). Also think about the load you introduce on PCCs...=20 In some inter-area networks where ABRs are acting as PCEs you may = several 10s of PCE in the backbone area, a PCC would have to send a = request to all these PCEs for each TE-LSP to be computed... I'm my view a better way to solve these race conditions could be to rely = on a proxy PCE, that would actually receive requests from all PCCs, and = would act as a path computation scheduler by appropriately sequencing = requests and distributing requests to a set of PCEs. This would avoid = sending requests to all PCEs, and would avoid maintaining and = synchronizing request tables between all PCEs. >=20 > Another purpose of the proposal is to decrease the PCE=20 > discovery's complexity.=20 > Before a PCC decides to send a=20 > request to a proper PCE, it must learn a lot of messages from=20 > the different PCEs through PCE discovery protocol, analyse=20 > all kinks of capabilities/policies contained in the messages,=20 > do some maintaining work, these perhaps will make the PCC=20 > fall into a painful situation which goes back on the=20 > intention of PCE arch.=20 The PCE discovery is done once, and not before each request. You are = rithg detailed PCE discovery requires message exhange, but this is done = once, and not per request. In your proposal a PCC has to send a message = to all PCEs and maintain a transient state per message for each request, = which is IMHO much more heavy than a capability discovery at PCC-PCE = session setup.=20 To relax the PCC's work, with this=20 > proposal, just get the dicision of the exact PCE for a=20 > request done in PCE. > for the PCC, only generic capabilities of PCEs are learned,=20 Yes, this is in sync with the PCE discovery req ID,=20 Note that we distinguish two types of information to be discovered: = general information (location, scopes...) and detailed information = (constraints, objective functions...).=20 The PCE discovery protocol could be limited to general information. This = would not require maintaining a lot of information (a set of bit flags = per PCE).=20 Detailed capabilities could be discovered thanks to the PCC-PCE = communcation protocol, at PCC-PCE session setup. This information is quite static, and discovery would be done once at = session setup. > based on which PCCs will hopfully choose the right PCE, in=20 > case of failure of the choice, PCE can get it done.=20 Of course sending the request to all PCEs avoid detailed PCE discovery. = but Frankly speaking IMHO this introduces much more complexity than it = tries to reduce... Think about the number of messages and transient states (one per = message) a PCC would have to maintain, particularly under network = failure condition, compared to a simple discovery as part of the PCC-PCE = session setup... Best Regards, JL >=20 > Cheers, > Zhang >=20 > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > To: "Zhang Renhai" ; > Sent: Friday, August 26, 2005 5:16 PM > Subject: RE: [Pce] About the=20 > presentationofdraft-zhang-pce-comm-app-model-01.txt >=20 >=20 > Hi Zhang >=20 > Sorry for replying so late... >=20 > Please see inline,=20 >=20 > > -----Message d'origine----- > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 > > Envoy=E9 : lundi 8 ao=FBt 2005 10:10 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > > Objet : Re: [Pce] About the=20 > > presentationofdraft-zhang-pce-comm-app-model-01.txt > >=20 > > Hi, Jean Louis > >=20 > > Nice to see your question again in mailing list. Please=20 > see inline. > >=20 > >=20 > > ----- Original Message ----- > > From: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > > > To: "Zhang Renhai" ; > > Sent: Friday, August 05, 2005 6:14 PM > > Subject: RE: [Pce] About the presentation=20 > > ofdraft-zhang-pce-comm-app-model-01.txt > >=20 > >=20 > > Hi Zhang > >=20 > > Please see inline=20 > >=20 > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org=20 > > > [mailto:pce-bounces@lists.ietf.org] De la part de Zhang Renhai > > > Envoy=E9 : mercredi 3 ao=FBt 2005 15:28 > > > =C0 : pce@ietf.org > > > Objet : [Pce] About the presentation=20 > > > ofdraft-zhang-pce-comm-app-model-01.txt > > >=20 > > > Hi, all > > > =20 > > > Sorry for not all clear about some questions asked to me at=20 > > > the meeting. > > > I really appreciate that someone can repeat the question and=20 > > > we can discuss more here. > >=20 > > Sure, here it is: > >=20 > > JL->The problem you raise is valuable, race condition issues=20 > > will increase in case of distributed-PCE computation with=20 > > external PCEs, as the delay between path computation and path=20 > > setup will increase. But I have some scalability concerns=20 > > with your proposed solution: Basically one objective of PCE=20 > > distribution would be to reduce the number of requests to be=20 > > handled by PCEs, as this could be the bottleneck, and here=20 > > actually your proposal requires sending requests to all PCEs.=20 > > Hence all PCEs will support the whole PCCs' requests load. > >=20 > > ZRH---->Sending requests to all PCEs is a method to make it=20 > > possible that each PCE can know the current resources=20 > > application status,=20 >=20 > Yes I understand this point, but the issue is that the=20 > request messages load is no longer distributed, a PCE will=20 > reveive all requests, and IMHO this may significantly=20 > diminish the benefits of PCE distribution. > This may be OK in steady state but let's take an emergency=20 > condition: For instance let's take a Link/node failure in the=20 > core, which impacts a large number of TE-LSPs. Many PCCs are=20 > going to simultaneously send a request to all PCEs.=20 > This raises a scalability issue regarding the number of=20 > messages to be handled by each PCE and also regarding the=20 > size of the request table to be maintained on each PCE (#=20 > failed LSPs). >=20 >=20 > and accordingly > > can sort order for the requests which may be computed in=20 > > different PCEs, for example, req1 and req2 are send=20 > > repectively to PCE1, PCE2, and req1 has > > a lower priority than req2, but if PCE1 doesn't know that=20 > > there is another req with a higher priority(req2 is sent to=20 > > PCE2), it may take the resource that req2 > > may also need and only suffice one request.=20 >=20 > Yes I clearly agree that your proposal would help solving the=20 > race condition issue, but to my mind the complexity=20 > introduced significantly reduces the benefits of this aproach. >=20 >=20 > Then when PCE2 is=20 > > computing the path for req2 later, what about the result?=20 > > teardown the first path computed=20 > > for req1? or reply the failure of the computation for req2? > > So if both the PCE1 and PCE2 know the all the current=20 > > requests, based on some policies configured by operator, PCE1=20 > > can delay the computation for req1, >=20 > > to get the computation orderly and make sure the resources=20 > > distributed reasonably. > >=20 > >=20 > > JL->IMHO this may significantly disminish the benefits of PCE=20 > > distribution. > >=20 > > ZRH--->Each PCE knowing all the requests doesn't means to add=20 > > the load of computation to each PCE, it's just give each PCE=20 > > enough information to make the PCEs working cooperatively.=20 >=20 > The issue is that the bootleneck does not only rely on the=20 > load of computation, but also, and above all, on the load of=20 > messages to be handled and on the amount of information to be=20 > maintained... >=20 > > See the example again, PCE1 knows there are being two=20 > > requests but only computes req1, PCE2 knows there are being two but=20 > > only computes req2. >=20 > Yes I clearly understand that, but it has at least to parse=20 > req1 message and store related information. In some emergency=20 > conditions this may lead to a large number of request to be=20 > handled and a huge amount of information to be maintained... >=20 > Anyway the race condition problem you raised is highly=20 > valuable, but IMHO we need more discussions on the way to=20 > address it... >=20 > Thanks, >=20 > JL >=20 > >=20 > > Thanks and Regards, > > Zhang > >=20 > >=20 > >=20 > > JL->Anyway thanks for higlighting this problem, and for=20 > > initiating discussion.=20 > >=20 > > Regards, > >=20 > > JL > >=20 > >=20 > > >=20 > > > Actually, what I proposed surely is just applied to some=20 > > > kind of circumstances. For example, if three PCEs are serving=20 > > > all requests in a domain, and these PCEs are coupled closely,=20 > > > for instance, they may be located in different box but in the=20 > > > same tank or room, or located in different place remote to=20 > > > each other and connected by a high speed line, so based on my=20 > > > proposal, even only one request is sent to one of these PCE,=20 > > > and the PCE can forward the request to other two PCEs quickly=20 > > > to make the two PCEs maintain the request table,and this=20 > > > delation of transmittion may be ignoed by some tradeoff. > > > The essential goal of the draft is just to use the table to=20 > > > solve some known question. > > > I don't know how the communication for the detailed=20 > > > discovery will be because the detailed capability is still=20 > > > not specified now, how complicated a detailed capability=20 > > > could be for a special request? Can a tradeoff be made=20 > > > between below two choice for some special application: > > > =20 > > > -saving the detailed discovery communication,=20 > > > correspondingly sending=20 > > > the same request to all PCEs(or just one of these PCEs=20 > > > like what I mentioned above) > > > -performing the detailed discovery communication for each PCC? > > >=20 > > > Certainly,this proposal is not intent to became part of the=20 > > > PCE communication protocol. > > >=20 > > > Another concern of this draft is to make the requests=20 > > > distributed to different PCE more *reasonable*, for example,=20 > > > three PCEs in a domain, PCE1, PCE2, PCE3, and now PCE3 is=20 > > > congested with too much requests or other reason, for the PCC=20 > > > originating the request, which PCE else should it choose?=20 > > > PCE1 or PCE2? what information should be used to help to=20 > > > select again more reasonable? Based on the Global Computing=20 > > > Table, the congesting PCE(PCE3) will know the number of=20 > > > requests that other PCE is now dealing with, although PCE1 and > > > PCE2 both are not congested now, based on the mentioned=20 > > > information, PCE3 can select other PCE with least number of=20 > > > requests and appropriate capability to make sure the PCC can=20 > > > get the computation result asap, and I think the time from=20 > > > sending request to receiving the computing result may be a=20 > > > important consideration for some application. > > >=20 > > > Cheers, > > > Zhang > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 31 08:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARn6-00048H-JH; Wed, 31 Aug 2005 08:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARn4-00048C-3e for pce@megatron.ietf.org; Wed, 31 Aug 2005 08:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17741 for ; Wed, 31 Aug 2005 08:34:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EARon-0004QK-D4 for pce@ietf.org; Wed, 31 Aug 2005 08:35:54 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2005 05:33:54 -0700 X-IronPort-AV: i="3.96,157,1122879600"; d="scan'208"; a="337499239:sNHT33759372" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7VCXf0R017751; Wed, 31 Aug 2005 05:33:51 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 08:33:47 -0400 Received: from [192.168.1.100] ([10.86.242.41]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 08:33:46 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <43AB7A03-623D-48E9-9B2A-EDFF01DAE7C0@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Date: Wed, 31 Aug 2005 08:34:20 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 31 Aug 2005 12:33:46.0636 (UTC) FILETIME=[3B46FCC0:01C5AE28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: pce@ietf.org, Richard Rabbat , Ting_Wo Chung , "raymond.zhang" , Paul Mabey Subject: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jean-Louis, On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Jean-Philippe, > > we plan to post a new revision by mid-september. > Is that OK? > Perfect, thanks. Provided that the remaining issues are sorted out, =20 we could go for WG LC on this ID. JP. > Regards, > > JL > > >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] >> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 >> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; Eiji Oki; >> Richard Rabbat; Ting_Wo Chung; raymond.zhang >> Cc : pce@ietf.org >> Objet : Progress on draft-ietf-pce-discovery-reqs-01.txt >> >> Hi, >> >> First of all, thanks for the very significant progress which >> has been made on this ID over the past 6 months. As discussed >> during the last meeting in Paris, there are still a few >> issues to be sorted out. >> Could we try to close on these remaining issues so as to >> quickly start the protocol work (we're a bit late on this =20 >> Milestone) ? >> >> Thanks. >> >> JP. >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Aug 31 17:26:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAa5u-00008y-D3; Wed, 31 Aug 2005 17:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAa5s-00007P-Li for pce@megatron.ietf.org; Wed, 31 Aug 2005 17:26:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16479 for ; Wed, 31 Aug 2005 17:26:01 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAa7f-00039d-H4 for pce@ietf.org; Wed, 31 Aug 2005 17:27:58 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2005 14:25:52 -0700 X-IronPort-AV: i="3.96,158,1122879600"; d="scan'208"; a="337707349:sNHT28825460" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7VLPnoo002424; Wed, 31 Aug 2005 14:25:49 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 17:25:48 -0400 Received: from [192.168.1.100] ([10.86.240.27]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 17:25:48 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 31 Aug 2005 17:26:22 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 31 Aug 2005 21:25:48.0580 (UTC) FILETIME=[8E3D1640:01C5AE72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] PCE WG Meeting Minutes - IETF-63 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@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Dear WG, The PCE WG minutes - IETF63 (including the comments received on the Draft Minutes) has been posted: https://datatracker.ietf.org/public/ proceeding_onsite.cgi?meeting_num=63 Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce