Subject: [Teas] RtgDir review: draft-ietf-teas-pce-central-control-03

From: Thomas Morin <[email-masked]>
Date: Mon, 10 Jul 2017 16:50:28 +0200

Hello,

I have been selected as the 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-ietf-teas-pce-central-control-03
Reviewer: Thomas Morin
Review Date: 2017-07-10
IETF LC End Date: ?
Intended Status: Informational

Summary:

     No issues found. This document is ready for publication.

Comments:

     Saying that the draft is well written would be an understatement: 
it reads like a fairy tale.  And a nicely illustrated one.

     Beyond the (barely) private joke, despite the document being 
overall fairly honest in detailing the conditions under which the PCE 
architecture and PCEP could be generically applicable to central 
control, I'm under the impression that the document could exercise a bit 
more criticism on this idea in some places. In particular, section 3.2.3 
on service delivery and the start of section 4, may lead the reader into 
believing that it it may actually be easy to adapt PCEP for this use 
case ("only realtively minor changes"), even though the document does 
not provide rationale to support that this would be easier than, for 
instance, completing the Netconf/YANG framework for the same purpose. 
That is to say, the document would be more interesting in this area, if 
it was discussing whether or not actually choosing to extend PCEP for 
this purpose is a direction to favor in particular.

Nits:

     First paragraph of section 2.1.1 ends with 'control "domains." ' 
where I would have expected 'control "domains".', but this is possibly 
just me being not aware of a typography rule.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Jul 2017 17:33:17 +0100

Thomas,

Thanks for the review!

>      No issues found. This document is ready for publication.

Perfect. That's what I like to hear.

> it reads like a fairy tale.  And a nicely illustrated one.

What? A bit like https://www.feedaread.com/profiles/8604/ ?

> this purpose is a direction to favor in particular.

It's tricky, and you're not the first to ask about this subjective statement.

I do not want, in this document, to describe all of the protocol mechanisms we could use. I think that would be a massive stretch.
On the other hand the conversation about using PCE is necessarily closely tied to "what protocol will you use?" and there is (in my mind) an assumption that a PCE is a thing that talks PCEP.

I might note that the work currently proposed to the PCE working group goes beyond the text of section 4 by suggesting the use of new messages. I take issue with that work because I think smaller changes to PCEP are sufficient.

All that said, I don't know how further to address this comment. If 3.2.3 and 4 lead the reader to think that it would be (relatively) easy to adapt PCEP for these needs then I think the document will have done the job it was intended to do!

> just me being not aware of a typography rule.

I refer you to Eric's response and suggest that the RFC editor can fix any house style issues.

A