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
computational constraints. The PCE entity can be located within an
(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
(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
- 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
- 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 ?
Rtgwg mailing list