An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
draft-ietf-teas-pce-central-control-05

I like how clearly this document spells out the nature of the work that is to be performed to adapt PCEP to enable the described network architecture. It's not entirely clear to me what value it has as an archival document (rather than simply being used internally by the working group to guide future development). Has the working group explicitly discussed why they might want this published as an RFC?

This document uses the term "control plane" rather extensively without concretely defining it. While I can infer some things about what is meant, it appears to be intended as a very concrete and specific term. In particular, it seems to diverge from how that term is used in (e.g.) voice networks, to the point of meaning nearly the opposite (that is: I've gathered that it refers to the exchange of routing information on the same paths as are used to exchange traffic). If there is a formal definition of the term in some referenced document, I would think a citation to it would be useful. If not, please take a stab at a formal definition of this term early in this document.

Section 2.1.2 suggests that inter-controller state sync can be achieved by sharing a common back-end database ("...or by using a shared database."). Without further qualifying the database as being also distributed, this simply pushes the single point of failure from the controller to the database. Please add terms to qualify the database itself as being highly-available/distributed.

Just some editorial comments:

- The abstract is unusually long, and seems more like an introduction. The second to last paragraph could almost stand by itself as a useful abstract.

- The terms "southbound" and "northbound" could use definition. (I find these terms cause lots of confusion, since not everyone draws the diagrams with the same idea of what goes on top or bottom.)

- 2.1.1: It's probably too late at this point to change it, but I find the use of "domains" unfortunate. That may be one of the most overloaded terms in the IETF lexicon, if not in that of the networking crowd at large. Since you describe them as "partitions", I think "partitions" would have been better.

- 2.1.2, 2nd to last paragraph: "This is nominally a simple task if
   there are just two controllers, but can actually be quite complex if
   state changes in the network are not to be lost."

That sentence seems self-contradictory. I don't think it's simple, nominally or otherwise.

Thanks for a clearly written document. While reading the document, I also had a quick look at the teas charter and am wondering how this work is covered by the charter. This shouldn't stop publication, but maybe there is a need to update the charter, especially if more work in this space is expected.