Subject: RE: [Pce] Choosing the PCE protocol

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Sat, 8 Oct 2005 08:57:37 -0700

Igor, Dimitri, 

Please see some response to your questions below.

Dean

>-----Original Message-----
>From: dimitri papadimitriou [mailto:[email-masked]] 
>Sent: Friday, October 07, 2005 11:13 AM
>To: [email-masked]; Dean Cheng (dcheng)
>Cc: [email-masked]
>Subject: Re: [Pce] Choosing the PCE protocol
>
>
>
>[email-masked] 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.

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

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

>>>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
>>>
>>>
>> 
>> 
>> 
>> _______________________________________________
>> 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: Zhang Renhai <[email-masked]>
Date: Sun, 09 Oct 2005 15:37:16 +0800

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)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 08, 2005 11:57 PM
Subject: RE: [Pce] Choosing the PCE protocol

Igor, Dimitri, 

Dean

ZRH>> If appropriate, I also want to know when the PCE initiat the connection

ZRH>>how do you think the flexibility of the  PCEP for the future extension for some kinds of usage. more than the tlv format. 

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 09 Oct 2005 11:17:01 +0200

dean

Dean Cheng (dcheng) wrote:

>>>>due to much optimization around its specifics such as:
>>>>

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

> need to have the switch/case statement in the existing code if any

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

>>>physically co-located indeed
> 

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

>>(read PCE) specific needs
> 

this underlines the need to come out with a more complete document for
assessing these statements

> 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