Subject: [RTG-DIR] RtgDir Review: draft-farrkingel-pce-abno-architecture

From: <[email-masked]>
Date: Thu, 15 Jan 2015 00:26:54 +0100

Hello,

I have been selected as the (2nd) Routing Directorate reviewer for this 
draft. The Routing Directorate seeks to review all routing or 
routing-related drafts as they pass through IETF last call and IESG 
review, and sometimes on special request. The purpose of the review is 
to provide assistance to the Routing ADs. For more information about the 
Routing Directorate, please see ​ 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-farrkingel-pce-abno-architecture-14.txt
Reviewer: Julien Meuric
Review Date: January 14, 2015
IETF LC End Date: January 9, 2015
Intended Status: Informational

Summary:
This document is basically ready for publication, but has nits that 
should be considered prior to publication.

Comments:
This document is clearly written and easy to understand. I had not 
realized, though, that the "cookbook" mentioned in the abstract had 
become an actual book along the updates. Anyway, the various use cases 
are helpful to extract some simple pieces from the general architecture.

Nits:
---
Page 1
- s/a operational/an operational/
---
Page 4
- s/GMPLS and MPLS/GMPLS-controlled and MPLS/
- The paragraph about remote control may deserve the inclusion of PCEP.
- The paragraph about provisioning, grooming, scheduling... may as well 
deserve the explicit inclusion of PCEP (RFC 5557 being implicit 
reference) to be consistent with other list items.
---
Page 7
- s/processing on a different/processing a different/
---
Page 8
- s/2.3.1 2.3.2/2.3.1 and 2.3.2/
---
Page 9
- The sentence "software tool with which the user makes requests of the 
networks to set up specific services" is difficult to parse and may need 
an update.
---
Page 10
- s/gathering state/gathering states/
---
Page 11
- The expansion of "LSP" is happening there while it is not the first 
use of the acronym, it would be enough to do it only at first occurrence.
---
Page 12
- s/information stores for use/information stored for use/  [or 
s/contain information stores for use/are informations stores for use/]
- s/should handled/should be handled/
---
Page 13
- s/paths can't/paths cannot/
- s/links and node failure/link and node failure/
---
Page 14
- s/packet switched network/packet-switched network/
---
Page 16
- s/programmed direct/programmed directly/
- GSMP is mentioned in section 2.3.2.6, is there a reason why it is not 
included in the list of 2.3.2.1?
---
Page 19
- s/PCE protocol/PCE communication Protocol/
---
Page 20
- s/combination or NETCONF/combination of NETCONF/
---
Page 21
- s/PCE protocol/PCE communication Protocol/
---
Page 22
- s/requests direct/requests directly/
- s/architecture and to determine/architecture, so as to determine/ [too 
many "ands"]
---
Page 23
- s/with the networks/with the network/
---
Page 24
- s/used set up/used to set up/
---
Page 26
- s/(LSR) and it signals/(LSR), which signals/
---
Page 27
- s/to the network direct/to the network directly/
---
Page 28
- Not sure the sentence about philosophers brings useful information 
(possibly because I feel like philosopher).
---
Page 30
- The parenthesis "(they have optical line cards)" should be dropped: no 
reason to introduce a particular case in that context.
---
Page 32
- s/GMPLS [RFC3473]/GMPLS RSVP-TE [RFC3473]/
- s/provisioned direct/provisioned directly/
- s/Interface to the Routing System/I2RS/  [used several times before]
---
Page 33
- s/operator and provider dependent/operator- and provider-dependent/
- s/packet switch cabale/packet switch capable/
- s/environments. Each DC site/environments: each DC site/  [or deeper 
rephrasing]
- s/GMPLS based/GMPLS-based/
---
Page 34
- The term "Cross-Stratum" is defined in section 3.7: it would be better 
to avoid its use before, especially only in a section header.
---
Page 35
- s/Application later/Application layer/
- s/t compute/to compute/
- s/end to end/end-to-end/
---
Page 36
- s/or discovery/or by discovery/
- s/without disruption/with minimized disruption/
---
Page 37
- s/is service-interrupting, but that arises/addresses a 
service-interrupting situation, which arises/
---
Page 40
- The "Endif" in the trigger loop should be removed.
- s/traffic engineered paths/traffic-engineered paths/
---
Page 43
- The phrase "as shown in Figure 20" is not in the right place: it 
should be moved from 2c. to 3.
- s/based on classification/relying on classification/  [to avoid 
"based" twice in the sentence]
- After traffic volume, I would add something like "optical modulation 
format and associated reach" to strengthen that the problem is more 
complex than bandwidth allocation.
- Associating the terms "adaptive and elastic" to a circuit-switched 
technology with a highly constrained container hierarchy reads odd... 
(to a philosopher like me)
---
Page 47
- s/LSPs each only span/LSPs only span/
---
Page 49
- s/path of the only one of/path of only one of/
- s/described in Section 3.6.3/as enabled by Section 3.6.3/ [protection 
is a use-case of path-diversity, not a synonymous]
---
Page 51
- s/Data center based/Data center-based/
- s/ QoS related/QoS-related/
---
Page 53
- s/makes a request an application request/makes an application request/
- s/network loading/network load/  [twice]
- s/data center based/data center-based/
- s/the services it wants/the desired services/
- s/it wishes to use/they wish to use/
---
Page 58
- s/Controller Setup/Controller Sets up/
---
Page 66
- s/The detials/The details/
- s/to satisfy I2RS./to satisfy I2RS will address the requirement./ [not 
a full sentence]
---
Page 67-68 (if considered useful before removal by the editor)
- s/seciton/section/
- s/GMPLS protocol/GMPLS protocols/
- s/tests made in TID has/tests made in TID have/
- s/BPG-LS/BGP-LS/
---
In various figures, the TED seems to be missing, e.g., 16, 17, 21 (+ 
LSP-DB).

