From pce-bounces@lists.ietf.org Mon Oct 03 17:41:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMY3p-0004y3-Iw; Mon, 03 Oct 2005 17:41:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMY3n-0004wc-IA for pce@megatron.ietf.org; Mon, 03 Oct 2005 17:41:23 -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 RAA17242 for ; Mon, 3 Oct 2005 17:41:21 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMYCK-0001Qz-Qn for pce@ietf.org; Mon, 03 Oct 2005 17:50:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Oct 2005 17:41:14 -0400 X-IronPort-AV: i="3.97,169,1125892800"; d="scan'208"; a="72792787:sNHT25650800" 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 j93LetR1003045; Mon, 3 Oct 2005 17:41:11 -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, 3 Oct 2005 17:41:01 -0400 Received: from [192.168.1.102] ([10.86.242.59]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 17:41:01 -0400 In-Reply-To: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ABC6DE5-0FE4-4C8E-8EB6-0586289BAFFC@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Choosing the PCE protocol Date: Mon, 3 Oct 2005 17:41:22 -0400 To: Adrian Farrel , pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 03 Oct 2005 21:41:01.0488 (UTC) FILETIME=[26018B00:01C5C863] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, First of all, we would like to explain a bit further the process that we followed to come up with the proposed PCEP protocol: We started by evaluating existing protocols (such as COPS, HTTP/XML + others) to see whether we could meet the PCE requirements by means of minor extensions (without negative impact on the protocol). Considering the PCE WG's specific requirements, we came to the conclusion that a new protocol was required and no existing protocol could be naturally and efficiently extended to meet such requirements. Furthermore, we did not want to have to use unneeded features/functionalities that were present in existing protocols and that have been designed for other purposes. Now to answer Adrian's question: Thus, we started to work on a new protocol (PCEP) for which we have received so far quite a few comments which have been incorporated in the latest revision (rev -02). Here are the following PCEP's characteristics: - Fully meets the PCE requirements spelled out in the PCE communication requirement document (draft-ietf-pce-comm-protocol-gen- reqs-02.txt) -> this is detailed in Appendix A of the draft, - Very lightweight protocol w/o complex state machinery, - Easily extensible by adding new messages or objects should we have to address new requirements in the future, - Limited number of messages and objects (actually there are several applications that would require the implementation a very limited subset of objects) - Maximum reuse of mechanisms which have already been defined and deployed in other protocols (no need to re-invent the wheel !). - Reuse of TCP for transport thus providing reliable messaging, flow control, security, ... - Support of solicited and unsolicited communication messages - ... Note that implementers have expressed interest in such solution. Thanks. JP, Jean-Louis, Eiji, Alia, Arthi and Andrew. On Sep 29, 2005, at 10:27 AM, Adrian Farrel wrote: > Hi, > > Three candidate protocols have been brought to my attention for us to > consider. These are (in no specific order): > - HTTP > - PCECP (as draft-vasseur-pce-pcep-02.txt) > - COPS > > I would like to close the nomination period, and move on to select our > protocol. > > The best approach will be if supporters of the candidate protocols > indicate (briefly) why their proposed protocol is suitable. It > would also > be helpful if they were frank about what the weaknesses of their > proposal > are. > > And please - this is not an election, it is an interview process. > > Thanks, > Adrian > > PS The reason why JP is keeping quite on this is that he is an > author of > draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not > occupying the > chair during this discussion. > > > > > _______________________________________________ > 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 Oct 03 18:30:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMYpV-0000gR-9H; Mon, 03 Oct 2005 18:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMYpT-0000gJ-9H for pce@megatron.ietf.org; Mon, 03 Oct 2005 18:30: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 SAA21550 for ; Mon, 3 Oct 2005 18:30:36 -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 1EMYy2-0002xQ-1U for pce@ietf.org; Mon, 03 Oct 2005 18:39:30 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2005 15:30:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j93MUK4b012372; Mon, 3 Oct 2005 15:30:27 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 15:30:14 -0700 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] Choosing the PCE protocol Date: Mon, 3 Oct 2005 15:30:13 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0EB275A4@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] Choosing the PCE protocol Thread-Index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 03 Oct 2005 22:30:14.0446 (UTC) FILETIME=[061B2CE0:01C5C86A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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, I don't think HTTP is a good candidate for the PCE application and here are some weakness one could think of, if it used for PCE application:=20 =20 1) The HTTP is specifically designed for communications between web server and its client, or applications in that nature.=20 Although it is possible to add extensions to support PCE application, it would require a considerable amount of work. That is not worth of the effort given the much smaller and narrower application scope of PCE. =20 2) The payload of HTTP messages (both request and response) is in form of byte stream, which is unstructured comparing=20 to the PCEP proposal, where the content is structured with objects. For the PCE application, the object based format is more=20 efficient in terms of processing. =20 3) The HTTP does not have unsolicited messages such as Notification message and Error message that are defined by PCEP. =20 4) PCE architecture allows a PCE functions as a server but also as a client communicating with another PCE server. In both cases,=20 the same protocol is used. PCEP supports this scenario. There requires some work to make HTTP behavior as such. =20 Dean >-----Original Message----- >From: pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >Sent: Thursday, September 29, 2005 7:27 AM >To: pce@ietf.org >Subject: [Pce] Choosing the PCE protocol > >Hi, > >Three candidate protocols have been brought to my attention=20 >for us to consider. These are (in no specific order): >- HTTP >- PCECP (as draft-vasseur-pce-pcep-02.txt) >- COPS > >I would like to close the nomination period, and move on to=20 >select our protocol. > >The best approach will be if supporters of the candidate=20 >protocols indicate (briefly) why their proposed protocol is=20 >suitable. It would also be helpful if they were frank about=20 >what the weaknesses of their proposal are. > >And please - this is not an election, it is an interview process. > >Thanks, >Adrian > >PS The reason why JP is keeping quite on this is that he is an=20 >author of draft-vasseur-pce-pcep-02.txt and so (quite rightly)=20 >is not occupying the chair during this discussion. > > > > >_______________________________________________ >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 Oct 04 00:14:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMe9N-0002HL-B5; Tue, 04 Oct 2005 00:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMe9M-0002HE-A9 for pce@megatron.ietf.org; Tue, 04 Oct 2005 00:11:32 -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 AAA11133 for ; Tue, 4 Oct 2005 00:11:29 -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 1EMeHx-0004ES-Ul for pce@ietf.org; Tue, 04 Oct 2005 00:20:26 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2005 21:11:20 -0700 X-IronPort-AV: i="3.97,171,1125903600"; d="scan'208"; a="347967119:sNHT28313800" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j944BB52009730; Mon, 3 Oct 2005 21:11:18 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 21:10:19 -0700 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] Choosing the PCE protocol Date: Mon, 3 Oct 2005 21:10:18 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0EB27654@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] Choosing the PCE protocol Thread-Index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5QAALsmmA= From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 04 Oct 2005 04:10:19.0144 (UTC) FILETIME=[88410080:01C5C899] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 As for COPS, its application environment is somewhat similar to that of PCE but has some problems (if used for PCE applciation) due to much optimization around its specifics such as: 1) The PEP (client) is the one required to initiate the connection with a PDP (server). Whereas for PCE=20 application, either PCE (server) or PCC may initiate the connection. 2) There requires a synchronization between PEP and PDP for the policy application with states maintained on both places. For PCE application, the PCE server is only required to perform a one-time service for each LSP, without the need maintain any subsequent states. 3) It requires some work to support a PDP functions as a PEP and communicates with another PDP. PCEP supports this model fully. 4) COPS is a server-client protocol, but with code point heavily dedicated for a specific application. It does not serve general purpose if any, and to support PCE application, there would be a large number of extensions, thus defeating the purpose of reusage. =20 As a result, I'd favor PECP as a PCE-specific protocol; it is much cleaner and also light-weighted. Dean >-----Original Message----- >From: pce-bounces@lists.ietf.org=20 >[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >Sent: Monday, October 03, 2005 3:30 PM >To: Adrian Farrel; pce@ietf.org >Subject: RE: [Pce] Choosing the PCE protocol > >Hi, > > I don't think HTTP is a good candidate for the PCE application > and here are some weakness one could think of, if it used for > PCE application:=20 >=20 > 1) The HTTP is specifically designed for communications between > web server and its client, or applications in that nature.=20 > Although it is possible to add extensions to support PCE > application, it would require a considerable amount of work. > That is not worth of the effort given the much smaller and > narrower application scope of PCE. >=20 > 2) The payload of HTTP messages (both request and response) > is in form of byte stream, which is unstructured comparing=20 > to the PCEP proposal, where the content is structured=20 >with objects. > For the PCE application, the object based format is more=20 > efficient in terms of processing. >=20 > 3) The HTTP does not have unsolicited messages such as Notification > message and Error message that are defined by PCEP. >=20 > 4) PCE architecture allows a PCE functions as a server but also as > a client communicating with another PCE server. In both cases,=20 > the same protocol is used. PCEP supports this scenario. There > requires some work to make HTTP behavior as such. >=20 >Dean > >>-----Original Message----- >>From: pce-bounces@lists.ietf.org >>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>Sent: Thursday, September 29, 2005 7:27 AM >>To: pce@ietf.org >>Subject: [Pce] Choosing the PCE protocol >> >>Hi, >> >>Three candidate protocols have been brought to my attention for us to=20 >>consider. These are (in no specific order): >>- HTTP >>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>- COPS >> >>I would like to close the nomination period, and move on to=20 >select our=20 >>protocol. >> >>The best approach will be if supporters of the candidate protocols=20 >>indicate (briefly) why their proposed protocol is suitable. It would=20 >>also be helpful if they were frank about what the weaknesses of their=20 >>proposal are. >> >>And please - this is not an election, it is an interview process. >> >>Thanks, >>Adrian >> >>PS The reason why JP is keeping quite on this is that he is an author=20 >>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not=20 >>occupying the chair during this discussion. >> >> >> >> >>_______________________________________________ >>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 Oct 04 12:28:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpeW-0008Rw-Vi; Tue, 04 Oct 2005 12:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpeW-0008Rl-7M for pce@megatron.ietf.org; Tue, 04 Oct 2005 12:28: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 MAA07765 for ; Tue, 4 Oct 2005 12:28:25 -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 1EMpnE-0000AG-68 for pce@ietf.org; Tue, 04 Oct 2005 12:37:28 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2005 09:28:18 -0700 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 j94GSDKE007903; Tue, 4 Oct 2005 09:28:16 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 12:28:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Choosing the PCE protocol Date: Tue, 4 Oct 2005 12:28:13 -0400 Message-ID: Thread-Topic: RE: [Pce] Choosing the PCE protocol Thread-Index: AcXJAJ2RlkhJ1XklT4m+Kqwe84IiFA== From: "Zafar Ali \(zali\)" To: X-OriginalArrivalTime: 04 Oct 2005 16:28:13.0831 (UTC) FILETIME=[9E061970:01C5C900] X-Spam-Score: 0.9 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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="===============1874359922==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1874359922== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C900.9DE86336" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C900.9DE86336 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I agree w/ the comments made by Dean. It is also important to realize that the PCE communication protocol is a control plane protocol, not a management plane protocol: hence it is of the utmost importance to minimize communication overhead (see Dean's comment on communication overhead). =20 =20 Thanks =20 Regards... Zafar =20 >To: "Adrian Farrel" , =20 >Subject: RE: [Pce] Choosing the PCE protocol=20 >From: "Dean Cheng \(dcheng\)" =20 >Date: Mon, 3 Oct 2005 15:30:13 -0700=20 >Cc:=20 >List-archive: =20 >List-help: =20 >List-id: Path Computation Element =20 >List-post: =20 >List-subscribe: , =20 >List-unsubscribe: , =20 >Sender: pce-bounces at lists.ietf.org=20 >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q=20 >Thread-topic: [Pce] Choosing the PCE protocol=20 > >----------------------------------------------------------------------- --------- > >Hi, > > I don't think HTTP is a good candidate for the PCE application > and here are some weakness one could think of, if it used for > PCE application:=20 >=20 > 1) The HTTP is specifically designed for communications between > web server and its client, or applications in that nature.=20 > Although it is possible to add extensions to support PCE > application, it would require a considerable amount of work. > That is not worth of the effort given the much smaller and > narrower application scope of PCE. >=20 > 2) The payload of HTTP messages (both request and response) > is in form of byte stream, which is unstructured comparing=20 > to the PCEP proposal, where the content is structured with >objects. > For the PCE application, the object based format is more=20 > efficient in terms of processing. >=20 > 3) The HTTP does not have unsolicited messages such as Notification > message and Error message that are defined by PCEP. >=20 > 4) PCE architecture allows a PCE functions as a server but also as > a client communicating with another PCE server. In both cases,=20 > the same protocol is used. PCEP supports this scenario. There > requires some work to make HTTP behavior as such. >=20 >Dean =20 =20 ------_=_NextPart_001_01C5C900.9DE86336 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,=20
 
I=20 agree w/ the comments made by Dean. It is also important to realize that = the PCE=20 communication protocol is a control plane protocol, not a management = plane=20 protocol: hence it is of the utmost importance to minimize = communication=20 overhead (see Dean's comment on communication overhead). =20
 
Thanks
 
Regards... Zafar
 
>To: "Adrian Farrel" <adrian = at=20 olddog.co.uk>, <pce at ietf.org>
>Subject: RE: [Pce] = Choosing=20 the PCE protocol
>From: "Dean Cheng \(dcheng\)" <dcheng at=20 cisco.com>
>Date: Mon, 3 Oct 2005 15:30:13 -0700
>Cc:=20
>List-archive: <http://www1.ietf.org/pipermai= l/pce>=20
>List-help: <mailto:pce-requ= est@lists.ietf.org?subject=3Dhelp>=20
>List-id: Path Computation Element <pce.lists.ietf.org>=20
>List-post: <mailto:pce@lists.ietf.org>=20
>List-subscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:pce= -request@lists.ietf.org?subject=3Dsubscribe>=20
>List-unsubscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:p= ce-request@lists.ietf.org?subject=3Dunsubscribe>=20
>Sender: pce-bounces at lists.ietf.org
>Thread-index:=20 AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q
>Thread-topic: [Pce] = Choosing the=20 PCE protocol=20
>
>---------------------------------------------------------= -----------------------
>
>Hi,
>
> =20 I don't think HTTP is a good candidate for the PCE = application
>  and=20 here are some weakness one could think of, if it used for
>  = PCE=20 application:
>
>    1) The HTTP is = specifically=20 designed for communications = between
>      =20 web server and its client, or applications in that nature.=20
>       Although it is possible to = add=20 extensions to support PCE
>      =20 application, it would require a considerable amount of=20 work.
>       That is not worth of = the=20 effort given the much smaller = and
>      =20 narrower application scope of PCE.
>
>    2) = The=20 payload of HTTP messages (both request and=20 response)
>       is in form of byte = stream,=20 which is unstructured comparing =
>       to=20 the PCEP proposal, where the content is structured=20 with
>objects.
>       For the = PCE=20 application, the object based format is more=20
>       efficient in terms of=20 processing.
>
>    3) The HTTP does not have = unsolicited messages such as=20 Notification
>       message and = Error=20 message that are defined by PCEP.
>
>    4) = PCE=20 architecture allows a PCE functions as a server but also=20 as
>       a client communicating = with=20 another PCE server. In both cases, =
>      =20 the same protocol is used. PCEP supports this scenario.=20 There
>       requires some work to = make=20 HTTP behavior as such.
>
>Dean
 
 
------_=_NextPart_001_01C5C900.9DE86336-- --===============1874359922== 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 --===============1874359922==-- From pce-bounces@lists.ietf.org Tue Oct 04 12:46:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpvr-0006Dh-TW; Tue, 04 Oct 2005 12:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpvq-0006DZ-OB for pce@megatron.ietf.org; Tue, 04 Oct 2005 12:46:23 -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 MAA08829 for ; Tue, 4 Oct 2005 12:46:19 -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 1EMq4Y-0000iT-8J for pce@ietf.org; Tue, 04 Oct 2005 12:55:23 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2005 09:46:11 -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 j94Gk54w013112; Tue, 4 Oct 2005 09:46:09 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 12:45:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Pce] Choosing the PCE protocol Date: Tue, 4 Oct 2005 12:45:44 -0400 Message-ID: Thread-Topic: Re: [Pce] Choosing the PCE protocol Thread-Index: AcXJAxAvhrhD9VgTRLCc9N0cHTKYBg== From: "Zafar Ali \(zali\)" To: X-OriginalArrivalTime: 04 Oct 2005 16:45:45.0380 (UTC) FILETIME=[10CBBE40:01C5C903] X-Spam-Score: 0.5 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d 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="===============0998103821==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0998103821== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C903.10983FDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C903.10983FDA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Agreed here too with Dean; COPS is quite heavy in term of states maintenance and protocol overhead, when compared with PCECP. =20 =20 Thanks =20 Regards... Zafar=20 =20 >To: "Adrian Farrel" , =20 >Subject: RE: [Pce] Choosing the PCE protocol=20 >From: "Dean Cheng \(dcheng\)" =20 >Date: Mon, 3 Oct 2005 21:10:18 -0700=20 >Cc:=20 >List-archive: =20 >List-help: =20 >List-id: Path Computation Element =20 >List-post: =20 >List-subscribe: , =20 >List-unsubscribe: , =20 >Sender: pce-bounces at lists.ietf.org=20 >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5QAALsmmA=3D=20 >Thread-topic: [Pce] Choosing the PCE protocol=20 > >----------------------------------------------------------------------- --------- > >As for COPS, its application environment is somewhat similar >to that of PCE but has some problems (if used for PCE applciation) >due to much optimization around its specifics such as: > > 1) The PEP (client) is the one required to initiate the > connection with a PDP (server). Whereas for PCE=20 > application, either PCE (server) or PCC may initiate > the connection. > > 2) There requires a synchronization between PEP and PDP for > the policy application with states maintained on both places. > For PCE application, the PCE server is only required to > perform a one-time service for each LSP, without the need > maintain any subsequent states. > > 3) It requires some work to support a PDP functions as a PEP > and communicates with another PDP. PCEP supports this model > fully. > > 4) COPS is a server-client protocol, but with code point > heavily dedicated for a specific application. It does not > serve general purpose if any, and to support PCE application, > there would be a large number of extensions, thus defeating > the purpose of reusage. >=20 >As a result, I'd favor PECP as a PCE-specific protocol; it is much >cleaner and also light-weighted. > >Dean > >>-----Original Message----- >>From: pce-bounces at lists.ietf.org=20 >>[mailto:pce-bounces at lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>Sent: Monday, October 03, 2005 3:30 PM >>To: Adrian Farrel; pce at ietf.org >>Subject: RE: [Pce] Choosing the PCE protocol >> >>Hi, >> >> I don't think HTTP is a good candidate for the PCE application >> and here are some weakness one could think of, if it used for >> PCE application:=20 >>=20 >> 1) The HTTP is specifically designed for communications between >> web server and its client, or applications in that nature.=20 >> Although it is possible to add extensions to support PCE >> application, it would require a considerable amount of work. >> That is not worth of the effort given the much smaller and >> narrower application scope of PCE. >>=20 >> 2) The payload of HTTP messages (both request and response) >> is in form of byte stream, which is unstructured comparing=20 >> to the PCEP proposal, where the content is structured=20 >>with objects. >> For the PCE application, the object based format is more=20 >> efficient in terms of processing. >>=20 >> 3) The HTTP does not have unsolicited messages such as Notification >> message and Error message that are defined by PCEP. >>=20 >> 4) PCE architecture allows a PCE functions as a server but also as >> a client communicating with another PCE server. In both cases,=20 >> the same protocol is used. PCEP supports this scenario. There >> requires some work to make HTTP behavior as such. >>=20 >>Dean >> >>>-----Original Message----- >>>From: pce-bounces at lists.ietf.org >>>[mailto:pce-bounces at lists.ietf.org] On Behalf Of Adrian Farrel >>>Sent: Thursday, September 29, 2005 7:27 AM >>>To: pce at ietf.org >>>Subject: [Pce] Choosing the PCE protocol >>> >>>Hi, >>> >>>Three candidate protocols have been brought to my attention for us to >>>consider. These are (in no specific order): >>>- HTTP >>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>- COPS >>> >>>I would like to close the nomination period, and move on to=20 >>select our=20 >>>protocol. >>> >>>The best approach will be if supporters of the candidate protocols=20 >>>indicate (briefly) why their proposed protocol is suitable. It would=20 >>>also be helpful if they were frank about what the weaknesses of their >>>proposal are. >>> >>>And please - this is not an election, it is an interview process. >>> >>>Thanks, >>>Adrian >>> >>>PS The reason why JP is keeping quite on this is that he is an author >>>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not=20 >>>occupying the chair during this discussion. >>> >>> >>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce at lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >> >>_______________________________________________ >>Pce mailing list >>Pce at lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/pce >> ------_=_NextPart_001_01C5C903.10983FDA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,=20
 
Agreed = here too with=20 Dean; COPS is quite heavy in term of states maintenance = and=20 protocol overhead, when compared with = PCECP. 
 
Thanks
 
Regards... Zafar=20
 
>To: "Adrian Farrel" <adrian at=20 olddog.co.uk>, <pce at ietf.org>
>Subject: RE: [Pce] = Choosing=20 the PCE protocol
>From: "Dean Cheng \(dcheng\)" <dcheng at=20 cisco.com>
>Date: Mon, 3 Oct 2005 21:10:18 -0700
>Cc:=20
>List-archive: <http://www1.ietf.org/pipermai= l/pce>=20
>List-help: <mailto:pce-requ= est@lists.ietf.org?subject=3Dhelp>=20
>List-id: Path Computation Element <pce.lists.ietf.org>=20
>List-post: <mailto:pce@lists.ietf.org>=20
>List-subscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:pce= -request@lists.ietf.org?subject=3Dsubscribe>=20
>List-unsubscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:p= ce-request@lists.ietf.org?subject=3Dunsubscribe>=20
>Sender: pce-bounces at lists.ietf.org
>Thread-index:=20 AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5QAALsmmA=3D
>Thread-topic: = [Pce]=20 Choosing the PCE protocol=20
>
>---------------------------------------------------------= -----------------------
>
>As=20 for COPS, its application environment is somewhat similar
>to that = of PCE=20 but has some problems (if used for PCE applciation)
>due to much=20 optimization around its specifics such as:
>
>   = 1) The=20 PEP (client) is the one required to initiate=20 the
>      connection with a PDP = (server).=20 Whereas for PCE
>      application, = either PCE=20 (server) or PCC may initiate
>      the=20 connection.
>
>   2) There requires a = synchronization=20 between PEP and PDP for
>      the policy = application with states maintained on both=20 places.
>      For PCE application, the = PCE=20 server is only required to
>      perform = a=20 one-time service for each LSP, without the=20 need
>      maintain any subsequent=20 states.
>
>   3) It requires some work to support = a PDP=20 functions as a PEP
>      and = communicates with=20 another PDP. PCEP supports this = model
>     =20 fully.
>
>   4) COPS is a server-client protocol, = but with=20 code point
>      heavily dedicated for a = specific application. It does not
>      = serve=20 general purpose if any, and to support PCE=20 application,
>      there would be a = large number=20 of extensions, thus defeating
>      the = purpose=20 of reusage.
>
>As a result, I'd favor PECP as a = PCE-specific=20 protocol; it is much
>cleaner and also=20 light-weighted.
>
>Dean
>
>>-----Original=20 Message-----
>>From: pce-bounces at lists.ietf.org=20
>>[mailto:pce-bounces at lists.ietf.org] On Behalf Of Dean = Cheng=20 (dcheng)
>>Sent: Monday, October 03, 2005 3:30 = PM
>>To: Adrian=20 Farrel; pce at ietf.org
>>Subject: RE: [Pce] Choosing the PCE=20 protocol
>>
>>Hi,
>>
>>  I = don't think=20 HTTP is a good candidate for the PCE application
>>  and = here are=20 some weakness one could think of, if it used for
>>  PCE=20 application:
>>
>>    1) The HTTP is=20 specifically designed for communications=20 between
>>       web server and = its=20 client, or applications in that nature.=20
>>       Although it is possible = to add=20 extensions to support = PCE
>>      =20 application, it would require a considerable amount of=20 work.
>>       That is not worth = of the=20 effort given the much smaller=20 and
>>       narrower application = scope=20 of PCE.
>>
>>    2) The payload of = HTTP=20 messages (both request and=20 response)
>>       is in form of = byte=20 stream, which is unstructured comparing=20
>>       to the PCEP proposal, = where the=20 content is structured
>>with=20 objects.
>>       For the PCE=20 application, the object based format is more=20
>>       efficient in terms of=20 processing.
>>
>>    3) The HTTP does = not have=20 unsolicited messages such as=20 Notification
>>       message and = Error=20 message that are defined by PCEP.
>> =
>>    4)=20 PCE architecture allows a PCE functions as a server but also=20 as
>>       a client = communicating with=20 another PCE server. In both cases,=20
>>       the same protocol is = used. PCEP=20 supports this scenario. = There
>>      =20 requires some work to make HTTP behavior as such.
>>=20
>>Dean
>>
>>>-----Original=20 Message-----
>>>From: pce-bounces at=20 lists.ietf.org
>>>[mailto:pce-bounces at lists.ietf.org] On = Behalf=20 Of Adrian Farrel
>>>Sent: Thursday, September 29, 2005 7:27=20 AM
>>>To: pce at ietf.org
>>>Subject: [Pce] = Choosing the=20 PCE=20 protocol
>>>
>>>Hi,
>>>
>>&g= t;Three=20 candidate protocols have been brought to my attention for us to=20
>>>consider. These are (in no specific = order):
>>>-=20 HTTP
>>>- PCECP (as = draft-vasseur-pce-pcep-02.txt)
>>>-=20 COPS
>>>
>>>I would like to close the nomination = period,=20 and move on to
>>select our=20
>>>protocol.
>>>
>>>The best = approach will=20 be if supporters of the candidate protocols
>>>indicate = (briefly)=20 why their proposed protocol is suitable. It would
>>>also = be=20 helpful if they were frank about what the weaknesses of their=20
>>>proposal are.
>>>
>>>And please = - this=20 is not an election, it is an interview=20 process.
>>>
>>>Thanks,
>>>Adrian
= >>>
>>>PS=20 The reason why JP is keeping quite on this is that he is an author=20
>>>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) = is not=20
>>>occupying the chair during this=20 discussion.
>>>
>>>
>>>
>>&g= t;
>>>_______________________________________________
>= >>Pce=20 mailing list
>>>Pce at=20 lists.ietf.org
>>>https://www1.ietf.org/mailman/listinfo/pce<= BR>>>>
>>
>>__________________________________= _____________
>>Pce=20 mailing list
>>Pce at=20 lists.ietf.org
>>https://www1.ietf.org/mailman/listinfo/pce
&= gt;>
------_=_NextPart_001_01C5C903.10983FDA-- --===============0998103821== 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 --===============0998103821==-- From pce-bounces@lists.ietf.org Tue Oct 04 13:13:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqLd-0006BY-Lu; Tue, 04 Oct 2005 13:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqLb-00069b-GJ for pce@megatron.ietf.org; Tue, 04 Oct 2005 13:12:59 -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 NAA10674 for ; Tue, 4 Oct 2005 13:12:56 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMqUJ-0001Xr-M8 for pce@ietf.org; Tue, 04 Oct 2005 13:22:00 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 19:12:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Choosing the PCE protocol Date: Tue, 4 Oct 2005 19:12:05 +0200 Message-ID: Thread-Topic: [Pce] Choosing the PCE protocol Thread-Index: AcXJAJ2RlkhJ1XklT4m+Kqwe84IiFAAAOv6A From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zafar Ali \(zali\)" , , X-OriginalArrivalTime: 04 Oct 2005 17:12:06.0618 (UTC) FILETIME=[BF4983A0:01C5C906] X-Spam-Score: 0.9 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad 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="===============0043004799==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0043004799== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C906.BF1B06D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C906.BF1B06D7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 To complement what Zafar just mentionned, regarding the control plane = flavour of PCC-PCE communication, I would like to highlight the fact = that LSRs can act as PCEs, in which case the PCE communication protocol = runs directly between LSRs (inter-router communication).=20 For the sake of illustration, in a multi-area network, ABRs can act as = PCE and cooperate together to compute optimal inter-area paths (by the = way, this is the application at the origin of the PCE concept...), and = this may requires a full mesh of inter-ABR PCE communications.=20 This is one of the reasons why the communication overhead should be = minimized and the state machine should remain light. Another reason = being the capability to easily handle bursts of requests under emergency = conditions (e.g. upon link or node failure impacting a large number of = LSPs). =20 PCEP has been designed with this requirement as key driver. =20 It sounds IMHO quite important to take this point into consideration = when selecting the protocol. =20 Regards, =20 JL =20 ________________________________ De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Zafar Ali (zali) Envoy=E9 : mardi 4 octobre 2005 18:28 =C0 : dcheng@cisco.com Cc : pce@ietf.org Objet : RE: [Pce] Choosing the PCE protocol =09 =09 Hi,=20 =20 I agree w/ the comments made by Dean. It is also important to realize = that the PCE communication protocol is a control plane protocol, not a = management plane protocol: hence it is of the utmost importance to = minimize communication overhead (see Dean's comment on communication = overhead). =20 =20 Thanks =20 Regards... Zafar =20 >To: "Adrian Farrel" , =20 >Subject: RE: [Pce] Choosing the PCE protocol=20 >From: "Dean Cheng \(dcheng\)" =20 >Date: Mon, 3 Oct 2005 15:30:13 -0700=20 >Cc:=20 >List-archive: =20 >List-help: =20 >List-id: Path Computation Element =20 >List-post: =20 >List-subscribe: , = =20 >List-unsubscribe: , = =20 >Sender: pce-bounces at lists.ietf.org=20 >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q=20 >Thread-topic: [Pce] Choosing the PCE protocol=20 > = >------------------------------------------------------------------------= -------- > >Hi, > > I don't think HTTP is a good candidate for the PCE application > and here are some weakness one could think of, if it used for > PCE application:=20 >=20 > 1) The HTTP is specifically designed for communications between > web server and its client, or applications in that nature.=20 > Although it is possible to add extensions to support PCE > application, it would require a considerable amount of work. > That is not worth of the effort given the much smaller and > narrower application scope of PCE. >=20 > 2) The payload of HTTP messages (both request and response) > is in form of byte stream, which is unstructured comparing=20 > to the PCEP proposal, where the content is structured with >objects. > For the PCE application, the object based format is more=20 > efficient in terms of processing. >=20 > 3) The HTTP does not have unsolicited messages such as = Notification > message and Error message that are defined by PCEP. >=20 > 4) PCE architecture allows a PCE functions as a server but also as > a client communicating with another PCE server. In both cases,=20 > the same protocol is used. PCEP supports this scenario. There > requires some work to make HTTP behavior as such. >=20 >Dean =20 =20 ------_=_NextPart_001_01C5C906.BF1B06D7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
To complement what Zafar just mentionned, = regarding the=20 control plane flavour of PCC-PCE communication, I = would like=20 to highlight the fact that LSRs can act as PCEs, in which case the PCE=20 communication protocol runs directly between LSRs (inter-router = communication).=20
For=20 the sake of illustration, in a multi-area network, ABRs can act as = PCE and=20 cooperate together to compute optimal inter-area paths = (by the=20 way, this is the application at the origin of the PCE = concept...), and=20 this may requires a full mesh of inter-ABR PCE=20 communications. 
This is one of the reasons why the = communication=20 overhead should be minimized and the state machine should remain = light.=20 Another reason being the capability to easily handle bursts of requests = under=20 emergency conditions (e.g. upon link or node failure impacting = a large=20 number of LSPs).
 
PCEP has been designed with=20 this requirement as key=20 driver.
 
It sounds IMHO quite important to take = this=20 point into consideration when selecting the=20 protocol.
 
Regards,
 
JL
 

De : = pce-bounces@lists.ietf.org=20 [mailto:pce-bounces@lists.ietf.org] De la part de Zafar Ali=20 (zali)
Envoy=E9 : mardi 4 octobre 2005 = 18:28
=C0 :=20 dcheng@cisco.com
Cc : = pce@ietf.org
Objet : RE:=20 [Pce] Choosing the PCE protocol

Hi,=20
 
