Hi,
Agreed here too with
Dean; COPS is quite heavy in term of states maintenance and
protocol overhead, when compared with PCECP.
Thanks
Regards... Zafar
>To: "Adrian Farrel" <adrian at
olddog.co.uk>, <pce at ietf.org>
>Subject: RE: [Pce] Choosing the PCE protocol
>From: "Dean Cheng \(dcheng\)" <dcheng at cisco.com>
>Date: Mon, 3 Oct 2005 21:10:18 -0700
>Cc:
>List-archive: <http://www1.ietf.org/pipermail/pce>
>List-help: <mailto:[EMAIL PROTECTED]>
>List-id: Path Computation Element <pce.lists.ietf.org>
>List-post: <mailto:[email protected]>
>List-subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[EMAIL PROTECTED]>
>List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[EMAIL PROTECTED]>
>Sender: pce-bounces at lists.ietf.org
>Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5QAALsmmA=
>Thread-topic: [Pce] Choosing the PCE protocol
>
>--------------------------------------------------------------------------------
>
>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.
>
> 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.
>
>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
>>[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:
>>
>> 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 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
>>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 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
>>
>Subject: RE: [Pce] Choosing the PCE protocol
>From: "Dean Cheng \(dcheng\)" <dcheng at cisco.com>
>Date: Mon, 3 Oct 2005 21:10:18 -0700
>Cc:
>List-archive: <http://www1.ietf.org/pipermail/pce>
>List-help: <mailto:[EMAIL PROTECTED]>
>List-id: Path Computation Element <pce.lists.ietf.org>
>List-post: <mailto:[email protected]>
>List-subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[EMAIL PROTECTED]>
>List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[EMAIL PROTECTED]>
>Sender: pce-bounces at lists.ietf.org
>Thread-index: AcXFDbZz2JEoluA8QS2YadSDtllKogDWGX5QAALsmmA=
>Thread-topic: [Pce] Choosing the PCE protocol
>
>--------------------------------------------------------------------------------
>
>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.
>
> 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.
>
>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
>>[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:
>>
>> 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 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
>>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 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
>>
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