Regards,

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Jan 2015 19:25:05 -0500

Julien,

Thanks very much for the thorough review; it's particularly useful with an
AD-sponsored draft.

Authors, could you take a look through the nits and update the draft
appropriately.

Regards,
Alia
On Jan 14, 2015 3:27 PM, <[email-masked]> wrote:

> routing-related drafts as they pass through IETF last call and IESG review,
> and sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see ​ http://trac.tools.ietf.org/
> area/rtg/trac/wiki/RtgDir
>
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> This document is basically ready for publication, but has nits that should
> be considered prior to publication.
>
> Comments:
> realized, though, that the "cookbook" mentioned in the abstract had become
> an actual book along the updates. Anyway, the various use cases are helpful
> to extract some simple pieces from the general architecture.
>
> Nits:
> ---
> Page 1
> deserve the explicit inclusion of PCEP (RFC 5557 being implicit reference)
> to be consistent with other list items.
> ---
> Page 7
> networks to set up specific services" is difficult to parse and may need an
> update.
> ---
> Page 10
> - The expansion of "LSP" is happening there while it is not the first use
> of the acronym, it would be enough to do it only at first occurrence.
> ---
> Page 12
> - s/information stores for use/information stored for use/  [or s/contain
> information stores for use/are informations stores for use/]
> - The phrase "as shown in Figure 20" is not in the right place: it should
> be moved from 2c. to 3.
> - s/based on classification/relying on classification/  [to avoid "based"
> twice in the sentence]
> format and associated reach" to strengthen that the problem is more complex
> than bandwidth allocation.
> technology with a highly constrained container hierarchy reads odd... (to a
> philosopher like me)
> ---
> Page 47
> - s/described in Section 3.6.3/as enabled by Section 3.6.3/ [protection is
> a use-case of path-diversity, not a synonymous]
> ---
> Page 51
> - s/to satisfy I2RS./to satisfy I2RS will address the requirement./ [not a
> full sentence]
> ---
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Jan 2015 10:17:19 -0000

Nice review, thanks.

Alia, any objection if we fix these before the end of IETF last call?

A

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 14 January 2015 23:27
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RtgDir Review: draft-farrkingel-pce-abno-architecture
> 
> Hello,
> 
> Routing Directorate, please see 
> ______________________________________________________________
> ___________________________________________________________
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Jan 2015 10:42:46 -0500

Adrian,

> Alia, any objection if we fix these before the end of IETF last call?

Please do.

Thanks,
Alia
> > Cc: [email-masked];
[email-masked]
> > In various figures, the TED seems to be missing, e.g., 16, 17, 21 (+
recu ce
> > message par erreur, veuillez le signaler
> > Orange decline toute responsabilite si ce message a ete altere, deforme
ou
> > falsifie. Merci.
> > If you have received this email in error, please notify the sender and
delete this
> > message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
been
> > modified, changed or falsified.
> > Thank you.
>