I=20 agree w/ the comments made by Dean. It is also important to realize = that the=20 PCE communication protocol is a control plane protocol, not a = management plane=20 protocol: hence it is of the utmost importance to minimize = communication=20 overhead (see Dean's comment on communication overhead). =20
 
Thanks
 
Regards... Zafar
 
>To: "Adrian Farrel" <adrian = at=20 olddog.co.uk>, <pce at ietf.org>
>Subject: RE: [Pce] = Choosing=20 the PCE protocol
>From: "Dean Cheng \(dcheng\)" <dcheng at=20 cisco.com>
>Date: Mon, 3 Oct 2005 15:30:13 -0700
>Cc: =
>List-archive: <http://www1.ietf.org/pipermai= l/pce>=20
>List-help: <mailto:pce-requ= est@lists.ietf.org?subject=3Dhelp>=20
>List-id: Path Computation Element <pce.lists.ietf.org>=20
>List-post: <mailto:pce@lists.ietf.org>=20
>List-subscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:pce= -request@lists.ietf.org?subject=3Dsubscribe>=20
>List-unsubscribe: <https://www1.ietf.org= /mailman/listinfo/pce>,=20 <mailto:p= ce-request@lists.ietf.org?subject=3Dunsubscribe>=20
>Sender: pce-bounces at lists.ietf.org
>Thread-index:=20 AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q
>Thread-topic: [Pce] = Choosing the=20 PCE protocol=20 =
>
>---------------------------------------------------------= -----------------------
>
>Hi,
>
> =20 I don't think HTTP is a good candidate for the PCE = application
> =20 and here are some weakness one could think of, if it used = for
> =20 PCE application:
>
>    1) The HTTP is=20 specifically designed for communications=20 between
>       web server and its = client,=20 or applications in that nature. =
>      =20 Although it is possible to add extensions to support=20 PCE
>       application, it would = require=20 a considerable amount of = work.
>      =20 That is not worth of the effort given the much smaller=20 and
>       narrower application = scope of=20 PCE.
>
>    2) The payload of HTTP = messages (both=20 request and response)
>       is = in form=20 of byte stream, which is unstructured comparing=20
>       to the PCEP proposal, = where the=20 content is structured=20 with
>objects.
>       For = the PCE=20 application, the object based format is more=20
>       efficient in terms of=20 processing.
>
>    3) The HTTP does not = have=20 unsolicited messages such as=20 Notification
>       message and = Error=20 message that are defined by PCEP.
>
>    = 4) PCE=20 architecture allows a PCE functions as a server but also=20 as
>       a client communicating = with=20 another PCE server. In both cases,=20
>       the same protocol is = used. PCEP=20 supports this scenario. = There
>      =20 requires some work to make HTTP behavior as such.
>=20
>Dean
 
 
------_=_NextPart_001_01C5C906.BF1B06D7-- --===============0043004799== 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 --===============0043004799==-- From pce-bounces@lists.ietf.org Tue Oct 04 13:54:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMr0A-0005ao-8C; Tue, 04 Oct 2005 13:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMr08-0005ai-RM for pce@megatron.ietf.org; Tue, 04 Oct 2005 13:54: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 NAA13537 for ; Tue, 4 Oct 2005 13:54:51 -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 1EMr8q-0002z9-RD for pce@ietf.org; Tue, 04 Oct 2005 14:03:54 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 Oct 2005 10:54:42 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="348155820:sNHT26811974" 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 j94HrO4h029784 for ; Tue, 4 Oct 2005 10:54:40 -0700 (PDT) Received: from xmb-rtp-216.amer.cisco.com ([64.102.31.80]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 13:54:32 -0400 Received: from [192.168.2.3] ([10.86.240.12]) by xmb-rtp-216.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 13:54:31 -0400 Message-ID: <4342C1D6.7070503@cisco.com> Date: Tue, 04 Oct 2005 13:54:30 -0400 From: Anca Zamfir User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Zafar Ali (zali)" Subject: Re: [Pce] Choosing the PCE protocol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 17:54:31.0960 (UTC) FILETIME=[AC6DE180:01C5C90C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 I agree. Also here are some advantages of PCEP: - draft-vasseur-pce-pcep-02.txt meets the PCE requirements as stated in draft-ietf-pce-comm-protocol-gen- reqs-02.txt - It is a lightweight protocol with a simple and clean state machine. - Looks that it is easily extensible for new future requirements (by adding new messages or objects). - It has small number of messages and objects. - Could reuse the mechanisms which have been already defined and deployed in other protocols. - Reuses of TCP for reliable messaging, flow control, security, etc. - Supports solicited and unsolicited communication messages. Cheers, Anca Zafar Ali (zali) wrote: > Hi, > > I agree w/ the comments made by Dean. It is also important to realize > that the PCE communication protocol is a control plane protocol, not a > management plane protocol: hence it is of the utmost importance to > minimize communication overhead (see Dean's comment on communication > overhead). > > Thanks > > Regards... Zafar > > >>To: "Adrian Farrel" , >>Subject: RE: [Pce] Choosing the PCE protocol >>From: "Dean Cheng \(dcheng\)" >>Date: Mon, 3 Oct 2005 15:30:13 -0700 >>Cc: >>List-archive: >>List-help: >>List-id: Path Computation Element >>List-post: >>List-subscribe: , > > > >>List-unsubscribe: , > > > >>Sender: pce-bounces at lists.ietf.org >>Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q >>Thread-topic: [Pce] Choosing the PCE protocol >> >>----------------------------------------------------------------------- > > --------- > >>Hi, >> >> I don't think HTTP is a good candidate for the PCE application >> and here are some weakness one could think of, if it used for >> PCE application: >> >> 1) The HTTP is specifically designed for communications between >> web server and its client, or applications in that nature. >> Although it is possible to add extensions to support PCE >> application, it would require a considerable amount of work. >> That is not worth of the effort given the much smaller and >> narrower application scope of PCE. >> >> 2) The payload of HTTP messages (both request and response) >> is in form of byte stream, which is unstructured comparing >> to the PCEP proposal, where the content is structured with >>objects. >> For the PCE application, the object based format is more >> efficient in terms of processing. >> >> 3) The HTTP does not have unsolicited messages such as Notification >> message and Error message that are defined by PCEP. >> >> 4) PCE architecture allows a PCE functions as a server but also as >> a client communicating with another PCE server. In both cases, >> the same protocol is used. PCEP supports this scenario. There >> requires some work to make HTTP behavior as such. >> >>Dean > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 05 03:14:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3Tz-0000uc-3R; Wed, 05 Oct 2005 03:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN3Tw-0000uX-PN for pce@megatron.ietf.org; Wed, 05 Oct 2005 03:14: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 DAA02643 for ; Wed, 5 Oct 2005 03:14:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN3cl-0001DW-Mz for pce@ietf.org; Wed, 05 Oct 2005 03:23:37 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EN3Tn-000Bsw-Ph; Wed, 05 Oct 2005 07:14:20 +0000 Message-ID: <43437D62.4030107@psg.com> Date: Wed, 05 Oct 2005 09:14:42 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Choosing the PCE protocol References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> <050b01c5c50f$63088050$be849ed9@Puppy> In-Reply-To: <050b01c5c50f$63088050$be849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 one specific comment looking at the APP Area response last August (and hence the first alternative here below) it stated "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." and may thus be interesting to collect valid input from this list on this proposal and send it to the APP Area note: i think since so far the concern is the processing efficiency (even if afaik the PCE requirements did not come with specific numbers in terms of computation delay that would allow comparison with the processing delay of the message to see whether this latter is indeed significant) and some messaging specific to PCC/PCE-PCE communication that may require extensions a last point it may also be important to come up with a clear view on the advantages of each of these solutions and not only their potential drawbacks thanks, - dimitri Adrian Farrel wrote: > All, > > I should have been more careful with my acronyms. > > PCECP is the generic protocol. In other words, what the requirements > describe. The job vacancy we are trying to fill. > > PCEP is JP's (and others) proposed solution. > > Cheers, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Thursday, September 29, 2005 3:27 PM > Subject: [Pce] Choosing the PCE protocol > > > >>Hi, >> >>Three candidate protocols have been brought to my attention for us to >>consider. These are (in no specific order): >>- HTTP >>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>- COPS >> >>I would like to close the nomination period, and move on to select our >>protocol. >> >>The best approach will be if supporters of the candidate protocols >>indicate (briefly) why their proposed protocol is suitable. It would > > also > >>be helpful if they were frank about what the weaknesses of their > > proposal > >>are. >> >>And please - this is not an election, it is an interview process. >> >>Thanks, >>Adrian >> >>PS The reason why JP is keeping quite on this is that he is an author of >>draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not occupying > > the > >>chair during this discussion. >> >> >> >> >>_______________________________________________ >>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 Oct 05 16:11:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbb-0000ZY-Hn; Wed, 05 Oct 2005 16:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBSM-0008Es-G0 for pce@megatron.ietf.org; Wed, 05 Oct 2005 11:45: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 LAA01086 for ; Wed, 5 Oct 2005 11:45:19 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENBbF-0007YH-TG for pce@ietf.org; Wed, 05 Oct 2005 11:54:35 -0400 Received: from du-069-0230.access.clara.net ([217.158.132.230] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1ENBSG-0003jU-Dx; Wed, 05 Oct 2005 16:45:18 +0100 Message-ID: <013801c5c9c4$30c9c630$6a849ed9@Puppy> From: "Adrian Farrel" To: , References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> <050b01c5c50f$63088050$be849ed9@Puppy> <43437D62.4030107@psg.com> Subject: Re: [Pce] Choosing the PCE protocol Date: Wed, 5 Oct 2005 16:45:44 +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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Thanks Dimitri, Picking one specific comment from your mail: > a last point it may also be important to come up with a clear view on > the advantages of each of these solutions and not only their potential > drawbacks Yes. In order to adopt any solution we must be clear that folk will implement it, and underpinning that would be a belief in some quarters that it is a "good" solution. So part of the selection process must be to hear from the supporters of each protocol why they think it is good. To some extent, PCEP has an unfair advantage here because it has a whole I-D in which to express how it meets the PCEP requirements, and can claim that its principal advantage is that it meets those requirements directly. That is why we are taking some time on the list to allow supporters of other options to put their case. That a protocol solution is good because it lacks the defects of another protocol solution is a small (albeit negative-campaigning) point in its favour. It is like my Member of Parliament who told me I should vote for him because he is not from the other party. We should hope for a few more positive comments in support of any proposal. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 05 19:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENIZ9-0001ku-B1; Wed, 05 Oct 2005 19:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENIZ7-0001he-Sy for pce@megatron.ietf.org; Wed, 05 Oct 2005 19:20: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 TAA08892 for ; Wed, 5 Oct 2005 19:20:44 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENIi2-0000fF-37 for pce@ietf.org; Wed, 05 Oct 2005 19:30:04 -0400 Received: from du-069-0054.access.clara.net ([217.158.132.54] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1ENIYn-0000oY-Ij; Thu, 06 Oct 2005 00:20:31 +0100 Message-ID: <020101c5ca03$c8c95ec0$6a849ed9@Puppy> From: "Adrian Farrel" To: "Ash, Gerald R \(Jerry\), ALABS" , References: <9473683187ADC049A855ED2DA739ABCA09FA938E@KCCLUST06EVS1.ugd.att.com> Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Date: Wed, 5 Oct 2005 21:51:15 +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: d8ae4fd88fcaf47c1a71c804d04f413d 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 Jerry and team, A question about section 6.1.16 of this draft. Here it says... Here is the list of generic constraints that MUST be supported: o MPLS-TE and GMPLS generic constraints: - Bandwidth - Affinities inclusion/exclusion - Link, Node, SRLG inclusion/exclusion - Maximum end-to-end delay metrics - Hop Count - Maximum end-to-end TE metric (cost) - Multiple disjoint path computation to allow path protection Correct me if I am wrong, but delay is not a standard link parameter exchanged by the TE IGPs. Instead, we have RFC 3785 that suggests that a network may be operationally configured so that the IGP metric has one meaning, and the TE metric another meaning. Further, it suggests that a use might be to place a delay metric in the IGP metric field. Certainly, therefore, if a network is operated according to RFC 3785 and the IGP metric is interpreted as a delay metric a PCE will understand how to constrain the path computation according to a delay bound. But if the network is operated in any other way, the PCE will not be able to act on the delay constraint. Further, if the network is operated in some other way, the PCC will not be able to request that the path is constrained according to the two metrics advertised by the TE IGP. Wouldn't it be more sensible to require that support of: - Maximum end-to-end IGP metric (cost) - Maximum end-to-end TE metric (cost) ...and add a note that if the network is operated according to [RFC3785] the IGP metric may be used to indicate a per link delay metric. Cheers, Adrian ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: Sent: Thursday, September 22, 2005 1:01 PM Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-02.txt. The changes include those listed on slide 3 of the Paris meeting: http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm and responses to Adrian's comprehensive review sent to the design team (these are all editorial comments). The most substantive changes are the inclusion of "boundary number" thresholds in Section 6.1.15 (Scalability). Dimitri suggested back in July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html that boundary numbers be specified, and it was agreed at IETF-63 to include 'order-of-magnitude' values in the updated draft. This has been done in the submitted update, and JP requested comments on this Section in his posting 2 days ago http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html. Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Oct 06 16:22:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENc9s-000423-Dq; Thu, 06 Oct 2005 16:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENc9q-0003yO-B2 for pce@megatron.ietf.org; Thu, 06 Oct 2005 16:16: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 QAA04529 for ; Thu, 6 Oct 2005 16:15:59 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcIy-0002sk-GJ for pce@ietf.org; Thu, 06 Oct 2005 16:25:29 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 9CECB180FF; Thu, 6 Oct 2005 16:15:40 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 93063AFA4; Thu, 6 Oct 2005 16:15:36 -0400 (EDT) Message-Id: <6.2.5.6.2.20051006160733.056a8be8@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Oct 2005 16:15:40 -0400 To: "JP Vasseur" , "Adrian Farrel" , gash@att.com From: Lou Berger Subject: Re: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 JP, Adrian, Gerry, I looks like most of my comments on Policy were NOT integrated into this version. These comments applied, even with the notion that there would be an additional PCE Policy Architecture document. What was your thinking here? Much thanks, Lou At 11:43 AM 9/27/2005, JP Vasseur wrote: >Hi, > >draft-ietf-pce-architecture-02.txt has been edited addressing the >list of open issues and is now ready for working group last call. > >This email initiates a working group last call on draft-ietf-pce- >architecture-02.txt. The last call will end on Tuesday 11th October >at noon EST. > >Please send your comments to the mailing list and copy the chairs. > >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 Fri Oct 07 08:33:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrQ7-0007VT-1y; Fri, 07 Oct 2005 08:33:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrQ6-0007U8-41 for pce@megatron.ietf.org; Fri, 07 Oct 2005 08:33: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 IAA14956 for ; Fri, 7 Oct 2005 08:33:48 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENrZK-00040r-7d for pce@ietf.org; Fri, 07 Oct 2005 08:43:26 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id 5D428180FF; Fri, 7 Oct 2005 08:33:36 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 7 Oct 2005 08:33:36 -0400 (EDT) Message-ID: <3056.68.100.80.11.1128688416.squirrel@webmail.movaz.com> In-Reply-To: <020101c5ca03$c8c95ec0$6a849ed9@Puppy> References: <9473683187ADC049A855ED2DA739ABCA09FA938E@KCCLUST06EVS1.ugd.att.com> <020101c5ca03$c8c95ec0$6a849ed9@Puppy> Date: Fri, 7 Oct 2005 08:33:36 -0400 (EDT) Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt To: "Adrian Farrel" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 8bit Cc: Gerald , pce@ietf.org, Ash@movaz.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 Adrian, What you are suggesting is reasonable and does not require changes in IGP-TE. However, it is too general. Why not to consider introducing more TE LINK sub-TLVs, for example, metric associated with delay introduced by the link? I personally believe that *all* pce constraints should be bound by evaluating formulas to corresponding TE advertising, so that if you need to support a new PCE constraint (whether it is a link type or path type constraint) network TE links should advertise appropriate piece of information. This is the only way how PCE can act on the constraint without guessing on TE metric values. Cheers, Igor > Thanks Jerry and team, > > A question about section 6.1.16 of this draft. > > Here it says... > > Here is the list of generic constraints that MUST be supported: > > o MPLS-TE and GMPLS generic constraints: > - Bandwidth > - Affinities inclusion/exclusion > - Link, Node, SRLG inclusion/exclusion > - Maximum end-to-end delay metrics > - Hop Count > - Maximum end-to-end TE metric (cost) > - Multiple disjoint path computation to allow path protection > > Correct me if I am wrong, but delay is not a standard link parameter > exchanged by the TE IGPs. Instead, we have RFC 3785 that suggests that a > network may be operationally configured so that the IGP metric has one > meaning, and the TE metric another meaning. Further, it suggests that a > use might be to place a delay metric in the IGP metric field. > > Certainly, therefore, if a network is operated according to RFC 3785 and > the IGP metric is interpreted as a delay metric a PCE will understand how > to constrain the path computation according to a delay bound. But if the > network is operated in any other way, the PCE will not be able to act on > the delay constraint. Further, if the network is operated in some other > way, the PCC will not be able to request that the path is constrained > according to the two metrics advertised by the TE IGP. > > Wouldn't it be more sensible to require that support of: > - Maximum end-to-end IGP metric (cost) > - Maximum end-to-end TE metric (cost) > > ...and add a note that if the network is operated according to [RFC3785] > the IGP metric may be used to indicate a per link delay metric. > > Cheers, > Adrian > ----- Original Message ----- > From: "Ash, Gerald R (Jerry), ALABS" > To: > Sent: Thursday, September 22, 2005 1:01 PM > Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt > > > Hi All, > > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req > s-02.txt. > > The changes include those listed on slide 3 of the Paris meeting: > http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm > and responses to Adrian's comprehensive review sent to the design team > (these are all editorial comments). > > The most substantive changes are the inclusion of "boundary number" > thresholds in Section 6.1.15 (Scalability). Dimitri suggested back in > July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html > that boundary numbers be specified, and it was agreed at IETF-63 to > include 'order-of-magnitude' values in the updated draft. This has been > done in the submitted update, and JP requested comments on this Section > in his posting 2 days ago > http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html. > > Our objective is to start a WG last call soon. We look forward to your > review and comments. > > Thanks, > Regards, > Jerry > > > _______________________________________________ > 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 Oct 07 11:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENuEz-0007TK-24; Fri, 07 Oct 2005 11:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENuEx-0007Q9-JL for pce@megatron.ietf.org; Fri, 07 Oct 2005 11:34: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 LAA25848 for ; Fri, 7 Oct 2005 11:34:28 -0400 (EDT) Received: from c158129.vh.plala.or.jp ([210.150.158.129] helo=mvs1.plala.or.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENuOC-0003wq-AP for pce@ietf.org; Fri, 07 Oct 2005 11:44:09 -0400 Received: from [65.213.193.40] by mvs1.plala.or.jp with ESMTP id <20051007153409.HQOX5861.mvs1.plala.or.jp@[65.213.193.40]>; Sat, 8 Oct 2005 00:34:09 +0900 Date: Sat, 08 Oct 2005 00:34:03 +0900 From: Eiji Oki To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: Re: [Pce] Choosing the PCE protocol In-Reply-To: References: Message-Id: <20051008001506.64D3.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Hi all, I agree with Jean-Louis. PCE must handle a large number of computation requests in a real time manner even in a large network with a bursty traffic condition such as network failure or congestion triggers. To perform this, the PCE communication protocol overhead must be light. It is important to consider this criteria when we choose the PCE protocol. As PCEP is defined to meet the PCE protocol requirements, it minimizes overheads as much as possible. Thank you. Eiji On Tue, 4 Oct 2005 19:12:05 +0200 "LE ROUX Jean-Louis RD-CORE-LAN" wrote: > Hi all, > > To complement what Zafar just mentionned, regarding the control plane flavour of PCC-PCE communication, I would like to highlight the fact that LSRs can act as PCEs, in which case the PCE communication protocol runs directly between LSRs (inter-router communication). > For the sake of illustration, in a multi-area network, ABRs can act as PCE and cooperate together to compute optimal inter-area paths (by the way, this is the application at the origin of the PCE concept...), and this may requires a full mesh of inter-ABR PCE communications. > This is one of the reasons why the communication overhead should be minimized and the state machine should remain light. Another reason being the capability to easily handle bursts of requests under emergency conditions (e.g. upon link or node failure impacting a large number of LSPs). > > PCEP has been designed with this requirement as key driver. > > It sounds IMHO quite important to take this point into consideration when selecting the protocol. > > Regards, > > JL > > > > ________________________________ > > De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De la part de Zafar Ali (zali) > Envoy$Bq(B: mardi 4 octobre 2005 18:28 > $B%?(B : dcheng@cisco.com > Cc : pce@ietf.org > Objet : RE: [Pce] Choosing the PCE protocol > > > Hi, > > I agree w/ the comments made by Dean. It is also important to realize that the PCE communication protocol is a control plane protocol, not a management plane protocol: hence it is of the utmost importance to minimize communication overhead (see Dean's comment on communication overhead). > > Thanks > > Regards... Zafar > > >To: "Adrian Farrel" , > >Subject: RE: [Pce] Choosing the PCE protocol > >From: "Dean Cheng \(dcheng\)" > >Date: Mon, 3 Oct 2005 15:30:13 -0700 > >Cc: > >List-archive: > >List-help: > >List-id: Path Computation Element > >List-post: > >List-subscribe: , > >List-unsubscribe: , > >Sender: pce-bounces at lists.ietf.org > >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q > >Thread-topic: [Pce] Choosing the PCE protocol > > > >-------------------------------------------------------------------------------- > > > >Hi, > > > > I don't think HTTP is a good candidate for the PCE application > > and here are some weakness one could think of, if it used for > > PCE application: > > > > 1) The HTTP is specifically designed for communications between > > web server and its client, or applications in that nature. > > Although it is possible to add extensions to support PCE > > application, it would require a considerable amount of work. > > That is not worth of the effort given the much smaller and > > narrower application scope of PCE. > > > > 2) The payload of HTTP messages (both request and response) > > is in form of byte stream, which is unstructured comparing > > to the PCEP proposal, where the content is structured with > >objects. > > For the PCE application, the object based format is more > > efficient in terms of processing. > > > > 3) The HTTP does not have unsolicited messages such as Notification > > message and Error message that are defined by PCEP. > > > > 4) PCE architecture allows a PCE functions as a server but also as > > a client communicating with another PCE server. In both cases, > > the same protocol is used. PCEP supports this scenario. There > > requires some work to make HTTP behavior as such. > > > >Dean > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 07 12:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvP9-00037S-Im; Fri, 07 Oct 2005 12:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvP6-00037N-J9 for pce@megatron.ietf.org; Fri, 07 Oct 2005 12:49:05 -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 MAA29710 for ; Fri, 7 Oct 2005 12:49:01 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENvYP-00073G-Hg for pce@ietf.org; Fri, 07 Oct 2005 12:58:42 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id A246D2E7E6; Fri, 7 Oct 2005 12:48:53 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 7 Oct 2005 12:48:53 -0400 (EDT) Message-ID: <3271.68.100.80.11.1128703733.squirrel@webmail.movaz.com> In-Reply-To: <4ABC6DE5-0FE4-4C8E-8EB6-0586289BAFFC@cisco.com> References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> <4ABC6DE5-0FE4-4C8E-8EB6-0586289BAFFC@cisco.com> Date: Fri, 7 Oct 2005 12:48:53 -0400 (EDT) Subject: Re: [Pce] Choosing the PCE protocol To: "JP Vasseur" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 8bit 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, My major problems with the PCEP: a) inability to introduce new constraints, diversities, their relaxation strategies, optimization criterias, etc. without modifying the protocol; b) inability to convey policies Igor > Hi, > > First of all, we would like to explain a bit further the process that > we followed to come up with the proposed PCEP protocol: > > We started by evaluating existing protocols (such as COPS, HTTP/XML + > others) to see whether we could meet the PCE requirements by means of > minor extensions (without negative impact on the protocol). > Considering the PCE WG's specific requirements, we came to the > conclusion that a new protocol was required and no existing protocol > could be naturally and efficiently extended to meet such > requirements. Furthermore, we did not want to have to use unneeded > features/functionalities that were present in existing protocols and > that have been designed for other purposes. > > Now to answer Adrian's question: > > Thus, we started to work on a new protocol (PCEP) for which we have > received so far quite a few comments which have been incorporated in > the latest revision (rev -02). Here are the following PCEP's > characteristics: > - Fully meets the PCE requirements spelled out in the PCE > communication requirement document (draft-ietf-pce-comm-protocol-gen- > reqs-02.txt) -> this is > detailed in Appendix A of the draft, > - Very lightweight protocol w/o complex state machinery, > - Easily extensible by adding new messages or objects should we > have to address new requirements in the future, > - Limited number of messages and objects (actually there are > several applications that would require the implementation a very > limited subset of objects) > - Maximum reuse of mechanisms which have already been defined > and deployed in other protocols (no need to re-invent the wheel !). > - Reuse of TCP for transport thus providing reliable messaging, > flow control, security, ... > - Support of solicited and unsolicited communication messages > - ... > > Note that implementers have expressed interest in such solution. > > Thanks. > > JP, Jean-Louis, Eiji, Alia, Arthi and Andrew. > > On Sep 29, 2005, at 10:27 AM, Adrian Farrel wrote: > >> Hi, >> >> Three candidate protocols have been brought to my attention for us to >> consider. These are (in no specific order): >> - HTTP >> - PCECP (as draft-vasseur-pce-pcep-02.txt) >> - COPS >> >> I would like to close the nomination period, and move on to select our >> protocol. >> >> The best approach will be if supporters of the candidate protocols >> indicate (briefly) why their proposed protocol is suitable. It >> would also >> be helpful if they were frank about what the weaknesses of their >> proposal >> are. >> >> And please - this is not an election, it is an interview process. >> >> Thanks, >> Adrian >> >> PS The reason why JP is keeping quite on this is that he is an >> author of >> draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not >> occupying the >> chair during this discussion. >> >> >> >> >> _______________________________________________ >> 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 Fri Oct 07 13:04:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvdY-00071k-HY; Fri, 07 Oct 2005 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvdV-0006zf-SE for pce@megatron.ietf.org; Fri, 07 Oct 2005 13:03: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 NAA00428 for ; Fri, 7 Oct 2005 13:03:54 -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 1ENvmo-0007bu-2U for pce@ietf.org; Fri, 07 Oct 2005 13:13:36 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2005 10:03:29 -0700 X-IronPort-AV: i="3.97,187,1125903600"; d="scan'208"; a="349426443:sNHT46739136040" 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 j97H2i53022327; Fri, 7 Oct 2005 10:03:26 -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, 7 Oct 2005 13:03:16 -0400 Received: from [161.44.70.230] ([161.44.70.230]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 13:03:16 -0400 In-Reply-To: <3271.68.100.80.11.1128703733.squirrel@webmail.movaz.com> References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> <4ABC6DE5-0FE4-4C8E-8EB6-0586289BAFFC@cisco.com> <3271.68.100.80.11.1128703733.squirrel@webmail.movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Choosing the PCE protocol Date: Fri, 7 Oct 2005 13:03:35 -0400 To: ibryskin@movaz.com X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 07 Oct 2005 17:03:16.0045 (UTC) FILETIME=[0247BFD0:01C5CB61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Hi Igor, On Oct 7, 2005, at 12:48 PM, ibryskin@movaz.com wrote: > Hi, > > My major problems with the PCEP: > > a) inability to introduce new constraints, diversities, their > relaxation > strategies, optimization criterias, etc. without modifying the > protocol; > > b) inability to convey policies > Thanks for your feed-back. Actually this could be easily handled by encoding your optimization criterias, policies, ... within a opaque Object: we had some discussion about this. There are many other protocols adopting a similar approach. The rest of the machinery, state machine of PCEP could be entirely re-used (synchronized requests, unsolicited notifications, negative replies, ...). Thanks. JP. > Igor > > > >> Hi, >> >> First of all, we would like to explain a bit further the process that >> we followed to come up with the proposed PCEP protocol: >> >> We started by evaluating existing protocols (such as COPS, HTTP/XML + >> others) to see whether we could meet the PCE requirements by means of >> minor extensions (without negative impact on the protocol). >> Considering the PCE WG's specific requirements, we came to the >> conclusion that a new protocol was required and no existing protocol >> could be naturally and efficiently extended to meet such >> requirements. Furthermore, we did not want to have to use unneeded >> features/functionalities that were present in existing protocols and >> that have been designed for other purposes. >> >> Now to answer Adrian's question: >> >> Thus, we started to work on a new protocol (PCEP) for which we have >> received so far quite a few comments which have been incorporated in >> the latest revision (rev -02). Here are the following PCEP's >> characteristics: >> - Fully meets the PCE requirements spelled out in the PCE >> communication requirement document (draft-ietf-pce-comm-protocol-gen- >> reqs-02.txt) -> this is >> detailed in Appendix A of the draft, >> - Very lightweight protocol w/o complex state machinery, >> - Easily extensible by adding new messages or objects should we >> have to address new requirements in the future, >> - Limited number of messages and objects (actually there are >> several applications that would require the implementation a very >> limited subset of objects) >> - Maximum reuse of mechanisms which have already been defined >> and deployed in other protocols (no need to re-invent the wheel !). >> - Reuse of TCP for transport thus providing reliable messaging, >> flow control, security, ... >> - Support of solicited and unsolicited communication messages >> - ... >> >> Note that implementers have expressed interest in such solution. >> >> Thanks. >> >> JP, Jean-Louis, Eiji, Alia, Arthi and Andrew. >> >> On Sep 29, 2005, at 10:27 AM, Adrian Farrel wrote: >> >> >>> Hi, >>> >>> Three candidate protocols have been brought to my attention for >>> us to >>> consider. These are (in no specific order): >>> - HTTP >>> - PCECP (as draft-vasseur-pce-pcep-02.txt) >>> - COPS >>> >>> I would like to close the nomination period, and move on to >>> select our >>> protocol. >>> >>> The best approach will be if supporters of the candidate protocols >>> indicate (briefly) why their proposed protocol is suitable. It >>> would also >>> be helpful if they were frank about what the weaknesses of their >>> proposal >>> are. >>> >>> And please - this is not an election, it is an interview process. >>> >>> Thanks, >>> Adrian >>> >>> PS The reason why JP is keeping quite on this is that he is an >>> author of >>> draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not >>> occupying the >>> chair during this discussion. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Fri Oct 07 13:04:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENveF-000787-Aa; Fri, 07 Oct 2005 13:04:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENveC-000782-Jn for pce@megatron.ietf.org; Fri, 07 Oct 2005 13:04:40 -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 NAA00508 for ; Fri, 7 Oct 2005 13:04:37 -0400 (EDT) From: ibryskin@movaz.com Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENvnX-0007dl-0G for pce@ietf.org; Fri, 07 Oct 2005 13:14:19 -0400 Received: by jera.movaz.com (Postfix, from userid 30) id 0DFCD1722A; Fri, 7 Oct 2005 13:04:31 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 7 Oct 2005 13:04:31 -0400 (EDT) Message-ID: <3275.68.100.80.11.1128704671.squirrel@webmail.movaz.com> In-Reply-To: <70BC84B185C3EE448EDB7AB8956D3B0EB27654@xmb-sjc-234.amer.cisco.com> References: <70BC84B185C3EE448EDB7AB8956D3B0EB27654@xmb-sjc-234.amer.cisco.com> Date: Fri, 7 Oct 2005 13:04:31 -0400 (EDT) Subject: RE: [Pce] Choosing the PCE protocol To: "Dean Cheng (dcheng)" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 8bit 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 Dean, See my comments in-line. Igor > As for COPS, its application environment is somewhat similar > to that of PCE but has some problems (if used for PCE applciation) > due to much optimization around its specifics such as: > > 1) The PEP (client) is the one required to initiate the > connection with a PDP (server). Whereas for PCE > application, either PCE (server) or PCC may initiate > the connection. IB>> Why would a PCE want to initiate a connection with a PCC? > > 2) There requires a synchronization between PEP and PDP for > the policy application with states maintained on both places. > For PCE application, the PCE server is only required to > perform a one-time service for each LSP, without the need > maintain any subsequent states. IB>> Even if all this is true, why is it a big deal? > > 3) It requires some work to support a PDP functions as a PEP > and communicates with another PDP. PCEP supports this model > fully. IB>> Functions of PDP and PEP are orthogonal and surely could be physically co-located > > 4) COPS is a server-client protocol, but with code point > heavily dedicated for a specific application. It does not > serve general purpose if any, and to support PCE application, > there would be a large number of extensions, thus defeating > the purpose of reusage. IB>> PCIM is designed to be easily expanded for application (read PCE) specific needs Igor > > As a result, I'd favor PECP as a PCE-specific protocol; it is much > cleaner and also light-weighted. > > Dean > >>-----Original Message----- >>From: pce-bounces@lists.ietf.org >>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>Sent: Monday, October 03, 2005 3:30 PM >>To: Adrian Farrel; pce@ietf.org >>Subject: RE: [Pce] Choosing the PCE protocol >> >>Hi, >> >> I don't think HTTP is a good candidate for the PCE application >> and here are some weakness one could think of, if it used for >> PCE application: >> >> 1) The HTTP is specifically designed for communications between >> web server and its client, or applications in that nature. >> Although it is possible to add extensions to support PCE >> application, it would require a considerable amount of work. >> That is not worth of the effort given the much smaller and >> narrower application scope of PCE. >> >> 2) The payload of HTTP messages (both request and response) >> is in form of byte stream, which is unstructured comparing >> to the PCEP proposal, where the content is structured >>with objects. >> For the PCE application, the object based format is more >> efficient in terms of processing. >> >> 3) The HTTP does not have unsolicited messages such as Notification >> message and Error message that are defined by PCEP. >> >> 4) PCE architecture allows a PCE functions as a server but also as >> a client communicating with another PCE server. In both cases, >> the same protocol is used. PCEP supports this scenario. There >> requires some work to make HTTP behavior as such. >> >>Dean >> >>>-----Original Message----- >>>From: pce-bounces@lists.ietf.org >>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>>Sent: Thursday, September 29, 2005 7:27 AM >>>To: pce@ietf.org >>>Subject: [Pce] Choosing the PCE protocol >>> >>>Hi, >>> >>>Three candidate protocols have been brought to my attention for us to >>>consider. These are (in no specific order): >>>- HTTP >>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>- COPS >>> >>>I would like to close the nomination period, and move on to >>select our >>>protocol. >>> >>>The best approach will be if supporters of the candidate protocols >>>indicate (briefly) why their proposed protocol is suitable. It would >>>also be helpful if they were frank about what the weaknesses of their >>>proposal are. >>> >>>And please - this is not an election, it is an interview process. >>> >>>Thanks, >>>Adrian >>> >>>PS The reason why JP is keeping quite on this is that he is an author >>>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not >>>occupying the chair during this discussion. >>> >>> >>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >> >>_______________________________________________ >>Pce mailing list >>Pce@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/pce >> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 07 13:31:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENw3z-00069o-JD; Fri, 07 Oct 2005 13:31:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENw3x-00069h-Si for pce@megatron.ietf.org; Fri, 07 Oct 2005 13:31: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 NAA01742 for ; Fri, 7 Oct 2005 13:31:14 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwDA-0000BI-08 for pce@ietf.org; Fri, 07 Oct 2005 13:40:56 -0400 Received: from zhang-D600.sa.infonet.com (sfjl84.us.info.net [204.79.139.84] (may be forged)) by sa.infonet.com with ESMTP id j97HUtt8023839 for ; Fri, 7 Oct 2005 17:30:55 GMT Message-Id: <6.2.1.2.2.20051007094046.046d4a90@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 07 Oct 2005 10:30:42 -0700 To: From: raymond zhang Subject: RE: [Pce] Choosing the PCE protocol 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: f49c97ce49302a02285a2d36a99eef8c 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 all, For SPs with both multi-area/level, the additional PCE-PCE peers across=20 AS-boundaries would further add to the amount of inter-PCE=20 communications. I'd agree with JL's comments below that control plane=20 protocol for PCC/PCE and PCE/PCE needs to be lightweight and optimized to=20 this requirement. PCEP is designed for this purpose. Regards, Raymond At 10:12 AM 10/4/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C5C906.BF1B06D7" > >Hi all, > >To complement what Zafar just mentionned, regarding the control plane=20 >flavour of PCC-PCE communication, I would like to highlight the fact that= =20 >LSRs can act as PCEs, in which case the PCE communication protocol runs=20 >directly between LSRs (inter-router communication). >For the sake of illustration, in a multi-area network, ABRs can act as PCE= =20 >and cooperate together to compute optimal inter-area paths (by the way,=20 >this is the application at the origin of the PCE concept...), and this may= =20 >requires a full mesh of inter-ABR PCE communications. >This is one of the reasons why the communication overhead should be=20 >minimized and the state machine should remain light. Another reason being= =20 >the capability to easily handle bursts of requests under emergency=20 >conditions (e.g. upon link or node failure impacting a large number of= LSPs). > >PCEP has been designed with this requirement as key driver. > >It sounds IMHO quite important to take this point into consideration when= =20 >selecting the protocol. > >Regards, > >JL > > > >---------- >De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De la= =20 >part de Zafar Ali (zali) >Envoy=E9 : mardi 4 octobre 2005 18:28 >=C0 : dcheng@cisco.com >Cc : pce@ietf.org >Objet : RE: [Pce] Choosing the PCE protocol > >Hi, > >I agree w/ the comments made by Dean. It is also important to realize that= =20 >the PCE communication protocol is a control plane protocol, not a=20 >management plane protocol: hence it is of the utmost importance to=20 >minimize communication overhead (see Dean's comment on communication=20 >overhead). > >Thanks > >Regards... Zafar > > >To: "Adrian Farrel" , > >Subject: RE: [Pce] Choosing the PCE protocol > >From: "Dean Cheng \(dcheng\)" > >Date: Mon, 3 Oct 2005 15:30:13 -0700 > >Cc: > >List-archive:=20 > <http://www1.ietf.org/pipermail/pce> > >List-help:=20 >= <mailto:pce-request@lists= .ietf.org?subject=3Dhelp>=20 > > >List-id: Path Computation Element > >List-post: <mailto:pce@lists.ietf.org> > >List-subscribe:=20 >= <https://www1.ietf.org/mailman/= listinfo/pce>,=20 > > >List-unsubscribe:=20 >= <https://www1.ietf.org/mailman/= listinfo/pce>,=20 > > >Sender: pce-bounces at lists.ietf.org > >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q > >Thread-topic: [Pce] Choosing the PCE protocol > > > >-------------------------------------------------------------------------= =20 > ------- > > > >Hi, > > > > I don't think HTTP is a good candidate for the PCE application > > and here are some weakness one could think of, if it used for > > PCE application: > > > > 1) The HTTP is specifically designed for communications between > > web server and its client, or applications in that nature. > > Although it is possible to add extensions to support PCE > > application, it would require a considerable amount of work. > > That is not worth of the effort given the much smaller and > > narrower application scope of PCE. > > > > 2) The payload of HTTP messages (both request and response) > > is in form of byte stream, which is unstructured comparing > > to the PCEP proposal, where the content is structured with > >objects. > > For the PCE application, the object based format is more > > efficient in terms of processing. > > > > 3) The HTTP does not have unsolicited messages such as Notification > > message and Error message that are defined by PCEP. > > > > 4) PCE architecture allows a PCE functions as a server but also as > > a client communicating with another PCE server. In both cases, > > the same protocol is used. PCEP supports this scenario. There > > requires some work to make HTTP behavior as such. > > > >Dean > > > >_______________________________________________ >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 Oct 07 14:12:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwhe-0001U0-Dt; Fri, 07 Oct 2005 14:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwhd-0001Ts-3n for pce@megatron.ietf.org; Fri, 07 Oct 2005 14:12: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 OAA03685 for ; Fri, 7 Oct 2005 14:12:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwqy-0001pM-4N for pce@ietf.org; Fri, 07 Oct 2005 14:21:56 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENwhb-0001yt-Ae; Fri, 07 Oct 2005 18:12:15 +0000 Message-ID: <4346BA93.5050201@psg.com> Date: Fri, 07 Oct 2005 20:12:35 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ibryskin@movaz.com, "Dean Cheng (dcheng)" Subject: Re: [Pce] Choosing the PCE protocol References: <70BC84B185C3EE448EDB7AB8956D3B0EB27654@xmb-sjc-234.amer.cisco.com> <3275.68.100.80.11.1128704671.squirrel@webmail.movaz.com> In-Reply-To: <3275.68.100.80.11.1128704671.squirrel@webmail.movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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 ibryskin@movaz.com wrote: > Dean, > > See my comments in-line. > > Igor > >>As for COPS, its application environment is somewhat similar >>to that of PCE but has some problems (if used for PCE applciation) >>due to much optimization around its specifics such as: >> >> 1) The PEP (client) is the one required to initiate the >> connection with a PDP (server). Whereas for PCE >> application, either PCE (server) or PCC may initiate >> the connection. > > IB>> Why would a PCE want to initiate a connection with a PCC? more generally i am not sure to understand why "PC" elements would initiate connections ... are they not meant to "compute" paths ? >> 2) There requires a synchronization between PEP and PDP for >> the policy application with states maintained on both places. >> For PCE application, the PCE server is only required to >> perform a one-time service for each LSP, without the need >> maintain any subsequent states. > > IB>> Even if all this is true, why is it a big deal? there is also a need to discuss what are these states and what they represent in the context of this application (PCE) before claiming that they are impacting one implementation and not the other >> 3) It requires some work to support a PDP functions as a PEP >> and communicates with another PDP. PCEP supports this model >> fully. > > IB>> Functions of PDP and PEP are orthogonal and surely could be > physically co-located indeed >> 4) COPS is a server-client protocol, but with code point >> heavily dedicated for a specific application. It does not >> serve general purpose if any, and to support PCE application, >> there would be a large number of extensions, thus defeating >> the purpose of reusage. > > IB>> PCIM is designed to be easily expanded for application (read PCE) > specific needs > > Igor > >>As a result, I'd favor PECP as a PCE-specific protocol; it is much >>cleaner and also light-weighted. there is very little material/argumentation as part of this e-mail that allows to come to such conclusion by the way i would like to ask what is meant here by "cleaner" ? and how it is possible to come to the conclusion that PCEP is lightweighted by the argumentation provided here above ? >>Dean >> >> >>>-----Original Message----- >>>From: pce-bounces@lists.ietf.org >>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>>Sent: Monday, October 03, 2005 3:30 PM >>>To: Adrian Farrel; pce@ietf.org >>>Subject: RE: [Pce] Choosing the PCE protocol >>> >>>Hi, >>> >>> I don't think HTTP is a good candidate for the PCE application >>> and here are some weakness one could think of, if it used for >>> PCE application: >>> >>> 1) The HTTP is specifically designed for communications between >>> web server and its client, or applications in that nature. >>> Although it is possible to add extensions to support PCE >>> application, it would require a considerable amount of work. >>> That is not worth of the effort given the much smaller and >>> narrower application scope of PCE. >>> >>> 2) The payload of HTTP messages (both request and response) >>> is in form of byte stream, which is unstructured comparing >>> to the PCEP proposal, where the content is structured >>>with objects. >>> For the PCE application, the object based format is more >>> efficient in terms of processing. >>> >>> 3) The HTTP does not have unsolicited messages such as Notification >>> message and Error message that are defined by PCEP. >>> >>> 4) PCE architecture allows a PCE functions as a server but also as >>> a client communicating with another PCE server. In both cases, >>> the same protocol is used. PCEP supports this scenario. There >>> requires some work to make HTTP behavior as such. >>> >>>Dean >>> >>> >>>>-----Original Message----- >>>>From: pce-bounces@lists.ietf.org >>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>>>Sent: Thursday, September 29, 2005 7:27 AM >>>>To: pce@ietf.org >>>>Subject: [Pce] Choosing the PCE protocol >>>> >>>>Hi, >>>> >>>>Three candidate protocols have been brought to my attention for us to >>>>consider. These are (in no specific order): >>>>- HTTP >>>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>>- COPS >>>> >>>>I would like to close the nomination period, and move on to >>> >>>select our >>> >>>>protocol. >>>> >>>>The best approach will be if supporters of the candidate protocols >>>>indicate (briefly) why their proposed protocol is suitable. It would >>>>also be helpful if they were frank about what the weaknesses of their >>>>proposal are. >>>> >>>>And please - this is not an election, it is an interview process. >>>> >>>>Thanks, >>>>Adrian >>>> >>>>PS The reason why JP is keeping quite on this is that he is an author >>>>of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not >>>>occupying the chair during this discussion. >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Pce mailing list >>>>Pce@lists.ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >> >>_______________________________________________ >>Pce mailing list >>Pce@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/pce >> >> > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 07 14:31:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENx01-0006ym-FL; Fri, 07 Oct 2005 14:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwzz-0006yN-Cp for pce@megatron.ietf.org; Fri, 07 Oct 2005 14:31:15 -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 OAA04715 for ; Fri, 7 Oct 2005 14:31:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENx9K-0002e3-Dt for pce@ietf.org; Fri, 07 Oct 2005 14:40:54 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ENwzx-0003Io-2J; Fri, 07 Oct 2005 18:31:13 +0000 Message-ID: <4346BF06.9020302@psg.com> Date: Fri, 07 Oct 2005 20:31:34 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: raymond zhang Subject: Re: [Pce] Choosing the PCE protocol References: <6.2.1.2.2.20051007094046.046d4a90@sa.infonet.com> In-Reply-To: <6.2.1.2.2.20051007094046.046d4a90@sa.infonet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA04715 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, see in-line - would you please clarify the following points ? raymond zhang wrote: > Hi all, >=20 > For SPs with both multi-area/level, the additional PCE-PCE peers across= =20 > AS-boundaries would further add to the amount of inter-PCE=20 > communications. =20 not sure to understand what you mean here - "who adds what to what" ? > I'd agree with JL's comments below that control plane=20 > protocol for PCC/PCE and PCE/PCE needs to be lightweight and optimized=20 > to this requirement. PCEP is designed for this purpose. i would propose that "light" vs "heavy"-weight gets exactly defined in=20 the present context b/f using related arguments when discussing pro/cons=20 of specific implementation(s) also what is meant with "optimized to this requirement" (i guess you=20 mean here "optimized to be ligthweight") ? thanks, - dimitri. > Regards, > Raymond >=20 > At 10:12 AM 10/4/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 >> Content-class: urn:content-classes:message >> Content-Type: multipart/alternative; >> boundary=3D"----_=3D_NextPart_001_01C5C906.BF1B06D7" >> >> Hi all, >> >> To complement what Zafar just mentionned, regarding the control plane=20 >> flavour of PCC-PCE communication, I would like to highlight the fact=20 >> that LSRs can act as PCEs, in which case the PCE communication=20 >> protocol runs directly between LSRs (inter-router communication). >> For the sake of illustration, in a multi-area network, ABRs can act as= =20 >> PCE and cooperate together to compute optimal inter-area paths (by the= =20 >> way, this is the application at the origin of the PCE concept...), and= =20 >> this may requires a full mesh of inter-ABR PCE communications. >> This is one of the reasons why the communication overhead should be=20 >> minimized and the state machine should remain light. Another reason=20 >> being the capability to easily handle bursts of requests under=20 >> emergency conditions (e.g. upon link or node failure impacting a large= =20 >> number of LSPs). >> >> PCEP has been designed with this requirement as key driver. >> >> It sounds IMHO quite important to take this point into consideration=20 >> when selecting the protocol. >> >> Regards, >> >> JL >> >> >> >> ---------- >> De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De= =20 >> la part de Zafar Ali (zali) >> Envoy=E9 : mardi 4 octobre 2005 18:28 >> =C0 : dcheng@cisco.com >> Cc : pce@ietf.org >> Objet : RE: [Pce] Choosing the PCE protocol >> >> Hi, >> >> I agree w/ the comments made by Dean. It is also important to realize=20 >> that the PCE communication protocol is a control plane protocol, not a= =20 >> management plane protocol: hence it is of the utmost importance to=20 >> minimize communication overhead (see Dean's comment on communication=20 >> overhead). >> >> Thanks >> >> Regards... Zafar >> >> >To: "Adrian Farrel" , >> >Subject: RE: [Pce] Choosing the PCE protocol >> >From: "Dean Cheng \(dcheng\)" >> >Date: Mon, 3 Oct 2005 15:30:13 -0700 >> >Cc: >> >List-archive:=20 >> <http://www1.ietf.org/pipermail/pc= e> >> >List-help:=20 >> <mailto:pce-request@= lists.ietf.org?subject=3Dhelp>=20 >> >> >List-id: Path Computation Element >> >List-post: <mailto:pce@lists.ietf.org> >> >List-subscribe:=20 >> <https://www1.ietf.org/mai= lman/listinfo/pce>,=20 >> >> >List-unsubscribe:=20 >> <https://www1.ietf.org/mai= lman/listinfo/pce>,=20 >> >> >Sender: pce-bounces at lists.ietf.org >> >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q >> >Thread-topic: [Pce] Choosing the PCE protocol >> > >> >---------------------------------------------------------------------= ----=20 >> ------- >> > >> >Hi, >> > >> > I don't think HTTP is a good candidate for the PCE application >> > and here are some weakness one could think of, if it used for >> > PCE application: >> > >> > 1) The HTTP is specifically designed for communications between >> > web server and its client, or applications in that nature. >> > Although it is possible to add extensions to support PCE >> > application, it would require a considerable amount of work. >> > That is not worth of the effort given the much smaller and >> > narrower application scope of PCE. >> > >> > 2) The payload of HTTP messages (both request and response) >> > is in form of byte stream, which is unstructured comparing >> > to the PCEP proposal, where the content is structured with >> >objects. >> > For the PCE application, the object based format is more >> > efficient in terms of processing. >> > >> > 3) The HTTP does not have unsolicited messages such as Notificati= on >> > message and Error message that are defined by PCEP. >> > >> > 4) PCE architecture allows a PCE functions as a server but also a= s >> > a client communicating with another PCE server. In both cases, >> > the same protocol is used. PCEP supports this scenario. There >> > requires some work to make HTTP behavior as such. >> > >> >Dean >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 > . >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Oct 08 11:58:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOH5F-0003lh-CQ; Sat, 08 Oct 2005 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOH5D-0003lU-S9 for pce@megatron.ietf.org; Sat, 08 Oct 2005 11:57:59 -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 LAA27138 for ; Sat, 8 Oct 2005 11:57:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOHEk-0002vZ-51 for pce@ietf.org; Sat, 08 Oct 2005 12:07:50 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Oct 2005 08:57:43 -0700 X-IronPort-AV: i="3.97,189,1125903600"; d="scan'208"; a="218336444:sNHT27351428" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j98Fvcuk005642; Sat, 8 Oct 2005 08:57:38 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 08:57:38 -0700 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] Choosing the PCE protocol Date: Sat, 8 Oct 2005 08:57:37 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0EBA042E@xmb-sjc-234.amer.cisco.com> Thread-Topic: [Pce] Choosing the PCE protocol Thread-Index: AcXLarNxUeaQDpqLRO6Pa1rWDm+9QQAs/4/Q From: "Dean Cheng \(dcheng\)" To: , , X-OriginalArrivalTime: 08 Oct 2005 15:57:38.0206 (UTC) FILETIME=[018EF3E0:01C5CC21] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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 Igor, Dimitri,=20 Please see some response to your questions below. Dean >-----Original Message----- >From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 >Sent: Friday, October 07, 2005 11:13 AM >To: ibryskin@movaz.com; Dean Cheng (dcheng) >Cc: pce@ietf.org >Subject: Re: [Pce] Choosing the PCE protocol > > > >ibryskin@movaz.com wrote: >> Dean, >>=20 >> See my comments in-line. >>=20 >> Igor >>=20 >>>As for COPS, its application environment is somewhat similar to that=20 >>>of PCE but has some problems (if used for PCE applciation)=20 >due to much=20 >>>optimization around its specifics such as: >>> >>> 1) The PEP (client) is the one required to initiate the >>> connection with a PDP (server). Whereas for PCE >>> application, either PCE (server) or PCC may initiate >>> the connection. >>=20 >> IB>> Why would a PCE want to initiate a connection with a PCC? > >more generally i am not sure to understand why "PC" elements=20 >would initiate connections ... are they not meant to "compute" paths ? The "connection" I meant a transport (say TCP) connection if used. The=20 current PCE architecture does not make any assumption as who should or=20 should not initiate the connection. While it may be easier to agree=20 that why a PCC wants to initiate a connection with a PCE, there would=20 be deployment/application scenarios where a PCE initiate the=20 connections, and the PCEP does not prevent from doing that. We could discuss such cases in Vancouver if you will. > >>> 2) There requires a synchronization between PEP and PDP for >>> the policy application with states maintained on both places. >>> For PCE application, the PCE server is only required to >>> perform a one-time service for each LSP, without the need >>> maintain any subsequent states. >>=20 >> IB>> Even if all this is true, why is it a big deal? > >there is also a need to discuss what are these states and what=20 >they represent in the context of this application (PCE) before=20 >claiming that they are impacting one implementation and not the other > This may not be a big deal, but when PCEP is used, there is no need to worry about the deal, nor the protocol backward-compatibility. No need to have the switch/case statement in the existing code if any either. > >>> 3) It requires some work to support a PDP functions as a PEP >>> and communicates with another PDP. PCEP supports this model >>> fully. >> >> IB>> Functions of PDP and PEP are orthogonal and surely could be >> physically co-located > >indeed > Again, this may not be a big deal, but PCEP explicitly supports the two modes with well defined functions and operations. >>> 4) COPS is a server-client protocol, but with code point >>> heavily dedicated for a specific application. It does not >>> serve general purpose if any, and to support PCE application, >>> there would be a large number of extensions, thus defeating >>> the purpose of reusage. >>=20 >> IB>> PCIM is designed to be easily expanded for application=20 >(read PCE) >> specific needs >>=20 Probably the amount of the work to add extensions to the COPS is a =20 large part of the PCEP already, and you only re-use a server-client communication mechanism that is a relatively small piece. And you need to do some filtering on the COPS code avoiding those not applied. >> Igor >>=20 >>>As a result, I'd favor PECP as a PCE-specific protocol; it is much=20 >>>cleaner and also light-weighted. > >there is very little material/argumentation as part of this=20 >e-mail that allows to come to such conclusion > >by the way i would like to ask what is meant here by "cleaner"=20 >? and how it is possible to come to the conclusion that PCEP=20 >is lightweighted by the argumentation provided here above ? > That means as a dedicated PCE communication protocol, it is designed solely for the PCE application, without carrying any non-applicable or useless protocol element. >>>Dean >>> >>> >>>>-----Original Message----- >>>>From: pce-bounces@lists.ietf.org >>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>>>Sent: Monday, October 03, 2005 3:30 PM >>>>To: Adrian Farrel; pce@ietf.org >>>>Subject: RE: [Pce] Choosing the PCE protocol >>>> >>>>Hi, >>>> >>>> I don't think HTTP is a good candidate for the PCE application and=20 >>>> here are some weakness one could think of, if it used for PCE=20 >>>> application: >>>> >>>> 1) The HTTP is specifically designed for communications between >>>> web server and its client, or applications in that nature. >>>> Although it is possible to add extensions to support PCE >>>> application, it would require a considerable amount of work. >>>> That is not worth of the effort given the much smaller and >>>> narrower application scope of PCE. >>>> >>>> 2) The payload of HTTP messages (both request and response) >>>> is in form of byte stream, which is unstructured comparing >>>> to the PCEP proposal, where the content is structured with=20 >>>>objects. >>>> For the PCE application, the object based format is more >>>> efficient in terms of processing. >>>> >>>> 3) The HTTP does not have unsolicited messages such as=20 >Notification >>>> message and Error message that are defined by PCEP. >>>> >>>> 4) PCE architecture allows a PCE functions as a server=20 >but also as >>>> a client communicating with another PCE server. In both cases, >>>> the same protocol is used. PCEP supports this scenario. There >>>> requires some work to make HTTP behavior as such. >>>> >>>>Dean >>>> >>>> >>>>>-----Original Message----- >>>>>From: pce-bounces@lists.ietf.org >>>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>>>>Sent: Thursday, September 29, 2005 7:27 AM >>>>>To: pce@ietf.org >>>>>Subject: [Pce] Choosing the PCE protocol >>>>> >>>>>Hi, >>>>> >>>>>Three candidate protocols have been brought to my attention for us=20 >>>>>to consider. These are (in no specific order): >>>>>- HTTP >>>>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>>>- COPS >>>>> >>>>>I would like to close the nomination period, and move on to >>>> >>>>select our >>>> >>>>>protocol. >>>>> >>>>>The best approach will be if supporters of the candidate protocols=20 >>>>>indicate (briefly) why their proposed protocol is=20 >suitable. It would=20 >>>>>also be helpful if they were frank about what the weaknesses of=20 >>>>>their proposal are. >>>>> >>>>>And please - this is not an election, it is an interview process. >>>>> >>>>>Thanks, >>>>>Adrian >>>>> >>>>>PS The reason why JP is keeping quite on this is that he is an=20 >>>>>author of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is=20 >>>>>not occupying the chair during this discussion. >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Pce mailing list >>>>>Pce@lists.ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>>>_______________________________________________ >>>>Pce mailing list >>>>Pce@lists.ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>=20 >>=20 >>=20 >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >>=20 >> . >>=20 > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 09 04:03:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOW9N-0004q5-JN; Sun, 09 Oct 2005 04:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOW9M-0004q0-LZ for pce@megatron.ietf.org; Sun, 09 Oct 2005 04:03: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 EAA01864 for ; Sun, 9 Oct 2005 04:03:15 -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 1EOWJ0-0007iU-GV for pce@ietf.org; Sun, 09 Oct 2005 04:13:16 -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 <0IO3002OV2QLZ3@szxga02-in.huawei.com> for pce@ietf.org; Sun, 09 Oct 2005 16:11:09 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IO300JOK2QL55@szxga02-in.huawei.com> for pce@ietf.org; Sun, 09 Oct 2005 16:11:09 +0800 (CST) Received: from z18605 ([10.110.100.58]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IO300BP72VWWQ@szxml01-in.huawei.com>; Sun, 09 Oct 2005 16:14:20 +0800 (CST) Date: Sun, 09 Oct 2005 15:37:16 +0800 From: Zhang Renhai Subject: Re: [Pce] Choosing the PCE protocol To: "Dean Cheng (dcheng)" Message-id: <003c01c5cca4$46b99f00$3a646e0a@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 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <70BC84B185C3EE448EDB7AB8956D3B0EBA042E@xmb-sjc-234.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d 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 Hi, Dean I basically agree with you on what you said below, the PCEP is specially disigned for the PCE invironment, certainly it can be the cleanest and most lightweight, in fact I think the PCEP will be the most suitable one although there are still some work to do on it. furthermore I have some comments inline. ----- Original Message ----- From: "Dean Cheng (dcheng)" To: ; ; Cc: Sent: Saturday, October 08, 2005 11:57 PM Subject: RE: [Pce] Choosing the PCE protocol Igor, Dimitri, Please see some response to your questions below. Dean >-----Original Message----- >From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >Sent: Friday, October 07, 2005 11:13 AM >To: ibryskin@movaz.com; Dean Cheng (dcheng) >Cc: pce@ietf.org >Subject: Re: [Pce] Choosing the PCE protocol > > > >ibryskin@movaz.com wrote: >> Dean, >> >> See my comments in-line. >> >> Igor >> >>>As for COPS, its application environment is somewhat similar to that >>>of PCE but has some problems (if used for PCE applciation) >due to much >>>optimization around its specifics such as: >>> >>> 1) The PEP (client) is the one required to initiate the >>> connection with a PDP (server). Whereas for PCE >>> application, either PCE (server) or PCC may initiate >>> the connection. >> >> IB>> Why would a PCE want to initiate a connection with a PCC? > >more generally i am not sure to understand why "PC" elements >would initiate connections ... are they not meant to "compute" paths ? The "connection" I meant a transport (say TCP) connection if used. The current PCE architecture does not make any assumption as who should or should not initiate the connection. While it may be easier to agree that why a PCC wants to initiate a connection with a PCE, there would be deployment/application scenarios where a PCE initiate the connections, and the PCEP does not prevent from doing that. We could discuss such cases in Vancouver if you will. ZRH>> If appropriate, I also want to know when the PCE initiat the connection > >>> 2) There requires a synchronization between PEP and PDP for >>> the policy application with states maintained on both places. >>> For PCE application, the PCE server is only required to >>> perform a one-time service for each LSP, without the need >>> maintain any subsequent states. >> >> IB>> Even if all this is true, why is it a big deal? > >there is also a need to discuss what are these states and what >they represent in the context of this application (PCE) before >claiming that they are impacting one implementation and not the other > This may not be a big deal, but when PCEP is used, there is no need to worry about the deal, nor the protocol backward-compatibility. No need to have the switch/case statement in the existing code if any either. > >>> 3) It requires some work to support a PDP functions as a PEP >>> and communicates with another PDP. PCEP supports this model >>> fully. >> >> IB>> Functions of PDP and PEP are orthogonal and surely could be >> physically co-located > >indeed > Again, this may not be a big deal, but PCEP explicitly supports the two modes with well defined functions and operations. >>> 4) COPS is a server-client protocol, but with code point >>> heavily dedicated for a specific application. It does not >>> serve general purpose if any, and to support PCE application, >>> there would be a large number of extensions, thus defeating >>> the purpose of reusage. >> >> IB>> PCIM is designed to be easily expanded for application >(read PCE) >> specific needs >> Probably the amount of the work to add extensions to the COPS is a large part of the PCEP already, and you only re-use a server-client communication mechanism that is a relatively small piece. And you need to do some filtering on the COPS code avoiding those not applied. ZRH>>how do you think the flexibility of the PCEP for the future extension for some kinds of usage. more than the tlv format. >> Igor >> >>>As a result, I'd favor PECP as a PCE-specific protocol; it is much >>>cleaner and also light-weighted. > >there is very little material/argumentation as part of this >e-mail that allows to come to such conclusion > >by the way i would like to ask what is meant here by "cleaner" >? and how it is possible to come to the conclusion that PCEP >is lightweighted by the argumentation provided here above ? > That means as a dedicated PCE communication protocol, it is designed solely for the PCE application, without carrying any non-applicable or useless protocol element. ZRH>>Agree. However I still want all the advantage/disadvantage of COPS/HTTP/PCEP can be listed when used as PCE protocol, then we can achieve a fair comments on these protocol Regards, Zhang >>>Dean >>> >>> >>>>-----Original Message----- >>>>From: pce-bounces@lists.ietf.org >>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>>>Sent: Monday, October 03, 2005 3:30 PM >>>>To: Adrian Farrel; pce@ietf.org >>>>Subject: RE: [Pce] Choosing the PCE protocol >>>> >>>>Hi, >>>> >>>> I don't think HTTP is a good candidate for the PCE application and >>>> here are some weakness one could think of, if it used for PCE >>>> application: >>>> >>>> 1) The HTTP is specifically designed for communications between >>>> web server and its client, or applications in that nature. >>>> Although it is possible to add extensions to support PCE >>>> application, it would require a considerable amount of work. >>>> That is not worth of the effort given the much smaller and >>>> narrower application scope of PCE. >>>> >>>> 2) The payload of HTTP messages (both request and response) >>>> is in form of byte stream, which is unstructured comparing >>>> to the PCEP proposal, where the content is structured with >>>>objects. >>>> For the PCE application, the object based format is more >>>> efficient in terms of processing. >>>> >>>> 3) The HTTP does not have unsolicited messages such as >Notification >>>> message and Error message that are defined by PCEP. >>>> >>>> 4) PCE architecture allows a PCE functions as a server >but also as >>>> a client communicating with another PCE server. In both cases, >>>> the same protocol is used. PCEP supports this scenario. There >>>> requires some work to make HTTP behavior as such. >>>> >>>>Dean >>>> >>>> >>>>>-----Original Message----- >>>>>From: pce-bounces@lists.ietf.org >>>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>>>>Sent: Thursday, September 29, 2005 7:27 AM >>>>>To: pce@ietf.org >>>>>Subject: [Pce] Choosing the PCE protocol >>>>> >>>>>Hi, >>>>> >>>>>Three candidate protocols have been brought to my attention for us >>>>>to consider. These are (in no specific order): >>>>>- HTTP >>>>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>>>- COPS >>>>> >>>>>I would like to close the nomination period, and move on to >>>> >>>>select our >>>> >>>>>protocol. >>>>> >>>>>The best approach will be if supporters of the candidate protocols >>>>>indicate (briefly) why their proposed protocol is >suitable. It would >>>>>also be helpful if they were frank about what the weaknesses of >>>>>their proposal are. >>>>> >>>>>And please - this is not an election, it is an interview process. >>>>> >>>>>Thanks, >>>>>Adrian >>>>> >>>>>PS The reason why JP is keeping quite on this is that he is an >>>>>author of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is >>>>>not occupying the chair during this discussion. >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Pce mailing list >>>>>Pce@lists.ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>>>_______________________________________________ >>>>Pce mailing list >>>>Pce@lists.ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pce >>>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >>> >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> . >> > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 09 05: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 1EOXIe-0003Y6-62; Sun, 09 Oct 2005 05:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOXIb-0003XA-SM for pce@megatron.ietf.org; Sun, 09 Oct 2005 05: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 FAA04608 for ; Sun, 9 Oct 2005 05:16:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOXSH-0005c1-BG for pce@ietf.org; Sun, 09 Oct 2005 05:26:53 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EOXIM-0000hg-Ex; Sun, 09 Oct 2005 09:16:39 +0000 Message-ID: <4348E00D.9030509@psg.com> Date: Sun, 09 Oct 2005 11:17:01 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dean Cheng (dcheng)" Subject: Re: [Pce] Choosing the PCE protocol References: <70BC84B185C3EE448EDB7AB8956D3B0EBA042E@xmb-sjc-234.amer.cisco.com> In-Reply-To: <70BC84B185C3EE448EDB7AB8956D3B0EBA042E@xmb-sjc-234.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 dean Dean Cheng (dcheng) wrote: > Igor, Dimitri, > > Please see some response to your questions below. > > Dean > > >>-----Original Message----- >>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>Sent: Friday, October 07, 2005 11:13 AM >>To: ibryskin@movaz.com; Dean Cheng (dcheng) >>Cc: pce@ietf.org >>Subject: Re: [Pce] Choosing the PCE protocol >> >> >> >>ibryskin@movaz.com wrote: >> >>>Dean, >>> >>>See my comments in-line. >>> >>>Igor >>> >>> >>>>As for COPS, its application environment is somewhat similar to that >>>>of PCE but has some problems (if used for PCE applciation) >>>>due to much optimization around its specifics such as: >>>> >>>> 1) The PEP (client) is the one required to initiate the >>>> connection with a PDP (server). Whereas for PCE >>>> application, either PCE (server) or PCC may initiate >>>> the connection. >>> >>> IB>> Why would a PCE want to initiate a connection with a PCC? >> >>more generally i am not sure to understand why "PC" elements >>would initiate connections ... are they not meant to "compute" paths ? > > The "connection" I meant a transport (say TCP) connection if used. The > current PCE architecture does not make any assumption as who should or > should not initiate the connection. While it may be easier to agree > that why a PCC wants to initiate a connection with a PCE, there would > be deployment/application scenarios where a PCE initiate the > connections, and the PCEP does not prevent from doing that. which scenarios ? > We could discuss such cases in Vancouver if you will. i am ok for discussion but i am also in favor then to postpone this argument until there is a common understanding here >>>> 2) There requires a synchronization between PEP and PDP for >>>> the policy application with states maintained on both places. >>>> For PCE application, the PCE server is only required to >>>> perform a one-time service for each LSP, without the need >>>> maintain any subsequent states. >>> >>>IB>> Even if all this is true, why is it a big deal? >> >>there is also a need to discuss what are these states and what >>they represent in the context of this application (PCE) before >>claiming that they are impacting one implementation and not the other > > This may not be a big deal, but when PCEP is used, there is no need > to worry about the deal, nor the protocol backward-compatibility. No > need to have the switch/case statement in the existing code if any > either. indeed, PCEP is a dedicated new protocol so there is no backward compatibility issue possible but does it prove something about the intrinsic quality of PCEP vs COPS ? i think the issue should better be positioned when the whole landscape will be available >>>> 3) It requires some work to support a PDP functions as a PEP >>>> and communicates with another PDP. PCEP supports this model >>>> fully. >>> >>>IB>> Functions of PDP and PEP are orthogonal and surely could be >>>physically co-located indeed > > Again, this may not be a big deal, but PCEP explicitly supports the > two modes with well defined functions and operations. the document is still an individual submission so i would not presume about the level of readiness (of any) particular solution - once the WG will converge one should expect several cycles to reach some stability >>>> 4) COPS is a server-client protocol, but with code point >>>> heavily dedicated for a specific application. It does not >>>> serve general purpose if any, and to support PCE application, >>>> there would be a large number of extensions, thus defeating >>>> the purpose of reusage. >>> >>>IB>> PCIM is designed to be easily expanded for application >>(read PCE) specific needs > > Probably the amount of the work to add extensions to the COPS is a > large part of the PCEP already, and you only re-use a server-client > communication mechanism that is a relatively small piece. And you > need to do some filtering on the COPS code avoiding those not applied. this underlines the need to come out with a more complete document for assessing these statements >>>>As a result, I'd favor PECP as a PCE-specific protocol; it is much >>>>cleaner and also light-weighted. >> >>there is very little material/argumentation as part of this >>e-mail that allows to come to such conclusion >> >>by the way i would like to ask what is meant here by "cleaner" >>? and how it is possible to come to the conclusion that PCEP >>is lightweighted by the argumentation provided here above ? > > That means as a dedicated PCE communication protocol, it is designed > solely for the PCE application, without carrying any non-applicable > or useless protocol element. so by cleaner you meant "dedicated" (the latter sounds obvious since referred to as PCEP) but i am unclear on why (even if your feeling is that one would have to cope with non-applicable elements using COPS) this makes PCEP lightweighted ? as said in a previous thread the light vs heavy argument should be used iff there is a common understanding on what these terms exactly mean >>>>Dean >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: pce-bounces@lists.ietf.org >>>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Dean Cheng (dcheng) >>>>>Sent: Monday, October 03, 2005 3:30 PM >>>>>To: Adrian Farrel; pce@ietf.org >>>>>Subject: RE: [Pce] Choosing the PCE protocol >>>>> >>>>>Hi, >>>>> >>>>>I don't think HTTP is a good candidate for the PCE application and >>>>>here are some weakness one could think of, if it used for PCE >>>>>application: >>>>> >>>>> 1) The HTTP is specifically designed for communications between >>>>> web server and its client, or applications in that nature. >>>>> Although it is possible to add extensions to support PCE >>>>> application, it would require a considerable amount of work. >>>>> That is not worth of the effort given the much smaller and >>>>> narrower application scope of PCE. >>>>> >>>>> 2) The payload of HTTP messages (both request and response) >>>>> is in form of byte stream, which is unstructured comparing >>>>> to the PCEP proposal, where the content is structured with >>>>>objects. >>>>> For the PCE application, the object based format is more >>>>> efficient in terms of processing. >>>>> >>>>> 3) The HTTP does not have unsolicited messages such as >> >>Notification >> >>>>> message and Error message that are defined by PCEP. >>>>> >>>>> 4) PCE architecture allows a PCE functions as a server >> >>but also as >> >>>>> a client communicating with another PCE server. In both cases, >>>>> the same protocol is used. PCEP supports this scenario. There >>>>> requires some work to make HTTP behavior as such. >>>>> >>>>>Dean >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: pce-bounces@lists.ietf.org >>>>>>[mailto:pce-bounces@lists.ietf.org] On Behalf Of Adrian Farrel >>>>>>Sent: Thursday, September 29, 2005 7:27 AM >>>>>>To: pce@ietf.org >>>>>>Subject: [Pce] Choosing the PCE protocol >>>>>> >>>>>>Hi, >>>>>> >>>>>>Three candidate protocols have been brought to my attention for us >>>>>>to consider. These are (in no specific order): >>>>>>- HTTP >>>>>>- PCECP (as draft-vasseur-pce-pcep-02.txt) >>>>>>- COPS >>>>>> >>>>>>I would like to close the nomination period, and move on to >>>>> >>>>>select our >>>>> >>>>> >>>>>>protocol. >>>>>> >>>>>>The best approach will be if supporters of the candidate protocols >>>>>>indicate (briefly) why their proposed protocol is >> >>suitable. It would >> >>>>>>also be helpful if they were frank about what the weaknesses of >>>>>>their proposal are. >>>>>> >>>>>>And please - this is not an election, it is an interview process. >>>>>> >>>>>>Thanks, >>>>>>Adrian >>>>>> >>>>>>PS The reason why JP is keeping quite on this is that he is an >>>>>>author of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is >>>>>>not occupying the chair during this discussion. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Pce mailing list >>>>>>Pce@lists.ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/pce >>>>>> >>>>> >>>>>_______________________________________________ >>>>>Pce mailing list >>>>>Pce@lists.ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pce >>>>> >>>> >>>>_______________________________________________ >>>>Pce mailing list >>>>Pce@lists.ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pce >>>> >>>> >>> >>> >>> >>>_______________________________________________ >>>Pce mailing list >>>Pce@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/pce >>> >>>. >>> >> > > . > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 09 07:18:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZBq-0007SH-R9; Sun, 09 Oct 2005 07:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZBp-0007S6-EL for pce@megatron.ietf.org; Sun, 09 Oct 2005 07:18:01 -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 HAA09543 for ; Sun, 9 Oct 2005 07:18:00 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOZLW-0008SB-9X for pce@ietf.org; Sun, 09 Oct 2005 07:28:02 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 78FC0E000230 for ; Sun, 9 Oct 2005 12:17:52 +0100 (BST) Received: from Puppy ([217.158.132.242] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Oct 2005 12:14:41 +0100 Message-ID: <008c01c5ccc3$0d1b5030$f2849ed9@Puppy> From: "Adrian Farrel" To: Date: Sun, 9 Oct 2005 12:03:37 +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-OriginalArrivalTime: 09 Oct 2005 11:14:42.0219 (UTC) FILETIME=[A57EA7B0:01C5CCC2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: 64th IETF - DRAFT Agenda 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 Early plans have PCE scheduled as: THURSDAY, November 10, 2005 0900-1130 Morning Session I RTG pce Path Computation Element WG This may change. Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 09 07:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZNj-0001AO-VS; Sun, 09 Oct 2005 07:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOZNi-0001AJ-I1 for pce@megatron.ietf.org; Sun, 09 Oct 2005 07:30: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 HAA10269 for ; Sun, 9 Oct 2005 07:30:17 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOZXP-0000Mq-B5 for pce@ietf.org; Sun, 09 Oct 2005 07:40:19 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 8E49BE000253; Sun, 9 Oct 2005 12:30:03 +0100 (BST) Received: from Puppy ([217.158.132.242] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Oct 2005 12:21:10 +0100 Message-ID: <00ca01c5ccc3$f4eeb1e0$f2849ed9@Puppy> From: "Adrian Farrel" To: "JP Vasseur" , , "Lou Berger" References: <6.2.5.6.2.20051006160733.056a8be8@movaz.com> Subject: Re: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt Date: Sun, 9 Oct 2005 12:19:08 +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-OriginalArrivalTime: 09 Oct 2005 11:21:11.0566 (UTC) FILETIME=[8D904AE0:01C5CCC3] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Lou, > I[t] looks like most of my comments on Policy were NOT > integrated into this version. These comments applied, even with the > notion that there would be an additional PCE Policy Architecture document. > > What was your thinking here? I don't think there was any deliberate attempt to leave out text that you requested included. The new revision includes three addition pieces of text to cover Policy - section 6.10 which has been increased in this revision by the addition of four paragraphs - section 8 where a new evaluation metric has been added to examine policy - section 9.1 which is a new section I'm sure I heard you say > I think limiting the policy discussion in the arch document to > ensuring it is include and excluding the definition of specific > policies is reasonable. If you would like to suggest text or point us at text you supplied before, we'd be pleased to see it. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Oct 11 04: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 1EPFys-00071I-2z; Tue, 11 Oct 2005 04: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 1EPFyr-00071D-7m for pce@megatron.ietf.org; Tue, 11 Oct 2005 04:59: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 EAA08947 for ; Tue, 11 Oct 2005 04:59:26 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPG8w-0001S9-02 for pce@ietf.org; Tue, 11 Oct 2005 05:09:54 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 10:59:23 +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: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Date: Tue, 11 Oct 2005 10:59:25 +0200 Message-ID: Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Thread-Index: AcXKA3UHvzHGQWFySEm8I2ZPBHV1wgENQzgQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "Ash, Gerald R \(Jerry\), ALABS" , X-OriginalArrivalTime: 11 Oct 2005 08:59:23.0462 (UTC) FILETIME=[132A2660:01C5CE42] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 Please see inline=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Adrian Farrel > Envoy=E9 : mercredi 5 octobre 2005 22:51 > =C0 : Ash, Gerald R (Jerry), ALABS; pce@ietf.org > Objet : Re: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt >=20 > Thanks Jerry and team, >=20 > A question about section 6.1.16 of this draft. >=20 > Here it says... >=20 > Here is the list of generic constraints that MUST be supported: >=20 > o MPLS-TE and GMPLS generic constraints: > - Bandwidth > - Affinities inclusion/exclusion > - Link, Node, SRLG inclusion/exclusion > - Maximum end-to-end delay metrics > - Hop Count > - Maximum end-to-end TE metric (cost) > - Multiple disjoint path computation to allow path protection >=20 > Correct me if I am wrong, but delay is not a standard link=20 > parameter exchanged by the TE IGPs.=20 Agree, today no >Instead, we have RFC 3785=20 > that suggests that a network may be operationally configured=20 > so that the IGP metric has one meaning, and the TE metric=20 > another meaning. Further, it suggests that a use might be to=20 > place a delay metric in the IGP metric field. >=20 > Certainly, therefore, if a network is operated according to=20 > RFC 3785 and the IGP metric is interpreted as a delay metric=20 > a PCE will understand how to constrain the path computation=20 > according to a delay bound. But if the network is operated in=20 > any other way, the PCE will not be able to act on the delay=20 > constraint. Further, if the network is operated in some other=20 > way, the PCC will not be able to request that the path is=20 > constrained according to the two metrics advertised by the TE IGP. >=20 > Wouldn't it be more sensible to require that support of: > - Maximum end-to-end IGP metric (cost) > - Maximum end-to-end TE metric (cost) Agree, but in this case we should not presume any semantic. The term cost refers IMHO to a particular semantic. This is more related to an optimization criteria i.e. an objectivie function ( = Computation of shortest cost path) than a path constraint. Computing a "cost bounded path" does not really make sense IMO... Given that at the time being as we don't have specific link attributes = to encode path attributes such as delay, distance, power loss, = polarization and so one, I would suggest that we say: " - Maximum end-to-end IGP metric=20 - Maximum end-to-end TE metric=20 where the IGP or TE metric may represent any additive aggregate path = attribute (e.g. delay, power loss...)" Best Regards, JL >=20 > ...and add a note that if the network is operated according=20 > to [RFC3785] the IGP metric may be used to indicate a per=20 > link delay metric. >=20 > Cheers, > Adrian > ----- Original Message ----- > From: "Ash, Gerald R (Jerry), ALABS" > To: > Sent: Thursday, September 22, 2005 1:01 PM > Subject: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt >=20 >=20 > Hi All, >=20 > Please review and comment on the updated version of the PCE > communications protocol (PCECP) generic requirements I-D > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protoc > ol-gen-req > s-02.txt. >=20 > The changes include those listed on slide 3 of the Paris meeting: > http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm > and responses to Adrian's comprehensive review sent to the design team > (these are all editorial comments). >=20 > The most substantive changes are the inclusion of "boundary number" > thresholds in Section 6.1.15 (Scalability). Dimitri suggested back in > July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html > that boundary numbers be specified, and it was agreed at IETF-63 to > include 'order-of-magnitude' values in the updated draft. =20 > This has been > done in the submitted update, and JP requested comments on=20 > this Section > in his posting 2 days ago > http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html. >=20 > Our objective is to start a WG last call soon. We look=20 > forward to your > review and comments. >=20 > Thanks, > Regards, > Jerry >=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 Oct 11 05:02:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPG22-0007QI-PZ; Tue, 11 Oct 2005 05:02:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPG21-0007QA-6W for pce@megatron.ietf.org; Tue, 11 Oct 2005 05:02: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 FAA09077 for ; Tue, 11 Oct 2005 05:02:42 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPGC3-0001Wi-Ux for pce@ietf.org; Tue, 11 Oct 2005 05:13:10 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 11:02:40 +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: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Date: Tue, 11 Oct 2005 11:02:42 +0200 Message-ID: Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Thread-Index: AcXLO4rnl/SOJgRNRrGzW+61VkHH4wC+3MrA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 11 Oct 2005 09:02:40.0620 (UTC) FILETIME=[88AE12C0:01C5CE42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable Cc: Ash@movaz.com, pce@ietf.org, Gerald 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 Igor, Please see inline,=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de ibryskin@movaz.com > Envoy=E9 : vendredi 7 octobre 2005 14:34 > =C0 : zzx-adrian@olddog.co.uk > Cc : Gerald; pce@ietf.org; Ash@movaz.com > Objet : Re: [Pce] RE: I-D=20 > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt >=20 > Adrian, >=20 > What you are suggesting is reasonable and does not require=20 > changes in IGP-TE. However, it is too general. Why not to=20 > consider introducing more TE LINK sub-TLVs, for example,=20 > metric associated with delay introduced by the link? I agree with you, if we find that having two aggregate path attributes = (IGP metric and TE-metric) is not enough to support various constraints = and optimizaiton criteria we may define new TE link sub-TLVs, = potentially with a specific semantic (distance, delay, power loss...) >=20 > I personally believe that *all* pce constraints should be=20 > bound by evaluating formulas to corresponding TE advertising,=20 > so that if you need to support a new PCE constraint (whether=20 > it is a link type or path type > constraint) network TE links should advertise appropriate=20 > piece of information.=20 >This is the only way how PCE can act on=20 > the constraint without guessing on TE metric values. In some cases the PCE does not need to be aware of the exact semantic of = a link metric, and could just apply a numeric constraint. But I agree with you that for certain constraints (e.g. polarization, = power loss...) the PCE may have to account for the exact semantic of the = constraints to compute accurate paths.=20 Best Regards, JL >=20 >=20 > Cheers, > Igor >=20 > > Thanks Jerry and team, > > > > A question about section 6.1.16 of this draft. > > > > Here it says... > > > > Here is the list of generic constraints that MUST be supported: > > > > o MPLS-TE and GMPLS generic constraints: > > - Bandwidth > > - Affinities inclusion/exclusion > > - Link, Node, SRLG inclusion/exclusion > > - Maximum end-to-end delay metrics > > - Hop Count > > - Maximum end-to-end TE metric (cost) > > - Multiple disjoint path computation to allow path protection > > > > Correct me if I am wrong, but delay is not a standard link=20 > parameter=20 > > exchanged by the TE IGPs. Instead, we have RFC 3785 that=20 > suggests that=20 > > a network may be operationally configured so that the IGP=20 > metric has=20 > > one meaning, and the TE metric another meaning. Further, it=20 > suggests=20 > > that a use might be to place a delay metric in the IGP metric field. > > > > Certainly, therefore, if a network is operated according to=20 > RFC 3785=20 > > and the IGP metric is interpreted as a delay metric a PCE will=20 > > understand how to constrain the path computation according=20 > to a delay=20 > > bound. But if the network is operated in any other way, the=20 > PCE will=20 > > not be able to act on the delay constraint. Further, if the=20 > network is=20 > > operated in some other way, the PCC will not be able to=20 > request that=20 > > the path is constrained according to the two metrics=20 > advertised by the TE IGP. > > > > Wouldn't it be more sensible to require that support of: > > - Maximum end-to-end IGP metric (cost) > > - Maximum end-to-end TE metric (cost) > > > > ...and add a note that if the network is operated according to=20 > > [RFC3785] the IGP metric may be used to indicate a per link=20 > delay metric. > > > > Cheers, > > Adrian > > ----- Original Message ----- > > From: "Ash, Gerald R (Jerry), ALABS" > > To: > > Sent: Thursday, September 22, 2005 1:01 PM > > Subject: [Pce] RE: I-D=20 > > ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt > > > > > > Hi All, > > > > Please review and comment on the updated version of the PCE=20 > > communications protocol (PCECP) generic requirements I-D=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-r > > eq > > s-02.txt. > > > > The changes include those listed on slide 3 of the Paris meeting: > > http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm > > and responses to Adrian's comprehensive review sent to the=20 > design team=20 > > (these are all editorial comments). > > > > The most substantive changes are the inclusion of "boundary number" > > thresholds in Section 6.1.15 (Scalability). Dimitri=20 > suggested back in=20 > > July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html > > that boundary numbers be specified, and it was agreed at IETF-63 to=20 > > include 'order-of-magnitude' values in the updated draft. This has=20 > > been done in the submitted update, and JP requested=20 > comments on this=20 > > Section in his posting 2 days ago=20 > > http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html. > > > > Our objective is to start a WG last call soon. We look forward to=20 > > your review and comments. > > > > Thanks, > > Regards, > > Jerry > > > > > > _______________________________________________ > > 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 Wed Oct 12 10:35:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhhX-0007if-EG; Wed, 12 Oct 2005 10:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhhW-0007iS-QK for pce@megatron.ietf.org; Wed, 12 Oct 2005 10:35: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 KAA24036 for ; Wed, 12 Oct 2005 10:35:23 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPhrq-0003ro-At for pce@ietf.org; Wed, 12 Oct 2005 10:46:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2005 07:35:17 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="13032600:sNHT1306864796" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9CEYu2L016878 for ; Wed, 12 Oct 2005 10:35:14 -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, 12 Oct 2005 10:35:09 -0400 Received: from [192.168.1.100] ([10.86.240.8]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 10:35:08 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <30777786-5526-44F3-9B24-3EF0B6C8EC19@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Wed, 12 Oct 2005 10:35:27 -0400 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 12 Oct 2005 14:35:08.0944 (UTC) FILETIME=[25388100:01C5CF3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Slot request - PCE Working Group Meeting - IETF-64 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, We're currently working on the PCE WG meeting agenda. Please send your slot request. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 11:59:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPj10-000437-0V; Wed, 12 Oct 2005 11:59:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPj0y-00040g-Jn for pce@megatron.ietf.org; Wed, 12 Oct 2005 11:59: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 LAA01335 for ; Wed, 12 Oct 2005 11:59:33 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPjBJ-0007BE-7F for pce@ietf.org; Wed, 12 Oct 2005 12:10:17 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id E488DA05; Wed, 12 Oct 2005 11:59:18 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id D2FF4AF6F; Wed, 12 Oct 2005 11:59:17 -0400 (EDT) Message-Id: <6.2.5.6.2.20051011174909.050cfcd8@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Oct 2005 11:59:17 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt In-Reply-To: <00ca01c5ccc3$f4eeb1e0$f2849ed9@Puppy> References: <6.2.5.6.2.20051006160733.056a8be8@movaz.com> <00ca01c5ccc3$f4eeb1e0$f2849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 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, (JP, Gerry), Sorry about the delayed response. See below for my original set of comments/changes. I'd like to work with you (probably off-line) on the best way to incorporate these and other policy related changes. Please feel free to follow-up on or off the list. Much thanks, Lou At 07:19 AM 10/9/2005, Adrian Farrel wrote: >Hi Lou, > > > I[t] looks like most of my comments on Policy were NOT > > integrated into this version. These comments applied, even with the > > notion that there would be an additional PCE Policy Architecture >document. > > > > What was your thinking here? > >I don't think there was any deliberate attempt to leave out text that you >requested included. > >The new revision includes three addition pieces of text to cover Policy >- section 6.10 which has been increased in this revision by the > addition of four paragraphs >- section 8 where a new evaluation metric has been added to examine > policy >- section 9.1 which is a new section >I'm sure I heard you say > > > I think limiting the policy discussion in the arch document to > > ensuring it is include and excluding the definition of specific > > policies is reasonable. > >If you would like to suggest text or point us at text you supplied before, >we'd be pleased to see it. see below. >Thanks, >Adrian Here are that changes that I sent privately to the authors on 27 Jul 2005 17:29:06. The original changes/comments were in a word document, these are in diff format. 198c201 < topology and routing information between domains. --- > topology, and routing, and policy information between domains. 461a470,484 > 4.8 Path Selection Policy > > A PCE may have local policy information that impacts the path selected > to support a particular LSP. A local policy may be applied based on any > information provided from a PCC. The policy may have any number of > results including, for example, rejecting the request for a path, > providing a path that provides different quality of service, or > providing a path that has different costs. Additionally, changes in PCE > policy may force a change to a previously provided path. > > PCE related policy must also be sensitive to where it is being applied. > A different set of policies may be applied for an intra-area or > single-layer LSP, than would be provided for an inter-area or > multi-layer LSP. > 477c500,501 < which is requested from a PCE. The PCE operates on the TED in order --- > which is requested from a PCE. The PCE operates on the TED, while > consulting with the Policy database, in order 509c534 < --------------- --- > ------------------------------ 518,522c543,547 < | --------- | | | < | | | | | Adjacent | < | | PCE | | | Node | < | | | | | | < | --------- | | | --- > | --------- --------- | | | > | | Policy | | | | | Adjacent | > | | Database|<-->| PCE | | | Node | > | | | | | | | | > | --------- --------- | | | 530c555 < ------+->| Engine |<-+----------+-> | --- > ------+---------------->| Engine |<-+----------+-> | 533c558 < --------------- --- > ------------------------------ 547c572,573 < as input to the computation and returns a response. --- > as input to the computation and, after consulting with the Policy > database, returns a response. 565c592 < ---------- --- > ---------------------- 572,575c599,602 < | ----- | < | | PCE | | < | ----- | < ---------- --- > | ------ ----- | > | |Policy|<-->| PCE | | > | ------ ----- | > ---------------------- 589c616 < it may be a composit PCE node), but those functions are purely --- > it may be a compositcomposite PCE node), but those functions are purely 603c630,631 < the path. --- > the path. In this case, all policy decisions are made independently > at each PCE based on information passed from the PCC. 621c650 < ---------- ---------- --- > ------------------ ------------------- 625,628c654,657 < | ----- | | ----- | < | | TED | | | | TED | | < | ----- | | ----- | < ---------- ---------- --- > | ------ ----- | | ----- ------ | > | |Policy| | TED | | | | TED | |Policy| | > | ------ ----- | | ----- ------ | > ------------------ ------------------- 650c679,680 < ---------- ---------- --- > > ------------------ ------------------ 652c682 < | PCE |<--------------------------------->| PCE | --- > | PCE |<--------------------------->| PCE | 654,657c684,687 < | ----- | | ----- | < | | TED | | | | TED | | < | ----- | | ----- | < ---------- ---------- --- > | ------ ----- | | ------ ----- | > | |Policy| | TED | | | |Policy| | TED | | > | ------ ----- | | ------ ----- | > ------------------ ------------------ 680c711 < other PCEs. This model does not provide a distributed computaiton --- > other PCEs. This model does not provide a distributed computation 683a715,722 > There are multiple options for how policy information is coordinated > when using this model. Similar to the previous model, all policy > decisions may be made independently at each PCE based on information > passed from the previous PCE. Alternatively, there may be explicit > communication of policy information between PCEs. The type of > information conveyed to support policy will have interesting and > important implications on what policies may be applied at each PCE. > 698c737,739 < - communication between PCCs and PCEs, and between cooperating PCEs --- > - communication between PCCs and PCEs, and between cooperating PCEs, > including the definition of policy related information > communication 705c746,747 < responsiveness and robustness of path computation models. --- > responsiveness, and robustness and policy support of path > computation models. 730a773 > 748c791,793 < manner in the event of a failure of the primary PCE. Note that at any --- > manner in the event of a failure of the primary PCE. Any policies > present on the primary PCE will also need to be present on the > backup. Note that at any 760c805,809 < for a discussion of PCE discovery which impacts on this choice. It --- > for a discussion of PCE discovery which impacts on this choice. Here > too, policies will need to be consistent across the set of available > PCEs. > > It 823,824c873,875 < various static (for example, Boolean capability) or dynamically < computed variables (for example, computing resources). Proxy PCE --- > various static (for example, Boolean capability, dynamically > computed variables (for example, computing resources), or based on > specific policy (for example, the specific PCC). Proxy PCE 835c886,888 < to the PCC and out of the scope of this document. --- > to the PCC and out of the scope of this document. As previously > mentioned, it is important that each of the multiple PCEs are able to > apply policy consistently across all PCCs and PCC requests. 910a966 > - other policy related information 931a988,991 > There must also be a mechanism that enables a PCE to withdraw, or > provide updated paths. The primary purpose of this is to support > changes in PCE policy. > 947c1007,1008 < is that they apply compatible or identical computation algorithms. --- > is that they apply compatible or identical computation algorithms and > policies. 1151c1216 < 6.10. Policy and Confidentiality --- > 6.10. Confidentiality 1182c1248,1249 < it computed earlier (perhaps in reaction to a change in the network), --- > it computed earlier (perhaps in reaction to a change in the network > or a change in policy), 1196a1264,1293 > 6.12 Policy > > [May want to move this earlier in the section] > > Policy impacts multiple aspects of the PCE architecture. The two > predominant impacts are covered in this section. The first is internal > impact; the second is impact on PCE related communication. > > It is envisioned that policy will be largely applied as a local mater > within each PCE. That said, it is necessary to define the policy models > that the PCE architecture can support. Some example policies include > rejection of a request based on requesting PCC or identified > constraints, selection of a path based on the computation target, or the > selection of a path based on the time of day. The definition of > supported policy models will drive PCE solutions and will enable proper > and complete evaluation of specific PCE solutions. PCE supported policy > models TDB. > > While the implementation and enforcement of policy is largely a local > matter, the policies that may be applied impact the communication > protocols used to support PCE. This includes PCC-PCE, PCC-PCC and > discovery communication. The primary impact is to the information > carried by the protocols. To a lesser degree, policy support > requirements may also drive the required protocol transactions. As the > more detailed requirements for each PCE communication protocol is > defined, it is important for these documents to articulate supported > (and unsupported) policy models and the related requirements. Also, any > defined solution must be evaluated on its ability to support these > policy models and requirements. > 1224a1322,1327 > > - Policy: The ability to apply and enforce policies to, based on the > request information, to reject PCE requests, to select path based on > policy, and to support the modification of policy after a path has > been provided. > 1308a1414,1417 > The policy configuration interface is yet to be determined. The > interface may be purely a local matter, or may be supported via a > standardized interface (e.g., MIB.) > 1386a1497,1505 > - Reuse of existing Policy models and mechanisms > > There has been significant work done within the IETF on routing and > signaling policy. As policy support mechanisms can be quite extensive, > it is worthwhile to explore to what extent this prior work can be > leveraged and applied to PCE. This desire to leverage prior work should > not be interpreted as a requirement to use any particular solution or > protocol. > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 12:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjUn-0003Un-MV; Wed, 12 Oct 2005 12:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjUm-0003Ui-9f for pce@megatron.ietf.org; Wed, 12 Oct 2005 12:30: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 MAA03653 for ; Wed, 12 Oct 2005 12:30:20 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPjf4-0008KK-Ko for pce@ietf.org; Wed, 12 Oct 2005 12:41:05 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1129134576!7108152!7 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 12506 invoked from network); 12 Oct 2005 16:30:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-10.tower-121.messagelabs.com with SMTP; 12 Oct 2005 16:30:10 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4336CAB7002837FE; Wed, 12 Oct 2005 12:30:08 -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] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Date: Wed, 12 Oct 2005 11:30:06 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA942F@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Thread-Index: AcXKA2Pdxu4EG19ARzeEzKhZDYWaIgFRkfsg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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, > A question about section 6.1.16 of this draft. >=20 > Here it says... >=20 > Here is the list of generic constraints that MUST be supported: >=20 > o MPLS-TE and GMPLS generic constraints: > - Bandwidth > - Affinities inclusion/exclusion > - Link, Node, SRLG inclusion/exclusion > - Maximum end-to-end delay metrics > - Hop Count > - Maximum end-to-end TE metric (cost) > - Multiple disjoint path computation to allow path protection >=20 > Correct me if I am wrong, but delay is not a standard link parameter > exchanged by the TE IGPs. Instead, we have RFC 3785 that=20 > suggests that a network may be operationally configured so that the > IGP metric has one meaning, and the TE metric another meaning. > Further, it suggests that a use might be to place a delay metric in > the IGP metric field. >=20 > Certainly, therefore, if a network is operated according to=20 > RFC 3785 and the IGP metric is interpreted as a delay metric a PCE > will understand how to constrain the path computation according to a > delay bound. But if the network is operated in any other way, the > PCE will not be able to act on the delay constraint. Further, if the > network is operated in some other way, the PCC will not be able to > request that the path is constrained according to the two metrics > advertised by the TE IGP. >=20 > Wouldn't it be more sensible to require that support of: > - Maximum end-to-end IGP metric (cost) > - Maximum end-to-end TE metric (cost) >=20 > ...and add a note that if the network is operated according=20 > to [RFC3785] the IGP metric may be used to indicate a per link > delay metric. Your comments and suggested change to Section 6.1.16 make sense to me. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 13:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkNG-0003ow-W6; Wed, 12 Oct 2005 13:26:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkNE-0003oo-JR for pce@megatron.ietf.org; Wed, 12 Oct 2005 13:26:40 -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 NAA06536 for ; Wed, 12 Oct 2005 13:26:36 -0400 (EDT) Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPkXa-0001Ll-HD for pce@ietf.org; Wed, 12 Oct 2005 13:37:22 -0400 Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.4/8.13.4) with ESMTP id j9CHQXr0013622 for ; Wed, 12 Oct 2005 13:26:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <6.2.1.2.2.20051007094046.046d4a90@sa.infonet.com> References: <6.2.1.2.2.20051007094046.046d4a90@sa.infonet.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <092DC47E-E93D-41E9-8479-0CE117C21872@ece.drexel.edu> Content-Transfer-Encoding: quoted-printable From: Jaudelice Cavalcante de Oliveira Subject: Re: [Pce] Choosing the PCE protocol Date: Wed, 12 Oct 2005 13:26:31 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: (-1.481) AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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 all, I agree with the advantages of PCEP that were already mentioned. Although it was brought up at the meeting in Paris that it might be =20 better to just modify (extend) and existing protocol, I believe that =20 coming up with a protocol that only carries the necessary overhead =20 (clean design) and requirements, and it is extensible is a much more =20 reliable approach, and PCEP has these characteristics. A clean design =20= is not necessarily a "wheel reinvention" since the experiences =20 learned can be incorporated. Moreover, it has the advantages of =20 keeping things "clean," simple and optimized for the related =20 requirements, and as a result avoiding the burden of carrying =20 unnecessary features/overhead. Regards, Jaudelice. On Oct 7, 2005, at 1:30 PM, raymond zhang wrote: > Hi all, > > For SPs with both multi-area/level, the additional PCE-PCE peers =20 > across AS-boundaries would further add to the amount of inter-PCE =20 > communications. I'd agree with JL's comments below that control =20 > plane protocol for PCC/PCE and PCE/PCE needs to be lightweight and =20 > optimized to this requirement. PCEP is designed for this purpose. > > Regards, > Raymond > > At 10:12 AM 10/4/2005, LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Content-class: urn:content-classes:message >> Content-Type: multipart/alternative; >> boundary=3D"----_=3D_NextPart_001_01C5C906.BF1B06D7" >> >> Hi all, >> >> To complement what Zafar just mentionned, regarding the control =20 >> plane flavour of PCC-PCE communication, I would like to highlight =20 >> the fact that LSRs can act as PCEs, in which case the PCE =20 >> communication protocol runs directly between LSRs (inter-router =20 >> communication). >> For the sake of illustration, in a multi-area network, ABRs can =20 >> act as PCE and cooperate together to compute optimal inter-area =20 >> paths (by the way, this is the application at the origin of the =20 >> PCE concept...), and this may requires a full mesh of inter-ABR =20 >> PCE communications. >> This is one of the reasons why the communication overhead should =20 >> be minimized and the state machine should remain light. Another =20 >> reason being the capability to easily handle bursts of requests =20 >> under emergency conditions (e.g. upon link or node failure =20 >> impacting a large number of LSPs). >> >> PCEP has been designed with this requirement as key driver. >> >> It sounds IMHO quite important to take this point into =20 >> consideration when selecting the protocol. >> >> Regards, >> >> JL >> >> >> >> ---------- >> De : pce-bounces@lists.ietf.org [mailto:pce-=20 >> bounces@lists.ietf.org] De la part de Zafar Ali (zali) >> Envoy=E9 : mardi 4 octobre 2005 18:28 >> =C0 : dcheng@cisco.com >> Cc : pce@ietf.org >> Objet : RE: [Pce] Choosing the PCE protocol >> >> Hi, >> >> I agree w/ the comments made by Dean. It is also important to =20 >> realize that the PCE communication protocol is a control plane =20 >> protocol, not a management plane protocol: hence it is of the =20 >> utmost importance to minimize communication overhead (see Dean's =20 >> comment on communication overhead). >> >> Thanks >> >> Regards... Zafar >> >> >To: "Adrian Farrel" , >> >Subject: RE: [Pce] Choosing the PCE protocol >> >From: "Dean Cheng \(dcheng\)" >> >Date: Mon, 3 Oct 2005 15:30:13 -0700 >> >Cc: >> >List-archive: <http://=20 >> www1.ietf.org/pipermail/pce> >> >List-help: <> subject=3Dhelp>mailto:pce-request@lists.ietf.org?subject=3Dhelp> >> >List-id: Path Computation Element >> >List-post: <mailto:pce@lists.ietf.org> >> >List-subscribe: <> pce>https://www1.ietf.org/mailman/listinfo/pce>, > request@lists.ietf.org?subject=3Dsubscribe> >> >List-unsubscribe: <> pce>https://www1.ietf.org/mailman/listinfo/pce>, > request@lists.ietf.org?subject=3Dunsubscribe> >> >Sender: pce-bounces at lists.ietf.org >> >Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5Q >> >Thread-topic: [Pce] Choosing the PCE protocol >> > >> >--------------------------------------------------------------------=20= >> ----- ------- >> > >> >Hi, >> > >> > I don't think HTTP is a good candidate for the PCE application >> > and here are some weakness one could think of, if it used for >> > PCE application: >> > >> > 1) The HTTP is specifically designed for communications between >> > web server and its client, or applications in that nature. >> > Although it is possible to add extensions to support PCE >> > application, it would require a considerable amount of work. >> > That is not worth of the effort given the much smaller and >> > narrower application scope of PCE. >> > >> > 2) The payload of HTTP messages (both request and response) >> > is in form of byte stream, which is unstructured comparing >> > to the PCEP proposal, where the content is structured with >> >objects. >> > For the PCE application, the object based format is more >> > efficient in terms of processing. >> > >> > 3) The HTTP does not have unsolicited messages such as =20 >> Notification >> > message and Error message that are defined by PCEP. >> > >> > 4) PCE architecture allows a PCE functions as a server but =20 >> also as >> > a client communicating with another PCE server. In both =20 >> cases, >> > the same protocol is used. PCEP supports this scenario. There >> > requires some work to make HTTP behavior as such. >> > >> >Dean >> >> >> >> _______________________________________________ >> 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 Oct 12 15:52:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmeF-0003eN-Vx; Wed, 12 Oct 2005 15:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmc3-0002gH-Sk; Wed, 12 Oct 2005 15:50:07 -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 PAA14516; Wed, 12 Oct 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmmL-0005PD-W0; Wed, 12 Oct 2005 16:00:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPmbx-0000XH-VR; Wed, 12 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-02.txt Pages : 14 Date : 2005-10-12 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocol(s) or extensions to existing protocol(s) for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-12120709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-12120709.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Oct 12 16:18:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPn3Q-0001Yx-I7; Wed, 12 Oct 2005 16:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPn3P-0001UB-1m for pce@megatron.ietf.org; Wed, 12 Oct 2005 16:18:23 -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 QAA25331 for ; Wed, 12 Oct 2005 16:18:19 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnDk-0001Cr-N0 for pce@ietf.org; Wed, 12 Oct 2005 16:29:06 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id D7A0D1797 for ; Wed, 12 Oct 2005 16:18:11 -0400 (EDT) Message-ID: <00c601c5cf6a$11ab2900$7a1810ac@movaz.com> From: "Igor Bryskin" To: References: <2ac001c5ceb0$4e1370b0$f2849ed9@Puppy> Date: Wed, 12 Oct 2005 16:18:11 -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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] draft-bryskin-pce-policy-enabled-path-comp-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, The draft introduces a policy element into the PCE architecture. It outlines the Path Computation Policy Information Model (PCCIM), defines various policy categories related to the path computation process (user service specific, path computation request, client and domain specific, etc.). The document also describes policy related architectural components and their interactions. Finally, various configuration scenarios are considered in the context of events that happen during policy governed path computations. The document makes no assumptions on what type of PCC-PCE communication protocol is used, however, it does set requirements for the protocol to satisfy in order to be capable of conveying policies in path computation requests and responses. Igor, Dimitri and Lou _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 16:27:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCM-0007MK-Cb; Wed, 12 Oct 2005 16:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCK-0007KR-Fc for pce@megatron.ietf.org; Wed, 12 Oct 2005 16:27: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 QAA29038 for ; Wed, 12 Oct 2005 16:27:32 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnMd-0002YN-0l for pce@ietf.org; Wed, 12 Oct 2005 16:38:18 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id D845EE0002A4; Wed, 12 Oct 2005 21:27:01 +0100 (BST) Received: from Puppy ([217.158.132.178] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 21:21:39 +0100 Message-ID: <2d3601c5cf6a$f93cedd0$f2849ed9@Puppy> From: "Adrian Farrel" To: "Lou Berger" References: <6.2.5.6.2.20051006160733.056a8be8@movaz.com> <00ca01c5ccc3$f4eeb1e0$f2849ed9@Puppy> <6.2.5.6.2.20051011174909.050cfcd8@movaz.com> Subject: Re: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt Date: Wed, 12 Oct 2005 20:18:14 +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-OriginalArrivalTime: 12 Oct 2005 20:21:43.0278 (UTC) FILETIME=[8F9C10E0:01C5CF6A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Lou, Many apologies. Your email with Word attachment was in my files, and I missed it. (In my defence, there were 23 emails on the PCE list about the architecture that day, and a further 4 private mails.) Anyway, We have it now. I'll look through it on my flight tomorrow. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 16:27:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCW-0007Rw-UV; Wed, 12 Oct 2005 16:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCL-0007L1-0X for pce@megatron.ietf.org; Wed, 12 Oct 2005 16:27:46 -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 QAA29041 for ; Wed, 12 Oct 2005 16:27:33 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnMd-0002YT-0h for pce@ietf.org; Wed, 12 Oct 2005 16:38:19 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id AFB4BE0002E3 for ; Wed, 12 Oct 2005 21:27:08 +0100 (BST) Received: from Puppy ([217.158.132.178] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 21:21:51 +0100 Message-ID: <2d3901c5cf6a$ffe64050$f2849ed9@Puppy> From: "Adrian Farrel" To: Date: Wed, 12 Oct 2005 21:09:03 +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-OriginalArrivalTime: 12 Oct 2005 20:21:52.0356 (UTC) FILETIME=[95054240:01C5CF6A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Selecting a PCE Communication Protocol - Pulling the threads together 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, Scanning the mails on the list so far I see no strong support for COPS or HTTP. If you are in support of either of these you will need to speak up. I know it can be worrying to stand in front of the IETF juggernaut, but if you don't speak up you will not be heard. I promise to support you. We have had several questions and issues about PCEP (draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me that these were deficiencies in the current specification of PCEP rather than intrinsic faults in the protocol, and that they could be solved by the definition of appropriate objects. [Please disagree loudly!] We have had much discussion of why COPS and/or HTTP might not be appropriate. Many of the reasons suggested have been refuted or argued with, but this in itself does not amount to a case against PCEP, nor a case for COPS or HTTP. We have also had some questions about the function that a pcecp should or should not provide (for example, should a PCE be able to connect to a PCC?). We need to do two things: 1. Go back to the requirements I-D with these considerations and add/remove them according to consensus. 2. Examine the candidate protocols only against the requirements I-D and not against other putative requirements. [Safety note: when I refer to vendors or service providers below, I do not mean to imply that an individual represents the view of any corporation or that anyone participating in the IETF does so other than as an individual.] The bottom line that I see forming is that several vendors support PCEP by co-authoring, and several service providers express interest in seeing this development so that they can further assess the value of PCE. I also see strong interest expressed by at least one vendor in producing an implementation. In the end, while we must strive not to do things that break the Internet, we should also support the running code principle. If the only proposal that anyone is willing to implement or experiment with is Protocol X, then that is what we will choose unless it is unfixably broken. Failing further comment we appear to be on the verge of selecting PCEP (draft-vasseur-pce-pcep-02.txt) Note that the acceptance of one solution or another at this stage does *NOT* imply that the solution is immune from significant changes. In fact, once a solution is owned by the WG, I would expect to see a lot of input and modification especially from the implementers. The discussion continues... Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Oct 12 16:41:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnPI-0003Oj-RO; Wed, 12 Oct 2005 16:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnPH-0003OZ-UZ for pce@megatron.ietf.org; Wed, 12 Oct 2005 16:41: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 QAA03947 for ; Wed, 12 Oct 2005 16:40:56 -0400 (EDT) Received: from exchange01.movaz.com ([70.158.43.240] helo=atlntex01.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnZf-0004Rn-MP for pce@ietf.org; Wed, 12 Oct 2005 16:51:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt Date: Wed, 12 Oct 2005 16:40:44 -0400 Message-ID: Thread-Topic: [Pce] Working Group Last call on draft-ietf-pce-architecture-02.txt Thread-Index: AcXPa1uP+eERfJWnQMGDk9jywCWnKAAAdwQh From: "Berger, Lou" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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="===============0081034218==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0081034218== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CF6D.37B4B66D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CF6D.37B4B66D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Much thanks.=20 -----Original Message----- From: Adrian Farrel To: Berger, Lou CC: JP Vasseur ; gash@att.com ; = Berger, Lou ; pce@ietf.org Sent: Wed Oct 12 15:18:14 2005 Subject: Re: [Pce] Working Group Last call on = draft-ietf-pce-architecture-02.txt Lou, Many apologies. Your email with Word attachment was in my files, and I missed it. (In my defence, there were 23 emails on the PCE list about the architecture that day, and a further 4 private mails.) Anyway, We have it now. I'll look through it on my flight tomorrow. Cheers, Adrian ------_=_NextPart_001_01C5CF6D.37B4B66D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Pce] Working Group Last call on = draft-ietf-pce-architecture-02.txt

