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

From: <[email-masked]>
Date: Fri, 08 Jun 2012 16:37:34 +0200

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Julien Meuric <[email-masked]>
Date: Mon, 11 Jun 2012 18:16:19 +0200

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-masked] 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.
>

---

From: "Daniel King" <[email-masked]>
Date: Thu, 14 Jun 2012 08:41:31 +0100

Thanks Julien, 

We will address these, along with other comments received during LC, after
the LC finishes. 

Br, Dan.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien
Meuric
Sent: 11 June 2012 17:16
To: [email-masked]
Subject: Re: [Pce] WG Last Call of draft-ietf-pce-hierarchy-fwk

Hi authors.

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

> Please sent your comments to the PCE mailing list.
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Julien Meuric <[email-masked]>
Date: Fri, 22 Jun 2012 15:08:55 +0200

Hi.

This WG LC has ended. Authors, please address or discuss received 
comments and publish an updated I-D.

Regards,

JP & Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Jun 2012 17:48:35 +0100

Hi Julien,

> for TED Synchronization".

We feel this section serves two purposes:
1. explain how BGP-TE is not necessarily a suitable substitute for H-PCE
2. show how BGP-TE may be a good northbound

The first point (1st two paras of section 6) should stay.
Second point is 3rd para of section 6. It is quite short. We agree it could be
in applicability statement and we will add a forward pointer, but we think it is
useful to keep the text here as well. As a compromise, we have split it out into
a separate section named as you suggested.

New revision soon.

Cheers,
Adrian (and probably Dan and the others :-)

---

From: Julien Meuric <[email-masked]>
Date: Thu, 28 Jun 2012 17:43:48 +0200

Hi Adrian.

The 1st purpose you advocate is indeed relevant in the document. Then, 
there is no reason to drop only the 3rd paragraph. The proposed 
sub-section looks all right to me and, obviously, it does not preclude 
to mention it in others I-Ds. I think this addresses my comment.

Cheers,

Julien