Skip to main content

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 Snapshot
Review review-farrkingel-pce-abno-architecture-13-rtgdir-early-meuric-2015-01-26
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.