Much thanks.

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Berger, Lou <lberger@movaz.com>
CC: JP Vasseur <jvasseur@cisco.com>; gash@att.com = <gash@att.com>; Berger, Lou <lberger@movaz.com>; = pce@ietf.org <pce@ietf.org>
Sent: Wed Oct 12 15:18:14 2005
Subject: Re: [Pce] Working Group Last call on   = draft-ietf-pce-architecture-02.txt

Lou,

Many apologies. Your email with Word attachment was in my files, and = I
missed it.
(In my defence, there were 23 emails on the PCE list about the
architecture that day, and a further 4 private mails.)

Anyway,
We have it now.

I'll look through it on my flight tomorrow.

Cheers,
Adrian

------_=_NextPart_001_01C5CF6D.37B4B66D-- --===============0081034218== 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 --===============0081034218==-- From pce-bounces@lists.ietf.org Wed Oct 12 18:51:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpRf-0004IF-KC; Wed, 12 Oct 2005 18:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpRd-0004I0-Qn for pce@megatron.ietf.org; Wed, 12 Oct 2005 18:51:33 -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 SAA10280 for ; Wed, 12 Oct 2005 18:51:29 -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 1EPpc1-0007iv-A9 for pce@ietf.org; Wed, 12 Oct 2005 19:02:18 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2005 15:51:23 -0700 X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="351426633:sNHT23482456" 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 j9CMpK94014634; Wed, 12 Oct 2005 15:51:21 -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, 12 Oct 2005 18:51:20 -0400 Received: from [192.168.1.100] ([10.86.240.8]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 18:51:19 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21C92240-1EB7-4D10-9C98-863838583E4A@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 12 Oct 2005 18:51:44 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 12 Oct 2005 22:51:19.0784 (UTC) FILETIME=[76062E80:01C5CF7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Working Group, This ends the WG Last call on draft-ietf-pce-architecture-02.txt The only comments received were from Lou with regards to the Policy section. The authors are planning to update the document after having addressed Lou's comments. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Oct 13 02:11:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPwJb-0000sg-WE; Thu, 13 Oct 2005 02:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPwJZ-0000sa-L1 for pce@megatron.ietf.org; Thu, 13 Oct 2005 02:11: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 CAA26473 for ; Thu, 13 Oct 2005 02:11: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 1EPwU1-00005B-0T for pce@ietf.org; Thu, 13 Oct 2005 02:22:30 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 08:11:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5CFBC.F7770389" Subject: TR: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-02.txt Date: Thu, 13 Oct 2005 08:11:33 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-02.txt Thread-Index: AcXPamB5YFlgY2MpRsKkOX61OKoFFQAUKwiw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 13 Oct 2005 06:11:36.0444 (UTC) FILETIME=[F7949BC0:01C5CFBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CFBC.F7770389 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Here is a new revision of the requirements for PCE discovery. It addresses open issues discussed during the last meeting and on the = list. Here are the major changes: -Clarifications on the two levels of PCE information to be disclosed (mandatory for general information, optional for detailed information) -Clarified differences between the set of domains where a PCE can = compute path and the capability to take part into computation of an = inter-domain path. -The requirement for alternate PCE discovery has become a MAY -The security requirements section has been reworded and detailed -Added a section that gives minimum order of magnitude estimates of what = the PCE discovery mechanism should support, and points out the relative = stability of PCE information. -Some rewording for the sake of clarity Best Regards, JL -----Message d'origine----- De : pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] De = la part de Internet-Drafts@ietf.org Envoy=E9 : mercredi 12 octobre 2005 21:50 =C0 : i-d-announce@ietf.org Cc : pce@ietf.org Objet : [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Path Computation Element Working Group = of the IETF. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-02.txt Pages : 14 Date : 2005-10-12 =09 This document presents a set of requirements for a Path Computation=20 Element (PCE) discovery mechanism that would allow a Path Computation = Client (PCC) to discover dynamically and automatically a set of PCEs=20 along with certain information relevant for PCE selection. It is=20 intended that solutions that specify procedures and protocol(s) or=20 extensions to existing protocol(s) for such PCE discovery satisfy=20 these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-02.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-02.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C5CFBC.F7770389 Content-Type: application/octet-stream; name="ATT4904661.TXT" Content-Description: ATT4904661.TXT Content-Disposition: attachment; filename="ATT4904661.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS0xMC0xMjEyMDcwOS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBjZS1kaXNjb3Zl cnktcmVxcy0wMi50eHQNCg== ------_=_NextPart_001_01C5CFBC.F7770389 Content-Type: application/octet-stream; name="draft-ietf-pce-discovery-reqs-02.URL" Content-Description: draft-ietf-pce-discovery-reqs-02.URL Content-Disposition: attachment; filename="draft-ietf-pce-discovery-reqs-02.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXBjZS1kaXNjb3ZlcnktcmVxcy0wMi50eHQNCg== ------_=_NextPart_001_01C5CFBC.F7770389 Content-Type: text/plain; name="ATT4904662.txt" Content-Description: ATT4904662.txt Content-Disposition: attachment; filename="ATT4904662.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBjZSBtYWls aW5nIGxpc3QNClBjZUBsaXN0cy5pZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGNlDQo= ------_=_NextPart_001_01C5CFBC.F7770389 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C5CFBC.F7770389-- From pce-bounces@lists.ietf.org Thu Oct 13 06:22:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ0Dp-0007u2-F8; Thu, 13 Oct 2005 06:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ0Dn-0007tn-EO for pce@megatron.ietf.org; Thu, 13 Oct 2005 06:21:59 -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 GAA07552 for ; Thu, 13 Oct 2005 06:21:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ0OH-0006d3-8t for pce@ietf.org; Thu, 13 Oct 2005 06:32:50 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EQ0Di-00033E-Iw; Thu, 13 Oct 2005 10:21:54 +0000 Message-ID: <434E357F.5020706@psg.com> Date: Thu, 13 Oct 2005 12:22:55 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Selecting a PCE Communication Protocol - Pulling the threads together References: <2d3901c5cf6a$ffe64050$f2849ed9@Puppy> In-Reply-To: <2d3901c5cf6a$ffe64050$f2849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Adrian Farrel wrote: > Hi, > > Scanning the mails on the list so far I see no strong support for COPS or > HTTP. > > If you are in support of either of these you will need to speak up. I know > it can be worrying to stand in front of the IETF juggernaut, but if you > don't speak up you will not be heard. I promise to support you. i repeated what has been stated in a previous e-mail (not sure i have been heard ;-) one specific comment looking at the APP Area response last August (and hence the first alternative here below) it stated "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." so please collect valid input from this list on this proposal and send it to the APP Area > We have had several questions and issues about PCEP > (draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me > that these were deficiencies in the current specification of PCEP rather > than intrinsic faults in the protocol, and that they could be solved by > the definition of appropriate objects. [Please disagree loudly!] i don't clearly see the distinction you make between "deficiencies in the current specification from intrinsic faults in the protocol" let's take an example (this may help) that has been already discussed on this list, the extensibility and flexibility requirement: when introducing new constraints (for instance) or modifying the set of constraints (for instance) in this protocol could be too constraining in further being compliant with this requirement, this pushes me to point out that the protocol may look like "lightweight" with its known and current list of objects but would it be also "lightweight" in operations such as upgrade and other maintenance ? > We have had much discussion of why COPS and/or HTTP might not be > appropriate. Many of the reasons suggested have been refuted or argued > with, but this in itself does not amount to a case against PCEP, nor a > case for COPS or HTTP. > > We have also had some questions about the function that a pcecp should or > should not provide (for example, should a PCE be able to connect to a > PCC?). We need to do two things: > 1. Go back to the requirements I-D with these considerations and > add/remove > them according to consensus. > 2. Examine the candidate protocols only against the requirements I-D and > not > against other putative requirements. > > [Safety note: when I refer to vendors or service providers below, I do not > mean to imply that an individual represents the view of any corporation or > that anyone participating in the IETF does so other than as an > individual.] > > The bottom line that I see forming is that several vendors support PCEP by > co-authoring, and several service providers express interest in seeing > this development so that they can further assess the value of PCE. I also > see strong interest expressed by at least one vendor in producing an > implementation. these objectives are different in nature, there is a difference in assessing value of PCE and assessing value of the PCC/PCE->PCE communication protocol, the "user" will assess value from what the transaction allows (as long as the communication protocol generic requirements are fulfilled) > In the end, while we must strive not to do things that break the Internet, > we should also support the running code principle. If the only proposal > that anyone is willing to implement or experiment with is Protocol X, then > that is what we will choose unless it is unfixably broken. > > Failing further comment we appear to be on the verge of selecting PCEP > (draft-vasseur-pce-pcep-02.txt) > > Note that the acceptance of one solution or another at this stage does > *NOT* imply that the solution is immune from significant changes. In fact, > once a solution is owned by the WG, I would expect to see a lot of input > and modification especially from the implementers. sure, another question is also to have a better view on the system expected responsiveness this may help also in assessing which level of integration we lay have to consider > The discussion continues... indeed, thanks, - dimitri. > 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 Thu Oct 13 15:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8fu-0003x4-Qa; Thu, 13 Oct 2005 15:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8ft-0003ww-VW for pce@megatron.ietf.org; Thu, 13 Oct 2005 15:23: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 PAA06412 for ; Thu, 13 Oct 2005 15:23:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ8qS-0004eJ-HC for pce@ietf.org; Thu, 13 Oct 2005 15:34:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2005 12:23:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,211,1125903600"; d="scan'208"; a="13123842:sNHT19713066" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9DJNH27026154; Thu, 13 Oct 2005 15:23:21 -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); Thu, 13 Oct 2005 15:23:15 -0400 Received: from [192.168.1.100] ([10.86.240.214]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 15:23:15 -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: Thu, 13 Oct 2005 15:23:37 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 13 Oct 2005 19:23:15.0668 (UTC) FILETIME=[8F530140:01C5D02B] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working Group Last call on draft-ietf-pce-discovery-reqs-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, draft-ietf-pce-discovery-reqs-02.txt has been posted which addresses the remaining open issues and is now ready for working group last call (see the authors' email sent to the list for the detailed list of changes). This email initiates a working group last call on draft-ietf-pce- discovery-reqs-02.txt. The last call will end on Tuesday 27th October at 5pm EST. Please send your comments to the mailing list and copy the chairs. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Oct 13 15:36:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8sV-0007Kx-Sy; Thu, 13 Oct 2005 15:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8sS-0007Ko-FF for pce@megatron.ietf.org; Thu, 13 Oct 2005 15:36:33 -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 PAA07086 for ; Thu, 13 Oct 2005 15:36:27 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ92v-0004xw-TG for pce@ietf.org; Thu, 13 Oct 2005 15:47:28 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1129232145!8253912!9 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 31462 invoked from network); 13 Oct 2005 19:36:13 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-10.tower-120.messagelabs.com with SMTP; 13 Oct 2005 19:36:13 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4336CAB70030B224; Thu, 13 Oct 2005 15:36:11 -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] Selecting a PCE Communication Protocol - Pulling the threadstogether Date: Thu, 13 Oct 2005 14:36:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA945E@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Selecting a PCE Communication Protocol - Pulling the threadstogether Thread-Index: AcXPbBNT2Z40mrWVTSiHUBQ2kHcm+AAvo7ag From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Adrian, All, I think good arguments have been put forward for supporting PCEP as the selected protocol. And I'm OK to support PCEP too. However: > Scanning the mails on the list so far I see no strong support=20 > for COPS or HTTP. Well, I've not seen any response to your original request from those who nominated COPS and HTTP: "The best approach will be if supporters of the candidate protocols indicate (briefly) why their proposed protocol is suitable. It would also be helpful if they were frank about what the weaknesses of their proposal are." Also, I've not seen too many weaknesses pointed out RE PCEP :-) > If you are in support of either of these you will need to=20 > speak up. I know it can be worrying to stand in front of the IETF > juggernaut, but if you don't speak up you will not be heard. I > promise to support you. I've been kind of waiting to see a more balanced pros and cons debate, maybe others are as well. =20 > We have had several questions and issues about PCEP > (draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me > that these were deficiencies in the current specification of=20 > PCEP rather than intrinsic faults in the protocol, and that they could > be solved by the definition of appropriate objects. [Please disagree > loudly!] >=20 > We have had much discussion of why COPS and/or HTTP might not be > appropriate. Many of the reasons suggested have been refuted or argued > with, but this in itself does not amount to a case against PCEP, nor a > case for COPS or HTTP. Right, it would be good to hear the pros & cons on COPS & HTTP from the nominators. =20 > We have also had some questions about the function that a=20 > pcecp should or should not provide (for example, should a PCE be > able to connect to a PCC?). We need to do two things: > 1. Go back to the requirements I-D with these considerations and > add/remove them according to consensus. > 2. Examine the candidate protocols only against the=20 > requirements I-D and not against other putative requirements. >=20 > [Safety note: when I refer to vendors or service providers=20 > below, I do not mean to imply that an individual represents the > view of any corporation or that anyone participating in the IETF > does so other than as an individual.] >=20 > The bottom line that I see forming is that several vendors=20 > support PCEP by co-authoring, and several service providers express > interest in seeing this development so that they can further assess > the value of PCE. I also see strong interest expressed by at least > one vendor in producing an implementation. >=20 > In the end, while we must strive not to do things that break=20 > the Internet, we should also support the running code principle. If > the only proposal that anyone is willing to implement or experiment > with is Protocol X, then that is what we will choose unless it is > unfixably broken. Well, I guess we have implementations of COPS & HTTP also, extensions obviously needed to meet PCECP requirements... =20 > Failing further comment we appear to be on the verge of selecting PCEP > (draft-vasseur-pce-pcep-02.txt) >=20 > Note that the acceptance of one solution or another at this stage does > *NOT* imply that the solution is immune from significant changes. In > fact, once a solution is owned by the WG, I would expect to see a=20 > lot of input and modification especially from the implementers. >=20 > The discussion continues... Before deciding, IMO it would be better to have a more balanced pros & cons discussion with nominators/supporters of the other 2 candidates speaking up. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 09:56:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ2j-0000Bj-AA; Fri, 14 Oct 2005 09:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ2h-0000B4-Cd for pce@megatron.ietf.org; Fri, 14 Oct 2005 09:56:15 -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 JAA11457 for ; Fri, 14 Oct 2005 09:56:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQDQ-00048z-BE for pce@ietf.org; Fri, 14 Oct 2005 10:07:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2005 06:56:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208,217"; a="13202392:sNHT39258536" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EDtb2R000174; Fri, 14 Oct 2005 09:56:03 -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); Fri, 14 Oct 2005 09:55:57 -0400 Received: from [192.168.1.100] ([10.86.242.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:55:57 -0400 Mime-Version: 1.0 (Apple Message framework v734) To: pce@ietf.org Message-Id: <026BDCFC-9CB3-4D6C-85ED-19C27C61CA49@cisco.com> From: JP Vasseur Date: Fri, 14 Oct 2005 09:56:20 -0400 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 14 Oct 2005 13:55:57.0189 (UTC) FILETIME=[004AAB50:01C5D0C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Pce] Draft PCE WG Meeting agenda - IETF-64 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="===============0075181132==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0075181132== Content-Type: multipart/alternative; boundary=Apple-Mail-47-667125339 --Apple-Mail-47-667125339 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is the draft PCE WG meeting agenda. Duration: 150mn As a reminder, please bear in mind that the goal of meetings is not to "present" documents but to rather discuss open issues, this is why we have face to face meetings. 1) Agenda/admin (5mn) 2) PCE WG Milestone update (10mn) 3) PCE Discovery requirements draft (Jean-Louis Le Roux - 5mn) - if necessary 4) Discussion on the PCE Discovery protocol (JL Le Roux - 15mn) draft-leroux-pce-discovery-proto-00.txt 5) PCECP discussion and next steps (20mn) 6) Inter-area PCECP requirement draft (Jean-Louis Le Roux - 10mn) draft-leroux-pce-pcecp-multiarea-reqs-00.txt 7) Inter-AS/Provider PCE requirement draft (Nabil Bitar/Raymond Zhang - 10mn) draft-bitar-interas-PCE-req-00.txt 8) Discussion on inter-layer deployment scenario, similarities with inter-area/AS, application specific requirements draft-oki-pce-inter-layer-req-00.txt (Eiji Oki - 10mn) 9) Path Computation Policy draft-bryskin-pce-policy-enabled-path-comp-00.txt (Igor - 20mn) 10) Cost object draft-dolganow-pce-cost-object-00.txt (Andrew - 10mn) 11) Next Steps Presenters, could you please send us your slides by Nov 3rd ? Let us know if you have any comment. JP and Adrian. --Apple-Mail-47-667125339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Here is = the draft PCE WG meeting agenda.

