Re: [Pce] WG Last Call of draft-ietf-pce-hierarchy-fwk

[Julien Meuric <[e-mail]>]

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, [e-mail] 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
>