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:[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 protocolHi,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).ThanksRegards... 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 PROTECTED]>
>List-id: Path Computation Element <pce.lists.ietf.org>
>List-post: <mailto:[email protected]>
>List-subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[EMAIL PROTECTED]>
>List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:[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
