Hi authors.
Here is the chair review of draft-ietf-pce-hierarchy-fwk-02. No blocking
issue, but a few fixes to consider.
----------
Section 1
-----
Page 4
s/egress in known/egress is known/
-----
Sub-section 1.1
The last 2 paragraphs of section 1.1 (page 5) duplicate with the
penultimate one of the common part of section 1 (page 4), which is only
1-page-old: a single place would be enough.
-----
Sub-section 1.1
- The phrase "parent domain is used" while only defined in section 1.4.
Would a change in section order be possible?
- s/See Section 6.2/See Section 5.2/
-----
Sub-section 1.3
s/See section 7/See Section 6/
See also related comment about Section 6 below.
-----
Sub-section 1.3.2
When it comes to diversity, the only true requirement is physical
diversity. Domain diversity is an indirection allowing to address that
requirement in an easier way, however it can be easily made wrong: e.g.
2 MPLS networks over a common optical backbone, carrier's carrier... I
would suggest to:
- change section 1.3.2 into "Diversity" (at large),
- give number 1.3.2.2 to the existing sub-section "Domain Diversity",
- add a short sub-section "1.3.2.1 Physical Diversity", mentioning
concepts associated to SRLGs and the situation (disclaimer?) I have just
introduced.
You may drop the sub-section numbers and titles.
-----
Sub-section 1.3.4
Instead of "dollar costs", I would have rather expected pound sterling,
or copper... A generic phrase would be better at this stage, e.g.
"credit" or "currency unit".
-----
Sub-section 1.4
There is a reference to RFC 4875, which is P2MP RSVP-TE: is that the
intended one? Would not RFC 4726 be more appropriate?
----------
Sub-section 2.1
The section begins by covering 2 path computation cases: BN and PCE.
From the 4th paragraph, only the PCE case is named, while both would be
relevant. I would suggest to replace the 3 instances of "PCE[s]" in
paragraph 4 and 5 by a generic phrase, such as "path computing entity".
-----
Sub-section 2.2
- twice: s/to the PCE responsible for/to a PCE responsible for/
- a blank line should be removed
-----
Sub-section 2.2.1
- s/to the PCE for the ingress/to a PCE for the ingress/
- s/to the PCE responsible for/to a PCE responsible for/
----------
Section 3
- s/further in Section 5.3./further in Section 4.3./
- You go quite deep into the details (e.g. zero-cost virtual links),
which brings quality to the document. In this context, you may consider
adding a sentence or 2 to describe the case when both the child and the
parent capabilities are supported by a common PCE, which it is
completely allowed by the architecture you describe. It does not change
much, but it helps in stressing the flexibility of the architecture and
the fact that it does not necessarily add more boxes in the network.
----------
Sub-section 4.1
s/or maybe applied by/or applied by/
-----
Sub-section 4.3
s/described in Section 4./described in Section 4.4./
-----
Sub-section 4.7
- s/Relax the constraints/Relax some of the constraints/
- Is there a particular reason why the cancellation option is missing
from the timeout case, while mentioned in the child error case?
- In both cases, would not it be relevant to add something like "Prune
corresponding domain path from the candidate set"?
-----
Sub-section 4.8 (repetition)
s/RP object carried within the PCReq/RP object within the PCReq/
----------
Sub-section 4.8.3 (clarification)
s/use the parent as a parent/use the parent-capable as a parent/
s/if the parent determines/if the parent-capable determines/
-----
Sub-section 4.8.4
s/Section 5.4 describes/Section 4.4 describes/
----------
Section 5
s/(see Section 4)/(see Section 3)/
----------
Section 6
I reckon "BGP-TE" spans a broader scope than H-PCE. I feel like
draft-ietf-pce-inter-area-as-applicability could be an option. Note the
text should find a home before being dropped. In the latter case, 2
references along the I-D will need a pointer update. If it is kept in
there, I would suggest to rephrase the section title (the reference tag
is all right) to avoid misunderstanding, e.g. "A Note on the Use of BGP
for TED Synchronization".
----------
Section 7
In line with my comment on Section 3, I propose to add a something like:
"Another deployment option is to have each participating SP to act as a
parent PCE for (multi-domain) path computations associated to ingress
nodes within their own domain."
-----
Sub-section 7.1.3
Same comment as above about "punt sterling".
----------
Section 8 (for RFC Editor?)
In this document, the 3 ASON references look to me as background
information. Based on
http://www.ietf.org/iesg/statement/normative-informative.html, I would
rather consider them as informative rather than normative references. If
nobody cares about for an informative RFC, then the sub-section titles
might be useless.
I do not know if you have used an automated tool to build the list of
references, but the ways authors are mentioned is not consistent:
- surname and first name are not all in the same order, especially after
an "and", e.g. "J. Ash";
- some dots after the first name initial are missings, e.g. "Medved, J";
- some comas are missing between surname and first name, e.g. "Farrel A.";
- the same people are hidden behind different strings, e.g. "Vasseur,
J."/"Vasseur, J.P."/"Vasseur, J.-P."/"Vasseur, JP.", "Le Roux,
J.L."/"Roux, J."...
The 1st authors do not have any physical address: one might wonder if
Old Dog Consulting actually exists...
----------
Cheers,
Julien
Le 08/06/2012 16:37, [email protected] a écrit :
Hi all.
The document has been stable for a while and the traffic on the list
is low: the time seems appropriate to get many reviews.
This message starts a PCE WG last call on
draft-ietf-pce-hierarchy-fwk-02; this LC will end on Friday June 22,
noon UTC.
Please sent your comments to the PCE mailing list.
JP & Julien
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
