Subject: RE: [Pce] Choosing the PCE protocol

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Mon, 3 Oct 2005 15:30:13 -0700

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Thursday, September 29, 2005 7:27 AM
>To: [email-masked]
>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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pce
>

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Tue, 4 Oct 2005 12:45:44 -0400

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-masked]?subject=help> 
>List-id: Path Computation Element <pce.lists.ietf.org> 
>List-post: <mailto:[email-masked]> 
>List-subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
<mailto:[email-masked]?subject=subscribe> 
>List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
<mailto:[email-masked]?subject=unsubscribe> 
>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
>
>>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,
>>
>>       to the PCEP proposal, where the content is structured 
>>with objects.
>>>From: pce-bounces at lists.ietf.org
>>>[mailto:pce-bounces at lists.ietf.org] On Behalf Of Adrian Farrel
>>>To: pce at ietf.org
>>>Three candidate protocols have been brought to my attention for us to

>>>consider. These are (in no specific order):
>>>- HTTP
>>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.
>>>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 at lists.ietf.org
>>Pce at lists.ietf.org