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

<julien.meuric@orange.com> Wed, 14 January 2015 23:27 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB831ACF1D for <rtg-dir@ietfa.amsl.com>; Wed, 14 Jan 2015 15:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sdLYsJXtYSa for <rtg-dir@ietfa.amsl.com>; Wed, 14 Jan 2015 15:27:00 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499871AD0AB for <rtg-dir@ietf.org>; Wed, 14 Jan 2015 15:27:00 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 697AD1B8781; Thu, 15 Jan 2015 00:26:58 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4DD1C3840B1; Thu, 15 Jan 2015 00:26:58 +0100 (CET)
Received: from [10.193.116.76] (10.197.38.2) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 15 Jan 2015 00:26:57 +0100
Message-ID: <26590_1421278018_54B6FB42_26590_15593_1_54B6FB3E.7090907@orange.com>
Date: Thu, 15 Jan 2015 00:26:54 +0100
From: julien.meuric@orange.com
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.197.38.2]
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.23.1824
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/aF20jB4qNqVkFxfn9zXq4A33Zpc>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-farrkingel-pce-abno-architecture.all@tools.ietf.org
Subject: [RTG-DIR] RtgDir Review: draft-farrkingel-pce-abno-architecture
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 23:27:04 -0000

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.