Subject: RE: [Pce] Choosing the PCE protocol

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Mon, 3 Oct 2005 21:10:18 -0700

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Dean Cheng (dcheng)
>Sent: Monday, October 03, 2005 3:30 PM
>To: Adrian Farrel; [email-masked]
>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: [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
>

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

---

From: [email-masked]
Date: Fri, 7 Oct 2005 13:04:31 -0400 (EDT)

Dean,

See my comments in-line.

Igor

>       application, either PCE (server) or PCC may initiate

 IB>> Why would a PCE want to initiate a connection with a PCC?

>       maintain any subsequent states.

IB>> Even if all this is true, why is it a big deal?

>       and communicates with another PDP. PCEP supports this model

IB>> Functions of PDP and PEP are orthogonal and surely could be
physically co-located
>       there would be a large number of extensions, thus defeating

IB>> PCIM is designed to be easily expanded for application (read PCE)
specific needs

Igor

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 07 Oct 2005 20:12:35 +0200

>  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 ?

> 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

> IB>> Functions of PDP and PEP are orthogonal and surely could be

indeed

>>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 ?

> .