Today’s visit to the Priority Queue curiosity shop explores the notion of multi-layered control planes. Guest Russ White joins us to outline the concept of a control plane that’s broken out into separate functional classes. The goal is to keep the networking protocols that operate at each layer as simple as possible.

Current efforts around software-defined networking advocate a centralized controller, but Russ and Ethan review how the industry has oscillated between centralized and decentralized models for decades.

Part of the problem is that both models come with their own complexities. Limitations inherent with decentralization may be addressed via centralization, but you also inherit the limitations built into centralization.

Russ and Ethan discuss CAP Theorem as it applies to the control plane, and the balance that has to be struck when centralizing control of a distributed system, i.e. a network.

They also discuss what a layered control plane might look like. Russ outlines three categories in a layered control plane.

First is base reachability and topology (that is, what is located where on the network). Second is network policy, such as traffic engineering, filtering packets, and service chaining. Third is business logic; for example, don’t run this workload across the network until after 5:00 pm.

By separating out these layers, you can allow protocols  to do what they are expressly designed to do, rather than trying to twist and manipulate them to enable more functions than they were intended to provide.

Prepare to have your mind expanded as Russ and Ethan get conceptual.

Show Notes:

Part 1 – Why Is The Industry Having This Argument?

* Decentralized is hard (complex)!

* Centralized is hard (complex)!

* Yes, but do we ever really do away with complexity?

* This leads us to CAP theorem. Which of these are going to have, and at what cost?

* Consistency

* Availability

* Partitionability

Part 2 – Layering

* We layer lots of things…

* Protocols

* Topologies

* Can we layer the control plane?

Part 3 – A Conceptual Proposal For Control Plane Layering

* Top layer

* Business logic

* We need the control plane to do things for these overriding business reasons

* Middle layer

* Hide things

* Traffic engineering

* Flow engineering

* Lower layer

* Reachability

* React to topology changes

* ALTERNATIVELY

* Problem bounding

* APIs

* Challenges with this approach

* Should this proceed? If so, how?