I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-teas-pce-central-control-03 Reviewer: Elwyn Davies Review Date: 2017-08-20 IETF LC End Date: 2017-08-24 IESG Telechat date: 2017-08-31 Summary: Amost ready. I found this a well-written and mostly readily comprehensible document although it contains a couple of instances of unexplained SDN/PCE jargon (notably 'southbound'). My main concern is that the archtecture suggests that extensions to PCEP will a.s. be needed and implies that mechanisms will be needed to provide multiple extensions but neither specifies detailed guidance as to how this might be done or points to work in progress that would provide this guidance. The implication of the statements in this document are that an implementation or deployment might need to check if particlar extensions are implemented in communication partners and also how to behave if an unreconixed extension is received especially to avoid possible DoS. The other minor issues are only just abve the level of nits. Major issues: None Minor issues: Abstract:  The abstract is probably overlong. s1:  RFC 4655 is itself an architecture that introduces the PCE.  It would be helpful to explain that this document is an extension of the basic PCE arcitecture except that it relies on the specific use f the PCEP for intercommunication between architectural elements providing traffic control and routing whereas RFC 4655 does not assume any particular protocol.  s3.2: It would be desirable to reiterate the problem of synchronization mentioned in s2.1.2 which is relevant to all the high level functions. s4: Since this document effectively gurantees that extensions to PCEP will be created and since RFC 5440 contains no extensibility procedures/guidelines, it seems to me that either this document should indicate how PCEP extensions and profiles are added to the base protocol or should point  to a (normative and currently non-existent) document that updates RFC 5440 and defines how extensions shoould be structured and provides ways for implementations to determine what is supported, if necessary. s5, para 2:  The second part of this paragraph;    However, debate will rage over overall system security and the opportunity for attacks in an    architecture with a central controller since the network can be vulnerable to denial of service     attacks on the controller, and the forwarding system may be harmed by attacks on the messages    sent to individual NEs. In short, while the interactions with a PCE-based controller are not     substantially different from those in any other SDN architecture, the security implications of SDN     are still open for discussion. The IRTF's SDN Research Group (SDNRG) discussed this topic.  This text needs to be rewritten to be suitable for inclusion in an RFC that is a document of record. s6:  The PCE, depending on which of the aspects mentioned in s3 and the technology being managed (LSPs, transport paths, etc.) are involved in a particular imlemetation/deployment, will need to access the relevant state information in NEs and possibly other PCEs using relevant managent protcol(s) and MIBs or similar.  Integrating this state information with the PCEP management information wil be key to effective operation of the centralized PCE system.   s10:  It is arguable, IMO, that RFC 5440 and I-D.ietf-pce-pce-initiated-lsp are normative references.  The architecture implies their usage and someone implementing the architecture would need to be familiar with the details of the extended PCEP, particularly in respect of the manageability and security aspects of the protocol.  Nits/editorial comments: Abstract, para 1: Statements of implied omnipotence by mortals a.s. lead to hubristic consequences...  s/any definition of "optimal"/virtually any definition of "optimal"/ Abstract (and subseqently):  The term 'southbound' is SDN specific jargon and should be explained.  Given that the abstract is already (IMO) too long, it would be wise to remove it from the abstract (I don't think it is essential) and provide the explation in s1. s1, para 4: See comment above... s/any form of routed or switched network./virtually any form of routed or switched network./ s2, para 2 and Figures 1-7:  It would be useful to add a note in s2 to indicate that the TED box in all the figures should imply that other databases may also be accessed. s2, last para (just before Fig.3): s/use case- specific/use case-specific [or use case specific]/ s2.1, para 1: The text at the beginning of the para doesn't read very easily - the 'or' disguises the fact that the two problems are on either sideof the 'or'.  Suggest someting like: OLD: Systems with central controllers are vulnerable to two problems: failure or overload of the single controller. NEW: Systems with a single central controllers are vulnerable to two problems:    - controller failure, and   - controller overload. ENDS s3.1.4, last para:      new protocol extensions may be needed, and some are already being worked on       in [I-D.ietf-pce-wson-rwa-ext].  The second clause of this is not future proof:   Suggest s/and some are already being worked on in [I-D.ietf-pce-wson-rwa-ext]./as, for example, described  in [I-D.ietf-pce-wson-rwa-ext]./ s3.1.5, para 1: s/the header or a packet/the header of a packet/ (I think - certainly for IPv6 use case) s3.2.2, last para:  The final sentence is probably superfluous - and, if it remains, probably needs a reference to explain what a FEC is.