Duration: = 150mn

As a = reminder, please bear in mind that the goal of meetings is not to = "present" documents but to rather discuss open issues, this is why we = have face to face meetings.

1) Agenda/admin (5mn)
2) PCE = WG Milestone update (10mn)
3) PCE = Discovery requirements draft (Jean-Louis Le Roux - 5mn) - if = necessary
4) Discussion on the PCE = Discovery protocol (JL Le Roux - 15mn)
=A0=A0 = =A0draft-leroux-pce-discovery-proto-00.txt
5) PCECP = discussion and next steps (20mn)
6) Inter-area = PCECP requirement draft (Jean-Louis Le Roux - 10mn)
=A0=A0 =A0draft-leroux-pce-pcecp-multiarea-reqs-00.txt
7) Inter-AS/Provider PCE requirement draft (Nabil = Bitar/Raymond Zhang - 10mn)
=A0=A0 = =A0draft-bitar-interas-PCE-req-00.txt
=A0=A0 =A0draft-oki-pce-inter-layer-req-00.txt=A0(Eiji= Oki - 10mn)
9) Path Computation = Policy=A0
=A0=A0 = =A0draft-bryskin-pce-policy-enabled-path-comp-00.txt (Igor - = 20mn)
10) Cost object
=A0=A0 = =A0draft-dolganow-pce-cost-object-00.txt =A0(Andrew - = 10mn)
11) Next Steps

