Subject: RE: [Pce] Choosing the PCE protocol

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 4 Oct 2005 19:12:05 +0200

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 : [email-masked] [mailto:[email-masked]] De la part de Zafar Ali (zali)
	Envoyé : mardi 4 octobre 2005 18:28
	À : [email-masked]
	Cc : [email-masked]
	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" <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 15:30:13 -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: 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: Eiji Oki <[email-masked]>
Date: Sat, 08 Oct 2005 00:34:03 +0900

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" <[email-masked]> wrote:

> 	Envoy$Bq(B: mardi 4 octobre 2005 18:28
> 	$B%?(B : [email-masked]
> 	Cc : [email-masked]

---

From: raymond zhang <[email-masked]>
Date: Fri, 07 Oct 2005 10:30:42 -0700

Hi all,

For SPs with both multi-area/level, the additional PCE-PCE peers across 
AS-boundaries would further add to the amount of inter-PCE 
communications.  I'd agree with JL's comments below that control plane 
protocol for PCC/PCE and PCE/PCE needs to be lightweight and 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="----_=_NextPart_001_01C5C906.BF1B06D7"
>
>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).
>
>----------
>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
>
> >List-archive: 
> <<http://www1.ietf.org/pipermail/pce>http://www1.ietf.org/pipermail/pce>
> >List-help: 
> <<mailto:[email-masked]?subject=help>mailto:[email-masked]?subject=help> 
>
> >List-post: <<mailto:[email-masked]>mailto:[email-masked]>
> >List-subscribe: 
> <<https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce>, 
> <mailto:[email-masked]?subject=subscribe>
> >List-unsubscribe: 
> <<https://www1.ietf.org/mailman/listinfo/pce>https://www1.ietf.org/mailman/listinfo/pce>, 
> <mailto:[email-masked]?subject=unsubscribe>

---

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

hi,

see in-line - would you please clarify the following points ?

raymond zhang wrote:

> communications.  

not sure to understand what you mean here - "who adds what to what" ?

> I'd agree with JL's comments below that control plane 
> protocol for PCC/PCE and PCE/PCE needs to be lightweight and optimized 
> to this requirement. PCEP is designed for this purpose.

i would propose that "light" vs "heavy"-weight gets exactly defined in 
the present context b/f using related arguments when discussing pro/cons 
of specific implementation(s)

also what is meant with "optimized to this requirement" (i guess you 
mean here "optimized to be ligthweight") ?

thanks,
- dimitri.

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

---

From: Jaudelice Cavalcante de Oliveira <[email-masked]>
Date: Wed, 12 Oct 2005 13:26:31 -0400

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  
better to just modify (extend) and existing protocol, I believe that  
coming up with a protocol that only carries the necessary overhead  
(clean design) and requirements, and it is extensible is a much more  
reliable approach, and PCEP has these characteristics. A clean design  
is not necessarily a "wheel reinvention" since the experiences  
learned can be incorporated. Moreover, it has the advantages of  
keeping things "clean," simple and optimized for the related  
requirements, and as a result avoiding the burden of carrying  
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  
> across AS-boundaries would further add to the amount of inter-PCE  
> communications.  I'd agree with JL's comments below that control  
> plane protocol for PCC/PCE and PCE/PCE needs to be lightweight and  
> optimized to this requirement.    PCEP is designed for this purpose.
>
> Regards,
> Raymond
>
>> 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).
>>
>> It sounds IMHO quite important to take this point into  
>> consideration when selecting the protocol.
>>
>> Regards,
>>
>> JL
>>
>>
>>
>> ----------
>> De : [email-masked] [mailto:pce- 
>> [email-masked]] De la part de Zafar Ali (zali)
>> 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
>>
>> >List-archive: <<http://www1.ietf.org/pipermail/pce>http:// 
>> www1.ietf.org/pipermail/pce>
>> >List-help: <<mailto:[email-masked]? 
>> subject=help>mailto:[email-masked]?subject=help>
>> >List-subscribe: <<https://www1.ietf.org/mailman/listinfo/ 
>> pce>https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce- 
>> [email-masked]?subject=subscribe>
>> >List-unsubscribe: <<https://www1.ietf.org/mailman/listinfo/ 
>> pce>https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce- 
>> [email-masked]?subject=unsubscribe>
>> >-------------------------------------------------------------------- 
>> ----- -------
>> >
>> >Hi,
>> >