Subject: [Pce] Re: [mpls] Mailing List for Path Computation Element (PCE)

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Jan 2005 09:50:17 -0500

Hi Raymond,

Thanks for your comments - see in line,

On Oct 12, 2004, at 5:10 PM, raymond zhang wrote:

>
> Hi Adrian, JP, Jerry,
>
> I've gone through the I-D "draft-ash-pce-architecture-00.txt" and  I 
> think this document has very well stated the architectural objectives 
> and need for a separate WG for this area.
>
> Also please find some minor comments below:
>
> - section 3. Definitions
>
> " Path Computation Element (PCE) is an entity that is capable of
> computing a network path or route based on a network graph, and
> applying
> computational constraints. The PCE entity can be located within an
> application"
>
> (RZ: I'd suggest some rewording here: The PCE entity is an application 
> process
> that can be located on a network node or component, on an out-of-
> network server, etc.)

Good suggestion, changes done.

>
> - Page 4, first paragraph:
> 1) Path computation is applicable in both intra-domain, inter-domain,
> and inter-layer contexts. Inter-domain path computation may involve the
> correlation of topology and routing information between domains.
> Overlapping domains are not within the scope of this document.
> In the inter-domain case, the domains may belong to a single or
> multiple
>
> (RZ:"inter-layer contexts" is mentioned at the beginning of this
> paragraph so it would be good to explain this a bit as did for
> inter-domain)

Text added:

"Inter-layer path computation refers to the use of PCE where multiple 
layers are involved and when the objective is to perform path 
computation at one or multiple layers while taking into account 
topology and resource information at such layers."

>
> - Page 4. 3) "Centralized computation model" ... There would (RZ: add 
> "be")...

ok

> - Page 6, 2nd paragraph:
> (RZ: From SP's perspective, it is not a difficult thing to migrate a
> legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane
> supporting TE ext. So I dont seem to see a strong case for this...)
>

We do agree but we wanted to mention this case for the sake of 
exhaustiveness. That said, this could happen in some cases with "small" 
edge devices not supporting the TE extensions for which TE LSPs would 
be required. That said, again, not a strong and usual case.

> - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say 
> on one hand this
> scenario does not relay on loose hops, yet on the other hand PCE based
> solution provides loose hops in the computed paths ?)

Good catch, the text is indeed ambiguous - New Text:
"This scenario suggests a solution that does not involve doing
computation on the ingress router, and that does not rely on static 
loose hops configuration in which case optimal paths could hardly be 
achieved.
A distinct PCE-based solution can help here. Note that the PCE in this 
case may, itself, provide a path that includes loose hops."

>
> - Page 7, section 5.1.  5.1. Composite PCE
>
> "Figure 1 below shows the components of a typical composite PCE node
> (that is, a router that also implements the PCE functionality) that
> utilizes path computation. The routing protocol is used to exchange TE
> information from which the TED is constructed. Service requests are
> received by the node and converted into signaling requests"
>
> (RZ:it would be good to clarify between service requests to the PCE or 
> inter-
> PCE requests and service requests to signal a TE-LSP request) ...
>

Some text added to clarify.

> - Page 12, first paragraph (RZ: It would be probably more appropriate 
> to rename to this section to
> "Service Request/Response Synchronization" vs. "TED Sync" in a
> subsequent section.  It may be more productive here in describing 
> service request/reponse sync of PCC-PCE and PCE-PCE
> as part of the architectural discussion, rather than illustrating more 
> detailed
> procedures since these procedures could be discussed in a detailed spec
> document in which it may transform to something different.)

Not entirely sure to see the section that you're referring to ?

>
> - page 13, 2nd paragrah:
> "No assumption is made at this stage about whether the PCC-PCE and
> PCE-PCE communication protocols are identical."
>
> (RZ: but I think it would be architectrually more scalable if they are 
> same, so are such comments are warranted here (same protocols for both 
> PCC-PCE/PCE-PCE...) in an arch doc ?
>

Thanks for your input - (With WG chair hat), this a WG item which will 
be discussed in the WG and has not been determined, thus this generic 
statement. Note that this does not have implication on the overall 
architecture.

> - Section 6.8: (RZ: since this is an arch doc, does it imply that 
> implementation of either scheme would meet the arch framework 
> established here ?)
>

The PCE architecture ID indeed describes two possible types of PCE, 
namely "statefull" and "stateless"
Note that this ID is "Informational" (see RFC2026):

> - A general comment:  there are a lot of very good, analytical 
> discussions in the document presenting different cases.  It would be 
> good I think if the authors could provide some guidance in drawing up 
> some architecture recommendations after comparing/analyzing some of 
> these cases or simply say all cases presented in some of these 
> sections are considered valid architectural options ?
>

The latter is what we indeed target. I'm sure other more specific IDs 
will be proposed with applicability statement.

Thanks a lot for your comments.

JP.

> Regards,
> Raymond

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