Presenters, could you please send us your slides by = Nov 3rd ?

Let us know = if you have any comment.

JP and = Adrian.
= --Apple-Mail-47-667125339-- --===============0075181132== 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 --===============0075181132==-- From pce-bounces@lists.ietf.org Fri Oct 14 10:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQTL-0001xm-CU; Fri, 14 Oct 2005 10:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQTJ-0001xe-RA for pce@megatron.ietf.org; Fri, 14 Oct 2005 10:23: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 KAA13554 for ; Fri, 14 Oct 2005 10:23:40 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQe1-000530-FT for pce@ietf.org; Fri, 14 Oct 2005 10:34:51 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENfm3023300 for ; Fri, 14 Oct 2005 23:23:41 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENekx021985 for ; Fri, 14 Oct 2005 23:23:40 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENeBu021980 for ; Fri, 14 Oct 2005 23:23:40 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENd5G029164 for ; Fri, 14 Oct 2005 23:23:40 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENd9Z029157 for ; Fri, 14 Oct 2005 23:23:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENdBr005373 for ; Fri, 14 Oct 2005 23:23:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENch9027505 for ; Fri, 14 Oct 2005 23:23:39 +0900 (JST) Received: from imi.m.ecl.ntt.co.jp (imi.m.ecl.ntt.co.jp [129.60.5.233]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j9EENcWE027502 for ; Fri, 14 Oct 2005 23:23:38 +0900 (JST) Received: from [172.28.177.249] ([129.60.15.201]) by imi.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id j9EENamv012055 for ; Fri, 14 Oct 2005 23:23:37 +0900 (JST) Date: Fri, 14 Oct 2005 23:23:37 +0900 From: Eiji Oki To: pce@ietf.org Message-Id: <20051014230222.2244.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] draft-oki-pce-inter-layer-req-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, The following draft has been submitted for discussion at the next IETF meeting. Title: PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering URL: http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-req-00.txt Abstract: The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. We would very much appreciate your comments and suggestions. Thank you. Eiji _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 12:20:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSGX-0000N9-9G; Fri, 14 Oct 2005 12:18:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSGU-0000Mz-7L for pce@megatron.ietf.org; Fri, 14 Oct 2005 12:18: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 MAA27559 for ; Fri, 14 Oct 2005 12:18:33 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSRD-0002aA-SL for pce@ietf.org; Fri, 14 Oct 2005 12:29:45 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 2B06F64D6D; Fri, 14 Oct 2005 11:58:33 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id AA790AFA4; Fri, 14 Oct 2005 11:58:32 -0400 (EDT) Message-Id: <6.2.5.6.2.20051014115113.052f4f90@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Oct 2005 11:58:31 -0400 To: "JP Vasseur" From: Lou Berger Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <21C92240-1EB7-4D10-9C98-863838583E4A@cisco.com> References: <21C92240-1EB7-4D10-9C98-863838583E4A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 JP/All, One additional (late) comment, is that it seems to be a bit hard to always distinguish when PCE is used to mean "Path Computation the topic/architecture" and when it is used to mean "Path Computation the computing component". What do you think about distinguishing these two, maybe using something like: PCE when talking about the whole topic&architecture PCS when talking the computing/server component. This also provides symmetry to the PCC component. I'm not stuck on these, so any other solution that you and the other authors come up with should be fine. Lou At 06:51 PM 10/12/2005, JP Vasseur wrote: >Working Group, > >This ends the WG Last call on draft-ietf-pce-architecture-02.txt > >The only comments received were from Lou with regards to the Policy >section. > >The authors are planning to update the document after having >addressed Lou's comments. > >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 Fri Oct 14 13:49:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTgJ-00010c-D3; Fri, 14 Oct 2005 13:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTgH-00010X-BY for pce@megatron.ietf.org; Fri, 14 Oct 2005 13:49: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 NAA02660 for ; Fri, 14 Oct 2005 13:49:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTr1-00055j-LT for pce@ietf.org; Fri, 14 Oct 2005 14:00:29 -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 j9EHn5rP010636; Fri, 14 Oct 2005 13:49:05 -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 NAA16315; Fri, 14 Oct 2005 13:49:05 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 14:49:04 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F8D@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Lou Berger'" , JP Vasseur Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Fri, 14 Oct 2005 14:49:03 -0300 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: d185fa790257f526fedfd5d01ed9c976 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 Lou, On the surface, this seems like a reasonable idea. However, PCE stands for "Path Computation Engine" - which is far more intuitively related to a PCC-PCE relationship than referring to the whole thing (WG, Architecture, etc.) as an "Engine". Moreover, it will not save any work in the short term (over the more direct approach of simply making it explicit which is meant - if it is not already clear from context), since that will mean a re-spin of all the documents just to conform to the name change. Any TLA you care to some up with, is going to have its own unique problems. -- Eric --> -----Original Message----- --> From: pce-bounces@lists.ietf.org --> [mailto:pce-bounces@lists.ietf.org]On --> Behalf Of Lou Berger --> Sent: Friday, October 14, 2005 11:59 AM --> To: JP Vasseur --> Cc: pce@ietf.org --> Subject: Re: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> JP/All, --> One additional (late) comment, is that it seems to --> be a bit --> hard to always distinguish when PCE is used to mean "Path --> Computation --> the topic/architecture" and when it is used to mean "Path --> Computation --> the computing component". What do you think about distinguishing --> these two, maybe using something like: --> --> PCE when talking about the whole topic&architecture --> --> PCS when talking the computing/server component. --> --> This also provides symmetry to the PCC component. --> --> I'm not stuck on these, so any other solution that you and --> the other --> authors come up with should be fine. --> --> Lou --> --> At 06:51 PM 10/12/2005, JP Vasseur wrote: --> --> >Working Group, --> > --> >This ends the WG Last call on draft-ietf-pce-architecture-02.txt --> > --> >The only comments received were from Lou with regards to the Policy --> >section. --> > --> >The authors are planning to update the document after having --> >addressed Lou's comments. --> > --> >Thanks. --> > --> >JP. --> > --> >_______________________________________________ --> >Pce mailing list --> >Pce@lists.ietf.org --> >https://www1.ie tf.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 Fri Oct 14 14:07:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTyI-00078P-4Y; Fri, 14 Oct 2005 14:07:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTyG-00076k-I8 for pce@megatron.ietf.org; Fri, 14 Oct 2005 14: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 OAA03365 for ; Fri, 14 Oct 2005 14:07:51 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQU8x-0005TN-23 for pce@ietf.org; Fri, 14 Oct 2005 14:19:04 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1129313147!7158106!34 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 10461 invoked from network); 14 Oct 2005 18:07:41 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-3.tower-121.messagelabs.com with SMTP; 14 Oct 2005 18:07:41 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4336CAB70039DBB8; Fri, 14 Oct 2005 14:07:41 -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] WG Last Call ended on draft-ietf-pce-architecture-02.txt Date: Fri, 14 Oct 2005 13:07:41 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9472@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt Thread-Index: AcXQ58cfoUpxillMRv20bWt89wFgtQAAYjXA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Gray, Eric" , "Lou Berger" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Eric, Lou, > PCE stands for "Path Computation Engine" 'PCE' stands for 'Path Computation Element'. > PCS when talking the computing/server component. 'PCS' was the old name for 'PCE', however 'PCS' connotes too much a separate 'server' implementation of 'PCE' (which doesn't have to be a separate network element, but can be 'composite'), so 'PCS' terminology was replaced by 'PCE'. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 15:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVIj-0000Mb-OD; Fri, 14 Oct 2005 15:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVIi-0000MW-TR for pce@megatron.ietf.org; Fri, 14 Oct 2005 15:33: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 PAA06583 for ; Fri, 14 Oct 2005 15:33:03 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVTU-0007Kz-7l for pce@ietf.org; Fri, 14 Oct 2005 15:44:17 -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 j9EJWtrP013661; Fri, 14 Oct 2005 15:32:56 -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 PAA00444; Fri, 14 Oct 2005 15:32:55 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 16:32:55 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F92@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Ash, Gerald R (Jerry), ALABS'" , Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Fri, 14 Oct 2005 16:32:54 -0300 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Jerry, Yes, thanks for the correction. I realized I wasn't sure whether it was element or engine, right after I hit "send". It's always that way, you know... -- Eric --> -----Original Message----- --> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] --> Sent: Friday, October 14, 2005 2:08 PM --> To: Gray, Eric; Lou Berger --> Cc: Ash, Gerald R (Jerry), ALABS; pce@ietf.org --> Subject: RE: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> Eric, --> Lou, --> --> > PCE stands for "Path Computation Engine" --> --> 'PCE' stands for 'Path Computation Element'. --> --> > PCS when talking the computing/server component. --> --> 'PCS' was the old name for 'PCE', however 'PCS' connotes too much a --> separate 'server' implementation of 'PCE' (which doesn't --> have to be a --> separate network element, but can be 'composite'), so 'PCS' --> terminology --> was replaced by 'PCE'. --> --> Thanks, --> Jerry --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 16:23:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVwO-0007OA-Px; Fri, 14 Oct 2005 16:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVwM-0007N9-BF for pce@megatron.ietf.org; Fri, 14 Oct 2005 16:14:07 -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 QAA13754 for ; Fri, 14 Oct 2005 16:14:00 -0400 (EDT) Received: from h-67-102-145-11.mclnva23.covad.net ([67.102.145.11] helo=chameleon.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQW77-0001st-FF for pce@ietf.org; Fri, 14 Oct 2005 16:25:14 -0400 Received: from lb.movaz.com (IDENT:0@localhost [127.0.0.1]) by chameleon.movaz.com (8.12.4/8.12.4) with ESMTP id j9EIwOdC001301; Fri, 14 Oct 2005 14:58:24 -0400 Message-Id: <6.2.5.6.2.20051014160940.04a87c18@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Oct 2005 16:13:50 -0400 To: "Ash, Gerald R \(Jerry\), ALABS" From: Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9472@KCCLUST06EVS1.ugd .att.com> References: <9473683187ADC049A855ED2DA739ABCA09FA9472@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Gerry, Eric, So what term do you use when referring to the identification of paths using PCCs and PCEs? The architecture document seems to also call this PCE. Having PCE refer to the whole process and also to a component in the process seems to be very confusing, and it'll only get worse as time goes on and the amount of material and discussions increase. IMO it would be better to endure the small pain now to fix the limited set of documents we have now rather than having to endure all the pain and confusion for years to come. Lou At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), ALABS wrote: >Eric, >Lou, > > > PCE stands for "Path Computation Engine" > >'PCE' stands for 'Path Computation Element'. > > > PCS when talking the computing/server component. > >'PCS' was the old name for 'PCE', however 'PCS' connotes too much a >separate 'server' implementation of 'PCE' (which doesn't have to be a >separate network element, but can be 'composite'), so 'PCS' terminology >was replaced by 'PCE'. > >Thanks, >Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 16:25:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQW7Z-0008Iv-79; Fri, 14 Oct 2005 16:25:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQW7X-0008I4-QP for pce@megatron.ietf.org; Fri, 14 Oct 2005 16:25:40 -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 QAA19607 for ; Fri, 14 Oct 2005 16:25:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWID-00043V-Fs for pce@ietf.org; Fri, 14 Oct 2005 16:36:47 -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 j9EKPKrP014868; Fri, 14 Oct 2005 16:25:20 -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 QAA06011; Fri, 14 Oct 2005 16:25:20 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 17:25:19 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F95@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Lou Berger'" , "Ash, Gerald R (Jerry), ALABS" Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Fri, 14 Oct 2005 17:25:18 -0300 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Uh, PC (Path Computation)? MDPC (multi-domain path computation)? What do you think PCE itself stands for in this - larger - context? Certainly nothing intuitive. Rather than change an intuitively meaningful acronym to accommodate an arbitrary (and intuitively meaningless) misuse, why not stop using the acronym in the larger sense? -- Eric --> -----Original Message----- --> From: Lou Berger [mailto:lberger@movaz.com] --> Sent: Friday, October 14, 2005 4:14 PM --> To: Ash, Gerald R (Jerry), ALABS --> Cc: Gray, Eric; Berger, Lou; Ash, Gerald R (Jerry), ALABS; --> pce@ietf.org --> Subject: RE: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> Gerry, Eric, --> So what term do you use when referring to the --> identification --> of paths using PCCs and PCEs? The architecture document seems to --> also call this PCE. --> --> Having PCE refer to the whole process and also to a --> component in the --> process seems to be very confusing, and it'll only get --> worse as time --> goes on and the amount of material and discussions increase. IMO it --> would be better to endure the small pain now to fix the limited set --> of documents we have now rather than having to endure all the pain --> and confusion for years to come. --> --> Lou --> --> At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), ALABS wrote: --> --> >Eric, --> >Lou, --> > --> > > PCE stands for "Path Computation Engine" --> > --> >'PCE' stands for 'Path Computation Element'. --> > --> > > PCS when talking the computing/server component. --> > --> >'PCS' was the old name for 'PCE', however 'PCS' connotes too much a --> >separate 'server' implementation of 'PCE' (which doesn't --> have to be a --> >separate network element, but can be 'composite'), so --> 'PCS' terminology --> >was replaced by 'PCE'. --> > --> >Thanks, --> >Jerry --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 16:31:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWDR-0005Dq-Tb; Fri, 14 Oct 2005 16:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWDR-0005BZ-2H for pce@megatron.ietf.org; Fri, 14 Oct 2005 16:31: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 QAA22220 for ; Fri, 14 Oct 2005 16:31:39 -0400 (EDT) Received: from h-67-102-145-11.mclnva23.covad.net ([67.102.145.11] helo=chameleon.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWO9-00055J-Kw for pce@ietf.org; Fri, 14 Oct 2005 16:42:54 -0400 Received: from lb.movaz.com (IDENT:0@localhost [127.0.0.1]) by chameleon.movaz.com (8.12.4/8.12.4) with ESMTP id j9EJG3dC001337; Fri, 14 Oct 2005 15:16:03 -0400 Message-Id: <6.2.5.6.2.20051014162953.05b6fe20@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Oct 2005 16:31:29 -0400 To: "Gray, Eric" From: Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F95@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885F95@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 At 04:25 PM 10/14/2005, Gray, Eric wrote: >Uh, PC (Path Computation)? MDPC (multi-domain path computation)? > >What do you think PCE itself stands for in this - larger - context? >Certainly nothing intuitive. precisely the point! >Rather than change an intuitively meaningful acronym to accommodate >an arbitrary (and intuitively meaningless) misuse, why not stop using >the acronym in the larger sense? I'm completely fine with this. So does the "PCE Architecture" document become "PC Architecture"? Lou >-- >Eric > >--> -----Original Message----- >--> From: Lou Berger [mailto:lberger@movaz.com] >--> Sent: Friday, October 14, 2005 4:14 PM >--> To: Ash, Gerald R (Jerry), ALABS >--> Cc: Gray, Eric; Berger, Lou; Ash, Gerald R (Jerry), ALABS; >--> pce@ietf.org >--> Subject: RE: [Pce] WG Last Call ended on >--> draft-ietf-pce-architecture-02.txt >--> >--> >--> Gerry, Eric, >--> So what term do you use when referring to the >--> identification >--> of paths using PCCs and PCEs? The architecture document seems to >--> also call this PCE. >--> >--> Having PCE refer to the whole process and also to a >--> component in the >--> process seems to be very confusing, and it'll only get >--> worse as time >--> goes on and the amount of material and discussions increase. IMO it >--> would be better to endure the small pain now to fix the limited set >--> of documents we have now rather than having to endure all the pain >--> and confusion for years to come. >--> >--> Lou >--> >--> At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), ALABS wrote: >--> >--> >Eric, >--> >Lou, >--> > >--> > > PCE stands for "Path Computation Engine" >--> > >--> >'PCE' stands for 'Path Computation Element'. >--> > >--> > > PCS when talking the computing/server component. >--> > >--> >'PCS' was the old name for 'PCE', however 'PCS' connotes too much a >--> >separate 'server' implementation of 'PCE' (which doesn't >--> have to be a >--> >separate network element, but can be 'composite'), so >--> 'PCS' terminology >--> >was replaced by 'PCE'. >--> > >--> >Thanks, >--> >Jerry >--> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 17:27:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQX55-0000fn-1m; Fri, 14 Oct 2005 17:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQX53-0000fd-Mw for pce@megatron.ietf.org; Fri, 14 Oct 2005 17:27: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 RAA26307 for ; Fri, 14 Oct 2005 17:27:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXFq-0006wq-TO for pce@ietf.org; Fri, 14 Oct 2005 17:38:19 -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 j9ELQwrP016134; Fri, 14 Oct 2005 17:26:58 -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 RAA11782; Fri, 14 Oct 2005 17:26:58 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 18:26:57 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F97@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Lou Berger'" , "Gray, Eric" Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Fri, 14 Oct 2005 18:26:55 -0300 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: 34d35111647d654d033d58d318c0d21a 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 Lou, MDPC Architecture is less misleading... -- Eric --> -----Original Message----- --> From: Lou Berger [mailto:lberger@movaz.com] --> Sent: Friday, October 14, 2005 4:31 PM --> To: Gray, Eric --> Cc: Berger, Lou; Ash, Gerald R (Jerry), ALABS; Gray, Eric; --> Ash, Gerald R --> (Jerry), ALABS; pce@ietf.org --> Subject: RE: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> At 04:25 PM 10/14/2005, Gray, Eric wrote: --> --> >Uh, PC (Path Computation)? MDPC (multi-domain path computation)? --> > --> >What do you think PCE itself stands for in this - larger - context? --> >Certainly nothing intuitive. --> --> precisely the point! --> --> >Rather than change an intuitively meaningful acronym to accommodate --> >an arbitrary (and intuitively meaningless) misuse, why not --> stop using --> >the acronym in the larger sense? --> --> I'm completely fine with this. So does the "PCE Architecture" --> document become "PC Architecture"? --> --> Lou --> --> >-- --> >Eric --> > --> >--> -----Original Message----- --> >--> From: Lou Berger --> [mailto:lberger@movaz.com] --> >--> Sent: Friday, October 14, 2005 4:14 PM --> >--> To: Ash, Gerald R (Jerry), ALABS --> >--> Cc: Gray, Eric; Berger, Lou; Ash, Gerald R (Jerry), ALABS; --> >--> pce@ietf.org --> >--> Subject: RE: [Pce] WG Last Call ended on --> >--> draft-ietf-pce-architecture-02.txt --> >--> --> >--> --> >--> Gerry, Eric, --> >--> So what term do you use when referring to the --> >--> identification --> >--> of paths using PCCs and PCEs? The architecture --> document seems to --> >--> also call this PCE. --> >--> --> >--> Having PCE refer to the whole process and also to a --> >--> component in the --> >--> process seems to be very confusing, and it'll only get --> >--> worse as time --> >--> goes on and the amount of material and discussions --> increase. IMO it --> >--> would be better to endure the small pain now to fix --> the limited set --> >--> of documents we have now rather than having to endure --> all the pain --> >--> and confusion for years to come. --> >--> --> >--> Lou --> >--> --> >--> At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), ALABS wrote: --> >--> --> >--> >Eric, --> >--> >Lou, --> >--> > --> >--> > > PCE stands for "Path Computation Engine" --> >--> > --> >--> >'PCE' stands for 'Path Computation Element'. --> >--> > --> >--> > > PCS when talking the computing/server component. --> >--> > --> >--> >'PCS' was the old name for 'PCE', however 'PCS' --> connotes too much a --> >--> >separate 'server' implementation of 'PCE' (which doesn't --> >--> have to be a --> >--> >separate network element, but can be 'composite'), so --> >--> 'PCS' terminology --> >--> >was replaced by 'PCE'. --> >--> > --> >--> >Thanks, --> >--> >Jerry --> >--> --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 17: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 1EQX7z-0001dU-IU; Fri, 14 Oct 2005 17:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQX7x-0001c6-6d for pce@megatron.ietf.org; Fri, 14 Oct 2005 17:30: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 RAA26878 for ; Fri, 14 Oct 2005 17:30:04 -0400 (EDT) Received: from h-67-102-145-11.mclnva23.covad.net ([67.102.145.11] helo=chameleon.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXIh-0007Aj-QX for pce@ietf.org; Fri, 14 Oct 2005 17:41:18 -0400 Received: from lb.movaz.com (IDENT:0@localhost [127.0.0.1]) by chameleon.movaz.com (8.12.4/8.12.4) with ESMTP id j9EKESdC001436; Fri, 14 Oct 2005 16:14:29 -0400 Message-Id: <6.2.5.6.2.20051014172935.04923f98@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Oct 2005 17:29:54 -0400 To: "Gray, Eric" From: Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F97@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885F97@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 humm, can't it be used within a single domain? Lou At 05:26 PM 10/14/2005, Gray, Eric wrote: >Lou, > > MDPC Architecture is less misleading... > >-- >Eric > >--> -----Original Message----- >--> From: Lou Berger [mailto:lberger@movaz.com] >--> Sent: Friday, October 14, 2005 4:31 PM >--> To: Gray, Eric >--> Cc: Berger, Lou; Ash, Gerald R (Jerry), ALABS; Gray, Eric; >--> Ash, Gerald R >--> (Jerry), ALABS; pce@ietf.org >--> Subject: RE: [Pce] WG Last Call ended on >--> draft-ietf-pce-architecture-02.txt >--> >--> >--> At 04:25 PM 10/14/2005, Gray, Eric wrote: >--> >--> >Uh, PC (Path Computation)? MDPC (multi-domain path computation)? >--> > >--> >What do you think PCE itself stands for in this - larger - context? >--> >Certainly nothing intuitive. >--> >--> precisely the point! >--> >--> >Rather than change an intuitively meaningful acronym to accommodate >--> >an arbitrary (and intuitively meaningless) misuse, why not >--> stop using >--> >the acronym in the larger sense? >--> >--> I'm completely fine with this. So does the "PCE Architecture" >--> document become "PC Architecture"? >--> >--> Lou >--> >--> >-- >--> >Eric >--> > >--> >--> -----Original Message----- >--> >--> From: Lou Berger >--> >[<mailto:lberger@movaz.com>mailto:lberger@movaz.com] >--> >--> Sent: Friday, October 14, 2005 4:14 PM >--> >--> To: Ash, Gerald R (Jerry), ALABS >--> >--> Cc: Gray, Eric; Berger, Lou; Ash, Gerald R (Jerry), ALABS; >--> >--> pce@ietf.org >--> >--> Subject: RE: [Pce] WG Last Call ended on >--> >--> draft-ietf-pce-architecture-02.txt >--> >--> >--> >--> >--> >--> Gerry, Eric, >--> >--> So what term do you use when referring to the >--> >--> identification >--> >--> of paths using PCCs and PCEs? The architecture >--> document seems to >--> >--> also call this PCE. >--> >--> >--> >--> Having PCE refer to the whole process and also to a >--> >--> component in the >--> >--> process seems to be very confusing, and it'll only get >--> >--> worse as time >--> >--> goes on and the amount of material and discussions >--> increase. IMO it >--> >--> would be better to endure the small pain now to fix >--> the limited set >--> >--> of documents we have now rather than having to endure >--> all the pain >--> >--> and confusion for years to come. >--> >--> >--> >--> Lou >--> >--> >--> >--> At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), ALABS wrote: >--> >--> >--> >--> >Eric, >--> >--> >Lou, >--> >--> > >--> >--> > > PCE stands for "Path Computation Engine" >--> >--> > >--> >--> >'PCE' stands for 'Path Computation Element'. >--> >--> > >--> >--> > > PCS when talking the computing/server component. >--> >--> > >--> >--> >'PCS' was the old name for 'PCE', however 'PCS' >--> connotes too much a >--> >--> >separate 'server' implementation of 'PCE' (which doesn't >--> >--> have to be a >--> >--> >separate network element, but can be 'composite'), so >--> >--> 'PCS' terminology >--> >--> >was replaced by 'PCE'. >--> >--> > >--> >--> >Thanks, >--> >--> >Jerry >--> >--> >--> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 14 18:06:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXhR-0001m7-2t; Fri, 14 Oct 2005 18:06:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQXhQ-0001lE-9y for pce@megatron.ietf.org; Fri, 14 Oct 2005 18:06:48 -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 SAA29610 for ; Fri, 14 Oct 2005 18:06:43 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQXsD-0008S1-N1 for pce@ietf.org; Fri, 14 Oct 2005 18:17:58 -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 j9EM6brP016718; Fri, 14 Oct 2005 18:06:37 -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 SAA14677; Fri, 14 Oct 2005 18:06:37 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 19:06:36 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Lou Berger'" , "Gray, Eric" Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Fri, 14 Oct 2005 19:06:33 -0300 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: b2809b6f39decc6de467dcf252f42af1 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 Lou, What would be the point? Then it is merely a traffic engineer application. -- Eric --> -----Original Message----- --> From: Lou Berger [mailto:lberger@movaz.com] --> Sent: Friday, October 14, 2005 5:30 PM --> To: Gray, Eric --> Cc: Berger, Lou; Gray, Eric; Ash, Gerald R (Jerry), ALABS; --> Gray, Eric; --> Ash, Gerald R (Jerry), ALABS; pce@ietf.org --> Subject: RE: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> humm, can't it be used within a single domain? --> --> Lou --> --> At 05:26 PM 10/14/2005, Gray, Eric wrote: --> --> >Lou, --> > --> > MDPC Architecture is less misleading... --> > --> >-- --> >Eric --> > --> >--> -----Original Message----- --> >--> From: Lou Berger --> [mailto:lberger@movaz.com] --> >--> Sent: Friday, October 14, 2005 4:31 PM --> >--> To: Gray, Eric --> >--> Cc: Berger, Lou; Ash, Gerald R (Jerry), ALABS; Gray, Eric; --> >--> Ash, Gerald R --> >--> (Jerry), ALABS; pce@ietf.org --> >--> Subject: RE: [Pce] WG Last Call ended on --> >--> draft-ietf-pce-architecture-02.txt --> >--> --> >--> --> >--> At 04:25 PM 10/14/2005, Gray, Eric wrote: --> >--> --> >--> >Uh, PC (Path Computation)? MDPC (multi-domain path --> computation)? --> >--> > --> >--> >What do you think PCE itself stands for in this - --> larger - context? --> >--> >Certainly nothing intuitive. --> >--> --> >--> precisely the point! --> >--> --> >--> >Rather than change an intuitively meaningful acronym --> to accommodate --> >--> >an arbitrary (and intuitively meaningless) misuse, why not --> >--> stop using --> >--> >the acronym in the larger sense? --> >--> --> >--> I'm completely fine with this. So does the "PCE Architecture" --> >--> document become "PC Architecture"? --> >--> --> >--> Lou --> >--> --> >--> >-- --> >--> >Eric --> >--> > --> >--> >--> -----Original Message----- --> >--> >--> From: Lou Berger --> >--> --> >[<mailto:lberger@movaz.com>mailto :lberger@movaz.com] --> >--> >--> Sent: Friday, October 14, 2005 4:14 PM --> >--> >--> To: Ash, Gerald R (Jerry), ALABS --> >--> >--> Cc: Gray, Eric; Berger, Lou; Ash, Gerald R (Jerry), ALABS; --> >--> >--> pce@ietf.org --> >--> >--> Subject: RE: [Pce] WG Last Call ended on --> >--> >--> draft-ietf-pce-architecture-02.txt --> >--> >--> --> >--> >--> --> >--> >--> Gerry, Eric, --> >--> >--> So what term do you use when referring to the --> >--> >--> identification --> >--> >--> of paths using PCCs and PCEs? The architecture --> >--> document seems to --> >--> >--> also call this PCE. --> >--> >--> --> >--> >--> Having PCE refer to the whole process and also to a --> >--> >--> component in the --> >--> >--> process seems to be very confusing, and it'll only get --> >--> >--> worse as time --> >--> >--> goes on and the amount of material and discussions --> >--> increase. IMO it --> >--> >--> would be better to endure the small pain now to fix --> >--> the limited set --> >--> >--> of documents we have now rather than having to endure --> >--> all the pain --> >--> >--> and confusion for years to come. --> >--> >--> --> >--> >--> Lou --> >--> >--> --> >--> >--> At 02:07 PM 10/14/2005, Ash, Gerald R \(Jerry\), --> ALABS wrote: --> >--> >--> --> >--> >--> >Eric, --> >--> >--> >Lou, --> >--> >--> > --> >--> >--> > > PCE stands for "Path Computation Engine" --> >--> >--> > --> >--> >--> >'PCE' stands for 'Path Computation Element'. --> >--> >--> > --> >--> >--> > > PCS when talking the computing/server component. --> >--> >--> > --> >--> >--> >'PCS' was the old name for 'PCE', however 'PCS' --> >--> connotes too much a --> >--> >--> >separate 'server' implementation of 'PCE' (which doesn't --> >--> >--> have to be a --> >--> >--> >separate network element, but can be 'composite'), so --> >--> >--> 'PCS' terminology --> >--> >--> >was replaced by 'PCE'. --> >--> >--> > --> >--> >--> >Thanks, --> >--> >--> >Jerry --> >--> >--> --> >--> --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Oct 15 12:19:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQokw-0002rD-4f; Sat, 15 Oct 2005 12:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQokt-0002qz-NG for pce@megatron.ietf.org; Sat, 15 Oct 2005 12:19: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 MAA15952 for ; Sat, 15 Oct 2005 12:19:26 -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 1EQovq-0007Nk-1f for pce@ietf.org; Sat, 15 Oct 2005 12:30:51 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2005 09:19:21 -0700 X-IronPort-AV: i="3.97,216,1125903600"; d="scan'208"; a="666446764:sNHT22125832" 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 j9FGJI94024423; Sat, 15 Oct 2005 09:19:19 -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); Sat, 15 Oct 2005 12:19:18 -0400 Received: from [192.168.1.100] ([10.86.240.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 12:19:17 -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: Sat, 15 Oct 2005 12:19:41 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 15 Oct 2005 16:19:17.0675 (UTC) FILETIME=[30FE6FB0:01C5D1A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [Pce] PCE WG Meeting Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, The agenda of our next PCE WG meeting has been posted: https:// datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 16 13:00:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBrk-0003tT-H7; Sun, 16 Oct 2005 13:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERBre-0003ow-FK for pce@megatron.ietf.org; Sun, 16 Oct 2005 13:00: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 MAA10609 for ; Sun, 16 Oct 2005 12:59:54 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERC2k-0007sV-TW for pce@ietf.org; Sun, 16 Oct 2005 13:11: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 69CFE48886; Sun, 16 Oct 2005 12:59:23 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 3EBFCB058; Sat, 15 Oct 2005 10:57:02 -0400 (EDT) Message-Id: <6.2.5.6.2.20051015105343.05eb4c78@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 15 Oct 2005 10:57:01 -0400 To: "Gray, Eric" From: Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lberger@labn.net, 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 At 06:06 PM 10/14/2005, Gray, Eric wrote: >Lou, > > What would be the point? Then it is merely a traffic >engineer application. > >-- >Eric Eric, The PCE Architecture doesn't limit PCE to multi-domain networks. to quote: "... Path computation in large, multi-domain, multi-region or multi-layer networks is complex and may require special computational components and cooperation between the different network domains." Lou _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 16 18:22:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERGtJ-0002fQ-E9; Sun, 16 Oct 2005 18:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERGtI-0002f5-Oj for pce@megatron.ietf.org; Sun, 16 Oct 2005 18:22: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 SAA27939 for ; Sun, 16 Oct 2005 18:21:57 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERH4U-0007xn-Kc for pce@ietf.org; Sun, 16 Oct 2005 18:33:40 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 3181AE00006C; Sun, 16 Oct 2005 23:21:36 +0100 (BST) Received: from Puppy ([205.252.31.205] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 23:20:13 +0100 Message-ID: <00e401c5d2a0$2f9e48f0$cd1ffccd@Puppy> From: "Adrian Farrel" To: "Gray, Eric" , "Lou Berger" References: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com> <6.2.5.6.2.20051015105343.05eb4c78@movaz.com> Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt Date: Sun, 16 Oct 2005 23:22:21 +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-OriginalArrivalTime: 16 Oct 2005 22:20:13.0287 (UTC) FILETIME=[C7285770:01C5D29F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: lberger@labn.net, 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 Hello, Nice to see some bandwidth being used. "PCE Architecture" -- an architecture that includes a PCE. "PCE" -- something that performs path computation. "PCC" -- something that requests path computation. In the Abstract... This document specifies the architecture for a Path Computation Element (PCE)-based model. Is it really necessary to then state... "We will term this architecture the PCE Architecture" ? I believe that at no other point in the architecture document is there a reference to "PCE" that means "PCE architecture" except it says explicitly "PCE architecture". I would be happy for you to point out places where this is a problem. In other documents (such as draft-ietf-pce-comm-protocol-gen-reqs-02.txt) appear to make exactly the same distinction. Thus, there is no use of the term "PCE" to mean an architecture. It is always used to mean a network element. There is no need to (re-)introduce the term "PCS" because it is isomorphic to "PCE" as currently defined. Thanks, Adrian ----- Original Message ----- From: "Lou Berger" To: "Gray, Eric" Cc: ; Sent: Saturday, October 15, 2005 3:57 PM Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt > > At 06:06 PM 10/14/2005, Gray, Eric wrote: > >Lou, > > > > What would be the point? Then it is merely a traffic > >engineer application. > > > >-- > >Eric > > Eric, > The PCE Architecture doesn't limit PCE to multi-domain > networks. to quote: > "... Path computation in large, multi-domain, multi-region or > multi-layer networks is complex and may require special > computational components and cooperation between the different > network domains." > > 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 Sun Oct 16 19:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHbr-0007Ew-Vc; Sun, 16 Oct 2005 19:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHbq-0007Ep-Ce for pce@megatron.ietf.org; Sun, 16 Oct 2005 19:08: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 TAA01488 for ; Sun, 16 Oct 2005 19:07:58 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERHn1-0000p2-Pj for pce@ietf.org; Sun, 16 Oct 2005 19:19:42 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id E436C6273E; Sun, 16 Oct 2005 19:07:54 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id A859BAF6F; Sun, 16 Oct 2005 19:07:49 -0400 (EDT) Message-Id: <6.2.5.6.2.20051016190308.06018228@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 16 Oct 2005 19:07:50 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <00e401c5d2a0$2f9e48f0$cd1ffccd@Puppy> References: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com> <6.2.5.6.2.20051015105343.05eb4c78@movaz.com> <00e401c5d2a0$2f9e48f0$cd1ffccd@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: lberger@labn.net, 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, but we have many existence proofs that having a name to refer to a technology that isn't simply a piece of the instantiation of the technology is goodness, routing!=ospf architecture, MPLS != routing architecture, signaling != rsvp/ldp architecture... I can live with what we have but think we're going to have more confusion and terminology arguments as a result. Lou PS so what do you call the architecture of a device that is a PCE, PCE device architecture? At 06:22 PM 10/16/2005, Adrian Farrel wrote: >Hello, > >Nice to see some bandwidth being used. > >"PCE Architecture" -- an architecture that includes a PCE. > >"PCE" -- something that performs path computation. > >"PCC" -- something that requests path computation. > >In the Abstract... > This document specifies the architecture for a Path Computation > Element (PCE)-based model. > >Is it really necessary to then state... "We will term this architecture >the PCE Architecture" ? > >I believe that at no other point in the architecture document is there a >reference to "PCE" that means "PCE architecture" except it says explicitly >"PCE architecture". I would be happy for you to point out places where >this is a problem. > >In other documents (such as draft-ietf-pce-comm-protocol-gen-reqs-02.txt) >appear to make exactly the same distinction. > >Thus, there is no use of the term "PCE" to mean an architecture. It is >always used to mean a network element. There is no need to (re-)introduce >the term "PCS" because it is isomorphic to "PCE" as currently defined. > >Thanks, >Adrian > > >----- Original Message ----- >From: "Lou Berger" >To: "Gray, Eric" >Cc: ; >Sent: Saturday, October 15, 2005 3:57 PM >Subject: RE: [Pce] WG Last Call ended on >draft-ietf-pce-architecture-02.txt > > > > > At 06:06 PM 10/14/2005, Gray, Eric wrote: > > >Lou, > > > > > > What would be the point? Then it is merely a traffic > > >engineer application. > > > > > >-- > > >Eric > > > > Eric, > > The PCE Architecture doesn't limit PCE to multi-domain > > networks. to quote: > > "... Path computation in large, multi-domain, multi-region or > > multi-layer networks is complex and may require special > > computational components and cooperation between the different > > network domains." > > > > 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 Mon Oct 17 09:22:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUwD-0005po-HX; Mon, 17 Oct 2005 09:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUwC-0005m3-1s for pce@megatron.ietf.org; Mon, 17 Oct 2005 09:22: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 JAA11714 for ; Mon, 17 Oct 2005 09:21:53 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERV7W-0005mf-1h for pce@ietf.org; Mon, 17 Oct 2005 09:33:43 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 2451255181; Mon, 17 Oct 2005 09:21:49 -0400 (EDT) Message-ID: <009c01c5d31d$ba2cd5e0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Adrian Farrel" , "Gray, Eric" , "Lou Berger" References: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com><6.2.5.6.2.20051015105343.05eb4c78@movaz.com> <00e401c5d2a0$2f9e48f0$cd1ffccd@Puppy> Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt Date: Mon, 17 Oct 2005 09:21:05 -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: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: lberger@labn.net, 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, My personal preferrences: PCE - Path Computation Entity - entity involved in PCE Architecture, a common term for PCS and PCC PCC - Path Computation Client - entity requesting path computation PCS - Path Computation Server - entity that can satisfy path computation request In your view PCE = PCS, and hence PCE Architecture is still mostly about servers. Yes, you did put a section about PCC, but PCC is still kind of a step-son compared to PCS. I beileve PCC is as important as PCS, and PCE architecture is about PCCs as about PCSs. Therefore, PCS is a tighter and less confusing term for the path computation server than PCE. Igor ----- Original Message ----- From: "Adrian Farrel" To: "Gray, Eric" ; "Lou Berger" Cc: ; Sent: Sunday, October 16, 2005 6:22 PM Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt > Hello, > > Nice to see some bandwidth being used. > > "PCE Architecture" -- an architecture that includes a PCE. > > "PCE" -- something that performs path computation. > > "PCC" -- something that requests path computation. > > In the Abstract... > This document specifies the architecture for a Path Computation > Element (PCE)-based model. > > Is it really necessary to then state... "We will term this architecture > the PCE Architecture" ? > > I believe that at no other point in the architecture document is there a > reference to "PCE" that means "PCE architecture" except it says explicitly > "PCE architecture". I would be happy for you to point out places where > this is a problem. > > In other documents (such as draft-ietf-pce-comm-protocol-gen-reqs-02.txt) > appear to make exactly the same distinction. > > > Thus, there is no use of the term "PCE" to mean an architecture. It is > always used to mean a network element. There is no need to (re-)introduce > the term "PCS" because it is isomorphic to "PCE" as currently defined. > > Thanks, > Adrian > > > > ----- Original Message ----- > From: "Lou Berger" > To: "Gray, Eric" > Cc: ; > Sent: Saturday, October 15, 2005 3:57 PM > Subject: RE: [Pce] WG Last Call ended on > draft-ietf-pce-architecture-02.txt > > > > > > At 06:06 PM 10/14/2005, Gray, Eric wrote: > > >Lou, > > > > > > What would be the point? Then it is merely a traffic > > >engineer application. > > > > > >-- > > >Eric > > > > Eric, > > The PCE Architecture doesn't limit PCE to multi-domain > > networks. to quote: > > "... Path computation in large, multi-domain, multi-region or > > multi-layer networks is complex and may require special > > computational components and cooperation between the different > > network domains." > > > > 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 > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Oct 17 09:34:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV8Z-0007x2-Oh; Mon, 17 Oct 2005 09:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV8Y-0007wZ-Qx for pce@megatron.ietf.org; Mon, 17 Oct 2005 09:34: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 JAA12391 for ; Mon, 17 Oct 2005 09:34:39 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVJr-00066X-PT for pce@ietf.org; Mon, 17 Oct 2005 09:46:30 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2005 06:34:32 -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 j9HDXuv3005842; Mon, 17 Oct 2005 06:34:29 -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); Mon, 17 Oct 2005 09:34:26 -0400 Received: from [192.168.1.100] ([10.86.240.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 09:34:25 -0400 In-Reply-To: <009c01c5d31d$ba2cd5e0$7a1810ac@movaz.com> References: <313680C9A886D511A06000204840E1CF0C885F9B@whq-msgusr-02.pit.comms.marconi.com><6.2.5.6.2.20051015105343.05eb4c78@movaz.com> <00e401c5d2a0$2f9e48f0$cd1ffccd@Puppy> <009c01c5d31d$ba2cd5e0$7a1810ac@movaz.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A413E89-2EC2-410A-AA42-9C3CEAEFF047@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt Date: Mon, 17 Oct 2005 09:34:48 -0400 To: Igor Bryskin X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 17 Oct 2005 13:34:25.0922 (UTC) FILETIME=[7DE03620:01C5D31F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: lberger@labn.net, 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 Igor, On Oct 17, 2005, at 9:21 AM, Igor Bryskin wrote: > Adrian, > > My personal preferrences: > > PCE - Path Computation Entity - entity involved in PCE Architecture, a > common term for PCS and PCC > PCC - Path Computation Client - entity requesting path computation > PCS - Path Computation Server - entity that can satisfy path > computation > request > > In your view PCE = PCS, and hence PCE Architecture is still mostly > about > servers. Yes, you did put a section about PCC, but PCC is still > kind of a > step-son compared to PCS. I beileve PCC is as important as PCS, and > PCE > architecture is about PCCs as about PCSs. Therefore, PCS is a > tighter and > less confusing term for the path computation server than PCE. > I fully agree with Adrian: there is no need to re-introduce the term PCS here which by the way did generate a lot a confusion several years ago. Thanks. JP. > Igor > > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Gray, Eric" ; "Lou Berger" > > Cc: ; > Sent: Sunday, October 16, 2005 6:22 PM > Subject: Re: [Pce] WG Last Call ended on draft-ietf-pce- > architecture-02.txt > > > >> Hello, >> >> Nice to see some bandwidth being used. >> >> "PCE Architecture" -- an architecture that includes a PCE. >> >> "PCE" -- something that performs path computation. >> >> "PCC" -- something that requests path computation. >> >> In the Abstract... >> This document specifies the architecture for a Path Computation >> Element (PCE)-based model. >> >> Is it really necessary to then state... "We will term this >> architecture >> the PCE Architecture" ? >> >> I believe that at no other point in the architecture document is >> there a >> reference to "PCE" that means "PCE architecture" except it says >> explicitly >> "PCE architecture". I would be happy for you to point out places >> where >> this is a problem. >> >> In other documents (such as draft-ietf-pce-comm-protocol-gen- >> reqs-02.txt) >> appear to make exactly the same distinction. >> >> >> Thus, there is no use of the term "PCE" to mean an architecture. >> It is >> always used to mean a network element. There is no need to (re-) >> introduce >> the term "PCS" because it is isomorphic to "PCE" as currently >> defined. >> >> Thanks, >> Adrian >> >> >> >> ----- Original Message ----- >> From: "Lou Berger" >> To: "Gray, Eric" >> Cc: ; >> Sent: Saturday, October 15, 2005 3:57 PM >> Subject: RE: [Pce] WG Last Call ended on >> draft-ietf-pce-architecture-02.txt >> >> >> >>> >>> At 06:06 PM 10/14/2005, Gray, Eric wrote: >>> >>>> Lou, >>>> >>>> What would be the point? Then it is merely a traffic >>>> engineer application. >>>> >>>> -- >>>> Eric >>>> >>> >>> Eric, >>> The PCE Architecture doesn't limit PCE to multi-domain >>> networks. to quote: >>> "... Path computation in large, multi-domain, multi-region or >>> multi-layer networks is complex and may require special >>> computational components and cooperation between the different >>> network domains." >>> >>> 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 >> >> > > > _______________________________________________ > 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 Oct 18 09:33:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrbH-0003b8-Ii; Tue, 18 Oct 2005 09:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrbF-0003Zx-Pv for pce@megatron.ietf.org; Tue, 18 Oct 2005 09:33: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 JAA29915 for ; Tue, 18 Oct 2005 09:33: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 1ERrmn-0005Ir-FM for pce@ietf.org; Tue, 18 Oct 2005 09:45:49 -0400 Received: from CAOTTN01855 (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j9IDXcTX021314; Tue, 18 Oct 2005 09:33:38 -0400 (EDT) Message-Id: <200510181333.j9IDXcTX021314@tm2.ca.alcatel.com> From: "Andrew Dolganow" To: Date: Tue, 18 Oct 2005 09:32:39 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C5D3C6.E28C5480" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcXTVwPXwnITnkd0QXylAw6spNWA8AAj5bxg X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ccamp@ops.ietf.org Subject: [Pce] FW: I-D ACTION:draft-dolganow-pce-cost-object-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Please find attach the new draft proposing a cost object to accumulate TE-LSP path cost. As per the below abstract, the draft proposes changes to PCEP and RSVP. A single draft has been created to focus initial technical discussions around the single point of reference. It is the intend of the authors to split the draft later on into 2 separate drafts (as marked in the draft). Section 8 of the document list future work items intended to be handled by the authors as part of this technical topic. Any comments are welcome. Please address those comments to the PCE WG list for now, again to ensure that we have a single forum on which the discussions take place, and so nobody accidentally misses on something. Cheers, Andrew -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 17, 2005 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-dolganow-pce-cost-object-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A new object to specify a Traffic Engineering (TE) Label Switch Path (LSP) cost Author(s) : A. Dolganow, J. Vasseur Filename : draft-dolganow-pce-cost-object-00.txt Pages : 11 Date : 2005-10-17 This document proposes a new object (named the COST object) used to specify the cost of a Traffic Engineering (TE) Label Switched Path (LSP). The COST object can be carried within an RSVP message so as to record a TE LSP cost during LSP establishment or within a Path Computation Element (PCE) path computation protocol message so as to provide the cost of a computed path to a Path Computation Client (PCC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolganow-pce-cost-object-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dolganow-pce-cost-object-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dolganow-pce-cost-object-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="ATT00179.dat" Content-Disposition: attachment; filename="ATT00179.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dolganow-pce-cost-object-00.txt ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: Message/External-body; name="draft-dolganow-pce-cost-object-00.txt" Content-Disposition: attachment; filename="draft-dolganow-pce-cost-object-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-10-17144514.I-D@ietf.org> ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; name="ATT00182.txt" Content-Disposition: attachment; filename="ATT00182.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0004_01C5D3C6.E28C5480 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0004_01C5D3C6.E28C5480-- From pce-bounces@lists.ietf.org Tue Oct 18 15:10:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwqq-0001ZK-Pu; Tue, 18 Oct 2005 15:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwqp-0001ZF-Nn for pce@megatron.ietf.org; Tue, 18 Oct 2005 15:10: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 PAA22723 for ; Tue, 18 Oct 2005 15:10:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERx2P-0007bU-AM for pce@ietf.org; Tue, 18 Oct 2005 15:22:18 -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 j9IJA3rP029397; Tue, 18 Oct 2005 15:10:03 -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 PAA04953; Tue, 18 Oct 2005 15:10:02 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <40SXXV0B>; Tue, 18 Oct 2005 16:10:02 -0300 Message-ID: <313680C9A886D511A06000204840E1CF0C885FA7@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Lou Berger'" Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.tx t Date: Tue, 18 Oct 2005 16:10:01 -0300 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: 4adaf050708fb13be3316a9eee889caa Cc: lberger@labn.net, 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, While I don't understand how the quote you provide impacts on the issue of using (or defining) PCE to work in the single domain case, I agree (having just talked to Adrian) that we have to allow that it might be employed for this purpose. Ideally - however - in the single domain case, the solution we come up with degenerate to something very like a traffic engineer application. The reason why this is true is fairly obvious - the problem domains are practically identical and the primary driver for PCE in the first place was the need to determine how to properly do a traffic engineering like function in a multi-domain environment. -- Eric --> -----Original Message----- --> From: Lou Berger [mailto:lberger@movaz.com] --> Sent: Saturday, October 15, 2005 10:57 AM --> To: Gray, Eric --> Cc: Ash, Gerald R (Jerry), ALABS; pce@ietf.org; lberger@labn.net --> Subject: RE: [Pce] WG Last Call ended on --> draft-ietf-pce-architecture-02.txt --> --> --> --> At 06:06 PM 10/14/2005, Gray, Eric wrote: --> >Lou, --> > --> > What would be the point? Then it is merely a traffic --> >engineer application. --> > --> >-- --> >Eric --> --> Eric, --> The PCE Architecture doesn't limit PCE to multi-domain --> networks. to quote: --> "... Path computation in large, multi-domain, multi-region or --> multi-layer networks is complex and may require special --> computational components and cooperation between the different --> network domains." --> --> Lou --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Oct 18 18:32:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES00N-0001Uf-9u; Tue, 18 Oct 2005 18:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES00K-0001Ql-WE for pce@megatron.ietf.org; Tue, 18 Oct 2005 18:32: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 SAA04020 for ; Tue, 18 Oct 2005 18:32:12 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES0Bx-0006c6-Fh for pce@ietf.org; Tue, 18 Oct 2005 18:44:21 -0400 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 57E1930105; Tue, 18 Oct 2005 18:32:09 -0400 (EDT) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id 5947CB007; Tue, 18 Oct 2005 18:32:08 -0400 (EDT) Message-Id: <6.2.5.6.2.20051018183126.047bcf70@movaz.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Oct 2005 18:32:06 -0400 To: "Gray, Eric" From: Lou Berger Subject: RE: [Pce] WG Last Call ended on draft-ietf-pce-architecture-02.txt In-Reply-To: <313680C9A886D511A06000204840E1CF0C885FA7@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0C885FA7@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: lberger@labn.net, 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, Glad to see that we agree. Lou At 03:10 PM 10/18/2005, Gray, Eric wrote: >Lou, > > While I don't understand how the quote you provide impacts on >the issue of using (or defining) PCE to work in the single domain >case, I agree (having just talked to Adrian) that we have to allow >that it might be employed for this purpose. > > Ideally - however - in the single domain case, the solution >we come up with degenerate to something very like a traffic engineer >application. The reason why this is true is fairly obvious - the >problem domains are practically identical and the primary driver for >PCE in the first place was the need to determine how to properly do >a traffic engineering like function in a multi-domain environment. > >-- >Eric > >--> -----Original Message----- >--> From: Lou Berger [mailto:lberger@movaz.com] >--> Sent: Saturday, October 15, 2005 10:57 AM >--> To: Gray, Eric >--> Cc: Ash, Gerald R (Jerry), ALABS; pce@ietf.org; lberger@labn.net >--> Subject: RE: [Pce] WG Last Call ended on >--> draft-ietf-pce-architecture-02.txt >--> >--> >--> >--> At 06:06 PM 10/14/2005, Gray, Eric wrote: >--> >Lou, >--> > >--> > What would be the point? Then it is merely a traffic >--> >engineer application. >--> > >--> >-- >--> >Eric >--> >--> Eric, >--> The PCE Architecture doesn't limit PCE to multi-domain >--> networks. to quote: >--> "... Path computation in large, multi-domain, multi-region or >--> multi-layer networks is complex and may require special >--> computational components and cooperation between the different >--> network domains." >--> >--> Lou >--> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 21 09:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxBz-00021Y-Fh; Fri, 21 Oct 2005 09:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxBx-0001yu-UJ for pce@megatron.ietf.org; Fri, 21 Oct 2005 09:44:17 -0400 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22191 for ; Fri, 21 Oct 2005 09:44:06 -0400 (EDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9LDhiF18728 for ; Fri, 21 Oct 2005 09:43:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Selecting a PCE Communication Protocol - Pulling the threadstogether Date: Fri, 21 Oct 2005 09:43:38 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465068CAD2E@zcarhxm1.corp.nortel.com> Thread-Topic: RE: [Pce] Selecting a PCE Communication Protocol - Pulling the threadstogether Thread-Index: AcXWRXEFR2ZB9BhXRRGm7ggEdHWz8w== From: "Darek Skalecki" To: 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="===============0401049665==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0401049665== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D645.71B6DB6F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D645.71B6DB6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good day, Just thought I would throw in my 2c. All considered, for our GMPLS solution we are also looking at PCEP, as opposed to the other alternatives, as a PCE communication protocol. While on the subject, I hope the authors of PCEP will consider computation of GMPLS paths, such as light paths, in the near future. Further extensions will be required for that purpose. For example, expressing bandwidth in bytes per second will not suffice for light paths. Thanks, Darek Darek Skalecki Optical Networks Nortel dareks@nortel.com ------_=_NextPart_001_01C5D645.71B6DB6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Pce] Selecting a PCE Communication Protocol - Pulling the = threadstogether

Good day,

Just thought I would throw in my 2c. = All considered, for our GMPLS solution we are also looking at PCEP, as = opposed to the other alternatives, as a PCE communication protocol. = While on the subject, I hope the authors of PCEP will consider = computation of GMPLS paths, such as light paths, in the near future. = Further extensions will be required for that purpose. For example, = expressing bandwidth in bytes per second will not suffice for light = paths.

Thanks,
Darek

Darek = Skalecki
Optical = Networks
Nortel
dareks@nortel.com

------_=_NextPart_001_01C5D645.71B6DB6F-- --===============0401049665== 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 --===============0401049665==-- From pce-bounces@lists.ietf.org Fri Oct 21 14:00:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1Bp-0003am-PY; Fri, 21 Oct 2005 14:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1Bo-0003Zw-6h for pce@megatron.ietf.org; Fri, 21 Oct 2005 14:00: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 OAA21903 for ; Fri, 21 Oct 2005 14:00:13 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET1Ny-00082l-0s for pce@ietf.org; Fri, 21 Oct 2005 14:13:00 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 32A87E0001F7 for ; Fri, 21 Oct 2005 19:00:10 +0100 (BST) Received: from Puppy ([217.158.132.74] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 18:57:01 +0100 Message-ID: <027a01c5d669$3e95c500$ca00470a@Puppy> From: "Adrian Farrel" To: Date: Fri, 21 Oct 2005 18:59:03 +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-OriginalArrivalTime: 21 Oct 2005 17:57:02.0286 (UTC) FILETIME=[D70D8EE0:01C5D668] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: 64th IETF - Agenda 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 PCE slot moved to Wednesday... > WEDNESDAY, November 9, 2005 > 0900-1130 Morning Session I > RTG pce Path Computation Element WG Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 21 15:19:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Qk-0003OU-5P; Fri, 21 Oct 2005 15:19:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2Qi-0003OL-Hi for pce@megatron.ietf.org; Fri, 21 Oct 2005 15:19: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 PAA27839 for ; Fri, 21 Oct 2005 15:19:41 -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 1ET2ct-000360-1b for pce@ietf.org; Fri, 21 Oct 2005 15:32:29 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j9LJGpl01755; Fri, 21 Oct 2005 15:16:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Selecting a PCE Communication Protocol - Pulling thethreadstogether Date: Fri, 21 Oct 2005 15:19:27 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650693305D@zcarhxm1.corp.nortel.com> Thread-Topic: [Pce] Selecting a PCE Communication Protocol - Pulling thethreadstogether Thread-Index: AcXWYTno0GE0G6//RZqRJefiVVs7owAAfpeg From: "Darek Skalecki" To: X-Spam-Score: 1.0 (+) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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="===============0494703318==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0494703318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D674.5BA52233" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D674.5BA52233 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same reasons as most other people on this list, i.e. lightweight and directly supports the requirements. =20 Darek Darek Skalecki=20 Optical Networks=20 Nortel=20 dareks@nortel.com=20 -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Sent: October 21, 2005 1:02 PM To: Skalecki, Darek [CAR:QT32:EXCH] Cc: pce@ietf.org Subject: RE: [Pce] Selecting a PCE Communication Protocol - Pulling thethreadstogether hi darek -=20 would it be possible to know what are the specific reasons (if any) that led you to this selection ? i think this may help debate during next meeting=20 thanks, - dimitri.=20 "Darek Skalecki" Sent by: pce-bounces@lists.ietf.org 10/21/2005 09:43 AST To: cc:=20 bcc:=20 Subject: RE: [Pce] Selecting a PCE Communication Protocol - Pulling thethreadstogether Good day,=20 Just thought I would throw in my 2c. All considered, for our GMPLS solution we are also looking at PCEP, as opposed to the other alternatives, as a PCE communication protocol. While on the subject, I hope the authors of PCEP will consider computation of GMPLS paths, such as light paths, in the near future. Further extensions will be required for that purpose. For example, expressing bandwidth in bytes per second will not suffice for light paths. Thanks,=20 Darek=20 Darek Skalecki=20 Optical Networks=20 Nortel=20 dareks@nortel.com=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C5D674.5BA52233 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Same=20 reasons as most other people on this list, i.e. lightweight and directly = supports the requirements.
 
Darek

Darek=20 Skalecki
Optical Networks
Nortel=20
dareks@nortel.com

-----Original Message-----
From:=20 Dimitri.Papadimitriou@alcatel.be = [mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: October 21, 2005 1:02 PM
To: Skalecki, = Darek=20 [CAR:QT32:EXCH]
Cc: pce@ietf.org
Subject: RE: = [Pce]=20 Selecting a PCE Communication Protocol - Pulling=20 thethreadstogether

hi darek -

would it be possible to know what = are the=20 specific reasons (if any) that led you to this selection ?

i think this may help debate during = next=20 meeting

thanks,

- dimitri.

"Darek Skalecki" = <dareks@nortel.com>
Sent by: pce-bounces@lists.ietf.org
10/21/2005=20 09:43 AST

To: <pce@ietf.org>
cc: =
bcc:
Subject: RE: [Pce]=20 Selecting a PCE Communication Protocol - Pulling=20 thethreadstogether


Good day,

Just thought I would throw = in my 2c.=20 All considered, for our GMPLS solution we are also looking at PCEP, as = opposed=20 to the other alternatives, as a PCE communication protocol. While on = the=20 subject, I hope the authors of PCEP will consider computation of GMPLS = paths,=20 such as light paths, in the near future. Further extensions will be = required=20 for that purpose. For example, expressing bandwidth in bytes per = second will=20 not suffice for light paths.

Thanks, =
Darek

Darek Skalecki=20
Optical Networks =
Nortel
dareks@nortel.com =

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

------_=_NextPart_001_01C5D674.5BA52233-- --===============0494703318== 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 --===============0494703318==-- From pce-bounces@lists.ietf.org Fri Oct 21 18:53:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5lX-0007sZ-1D; Fri, 21 Oct 2005 18:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5lT-0007sU-6E for pce@megatron.ietf.org; Fri, 21 Oct 2005 18:53:32 -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 SAA23433 for ; Fri, 21 Oct 2005 18:53:19 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET5xh-0001Lk-Ia for pce@ietf.org; Fri, 21 Oct 2005 19:06:09 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2005 15:53:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208,217"; a="13660946:sNHT33329252" 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 j9LMrJEi024327; Fri, 21 Oct 2005 18:53: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); Fri, 21 Oct 2005 18:53:19 -0400 Received: from [216.204.255.239] ([10.86.240.211]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 18:53:18 -0400 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465068CAD2E@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB6465068CAD2E@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v734) Message-Id: From: JP Vasseur Subject: Re: [Pce] Selecting a PCE Communication Protocol - Pulling the threadstogether Date: Fri, 21 Oct 2005 18:53:35 -0400 To: Darek Skalecki X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 21 Oct 2005 22:53:19.0000 (UTC) FILETIME=[3ACCD980:01C5D692] X-Spam-Score: 0.6 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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="===============1018566065==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1018566065== Content-Type: multipart/alternative; boundary=Apple-Mail-16--843323047 --Apple-Mail-16--843323047 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Darek, Thanks for your opinion. On Oct 21, 2005, at 9:43 AM, Darek Skalecki wrote: > Good day, > > Just thought I would throw in my 2c. All considered, for our GMPLS > solution we are also looking at PCEP, as opposed to the other > alternatives, as a PCE communication protocol. While on the > subject, I hope the authors of PCEP will consider computation of > GMPLS paths, such as light paths, in the near future. Further > extensions will be required for that purpose. Absolutely. Let's try to meet in Vancouver for further discussion ? JP. > For example, expressing bandwidth in bytes per second will not > suffice for light paths. > > Thanks, > Darek > > Darek Skalecki > Optical Networks > Nortel > dareks@nortel.com > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > --Apple-Mail-16--843323047 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Darek,

Thanks for your = opinion.

On Oct 21, 2005, at 9:43 AM, Darek = Skalecki wrote:

Good day, =

Just thought I would throw in my = 2c. All considered, for our GMPLS solution we are also looking at PCEP, = as opposed to the other alternatives, as a PCE communication protocol. = While on the subject, I hope the authors of PCEP will consider = computation of GMPLS paths, such as light paths, in the near future. = Further extensions will be required for that = purpose.

Absolutely. Let's try to meet in = Vancouver for further discussion ?

JP.

For example, = expressing bandwidth in bytes per second will not suffice for light = paths.

Thanks, =
Darek

Darek Skalecki =
Optical = Networks
Nortel
dareks@nortel.com =

Pce mailing list


= --Apple-Mail-16--843323047-- --===============1018566065== 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 --===============1018566065==-- From pce-bounces@lists.ietf.org Sat Oct 22 11:06:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKwg-0005ed-SJ; Sat, 22 Oct 2005 11:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKwf-0005eQ-8g for pce@megatron.ietf.org; Sat, 22 Oct 2005 11:06:05 -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 LAA15622 for ; Sat, 22 Oct 2005 11:05:53 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETL92-0002GW-0H for pce@ietf.org; Sat, 22 Oct 2005 11:18:52 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 7AA5AE00013E; Sat, 22 Oct 2005 16:05:45 +0100 (BST) Received: from Puppy ([217.158.132.189] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 15:58:20 +0100 Message-ID: <03d901c5d719$711d0a50$ca00470a@Puppy> From: "Adrian Farrel" To: , References: <2d3901c5cf6a$ffe64050$f2849ed9@Puppy> <434E357F.5020706@psg.com> Subject: Re: [Pce] Selecting a PCE Communication Protocol - Pulling the threads together Date: Sat, 22 Oct 2005 13:47:19 +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-OriginalArrivalTime: 22 Oct 2005 14:58:22.0683 (UTC) FILETIME=[0C15B2B0:01C5D719] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 Dimitri, Sorry for the slow response. > > Scanning the mails on the list so far I see no strong support for COPS or > > HTTP. > > > > If you are in support of either of these you will need to speak up. I know > > it can be worrying to stand in front of the IETF juggernaut, but if you > > don't speak up you will not be heard. I promise to support you. > > i repeated what has been stated in a previous e-mail (not sure i have > been heard ;-) > > one specific comment looking at the APP Area response last August (and > hence the first alternative here below) it stated > > "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." > > so please collect valid input from this list on this proposal and send > it to the APP Area Let's not over-cook the nature of the response from the Applications Area. In response to our many requests for input from the Applications Area, I received one response from an individual (Martine Duesrt) that suggested XML using HTTP. Clearly that individual is willing to help and might be engaged in the discussions, but I think the Apps Area has punted on this. Listening to the conversation so far, it seems that the arguments against HTTP are: - too many options - conversation oriented, rather than request response based - too heavy If anyone would like to add to that list, I will send it to Martin. > > We have had several questions and issues about PCEP > > (draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me > > that these were deficiencies in the current specification of PCEP rather > > than intrinsic faults in the protocol, and that they could be solved by > > the definition of appropriate objects. [Please disagree loudly!] > > i don't clearly see the distinction you make between "deficiencies in > the current specification from intrinsic faults in the protocol" Before dealing with your example, let me give two examples of my own. 1. The PCEP spec does not contain a state machine. Clearly this does not represent a deficiency in the protocol. It is a documentation deficientcy that the authors say they will solve in a future revision. I would agree that it might be masking a deficiency in the protocol. 2. No way to carry encodings of complex constraint interactions. There has been some talk about the need to encode certain information such as complex constraint interactions using a language (such as XML) rather than bits and bytes as we see in most signaling protocols. It seems to me that this problem is easliy solved by the definition of an object that carries an XML payload. This is not an intrinsic problem with the protocol, but is just a matter of defining the encoding of an object. The only possible issue I can see is making sure that the message and object lengths can handle the verbosity of a language encoding. > let's > take an example (this may help) that has been already discussed on this > list, the extensibility and flexibility requirement: when introducing > new constraints (for instance) or modifying the set of constraints (for > instance) in this protocol could be too constraining in further being > compliant with this requirement, this pushes me to point out that the > protocol may look like "lightweight" with its known and current list of > objects but would it be also "lightweight" in operations such as upgrade > and other maintenance ? I think you are mixing "protocol" with "encoding". I believe that discussions of "lightweight protocol" are intended to refer to protocol message exchanges, protocol state, and protocol procedures. They are not intended to refer to bits on the wire - although this is importnat to some degree, it is not a killer. Certainly extensiblity is crucial to any PCECP. Certainly it is possible to extend XML encoding to include new information, and this can be done in a backwards compatible way by defining that legacy nodes will reject or ignore new verbs and adverbs (nouns and adjectives) according to rules specified within the encoding and/or documentation. But I don't see why and object/TLV-based encoding is any harder to make extensible. > > We have had much discussion of why COPS and/or HTTP might not be > > appropriate. Many of the reasons suggested have been refuted or argued > > with, but this in itself does not amount to a case against PCEP, nor a > > case for COPS or HTTP. > > > > We have also had some questions about the function that a pcecp should or > > should not provide (for example, should a PCE be able to connect to a > > PCC?). We need to do two things: > > 1. Go back to the requirements I-D with these considerations and > > add/remove them according to consensus. > > 2. Examine the candidate protocols only against the requirements I-D and > > not against other putative requirements. > > > > [Safety note: when I refer to vendors or service providers below, I do not > > mean to imply that an individual represents the view of any corporation or > > that anyone participating in the IETF does so other than as an > > individual.] > > > > The bottom line that I see forming is that several vendors support PCEP by > > co-authoring, and several service providers express interest in seeing > > this development so that they can further assess the value of PCE. I also > > see strong interest expressed by at least one vendor in producing an > > implementation. > > these objectives are different in nature, there is a difference in > assessing value of PCE and assessing value of the PCC/PCE->PCE > communication protocol, the "user" will assess value from what the > transaction allows (as long as the communication protocol generic > requirements are fulfilled) Yes. And your point is? I am saying that we must select a protocol. Also that we should select a protocol this century. I am saying that I am seeing support expressed for selecting PCEP. But I am also saying that while some of the support is in order to implement, some of the support is so that PCE can be the subject of experimentation. > > In the end, while we must strive not to do things that break the Internet, > > we should also support the running code principle. If the only proposal > > that anyone is willing to implement or experiment with is Protocol X, then > > that is what we will choose unless it is unfixably broken. > > > > Failing further comment we appear to be on the verge of selecting PCEP > > (draft-vasseur-pce-pcep-02.txt) > > > > Note that the acceptance of one solution or another at this stage does > > *NOT* imply that the solution is immune from significant changes. In fact, > > once a solution is owned by the WG, I would expect to see a lot of input > > and modification especially from the implementers. > > sure, another question is also to have a better view on the system > expected responsiveness this may help also in assessing which level of > integration we lay have to consider > > > The discussion continues... > > indeed, Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Oct 23 10:56:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EThH5-00072q-6z; Sun, 23 Oct 2005 10:56:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EThH2-00072Z-9b for pce@megatron.ietf.org; Sun, 23 Oct 2005 10:56: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 KAA09224 for ; Sun, 23 Oct 2005 10:56:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EThTb-0004O5-Hs for pce@ietf.org; Sun, 23 Oct 2005 11:09:36 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EThGz-000Kuk-E4; Sun, 23 Oct 2005 14:56:33 +0000 Message-ID: <435BA46D.8050709@psg.com> Date: Sun, 23 Oct 2005 16:55:41 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel Subject: Re: [Pce] Selecting a PCE Communication Protocol - Pulling the threads together References: <2d3901c5cf6a$ffe64050$f2849ed9@Puppy> <434E357F.5020706@psg.com> <03d901c5d719$711d0a50$ca00470a@Puppy> In-Reply-To: <03d901c5d719$711d0a50$ca00470a@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 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, Adrian Farrel wrote: > Dimitri, > > Sorry for the slow response. > > >>>Scanning the mails on the list so far I see no strong support for COPS >>>or HTTP. >>> >>>If you are in support of either of these you will need to speak up. I >>>know it can be worrying to stand in front of the IETF juggernaut, but if >>>you don't speak up you will not be heard. I promise to support you. >> >>i repeated what has been stated in a previous e-mail (not sure i have >>been heard ;-) >> >>one specific comment looking at the APP Area response last August (and >>hence the first alternative here below) it stated >> >>"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." >> >>so please collect valid input from this list on this proposal and send >>it to the APP Area > > Let's not over-cook the nature of the response from the Applications Area. > In response to our many requests for input from the Applications Area, I > received one response from an individual (Martine Duesrt) that suggested > XML using HTTP. Clearly that individual is willing to help and might be > engaged in the discussions, but I think the Apps Area has punted on this. > > Listening to the conversation so far, it seems that the arguments against > HTTP are: > - too many options > - conversation oriented, rather than request response based > - too heavy > > If anyone would like to add to that list, I will send it to Martin. two points here: - are we in agreement concerning the fraction of time required to parse the path request/response compared to the real computation time (afaik, the PCE is meant to off-load time consuming path computation hence this point becomes important when evaluating performance); are we in agreement that this fraction of time can even be negligible compared to the delay the message could experience in certain specific cases ? - the notion of "lightweight" vs "heavyweight" is still rather confusing, do we have something more formal ? >>>We have had several questions and issues about PCEP >>>(draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me >>>that these were deficiencies in the current specification of PCEP >>>rather than intrinsic faults in the protocol, and that they could be solved >>>by the definition of appropriate objects. [Please disagree loudly!] >> >>i don't clearly see the distinction you make between "deficiencies in >>the current specification from intrinsic faults in the protocol" > > Before dealing with your example, let me give two examples of my own. > 1. The PCEP spec does not contain a state machine. > Clearly this does not represent a deficiency in the protocol. It is a > documentation deficientcy that the authors say they will solve in a > future revision. I would agree that it might be masking a deficiency > in the protocol. > 2. No way to carry encodings of complex constraint interactions. > There has been some talk about the need to encode certain information > such as complex constraint interactions using a language (such as XML) > rather than bits and bytes as we see in most signaling protocols. > It seems to me that this problem is easliy solved by the definition of > an > object that carries an XML payload. This is not an intrinsic problem > with the protocol, but is just a matter of defining the encoding of an > object. The only possible issue I can see is making sure that the > message and object lengths can handle the verbosity of a language > encoding. on point 2. this would mean that the issue of being verbose disappears as concern ? >>let's >>take an example (this may help) that has been already discussed on this >>list, the extensibility and flexibility requirement: when introducing >>new constraints (for instance) or modifying the set of constraints (for >>instance) in this protocol could be too constraining in further being >>compliant with this requirement, this pushes me to point out that the >>protocol may look like "lightweight" with its known and current list of >>objects but would it be also "lightweight" in operations such as upgrade >>and other maintenance ? > > I think you are mixing "protocol" with "encoding". i am not sure i am mixing issues, i only think the issue is twofold a TLV based oriented protocol associates a processing to the TLV; on the other side you could well define a TLV to carry "opaque" information; the question then becomes whether it would not be simpler to have a message-oriented protocol over the selected transport protocol (here, TCP) ? > I believe that > discussions of "lightweight protocol" are intended to refer to protocol > message exchanges, protocol state, and protocol procedures. They are not > intended to refer to bits on the wire - although this is importnat to some > degree, it is not a killer. but if this is the case then i think we are coming closer to a consensus that the PCC/E->PCE protocol function is to exchange a set of messages whose content encoding should be as flexible as possible; > Certainly extensiblity is crucial to any PCECP. Certainly it is possible > to extend XML encoding to include new information, and this can be done in > a backwards compatible way by defining that legacy nodes will reject or > ignore new verbs and adverbs (nouns and adjectives) according to rules > specified within the encoding and/or documentation. But I don't see why > and object/TLV-based encoding is any harder to make extensible. so if it is to transport messages with structured XML textual content ... why not use a protocol like BEEP for instance ? note that BEEP session can be transported over TCP (see RFC 3081) >>>We have had much discussion of why COPS and/or HTTP might not be >>>appropriate. Many of the reasons suggested have been refuted or argued >>>with, but this in itself does not amount to a case against PCEP, nor a >>>case for COPS or HTTP. >>> >>>We have also had some questions about the function that a pcecp should >>>or should not provide (for example, should a PCE be able to connect to a >>>PCC?). We need to do two things: >>>1. Go back to the requirements I-D with these considerations and >>>add/remove them according to consensus. >>>2. Examine the candidate protocols only against the requirements I-D >>>and not against other putative requirements. >>> >>>[Safety note: when I refer to vendors or service providers below, I do >>>not mean to imply that an individual represents the view of any >>>corporation or that anyone participating in the IETF does so other >>>than as an individual.] >>> >>>The bottom line that I see forming is that several vendors support >>>PCEP by co-authoring, and several service providers express interest >>>in seeing this development so that they can further assess the value >>>of PCE. I also see strong interest expressed by at least one vendor >>>in producing an implementation. >> >>these objectives are different in nature, there is a difference in >>assessing value of PCE and assessing value of the PCC/PCE->PCE >>communication protocol, the "user" will assess value from what the >>transaction allows (as long as the communication protocol generic >>requirements are fulfilled) > > Yes. And your point is? that we are creating an inverse value chain only, most issues we are discussing are not specifically driving value for the PCE users; this is part of the concern that feature requirement work just started (see inter-area, inter-AS, and multi-layer requirements) ... i think at the end the main question is the PCE WG sole purpose to define the specific communication protocol to be used between the requester and the computing element or to use this protocol in order to address the initial problem(s) the WG intended to solve ? i think the response to this question is a conjunction of both elements > I am saying that we must select a protocol. Also that we should select a > protocol this century. i agree, but as you are implying timely decision, i would like to remember that a "new" protocol is not necessarily the less time- consuming solution > I am saying that I am seeing support expressed for selecting PCEP. But I > am also saying that while some of the support is in order to implement, > some of the support is so that PCE can be the subject of experimentation. indeed but the initial issue remains the PCE approach will be gauged by the problem space it really solves; on the other side we all perfectly know that this communication protocol is just going to be the mechanism on top of which a series of specific path computation request will be constructed >>>In the end, while we must strive not to do things that break the >>>Internet, we should also support the running code principle. If the only >>>proposal that anyone is willing to implement or experiment with is >>>Protocol X, then that is what we will choose unless it is unfixably >>>broken. >>> >>>Failing further comment we appear to be on the verge of selecting PCEP >>>(draft-vasseur-pce-pcep-02.txt) >>> >>>Note that the acceptance of one solution or another at this stage does >>>*NOT* imply that the solution is immune from significant changes. In >>>fact, once a solution is owned by the WG, I would expect to see a lot of >>>input and modification especially from the implementers. >> >>sure, another question is also to have a better view on the system >>expected responsiveness this may help also in assessing which level of >>integration we lay have to consider yep, moreover, looking at the heterogeneity of systems that can host a PCE (and even a PCC) and with the elements we have at hand it is indeed premature to come out with a "one siwe fits all" like-answer >>>The discussion continues... >> >>indeed, thanks, - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Oct 24 11:37:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4OD-0006tS-Tn; Mon, 24 Oct 2005 11:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3zx-0008QC-KZ for pce@megatron.ietf.org; Mon, 24 Oct 2005 11:12: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 LAA14768 for ; Mon, 24 Oct 2005 11:12:15 -0400 (EDT) Received: from web30811.mail.mud.yahoo.com ([68.142.201.254]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EU4Cg-0006zG-VG for pce@ietf.org; Mon, 24 Oct 2005 11:25:42 -0400 Received: (qmail 12931 invoked by uid 60001); 24 Oct 2005 15:12:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hgvPfWryW5+HGZQtpMRWOYUxU1Pu39YcFZDVl54XVeRlfu5YjdeBzzoAc+t6ZWT0u/oOvLT/HwO/b5s3YPEbJx6/3uFT7cveGzC9BkXRJNLu0byOiUkkK6C6BXszppay9zTx4+iaxHfvLVJ0WSCWKB0lExvFbkxOqGX02QecXpk= ; Message-ID: <20051024151214.12929.qmail@web30811.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30811.mail.mud.yahoo.com via HTTP; Mon, 24 Oct 2005 08:12:14 PDT Date: Mon, 24 Oct 2005 08:12:14 -0700 (PDT) From: Igor Bryskin To: jpv@cisco.com, jeanlouis.leroux@francetelecom.com, arthi@juniper.net, oki.eiji@lab.ntt.co.jp, akatlas@alum.mit.edu, andrew.dolganow@alcatel.com, y.ikejiri@ntt.com MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-Mailman-Approved-At: Mon, 24 Oct 2005 11:37:32 -0400 Cc: pce@ietf.org Subject: [Pce] Using SIP as PCEP transport 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="===============0946625778==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============0946625778== Content-Type: multipart/alternative; boundary="0-1783237433-1130166734=:11950" --0-1783237433-1130166734=:11950 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA14768 JP (and PCEP design co-authors), =20 I wonder if you ever considered using SIP (rfc 3261) as a transport for P= CEP (note that I don=92t mean replacing PCEP with SIP, rather, running PC= EP on top of SIP instead of TCP)? After all SIP is a protocol that can cr= eate and manage sessions between two or more parties and transfer opaque = objects between them that presumably carry a payload of higher layer prot= ocols such as Session Description Protocol (SDP, rfc 2327) or, as I belie= ve, PCEP. =20 I am not a SIP specialist and, therefore, could be wrong; however, it doe= s seem to me that SIP has a lot of machinery that falls straight under re= quirements for PCC-PCE communication protocol developed within the PCE WG= . To name some of the mechanisms: 1. Authentication of parties and encrypted communication= between them; 2. Protection against malicious attacks; 3. Party discovery capability enabled by intrinsic locat= ion service. In the context of PCEP it means that one or several PCEs wit= h identical or similar capabilities could be registered under the same na= me (address-of-record), and PCCs could query one or more SIP registrars a= nd learn about all PCEs on the network. There is a SIP method =96 CAPABIL= ITIES- that is specifically designed to help understanding the peculiarit= ies of accessing a particular party (read PCE) without actually ringing t= he party. Such service would facilitate: a) moving a PCE around the network in a transparent for PCCs and oth= er PCEs manner; b) easy support of backup PCEs; c) natural computation load distribution (by forking INVITE requests= between PCEs sharing the same AOR according to some policy). Note, that = if a network has, say, 3 PCEs with identical capabilities and all of them= known to PCCs, I don=92t know how current architecture can guarantee tha= t all PCCs will not use (and possibly kill) one of PCEs with keeping all = others idle; 4. Many useful services such as: a) message forwarding; b) message re-directing; c) =93am_busy_now_will_call_as_soon_as_I_can=94 service, etc. =20 5. Ability for a PCC to track the process of the request= (via provisioning (1xx) messages). For instance, a PCC may receive a mes= sage that its request is received and queued, PCE waits for completion of= local computations or response(s) from cooperating PCEs, etc. 6. SIP has a =93CANCEL=94 method specifically design for= canceling previously sent requests without causing race conditions, for = instance, to avoid situation when the CANCEL request is processed by a PC= E before the associated path computation request and, thus, dropped 7. SIP supports conferences, that is, association of man= y parties. For instance a group of cooperating PCEs could setup such a co= nference to split responsibilities in satisfying a particular path comput= ation request, and then perform necessary computations in parallel, rathe= r than sequentially with each PCE deciding on its own what paths, path or= tree segments it must compute. Cooperation of PCEs is an important scena= rio described in the PCE architecture; however, there were no discussions= so far how this could be achieved. I believe that there will be a need o= f strong protocol support for such cooperation to happen. Likewise, a PCC= may setup a conference with several PCEs at once to decide which of them= can satisfy a particular request best. =20 I also would like to make a couple of observations, which IMO makes SIP w= orth looking at. Firstly, SIP has a good likelihood to become a protocol = of choice for (G)MPLS call control, so why not to reuse the same tool for= other purposes? Secondly, SIP could be involved at some later stage of t= he PCEP development, I mean, we can start running PCEP over TCP and some = time later switch to SIP. =20 What do you think? =20 Igor =20 =20 =09 --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. =20 --0-1783237433-1130166734=:11950 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA14768

JP (and PCEP design co-authors),

 

I wonder if you ever considered using SIP (rfc 3261) as= a transport for PCEP (note that I don=92t mean replacing PCEP with SIP, = rather, running PCEP on top of SIP instead of TCP)? After all SIP is a pr= otocol that can create and manage sessions between two or more parties an= d transfer opaque objects between them that presumably carry a payload of= higher layer protocols such as Session Description Protocol (SDP, rfc 23= 27) or, as I believe, PCEP.

 

I am not a SIP specialist and, therefore, could be wron= g; however, it does seem to me that SIP has a lot of machinery that falls= straight under requirements for PCC-PCE communication protocol developed= within the PCE WG. To name some of the mechanisms:

1.           = ;       Authenticatio= n of parties and encrypted communication between them;

2.           = ;       Protection ag= ainst malicious attacks;

3.           = ;       Party discove= ry capability enabled by intrinsic location service. In the context of PC= EP it means that one or several PCEs with identical or similar capabiliti= es could be registered under the same name (address-of-record), and PCCs = could query one or more SIP registrars and learn about all PCEs on the ne= twork. There is a SIP method =96 CAPABILITIES- that is specifically desig= ned to help understanding the peculiarities of accessing a particular par= ty (read PCE) without actually ringing the party. Such service would faci= litate:

a)      moving = a PCE around the network in a transparent for PCCs and other PCEs manner;=

b)     easy support of back= up PCEs;

c)      natural comput= ation load distribution (by forking INVITE requests between PCEs sharing = the same AOR according to some policy). Note, that if a network has, say,= 3 PCEs with identical capabilities and all of them known to PCCs, I don=92= t know how current architecture can guarantee that all PCCs will not use = (and possibly kill) one of PCEs with keeping all others idle;

4.           = ;       Many useful s= ervices such as:

a)      message forwar= ding;

b)     message re-directing= ;

c)      =93am_busy_now= _will_call_as_soon_as_I_can=94 service, etc.

 

5.           = ;       Ability for a= PCC to track the process of the request (via provisioning (1xx) messages= ). For instance, a PCC may receive a message that its request is received= and queued, PCE waits for completion of local computations or response(s= ) from cooperating PCEs, etc.

6.           = ;       SIP has a =93= CANCEL=94 method specifically design for canceling previously sent reques= ts without causing race conditions, for instance, to avoid situation when= the CANCEL request is processed by a PCE before the associated path comp= utation request and, thus, dropped

7.           = ;       SIP supports = conferences, that is, association of many parties. For instance a group o= f cooperating PCEs could setup such a conference to split responsibilitie= s in satisfying a particular path computation request, and then perform n= ecessary computations in parallel, rather than sequentially with each PCE= deciding on its own what paths, path or tree segments it must compute. C= ooperation of PCEs is an important scenario described in the PCE architec= ture; however, there were no discussions so far how this could be achieve= d. I believe that there will be a need of strong protocol support for suc= h cooperation to happen. Likewise, a PCC may setup a conference with several PCEs at once to decide which of them can satisfy= a particular request best.

 

I also would like to make a couple of observations, whi= ch IMO makes SIP worth looking at. Firstly, SIP has a good likelihood to = become a protocol of choice for (G)MPLS call control, so why not to reuse= the same tool for other purposes? Secondly, SIP could be involved at som= e later stage of the PCEP development, I mean, we can start running PCEP = over TCP and some time later switch to SIP.

 

What do you think?

 

Igor

 

 

Yahoo! FareChase - Sear= ch multiple travel sites in one click. =20 =20 --0-1783237433-1130166734=:11950-- --===============0946625778== 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 --===============0946625778==-- From pce-bounces@lists.ietf.org Mon Oct 24 12:50:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Wm-0006jG-Pu; Mon, 24 Oct 2005 12:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Wg-0006ic-3j for pce@megatron.ietf.org; Mon, 24 Oct 2005 12:50:23 -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 MAA20104 for ; Mon, 24 Oct 2005 12:50:08 -0400 (EDT) Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5jS-0001sx-SY for pce@ietf.org; Mon, 24 Oct 2005 13:03:35 -0400 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 89C7668EA7; Mon, 24 Oct 2005 12:50:00 -0400 (EDT) Message-ID: <010b01c5d8ba$f51ccff0$7a1810ac@movaz.com> From: "Igor Bryskin" To: , "LE ROUX Jean-Louis RD-CORE-LAN" , "Arthi Ayyangar" , "Eiji Oki" , , , Date: Mon, 24 Oct 2005 12:49:53 -0400 MIME-Version: 1.0 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.8 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: pce@ietf.org Subject: [Pce] Using SIP as PCEP transport 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="===============0234590783==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0234590783== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01C5D899.6DBA29C0" This is a multi-part message in MIME format. ------=_NextPart_000_0108_01C5D899.6DBA29C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JP (and PCEP design co-authors), I wonder if you ever considered using = SIP (rfc 3261) as a transport for PCEP (note that I don't mean replacing = PCEP with SIP, rather, running PCEP on top of SIP instead of TCP)? After = all SIP is a protocol that can create and manage sessions between two or = more parties and transfer opaque objects between them that presumably = carry a payload of higher layer protocols such as Session Description = Protocol (SDP, rfc 2327) or, as I believe, PCEP. I am not a SIP = specialist and, therefore, could be wrong; however, it does seem to me = that SIP has a lot of machinery that falls straight under requirements = for PCC-PCE communication protocol developed within the PCE WG. To name = some of the mechanisms:1. Authentication of parties and = encrypted communication between them;2. Protection = against malicious attacks;3. Party discovery capability = enabled by intrinsic location service. In the context of PCEP it means = that one or several PCEs with identical or similar capabilities could be = registered under the same name (address-of-record), and PCCs could query = one or more SIP registrars and learn about all PCEs on the network. = There is a SIP method - CAPABILITIES- that is specifically designed to = help understanding the peculiarities of accessing a particular party = (read PCE) without actually ringing the party. Such service would = facilitate:a) moving a PCE around the network in a transparent for = PCCs and other PCEs manner;b) easy support of backup PCEs;c) = natural computation load distribution (by forking INVITE requests = between PCEs sharing the same AOR according to some policy). Note, that = if a network has, say, 3 PCEs with identical capabilities and all of = them known to PCCs, I don't know how current architecture can guarantee = that all PCCs will not use (and possibly kill) one of PCEs with keeping = all others idle;4. Many useful services such as:a) = message forwarding;b) message re-directing;c) = "am_busy_now_will_call_as_soon_as_I_can" service, etc. 5. = Ability for a PCC to track the process of the request (via = provisioning (1xx) messages). For instance, a PCC may receive a message = that its request is received and queued, PCE waits for completion of = local computations or response(s) from cooperating PCEs, etc.6. = SIP has a "CANCEL" method specifically design for canceling = previously sent requests without causing race conditions, for instance, = to avoid situation when the CANCEL request is processed by a PCE before = the associated path computation request and, thus, dropped7. = SIP supports conferences, that is, association of many parties. For = instance a group of cooperating PCEs could setup such a conference to = split responsibilities in satisfying a particular path computation = request, and then perform necessary computations in parallel, rather = than sequentially with each PCE deciding on its own what paths, path or = tree segments it must compute. Cooperation of PCEs is an important = scenario described in the PCE architecture; however, there were no = discussions so far how this could be achieved. I believe that there will = be a need of strong protocol support for such cooperation to happen. = Likewise, a PCC may setup a conference with several PCEs at once to = decide which of them can satisfy a particular request best. I also would = like to make a couple of observations, which IMO makes SIP worth looking = at. Firstly, SIP has a good likelihood to become a protocol of choice = for (G)MPLS call control, so why not to reuse the same tool for other = purposes? Secondly, SIP could be involved at some later stage of the = PCEP development, I mean, we can start running PCEP over TCP and some = time later switch to SIP. What do you think? Igor ------=_NextPart_000_0108_01C5D899.6DBA29C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
JP (and PCEP design =
co-authors),
 
