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

[raymond zhang <zhangr@sa.infonet.com>]

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

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

- Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")...
- 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...)

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

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

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

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

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

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

Regards,
Raymond