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
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).
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 PROTECTED] [mailto:pce-
[EMAIL PROTECTED] De la part de Zafar Ali (zali)
Envoyé : mardi 4 octobre 2005 18:28
À : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]
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>http://
www1.ietf.org/pipermail/pce>
>List-help: <<mailto:[EMAIL PROTECTED]
subject=help>mailto:[EMAIL PROTECTED]>
>List-id: Path Computation Element <pce.lists.ietf.org>
>List-post: <<mailto:[email protected]>mailto:[email protected]>
>List-subscribe: <<https://www1.ietf.org/mailman/listinfo/
pce>https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-
[EMAIL PROTECTED]>
>List-unsubscribe: <<https://www1.ietf.org/mailman/listinfo/
pce>https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-
[EMAIL PROTECTED]>
>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 protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