I wonder if you ever considered =
using SIP (rfc 3261) as a transport for PCEP (note that I don=92t mean =
replacing PCEP with SIP, rather, running PCEP on top of SIP instead of =
TCP)? After all SIP is a protocol that can create and manage sessions =
between two or more parties and transfer opaque objects between them =
that presumably carry a payload of higher layer protocols such as =
Session Description Protocol (SDP, rfc 2327) or, as I believe, =
PCEP.
 
I am not a SIP specialist and, therefore, could be wrong; =
however, it does seem to me that SIP has a lot of machinery that falls =
straight under requirements for PCC-PCE communication protocol developed =
within the PCE WG. To name some of the mechanisms:
1.           =
;       Authentication of parties =
and encrypted communication between them;
2.           =
;       Protection against =
malicious attacks;
3.           =
;       Party discovery capability =
enabled by intrinsic location service. In the context of PCEP it means =
that one or several PCEs with identical or similar capabilities could be =
registered under the same name (address-of-record), and PCCs could query =
one or more SIP registrars and learn about all PCEs on the network. =
There is a SIP method =96 CAPABILITIES- that is specifically designed to =
help understanding the peculiarities of accessing a particular party =
(read PCE) without actually ringing the party. Such service would =
facilitate:
a)      moving a PCE =
around the network in a transparent for PCCs and other PCEs =
manner;
b)     easy support of backup =
PCEs;
c)      natural computation =
load distribution (by forking INVITE requests between PCEs sharing the =
same AOR according to some policy). Note, that if a network has, say, 3 =
PCEs with identical capabilities and all of them known to PCCs, I =
don=92t know how current architecture can guarantee that all PCCs will =
not use (and possibly kill) one of PCEs with keeping all others =
idle;
4.           =
;       Many useful services such =
as:
a)      message =
forwarding;
b)     message =
re-directing;
c)      =
=93am_busy_now_will_call_as_soon_as_I_can=94 service, =
etc.
 
