[Teas] Genart last call review of draft-ietf-teas-pce-central-control-03

[Elwyn Davies <[e-mail]>]

Reviewer: Elwyn Davies
Review result: Almost Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.