An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
Note: This ballot was opened for revision 04 and is now closed.
Deborah Brungard Former IESG member
Yes (for -04)
Spencer Dawkins Former IESG member
Yes (2017-08-27 for -04)
This topic is not my area (duh, but I mean knowledge, not AD responsibility), and I learned enough to ballot Yes while reviewing. I find myself wondering why it’s more helpful than some other architecture drafts I’ve reviewed, and note that it’s also pretty close to a forward-looking applicability statement for PCE (re: https://tools.ietf.org/html/rfc2026#section-3.2). No action requested for this document, but something for ADs to think about, when we’re thinking about architecture documents in general. I did see a couple of places that were not as clear to me as most of the document was. In https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-04#section-3.1.1, the description is short, which could be fine, but meant I was guessing at a lot of high-level details that I could dig out of https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21 for myself, but it might be helpful to include a couple of points, like whether the PCCs in this technology are (always?) LSRs participating in the IGP (OSPF or IS-IS), and whether the PCEs are (always?) either LSRs or servers also participating in the IGP, and whether the IGP is (always?) used to set up LSPs, for readers who have a (G)MPLS or MPLS-TE network now, to figure out how it maps at a high level to what they already have. I’m guessing from https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21#section-5.5, but I’m guessing. I’m not quite sure what to do with this part of the security considerations: In short, while the interactions with a PCE-based controller are not substantially different to those in any other SDN architecture, the security implications of SDN have not been fully discussed or described. Therefore, protocol and applicability work around solutions for this architecture must take proper account of these concerns. It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCE-based central controller on the network type and services being managed. If I’m reading this literally, it’s saying that we haven’t finished discussing SDN security considerations in general yet, so each new document will consider the security impact of a PCE-based central controller on the network type and services being managed as an SDN. Is that what was meant? If I’m reading the manageability considerations section correctly, perhaps it’s worth pointing out what the extension story is for the IGPs that will be used in some of the technologies discussed earlier in the document, if that’s part of this work as well.
Adam Roach Former IESG member
No Objection (2017-08-30 for -04)
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.
Ben Campbell Former IESG member
No Objection (2017-08-29 for -04)
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.
Benoît Claise Former IESG member
No Objection (for -04)
Mirja Kühlewind Former IESG member
No Objection (2017-08-25 for -04)
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.
Suresh Krishnan Former IESG member
No Objection (for -04)
Terry Manderson Former IESG member
No Objection (for -04)