5.           =
;       Ability for a PCC to track =
the process of the request (via provisioning (1xx) messages). For =
instance, a PCC may receive a message that its request is received and =
queued, PCE waits for completion of local computations or response(s) =
from cooperating PCEs, etc.
6.           =
;       SIP has a =93CANCEL=94 =
method specifically design for canceling previously sent requests =
without causing race conditions, for instance, to avoid situation when =
the CANCEL request is processed by a PCE before the associated path =
computation request and, thus, dropped
7.           =
;       SIP supports conferences, =
that is, association of many parties. For instance a group of =
cooperating PCEs could setup such a conference to split responsibilities =
in satisfying a particular path computation request, and then perform =
necessary computations in parallel, rather than sequentially with each =
PCE deciding on its own what paths, path or tree segments it must =
compute. Cooperation of PCEs is an important scenario described in the =
PCE architecture; however, there were no discussions so far how this =
could be achieved. I believe that there will be a need of strong =
protocol support for such cooperation to happen. Likewise, a PCC may =
setup a conference with several PCEs at once to decide which of them can =
satisfy a particular request best.
 
I also would like to make a =
couple of observations, which IMO makes SIP worth looking at. Firstly, =
SIP has a good likelihood to become a protocol of choice for (G)MPLS =
call control, so why not to reuse the same tool for other purposes? =
Secondly, SIP could be involved at some later stage of the PCEP =
development, I mean, we can start running PCEP over TCP and some time =
later switch to SIP.
 
What do you think?
 
