Early Review of draft-farrkingel-pce-abno-architecture-13
review-farrkingel-pce-abno-architecture-13-rtgdir-early-meuric-2015-01-26-00
Request | Review of | draft-farrkingel-pce-abno-architecture |
---|---|---|
Requested revision | No specific revision (document currently at 16) | |
Type | Early Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2015-01-26 | |
Requested | 2014-12-08 | |
Authors | Daniel King , Adrian Farrel | |
I-D last updated | 2015-01-26 | |
Completed reviews |
Genart Last Call review of -13 by Vijay K. Gurbani
(diff)
Genart Telechat review of -15 by Vijay K. Gurbani (diff) Opsdir Early review of -11 by Tina Tsou (Ting ZOU) (diff) Opsdir Last Call review of -13 by Tina Tsou (Ting ZOU) (diff) Rtgdir Early review of -11 by Tomonori Takeda (diff) Rtgdir Early review of -13 by Julien Meuric (diff) |
|
Assignment | Reviewer | Julien Meuric |
State | Completed | |
Request | Early review on draft-farrkingel-pce-abno-architecture by Routing Area Directorate Assigned | |
Reviewed revision | 13 (document currently at 16) | |
Result | Has nits | |
Completed | 2015-01-26 |
review-farrkingel-pce-abno-architecture-13-rtgdir-early-meuric-2015-01-26-00
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.