Igor
 
 
------=_NextPart_000_0108_01C5D899.6DBA29C0-- --===============0234590783== 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 --===============0234590783==-- From pce-bounces@lists.ietf.org Tue Oct 25 03:49:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJYf-0003KM-Q5; Tue, 25 Oct 2005 03:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJYc-0003Jr-It for pce@megatron.ietf.org; Tue, 25 Oct 2005 03:49: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 DAA27725 for ; Tue, 25 Oct 2005 03:49:03 -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 1EUJlU-0001T0-BD for pce@ietf.org; Tue, 25 Oct 2005 04:02:39 -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 <0IOW00KSOORLCT@szxga02-in.huawei.com> for pce@ietf.org; Tue, 25 Oct 2005 15:57:21 +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 <0IOW00DABOQX2S@szxga02-in.huawei.com> for pce@ietf.org; Tue, 25 Oct 2005 15:57:21 +0800 (CST) Received: from z18605 ([10.110.100.58]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOW008BLO1BD0@szxml02-in.huawei.com>; Tue, 25 Oct 2005 15:41:36 +0800 (CST) Date: Tue, 25 Oct 2005 15:07:14 +0800 From: Zhang Renhai Subject: Re: [Pce] Using SIP as PCEP transport To: Igor Bryskin , jpv@cisco.com, LE ROUX Jean-Louis RD-CORE-LAN , Arthi Ayyangar , Eiji Oki , akatlas@alum.mit.edu, andrew.dolganow@alcatel.com, y.ikejiri@ntt.com Message-id: <001301c5d932$baff1a80$3a646e0a@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: <010b01c5d8ba$f51ccff0$7a1810ac@movaz.com> X-Spam-Score: 3.3 (+++) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad 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="===============1452539485==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1452539485== Content-type: multipart/alternative; boundary="Boundary_(ID_fjzRYX40L3aaYHlJPljR8A)" This is a multi-part message in MIME format. --Boundary_(ID_fjzRYX40L3aaYHlJPljR8A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGksSWdvcg0KDQpjKSAgICAgIG5hdHVyYWwgY29tcHV0YXRpb24gbG9hZCBkaXN0cmlidXRpb24g KGJ5IGZvcmtpbmcgSU5WSVRFIHJlcXVlc3RzIGJldHdlZW4gUENFcyBzaGFyaW5nIHRoZSBzYW1l IEFPUiBhY2NvcmRpbmcgdG8gc29tZSBwb2xpY3kpLiBOb3RlLCB0aGF0IGlmIGEgbmV0d29yayBo YXMsIHNheSwgMyBQQ0VzIHdpdGggaWRlbnRpY2FsIGNhcGFiaWxpdGllcyBhbmQgYWxsIG9mIHRo ZW0ga25vd24gdG8gUENDcywgSSBkb24ndCBrbm93IGhvdyBjdXJyZW50IGFyY2hpdGVjdHVyZSBj YW4gZ3VhcmFudGVlIHRoYXQgYWxsIFBDQ3Mgd2lsbCBub3QgdXNlIChhbmQgcG9zc2libHkga2ls bCkgb25lIG9mIFBDRXMgd2l0aCBrZWVwaW5nIGFsbCBvdGhlcnMgaWRsZTsNCg0KWlJILT50aGlz IGlzIGFsc28gbXkgY29uY2VybiBhbmQgaXMgYWRkcmVzc2VkIGluIG15IGRyYWZ0IGRyYWZ0LXpo YW5nLXBjZS1jb21tLWFwcC1tb2RlbC0wMS50eHQoc2VlIHNlY3Rpb24gNSkuDQoNCg0KDQpDb29w ZXJhdGlvbiBvZiBQQ0VzIGlzIGFuIGltcG9ydGFudCBzY2VuYXJpbyBkZXNjcmliZWQgaW4gdGhl IFBDRSBhcmNoaXRlY3R1cmU7IGhvd2V2ZXIsIHRoZXJlIHdlcmUgbm8gZGlzY3Vzc2lvbnMgc28g ZmFyIGhvdyB0aGlzIGNvdWxkIGJlIGFjaGlldmVkLiBJIGJlbGlldmUgdGhhdCB0aGVyZSB3aWxs IGJlIGEgbmVlZCBvZiBzdHJvbmcgcHJvdG9jb2wgc3VwcG9ydCBmb3Igc3VjaCBjb29wZXJhdGlv biB0byBoYXBwZW4uIExpa2V3aXNlLCBhIFBDQyBtYXkgc2V0dXAgYSBjb25mZXJlbmNlIHdpdGgg c2V2ZXJhbCBQQ0VzIGF0IG9uY2UgdG8gZGVjaWRlIHdoaWNoIG9mIHRoZW0gY2FuIHNhdGlzZnkg YSBwYXJ0aWN1bGFyIHJlcXVlc3QgYmVzdC4NCg0KWlJILT5JIGFncmVlIHdpdGggeW91IHRoYXQg Y29vcGVyYXRpb24gb2YgUENFIGlzIGltcG9ydGFudCwgYWN0dWFsbHksIHRoaXMgaXMgYWxzbyBk aXNjdXNzZWQgaW4gbXkgZHJhZnQgaW4gd2hpY2ggc29tZSBjb29wZXJhdGlvbnMgaXMgaW50cm9k dWNlZCB0byBzb2x2ZSB0aGUgcmFjZSBjb25kaXRpb25zLCBob3dldmVyLCBjb29wZXJhdGlvbiBz aG91bGQgYmUgbW9yZSBkaXNjdXNzZWQgaSB0aGluay4NCg0KDQoNCkNoZWVycywNCg0KWmhhbmcN Cg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBJZ29yIEJyeXNraW4g DQogIFRvOiBqcHZAY2lzY28uY29tIDsgTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOIDsg QXJ0aGkgQXl5YW5nYXIgOyBFaWppIE9raSA7IGFrYXRsYXNAYWx1bS5taXQuZWR1IDsgYW5kcmV3 LmRvbGdhbm93QGFsY2F0ZWwuY29tIDsgeS5pa2VqaXJpQG50dC5jb20gDQogIENjOiBwY2VAaWV0 Zi5vcmcgDQogIFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjUsIDIwMDUgMTI6NDkgQU0NCiAgU3Vi amVjdDogW1BjZV0gVXNpbmcgU0lQIGFzIFBDRVAgdHJhbnNwb3J0DQoNCg0KSlAgKGFuZCBQQ0VQ IGRlc2lnbiBjby1hdXRob3JzKSwgSSB3b25kZXIgaWYgeW91IGV2ZXIgY29uc2lkZXJlZCB1c2lu ZyBTSVAgKHJmYyAzMjYxKSBhcyBhIHRyYW5zcG9ydCBmb3IgUENFUCAobm90ZSB0aGF0IEkgZG9u J3QgbWVhbiByZXBsYWNpbmcgUENFUCB3aXRoIFNJUCwgcmF0aGVyLCBydW5uaW5nIFBDRVAgb24g dG9wIG9mIFNJUCBpbnN0ZWFkIG9mIFRDUCk/IEFmdGVyIGFsbCBTSVAgaXMgYSBwcm90b2NvbCB0 aGF0IGNhbiBjcmVhdGUgYW5kIG1hbmFnZSBzZXNzaW9ucyBiZXR3ZWVuIHR3byBvciBtb3JlIHBh cnRpZXMgYW5kIHRyYW5zZmVyIG9wYXF1ZSBvYmplY3RzIGJldHdlZW4gdGhlbSB0aGF0IHByZXN1 bWFibHkgY2FycnkgYSBwYXlsb2FkIG9mIGhpZ2hlciBsYXllciBwcm90b2NvbHMgc3VjaCBhcyBT ZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFAsIHJmYyAyMzI3KSBvciwgYXMgSSBiZWxp ZXZlLCBQQ0VQLiBJIGFtIG5vdCBhIFNJUCBzcGVjaWFsaXN0IGFuZCwgdGhlcmVmb3JlLCBjb3Vs ZCBiZSB3cm9uZzsgaG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIG1lIHRoYXQgU0lQIGhhcyBhIGxv dCBvZiBtYWNoaW5lcnkgdGhhdCBmYWxscyBzdHJhaWdodCB1bmRlciByZXF1aXJlbWVudHMgZm9y IFBDQy1QQ0UgY29tbXVuaWNhdGlvbiBwcm90b2NvbCBkZXZlbG9wZWQgd2l0aGluIHRoZSBQQ0Ug V0cuIFRvIG5hbWUgc29tZSBvZiB0aGUgbWVjaGFuaXNtczoxLiAgICAgICAgICAgICAgICAgIEF1 dGhlbnRpY2F0aW9uIG9mIHBhcnRpZXMgYW5kIGVuY3J5cHRlZCBjb21tdW5pY2F0aW9uIGJldHdl ZW4gdGhlbTsyLiAgICAgICAgICAgICAgICAgIFByb3RlY3Rpb24gYWdhaW5zdCBtYWxpY2lvdXMg YXR0YWNrczszLiAgICAgICAgICAgICAgICAgIFBhcnR5IGRpc2NvdmVyeSBjYXBhYmlsaXR5IGVu YWJsZWQgYnkgaW50cmluc2ljIGxvY2F0aW9uIHNlcnZpY2UuIEluIHRoZSBjb250ZXh0IG9mIFBD RVAgaXQgbWVhbnMgdGhhdCBvbmUgb3Igc2V2ZXJhbCBQQ0VzIHdpdGggaWRlbnRpY2FsIG9yIHNp bWlsYXIgY2FwYWJpbGl0aWVzIGNvdWxkIGJlIHJlZ2lzdGVyZWQgdW5kZXIgdGhlIHNhbWUgbmFt ZSAoYWRkcmVzcy1vZi1yZWNvcmQpLCBhbmQgUENDcyBjb3VsZCBxdWVyeSBvbmUgb3IgbW9yZSBT SVAgcmVnaXN0cmFycyBhbmQgbGVhcm4gYWJvdXQgYWxsIFBDRXMgb24gdGhlIG5ldHdvcmsuIFRo ZXJlIGlzIGEgU0lQIG1ldGhvZCAtIENBUEFCSUxJVElFUy0gdGhhdCBpcyBzcGVjaWZpY2FsbHkg ZGVzaWduZWQgdG8gaGVscCB1bmRlcnN0YW5kaW5nIHRoZSBwZWN1bGlhcml0aWVzIG9mIGFjY2Vz c2luZyBhIHBhcnRpY3VsYXIgcGFydHkgKHJlYWQgUENFKSB3aXRob3V0IGFjdHVhbGx5IHJpbmdp bmcgdGhlIHBhcnR5LiBTdWNoIHNlcnZpY2Ugd291bGQgZmFjaWxpdGF0ZTphKSAgICAgIG1vdmlu ZyBhIFBDRSBhcm91bmQgdGhlIG5ldHdvcmsgaW4gYSB0cmFuc3BhcmVudCBmb3IgUENDcyBhbmQg b3RoZXIgUENFcyBtYW5uZXI7YikgICAgIGVhc3kgc3VwcG9ydCBvZiBiYWNrdXAgUENFcztjKSAg ICAgIG5hdHVyYWwgY29tcHV0YXRpb24gbG9hZCBkaXN0cmlidXRpb24gKGJ5IGZvcmtpbmcgSU5W SVRFIHJlcXVlc3RzIGJldHdlZW4gUENFcyBzaGFyaW5nIHRoZSBzYW1lIEFPUiBhY2NvcmRpbmcg dG8gc29tZSBwb2xpY3kpLiBOb3RlLCB0aGF0IGlmIGEgbmV0d29yayBoYXMsIHNheSwgMyBQQ0Vz IHdpdGggaWRlbnRpY2FsIGNhcGFiaWxpdGllcyBhbmQgYWxsIG9mIHRoZW0ga25vd24gdG8gUEND cywgSSBkb24ndCBrbm93IGhvdyBjdXJyZW50IGFyY2hpdGVjdHVyZSBjYW4gZ3VhcmFudGVlIHRo YXQgYWxsIFBDQ3Mgd2lsbCBub3QgdXNlIChhbmQgcG9zc2libHkga2lsbCkgb25lIG9mIFBDRXMg d2l0aCBrZWVwaW5nIGFsbCBvdGhlcnMgaWRsZTs0LiAgICAgICAgICAgICAgICAgIE1hbnkgdXNl ZnVsIHNlcnZpY2VzIHN1Y2ggYXM6YSkgICAgICBtZXNzYWdlIGZvcndhcmRpbmc7YikgICAgIG1l c3NhZ2UgcmUtZGlyZWN0aW5nO2MpICAgICAgImFtX2J1c3lfbm93X3dpbGxfY2FsbF9hc19zb29u X2FzX0lfY2FuIiBzZXJ2aWNlLCBldGMuIDUuICAgICAgICAgICAgICAgICAgQWJpbGl0eSBmb3Ig YSBQQ0MgdG8gdHJhY2sgdGhlIHByb2Nlc3Mgb2YgdGhlIHJlcXVlc3QgKHZpYSBwcm92aXNpb25p bmcgKDF4eCkgbWVzc2FnZXMpLiBGb3IgaW5zdGFuY2UsIGEgUENDIG1heSByZWNlaXZlIGEgbWVz c2FnZSB0aGF0IGl0cyByZXF1ZXN0IGlzIHJlY2VpdmVkIGFuZCBxdWV1ZWQsIFBDRSB3YWl0cyBm b3IgY29tcGxldGlvbiBvZiBsb2NhbCBjb21wdXRhdGlvbnMgb3IgcmVzcG9uc2UocykgZnJvbSBj b29wZXJhdGluZyBQQ0VzLCBldGMuNi4gICAgICAgICAgICAgICAgICBTSVAgaGFzIGEgIkNBTkNF TCIgbWV0aG9kIHNwZWNpZmljYWxseSBkZXNpZ24gZm9yIGNhbmNlbGluZyBwcmV2aW91c2x5IHNl bnQgcmVxdWVzdHMgd2l0aG91dCBjYXVzaW5nIHJhY2UgY29uZGl0aW9ucywgZm9yIGluc3RhbmNl LCB0byBhdm9pZCBzaXR1YXRpb24gd2hlbiB0aGUgQ0FOQ0VMIHJlcXVlc3QgaXMgcHJvY2Vzc2Vk IGJ5IGEgUENFIGJlZm9yZSB0aGUgYXNzb2NpYXRlZCBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3Qg YW5kLCB0aHVzLCBkcm9wcGVkNy4gICAgICAgICAgICAgICAgICBTSVAgc3VwcG9ydHMgY29uZmVy ZW5jZXMsIHRoYXQgaXMsIGFzc29jaWF0aW9uIG9mIG1hbnkgcGFydGllcy4gRm9yIGluc3RhbmNl IGEgZ3JvdXAgb2YgY29vcGVyYXRpbmcgUENFcyBjb3VsZCBzZXR1cCBzdWNoIGEgY29uZmVyZW5j ZSB0byBzcGxpdCByZXNwb25zaWJpbGl0aWVzIGluIHNhdGlzZnlpbmcgYSBwYXJ0aWN1bGFyIHBh dGggY29tcHV0YXRpb24gcmVxdWVzdCwgYW5kIHRoZW4gcGVyZm9ybSBuZWNlc3NhcnkgY29tcHV0 YXRpb25zIGluIHBhcmFsbGVsLCByYXRoZXIgdGhhbiBzZXF1ZW50aWFsbHkgd2l0aCBlYWNoIFBD RSBkZWNpZGluZyBvbiBpdHMgb3duIHdoYXQgcGF0aHMsIHBhdGggb3IgdHJlZSBzZWdtZW50cyBp dCBtdXN0IGNvbXB1dGUuIENvb3BlcmF0aW9uIG9mIFBDRXMgaXMgYW4gaW1wb3J0YW50IHNjZW5h cmlvIGRlc2NyaWJlZCBpbiB0aGUgUENFIGFyY2hpdGVjdHVyZTsgaG93ZXZlciwgdGhlcmUgd2Vy ZSBubyBkaXNjdXNzaW9ucyBzbyBmYXIgaG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQuIEkgYmVs aWV2ZSB0aGF0IHRoZXJlIHdpbGwgYmUgYSBuZWVkIG9mIHN0cm9uZyBwcm90b2NvbCBzdXBwb3J0 IGZvciBzdWNoIGNvb3BlcmF0aW9uIHRvIGhhcHBlbi4gTGlrZXdpc2UsIGEgUENDIG1heSBzZXR1 cCBhIGNvbmZlcmVuY2Ugd2l0aCBzZXZlcmFsIFBDRXMgYXQgb25jZSB0byBkZWNpZGUgd2hpY2gg b2YgdGhlbSBjYW4gc2F0aXNmeSBhIHBhcnRpY3VsYXIgcmVxdWVzdCBiZXN0LiBJIGFsc28gd291 bGQgbGlrZSB0byBtYWtlIGEgY291cGxlIG9mIG9ic2VydmF0aW9ucywgd2hpY2ggSU1PIG1ha2Vz IFNJUCB3b3J0aCBsb29raW5nIGF0LiBGaXJzdGx5LCBTSVAgaGFzIGEgZ29vZCBsaWtlbGlob29k IHRvIGJlY29tZSBhIHByb3RvY29sIG9mIGNob2ljZSBmb3IgKEcpTVBMUyBjYWxsIGNvbnRyb2ws IHNvIHdoeSBub3QgdG8gcmV1c2UgdGhlIHNhbWUgdG9vbCBmb3Igb3RoZXIgcHVycG9zZXM/IFNl Y29uZGx5LCBTSVAgY291bGQgYmUgaW52b2x2ZWQgYXQgc29tZSBsYXRlciBzdGFnZSBvZiB0aGUg UENFUCBkZXZlbG9wbWVudCwgSSBtZWFuLCB3ZSBjYW4gc3RhcnQgcnVubmluZyBQQ0VQIG92ZXIg VENQIGFuZCBzb21lIHRpbWUgbGF0ZXIgc3dpdGNoIHRvIFNJUC4gV2hhdCBkbyB5b3UgdGhpbms/ IElnb3IgIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgUGNlIG1haWxpbmcgbGlzdA0KICBQ Y2VAbGlzdHMuaWV0Zi5vcmcNCiAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQoNCg== --Boundary_(ID_fjzRYX40L3aaYHlJPljR8A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUw LjQ4MDcuMjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mj5IaSxJZ29yPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg DQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBt c28tbGlzdDogbDAgbGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PEZPTlQgDQpm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPmM8Rk9OVCBzaXplPTI+KTxTUEFOIA0Kc3R5bGU9IkZPTlQ6 IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K PC9TUEFOPm5hdHVyYWwgY29tcHV0YXRpb24gbG9hZCBkaXN0cmlidXRpb24gKGJ5IGZvcmtpbmcg SU5WSVRFIHJlcXVlc3RzIGJldHdlZW4gDQpQQ0VzIHNoYXJpbmcgdGhlIHNhbWUgQU9SIGFjY29y ZGluZyB0byBzb21lIHBvbGljeSkuIE5vdGUsIHRoYXQgaWYgYSBuZXR3b3JrIA0KaGFzLCBzYXks IDMgUENFcyB3aXRoIGlkZW50aWNhbCBjYXBhYmlsaXRpZXMgYW5kIGFsbCBvZiB0aGVtIGtub3du IHRvIFBDQ3MsIEkgDQpkb24mIzgyMTc7dCBrbm93IGhvdyBjdXJyZW50IGFyY2hpdGVjdHVyZSBj YW4gZ3VhcmFudGVlIHRoYXQgYWxsIFBDQ3Mgd2lsbCBub3QgdXNlIA0KKGFuZCBwb3NzaWJseSBr aWxsKSBvbmUgb2YgUENFcyB3aXRoIGtlZXBpbmcgYWxsIG90aGVycyBpZGxlOzwvRk9OVD48L0ZP TlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQg MWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMiBsZm8xOyB0YWIt c3RvcHM6IGxpc3QgMS4waW4iPjxGT05UIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5a UkgtJmd0O3RoaXMgaXMgYWxzbyBteSBjb25jZXJuIGFuZCBpcyBhZGRyZXNzZWQgaW4gbXkgZHJh ZnQgDQpkcmFmdC16aGFuZy1wY2UtY29tbS1hcHAtbW9kZWwtMDEudHh0KHNlZSBzZWN0aW9uIDUp LjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28tbGlzdDogbDAgbGV2ZWwyIGxmbzE7 IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PEZPTlQgDQpmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lO OiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28tbGlzdDogbDAgbGV2 ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PEZPTlQgDQpzaXplPTI+Q29vcGVyYXRp b24gb2YgUENFcyBpcyBhbiBpbXBvcnRhbnQgc2NlbmFyaW8gZGVzY3JpYmVkIGluIHRoZSBQQ0Ug DQphcmNoaXRlY3R1cmU7IGhvd2V2ZXIsIHRoZXJlIHdlcmUgbm8gZGlzY3Vzc2lvbnMgc28gZmFy IGhvdyB0aGlzIGNvdWxkIGJlIA0KYWNoaWV2ZWQuIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIHdpbGwg YmUgYSBuZWVkIG9mIHN0cm9uZyBwcm90b2NvbCBzdXBwb3J0IGZvciANCnN1Y2ggY29vcGVyYXRp b24gdG8gaGFwcGVuLiBMaWtld2lzZSwgYSBQQ0MgbWF5IHNldHVwIGEgY29uZmVyZW5jZSB3aXRo IHNldmVyYWwgDQpQQ0VzIGF0IG9uY2UgdG8gZGVjaWRlIHdoaWNoIG9mIHRoZW0gY2FuIHNhdGlz ZnkgYSBwYXJ0aWN1bGFyIHJlcXVlc3QgDQpiZXN0LjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4y NWluOyBtc28tbGlzdDogbDAgbGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PEZP TlQgDQpmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlpSSC0mZ3Q7SSBhZ3JlZSB3aXRoIHlv dSB0aGF0IGNvb3BlcmF0aW9uIG9mIFBDRSBpcyBpbXBvcnRhbnQsIA0KYWN0dWFsbHksIHRoaXMg aXMgYWxzbyBkaXNjdXNzZWQgaW4mbmJzcDtteSBkcmFmdCZuYnNwO2luIHdoaWNoJm5ic3A7c29t ZSANCmNvb3BlcmF0aW9ucyBpcyBpbnRyb2R1Y2VkIHRvIHNvbHZlIHRoZSByYWNlIGNvbmRpdGlv bnMsIGhvd2V2ZXIsIGNvb3BlcmF0aW9uIA0Kc2hvdWxkIGJlIG1vcmUgZGlzY3Vzc2VkIGkgdGhp bmsuPC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDIgbGZv MTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48Rk9OVCANCmZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+PC9GT05UPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBs ZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48Rk9OVCANCmZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+Q2hlZXJzLDwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28t bGlzdDogbDAgbGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PEZPTlQgDQpmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlpoYW5nPC9GT05UPjwvUD48L0RJVj4NCjxCTE9DS1FV T1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJ Ti1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hU OiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDog I2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48 Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWlicnlza2luQG1vdmF6LmNvbSBocmVmPSJtYWlsdG86 aWJyeXNraW5AbW92YXouY29tIj5JZ29yIEJyeXNraW48L0E+IA0KICA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9anB2 QGNpc2NvLmNvbSANCiAgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5jb20iPmpwdkBjaXNjby5jb208 L0E+IDsgPEEgDQogIHRpdGxlPWplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVsZWNvbS5jb20gDQog IGhyZWY9Im1haWx0bzpqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tIj5MRSBST1VY IEplYW4tTG91aXMgDQogIFJELUNPUkUtTEFOPC9BPiA7IDxBIHRpdGxlPWFydGhpQGp1bmlwZXIu bmV0IA0KICBocmVmPSJtYWlsdG86YXJ0aGlAanVuaXBlci5uZXQiPkFydGhpIEF5eWFuZ2FyPC9B PiA7IDxBIA0KICB0aXRsZT1Pa2kuRWlqaUBsYWIubnR0LmNvLmpwIGhyZWY9Im1haWx0bzpPa2ku RWlqaUBsYWIubnR0LmNvLmpwIj5FaWppIE9raTwvQT4gDQogIDsgPEEgdGl0bGU9YWthdGxhc0Bh bHVtLm1pdC5lZHUgDQogIGhyZWY9Im1haWx0bzpha2F0bGFzQGFsdW0ubWl0LmVkdSI+YWthdGxh c0BhbHVtLm1pdC5lZHU8L0E+IDsgPEEgDQogIHRpdGxlPWFuZHJldy5kb2xnYW5vd0BhbGNhdGVs LmNvbSANCiAgaHJlZj0ibWFpbHRvOmFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLmNvbSI+YW5kcmV3 LmRvbGdhbm93QGFsY2F0ZWwuY29tPC9BPiA7IDxBIA0KICB0aXRsZT15LmlrZWppcmlAbnR0LmNv bSBocmVmPSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9BPiAN CiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5D Yzo8L0I+IDxBIHRpdGxlPXBjZUBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9y ZyI+cGNlQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBPY3RvYmVyIDI1LCAyMDA1IDEyOjQ5 IA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxC PlN1YmplY3Q6PC9CPiBbUGNlXSBVc2luZyBTSVAgYXMgUENFUCANCiAgdHJhbnNwb3J0PC9ESVY+ DQogIDxESVY+PEJSPjwvRElWPjxQUkU+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gMHB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkpQIChhbmQgUENFUCBk ZXNpZ24gY28tYXV0aG9ycyksPC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PG86 cD48L286cD48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHdvbmRlciBpZiB5b3UgZXZl ciBjb25zaWRlcmVkIHVzaW5nIFNJUCAocmZjIDMyNjEpIGFzIGEgdHJhbnNwb3J0IGZvciBQQ0VQ IChub3RlIHRoYXQgSSBkb24mIzgyMTc7dCBtZWFuIHJlcGxhY2luZyBQQ0VQIHdpdGggU0lQLCBy YXRoZXIsIHJ1bm5pbmcgUENFUCBvbiB0b3Agb2YgU0lQIGluc3RlYWQgb2YgVENQKT8gQWZ0ZXIg YWxsIFNJUCBpcyBhIHByb3RvY29sIHRoYXQgY2FuIGNyZWF0ZSBhbmQgbWFuYWdlIHNlc3Npb25z IGJldHdlZW4gdHdvIG9yIG1vcmUgcGFydGllcyBhbmQgdHJhbnNmZXIgb3BhcXVlIG9iamVjdHMg YmV0d2VlbiB0aGVtIHRoYXQgcHJlc3VtYWJseSBjYXJyeSBhIHBheWxvYWQgb2YgaGlnaGVyIGxh eWVyIHByb3RvY29scyBzdWNoIGFzIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCwg cmZjIDIzMjcpIG9yLCBhcyBJIGJlbGlldmUsIFBDRVAuPC9GT05UPjwvUD48UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PG86cD48L286cD48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIGFt IG5vdCBhIFNJUCBzcGVjaWFsaXN0IGFuZCwgdGhlcmVmb3JlLCBjb3VsZCBiZSB3cm9uZzsgaG93 ZXZlciwgaXQgZG9lcyBzZWVtIHRvIG1lIHRoYXQgU0lQIGhhcyBhIGxvdCBvZiBtYWNoaW5lcnkg dGhhdCBmYWxscyBzdHJhaWdodCB1bmRlciByZXF1aXJlbWVudHMgZm9yIFBDQy1QQ0UgY29tbXVu aWNhdGlvbiBwcm90b2NvbCBkZXZlbG9wZWQgd2l0aGluIHRoZSBQQ0UgV0cuIFRvIG5hbWUgc29t ZSBvZiB0aGUgbWVjaGFuaXNtczo8L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwaW4gMGluIDBwdCAwLjc1aW47IFRFWFQtSU5ERU5UOiAtMC41aW47IG1zby1saXN0 OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC43NWluIj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjEuPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5BdXRo ZW50aWNhdGlvbiBvZiBwYXJ0aWVzIGFuZCBlbmNyeXB0ZWQgY29tbXVuaWNhdGlvbiBiZXR3ZWVu IHRoZW07PC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQgMC43NWluOyBURVhULUlOREVOVDogLTAuNWluOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuNzVpbiI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4y LjxTUEFOIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+UHJvdGVjdGlvbiBhZ2FpbnN0 IG1hbGljaW91cyBhdHRhY2tzOzwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0IDAuNzVpbjsgVEVYVC1JTkRFTlQ6IC0wLjVpbjsgbXNvLWxpc3Q6 IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjc1aW4iPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+My48U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlBhcnR5 IGRpc2NvdmVyeSBjYXBhYmlsaXR5IGVuYWJsZWQgYnkgaW50cmluc2ljIGxvY2F0aW9uIHNlcnZp Y2UuIEluIHRoZSBjb250ZXh0IG9mIFBDRVAgaXQgbWVhbnMgdGhhdCBvbmUgb3Igc2V2ZXJhbCBQ Q0VzIHdpdGggaWRlbnRpY2FsIG9yIHNpbWlsYXIgY2FwYWJpbGl0aWVzIGNvdWxkIGJlIHJlZ2lz dGVyZWQgdW5kZXIgdGhlIHNhbWUgbmFtZSAoYWRkcmVzcy1vZi1yZWNvcmQpLCBhbmQgUENDcyBj b3VsZCBxdWVyeSBvbmUgb3IgbW9yZSBTSVAgcmVnaXN0cmFycyBhbmQgbGVhcm4gYWJvdXQgYWxs IFBDRXMgb24gdGhlIG5ldHdvcmsuIFRoZXJlIGlzIGEgU0lQIG1ldGhvZCAmIzgyMTE7IENBUEFC SUxJVElFUy0gdGhhdCBpcyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgdG8gaGVscCB1bmRlcnN0YW5k aW5nIHRoZSBwZWN1bGlhcml0aWVzIG9mIGFjY2Vzc2luZyBhIHBhcnRpY3VsYXIgcGFydHkgKHJl YWQgUENFKSB3aXRob3V0IGFjdHVhbGx5IHJpbmdpbmcgdGhlIHBhcnR5LiBTdWNoIHNlcnZpY2Ug d291bGQgZmFjaWxpdGF0ZTo8L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb0JvZHlUZXh0SW5kZW50IHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1s aXN0OiBsMCBsZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPmEpPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFu JyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5tb3ZpbmcgYSBQQ0UgYXJv dW5kIHRoZSBuZXR3b3JrIGluIGEgdHJhbnNwYXJlbnQgZm9yIFBDQ3MgYW5kIG90aGVyIFBDRXMg bWFubmVyOzwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDIgbGZv MTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmIp PFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvU1BBTj5lYXN5IHN1cHBvcnQgb2YgYmFja3VwIFBDRXM7PC9GT05UPjwvUD48 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMWluOyBURVhULUlO REVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3Qg MS4waW4iPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Yyk8U1BBTiBzdHlsZT0iRk9OVDog N3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPm5hdHVyYWwgY29tcHV0YXRpb24gbG9hZCBkaXN0cmlidXRpb24gKGJ5IGZvcmtpbmcgSU5W SVRFIHJlcXVlc3RzIGJldHdlZW4gUENFcyBzaGFyaW5nIHRoZSBzYW1lIEFPUiBhY2NvcmRpbmcg dG8gc29tZSBwb2xpY3kpLiBOb3RlLCB0aGF0IGlmIGEgbmV0d29yayBoYXMsIHNheSwgMyBQQ0Vz IHdpdGggaWRlbnRpY2FsIGNhcGFiaWxpdGllcyBhbmQgYWxsIG9mIHRoZW0ga25vd24gdG8gUEND cywgSSBkb24mIzgyMTc7dCBrbm93IGhvdyBjdXJyZW50IGFyY2hpdGVjdHVyZSBjYW4gZ3VhcmFu dGVlIHRoYXQgYWxsIFBDQ3Mgd2lsbCBub3QgdXNlIChhbmQgcG9zc2libHkga2lsbCkgb25lIG9m IFBDRXMgd2l0aCBrZWVwaW5nIGFsbCBvdGhlcnMgaWRsZTs8L0ZPTlQ+PC9QPjxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjc1aW47IFRFWFQtSU5ERU5UOiAt MC41aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC43NWluIj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjQuPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGlt ZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvU1BBTj5NYW55IHVzZWZ1bCBzZXJ2aWNlcyBzdWNoIGFzOjwvRk9OVD48L1A+PFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6 IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDEuMGlu Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmEpPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAn VGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5t ZXNzYWdlIGZvcndhcmRpbmc7PC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQgMWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGww IGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3QgMS4waW4iPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Yik8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPm1lc3NhZ2UgcmUtZGlyZWN0aW5nOzwvRk9OVD48 L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDFpbjsgVEVY VC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBs aXN0IDEuMGluIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmMpPFNQQU4gc3R5bGU9IkZP TlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvU1BBTj4mIzgyMjA7YW1fYnVzeV9ub3dfd2lsbF9jYWxsX2FzX3Nvb25fYXNfSV9jYW4mIzgy MjE7IHNlcnZpY2UsIGV0Yy48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8bzpw PjwvbzpwPjwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IDAuNzVpbjsgVEVYVC1JTkRFTlQ6IC0wLjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBs Zm8xOyB0YWItc3RvcHM6IGxpc3QgLjc1aW4iPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ NS48U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPkFiaWxpdHkgZm9yIGEgUEND IHRvIHRyYWNrIHRoZSBwcm9jZXNzIG9mIHRoZSByZXF1ZXN0ICh2aWEgcHJvdmlzaW9uaW5nICgx eHgpIG1lc3NhZ2VzKS4gRm9yIGluc3RhbmNlLCBhIFBDQyBtYXkgcmVjZWl2ZSBhIG1lc3NhZ2Ug dGhhdCBpdHMgcmVxdWVzdCBpcyByZWNlaXZlZCBhbmQgcXVldWVkLCBQQ0Ugd2FpdHMgZm9yIGNv bXBsZXRpb24gb2YgbG9jYWwgY29tcHV0YXRpb25zIG9yIHJlc3BvbnNlKHMpIGZyb20gY29vcGVy YXRpbmcgUENFcywgZXRjLjwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0IDAuNzVpbjsgVEVYVC1JTkRFTlQ6IC0wLjVpbjsgbXNvLWxpc3Q6IGww IGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjc1aW4iPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Ni48U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlNJUCBoYXMg YSAmIzgyMjA7Q0FOQ0VMJiM4MjIxOyBtZXRob2Qgc3BlY2lmaWNhbGx5IGRlc2lnbiBmb3IgY2Fu Y2VsaW5nIHByZXZpb3VzbHkgc2VudCByZXF1ZXN0cyB3aXRob3V0IGNhdXNpbmcgcmFjZSBjb25k aXRpb25zLCBmb3IgaW5zdGFuY2UsIHRvIGF2b2lkIHNpdHVhdGlvbiB3aGVuIHRoZSBDQU5DRUwg cmVxdWVzdCBpcyBwcm9jZXNzZWQgYnkgYSBQQ0UgYmVmb3JlIHRoZSBhc3NvY2lhdGVkIHBhdGgg Y29tcHV0YXRpb24gcmVxdWVzdCBhbmQsIHRodXMsIGRyb3BwZWQ8L0ZPTlQ+PC9QPjxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjc1aW47IFRFWFQtSU5ERU5U OiAtMC41aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC43NWlu Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjcuPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAn VGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvU1BBTj5TSVAgc3VwcG9ydHMgY29uZmVyZW5jZXMsIHRoYXQgaXMsIGFzc29jaWF0 aW9uIG9mIG1hbnkgcGFydGllcy4gRm9yIGluc3RhbmNlIGEgZ3JvdXAgb2YgY29vcGVyYXRpbmcg UENFcyBjb3VsZCBzZXR1cCBzdWNoIGEgY29uZmVyZW5jZSB0byBzcGxpdCByZXNwb25zaWJpbGl0 aWVzIGluIHNhdGlzZnlpbmcgYSBwYXJ0aWN1bGFyIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdCwg YW5kIHRoZW4gcGVyZm9ybSBuZWNlc3NhcnkgY29tcHV0YXRpb25zIGluIHBhcmFsbGVsLCByYXRo ZXIgdGhhbiBzZXF1ZW50aWFsbHkgd2l0aCBlYWNoIFBDRSBkZWNpZGluZyBvbiBpdHMgb3duIHdo YXQgcGF0aHMsIHBhdGggb3IgdHJlZSBzZWdtZW50cyBpdCBtdXN0IGNvbXB1dGUuIENvb3BlcmF0 aW9uIG9mIFBDRXMgaXMgYW4gaW1wb3J0YW50IHNjZW5hcmlvIGRlc2NyaWJlZCBpbiB0aGUgUENF IGFyY2hpdGVjdHVyZTsgaG93ZXZlciwgdGhlcmUgd2VyZSBubyBkaXNjdXNzaW9ucyBzbyBmYXIg aG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQuIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIHdpbGwgYmUg YSBuZWVkIG9mIHN0cm9uZyBwcm90b2NvbCBzdXBwb3J0IGZvciBzdWNoIGNvb3BlcmF0aW9uIHRv IGhhcHBlbi4gTGlrZXdpc2UsIGEgUENDIG1heSBzZXR1cCBhIGNvbmZlcmVuY2Ugd2l0aCBzZXZl cmFsIFBDRXMgYXQgb25jZSB0byBkZWNpZGUgd2hpY2ggb2YgdGhlbSBjYW4gc2F0aXNmeSBhIHBh cnRpY3VsYXIgcmVxdWVzdCBiZXN0LjwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9GT05UPjwvUD48UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SSBhbHNvIHdvdWxkIGxp a2UgdG8gbWFrZSBhIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnMsIHdoaWNoIElNTyBtYWtlcyBTSVAg d29ydGggbG9va2luZyBhdC4gRmlyc3RseSwgU0lQIGhhcyBhIGdvb2QgbGlrZWxpaG9vZCB0byBi ZWNvbWUgYSBwcm90b2NvbCBvZiBjaG9pY2UgZm9yIChHKU1QTFMgY2FsbCBjb250cm9sLCBzbyB3 aHkgbm90IHRvIHJldXNlIHRoZSBzYW1lIHRvb2wgZm9yIG90aGVyIHB1cnBvc2VzPyBTZWNvbmRs eSwgU0lQIGNvdWxkIGJlIGludm9sdmVkIGF0IHNvbWUgbGF0ZXIgc3RhZ2Ugb2YgdGhlIFBDRVAg ZGV2ZWxvcG1lbnQsIEkgbWVhbiwgd2UgY2FuIHN0YXJ0IHJ1bm5pbmcgUENFUCBvdmVyIFRDUCBh bmQgc29tZSB0aW1lIGxhdGVyIHN3aXRjaCB0byBTSVAuPC9GT05UPjwvUD48UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PG86cD48L286cD48L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5XaGF0 IGRvIHlvdSB0aGluaz88L0ZPTlQ+PC9QPjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwaW4gMGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8bzpwPjwv bzpwPjwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4g MHB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPklnb3I8L0ZPTlQ+PC9QPjxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8bzpwPjwvbzpwPjwvRk9OVD48L1A+PFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9GT05UPjwvUD48L1BSRT4NCiAgPFA+DQogIDxIUj4NCg0KICA8 UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ UGNlIG1haWxpbmcgDQogIGxpc3Q8QlI+UGNlQGxpc3RzLmlldGYub3JnPEJSPmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwv SFRNTD4NCg== --Boundary_(ID_fjzRYX40L3aaYHlJPljR8A)-- --===============1452539485== 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 --===============1452539485==-- From pce-bounces@lists.ietf.org Fri Oct 28 10:04:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUqg-0004yh-Av; Fri, 28 Oct 2005 10:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUqe-0004yc-Nw for pce@megatron.ietf.org; Fri, 28 Oct 2005 10:04:48 -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 KAA19330 for ; Fri, 28 Oct 2005 10:04:30 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVV4E-0006tq-2F for pce@ietf.org; Fri, 28 Oct 2005 10:18:51 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2005 10:04:39 -0400 X-IronPort-AV: i="3.97,263,1125892800"; d="scan'208"; a="74620878:sNHT21842196" 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 j9SE43FG013498; Fri, 28 Oct 2005 10:04:37 -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); Fri, 28 Oct 2005 10:04:13 -0400 Received: from [192.168.1.100] ([10.86.242.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 10:04:13 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <258E8AAA-6299-4631-A50E-D9C64D47CB0F@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 27 Oct 2005 10:03:40 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 28 Oct 2005 14:04:13.0550 (UTC) FILETIME=[79EDD8E0:01C5DBC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Updated PCE WG Meeting Agenda X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Updated PCE WG meeting agenda can be found at: http://www3.ietf.org/ proceedings/05nov/agenda/pce.txt JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Oct 28 11:18:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW0I-0001cO-MY; Fri, 28 Oct 2005 11:18:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW0G-0001cJ-Jd for pce@megatron.ietf.org; Fri, 28 Oct 2005 11:18:48 -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 LAA24065 for ; Fri, 28 Oct 2005 11:18:32 -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 1EVWDp-0000hH-GR for pce@ietf.org; Fri, 28 Oct 2005 11:32:51 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2005 08:18:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9SFIK9E001333; Fri, 28 Oct 2005 08:18:32 -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); Fri, 28 Oct 2005 11:18:30 -0400 Received: from [192.168.1.100] ([10.86.240.68]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 11:18:29 -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: Fri, 28 Oct 2005 10:16:37 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 28 Oct 2005 15:18:29.0905 (UTC) FILETIME=[DA1FA810:01C5DBD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] WG Last Call ended on draft-ietf-pce-discovery-reqs-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Working Group, The WG LC on draft-ietf-pce-discovery-reqs-02.txt has ended with no further comments and will move forward. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Oct 31 11:15:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcJd-0002Oj-H1; Mon, 31 Oct 2005 11:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcJc-0002Nk-1G for pce@megatron.ietf.org; Mon, 31 Oct 2005 11:15:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17884 for ; Mon, 31 Oct 2005 11:14:59 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWcXj-0004PN-OG for pce@ietf.org; Mon, 31 Oct 2005 11:30:01 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1130775226!7266681!32 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27880 invoked from network); 31 Oct 2005 16:15:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 31 Oct 2005 16:15:02 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA0010E2C9; Mon, 31 Oct 2005 11:11:15 -0500 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] Updated PCE WG Meeting Agenda Date: Mon, 31 Oct 2005 10:11:15 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA95D0@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Updated PCE WG Meeting Agenda Thread-Index: AcXbyOBf69K827kVQFKsXVEmP/NPoACa+Pug From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 RE agenda item #5: 5) Discussion on the PCE Discovery protocol (JL Le Roux - 15mn) draft-leroux-pce-discovery-proto-00.txt I don't find any draft by that name, maybe I missed the announcement. Is it perhaps http://www.ietf.org/internet-drafts/draft-leroux-pce-disco-proto-igp-00. txt? A link to the referenced draft(s) in the agenda would be helpful. Thanks, Jerry -----Original Message----- From: pce-bounces@lists.ietf.org [mailto:pce-bounces@lists.ietf.org] On Behalf Of JP Vasseur Sent: Thursday, October 27, 2005 10:04 AM To: pce@ietf.org Subject: [Pce] Updated PCE WG Meeting Agenda Hi, Updated PCE WG meeting agenda can be found at: http://www3.ietf.org/=20 proceedings/05nov/agenda/pce.txt JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Oct 31 13:21:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeHu-0000Fj-Iu; Mon, 31 Oct 2005 13:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeHs-0000FI-3F for pce@megatron.ietf.org; Mon, 31 Oct 2005 13:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25480 for ; Mon, 31 Oct 2005 13:21:21 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWeW5-0005NS-F7 for pce@ietf.org; Mon, 31 Oct 2005 13:36:22 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Oct 2005 13:21:30 -0500 X-IronPort-AV: i="3.97,270,1125892800"; d="scan'208"; a="74788222:sNHT2075018578" 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 j9VIKnFI007806; Mon, 31 Oct 2005 13:21:27 -0500 (EST) 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); Mon, 31 Oct 2005 13:21:23 -0500 Received: from [192.168.1.100] ([10.86.241.24]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 13:21:22 -0500 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA95D0@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA09FA95D0@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D58E3C2-34C7-4DFC-8A83-59D4A03D2CDA@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Updated PCE WG Meeting Agenda Date: Mon, 31 Oct 2005 13:20:43 -0500 To: "Ash, Gerald R ((Jerry)), ALABS" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 31 Oct 2005 18:21:22.0777 (UTC) FILETIME=[E5B44C90:01C5DE47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Good catch, thanks Jerry. I updated the agenda with the correct reference. Thanks, JP. On Oct 31, 2005, at 11:11 AM, Ash, Gerald R ((Jerry)), ALABS wrote: > RE agenda item #5: > > 5) Discussion on the PCE Discovery protocol (JL Le Roux - 15mn) > draft-leroux-pce-discovery-proto-00.txt > > I don't find any draft by that name, maybe I missed the announcement. > Is it perhaps > http://www.ietf.org/internet-drafts/draft-leroux-pce-disco-proto- > igp-00. > txt? > > A link to the referenced draft(s) in the agenda would be helpful. > > Thanks, > Jerry > > -----Original Message----- > From: pce-bounces@lists.ietf.org [mailto:pce- > bounces@lists.ietf.org] On > Behalf Of JP Vasseur > Sent: Thursday, October 27, 2005 10:04 AM > To: pce@ietf.org > Subject: [Pce] Updated PCE WG Meeting Agenda > > Hi, > > Updated PCE WG meeting agenda can be found at: http://www3.ietf.org/ > proceedings/05nov/agenda/pce.txt > > JP. > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Oct 31 16:58:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhfZ-0005Tp-K2; Mon, 31 Oct 2005 16:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhfX-0005RS-V2 for pce@megatron.ietf.org; Mon, 31 Oct 2005 16:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13450 for ; Mon, 31 Oct 2005 16:57:59 -0500 (EST) 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 1EWhtl-0002CW-6t for pce@ietf.org; Mon, 31 Oct 2005 17:13:04 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2005 13:58:07 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="359079378:sNHT21914084" 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 j9VLvibQ015289 for ; Mon, 31 Oct 2005 13:58:06 -0800 (PST) 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); Mon, 31 Oct 2005 16:58:04 -0500 Received: from [192.168.1.100] ([10.86.240.239]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 16:58:04 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <7B6FD642-46C0-46C3-A290-0154F8F9B798@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Mon, 31 Oct 2005 16:57:25 -0500 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 31 Oct 2005 21:58:04.0168 (UTC) FILETIME=[2B232080:01C5DE66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Presentations 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 Presenters, Could you please send your presentation by Nov7th ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce