The document discusses the trade-offs between centralized and distributed control planes in networking, highlighting factors like network control and policy complexity. It outlines three potential API points for injecting information into network devices, facilitating different operational modes and interactions with routing tables. Additionally, it emphasizes the shift in focus for network professionals towards the control plane and the significance of data-driven approaches in future business models.

2. Consistent, Accessible, and Partitionable
(CAP Theorem)

8. • It depends on the network, the controller, the kinds of changes, all
of these kinds of things. In the real world, if you can completely
control the network and the controller, if the policy is complex and
difficult to distribute, and other factors line up, then the centralized
control planes can be better.
• However, if you have policy that can be easy to distribute and is not
very complex or can be easily divided among the modules in the
network in a way that allows you to spread your policy out more
effectively, if you don't have complete control over the network or
the controller, you have multiple spans of domain or domains of
control in your network, then a distributed control plane might be
better. So that's the trade-offs in a centralized control plane.

9. 3 Possible API points

10. 3 Possible API points
• three basic places or APIs where information can be injected into a network device or a router or
an intermediate system, depending on what routing protocol and what you're doing in the
network. You can actually inject information here at the control plane itself, into the control plane
itself in some way and again, I'll give you some examples of these as we go through these slides just
so you have a better sense of how these Southbound Interfaces actually work. So, you can actually
interface directly with a distributed control plane, so this might be considered some sort of a hybrid
mode where you have a control plane distributed and you also have a centralized controller that is
managing some of the information that the distributed control plane also deals with. Another way
of dealing with this is to have an API sitting here going into the RIB or the Routing Information Base,
the routing table itself. In the case of FRRouting and many other routing stacks, that would be
Zebra, which is a Routing Information Base or again a routing table. Now, in this case, again, you
might be running a hybrid mode where you're running a distributed routing protocol as well as a
centralized controller, the third optional place to put it is in the FIB, directly injecting the
information into the forwarding table just before it goes into the ASIC or in some cases, directly into
the ASIC itself, that would be kind of unusual, but it is a possibility out there. Now, if you're running
into the FIB, into the API, directly into the FIB, you would not be running this in a hybrid mode, you
normally would not be running a distributed control plane along with this type of injection pointer
into this API. Each one of these options presents different trade-offs, different positive and negative
aspects to them.

11. • Now, another way that you can do this is you can have an API that talks directly to the routing table on each device, most of the
routers in the world have an API that talks directly to the RIB, for instance, Arista EOS has an API that will talk directly to the RIB, Junos
does, FRRouting, there is a Northbound Interface off of the Zebra RIB that sits in FRRouting that you can talk directly to, which you
would need to do as you would need to put a little agent sitting on the box that talks to the RIB, so you would have the RIB process
locally and then you would have a little agent talking to that that would look like just another routing protocol to the RIB and then you
would develop a Northbound Interface off of this. And actually, FRRouting has a Northbound Interface that you can use that's Yang-
based off of the RIB to do this with, it could be using Yang like I said, it could be using GRPC, JSON, or anything like that, any of these
interfaces or even a proprietary interface if you wanted to, some hyperscalers will build their own proprietary interface that talks
directly to the RIB on something like Zebra. This interface will allow you to install routes directly into the RIB, for instance, you might
install, instead of the route going this way, you want it to go this way or something like that, you can actually do traffic engineering
this way. You can also install Label-Switched Paths, LSP's, into the RIB directly through this outside controller. Now, the RP, if there's a
distributed routing protocol running on all of these devices, because the controller is talking to the RIB, the distributed routing
protocol, again, will be able to see the routes that the controller is installing into the RIB, so again, this is a form of a hybrid mode type
of thing for if you were talking about a software-defined network model or if you were thinking about a software-defined model of
networking.
• RIB and to the label manager sitting on the box, so it not only talks to the RIB, it talks to the label manager, so, PCEP is designed
primarily, as I said, for managing Label-Switched Paths for traffic engineering. A centralized controller would now consume the LSDB,
which is the Link-State Database, so this assumes you are running a Link-State protocol, rather than something like BGP and it's gonna
consume the LSDB from each of the devices in the network and pull them into the controller and it's gonna run constrained SPF
locally on the controller to build traffic engineer paths, so then, it's going to figure out what those traffic engineer paths are and
install Label-Switched Paths in each of the devices contacting directly to the RIB and the label manager. So, the router, then, would
impose a label stack on traffic coming in through particular interfaces so that you get the Label-Switched interface or the Label-
Switched Path running through there. If you're already running MPLS or segment routing, the PCEP tends to be a really good solution
for a Southbound Interface if you want to install an overlay controller into your network

15. Automation is baked in

16. • So in the past, my focus was on all these devices on these appliances. So I was very
focused down here. And as I moved up, I would actually move up in my amount of
knowledge to smaller and smaller amounts, so that I get to the point where I know
almost nothing about the business. In the disaggregated world, I can flip that
around. I can allow the hardware engineers who really know hardware to focus in
on hardware. And as a network designer or operator, I can focus more on the
control plane network operating system, network management, the applications,
and I can drive further into the business side. So this is considered climbing the
stack. It releases me, it allows the hardware to become commodity while I drive up
the stack and try to add value in different places in the network, rather than sticking
me down there at the appliance level as a network operator, or network engineer,
network designer, or whatever it happens to be. So the shape of knowledge is really
different in a disaggregated network than it would be in an appliance-based
network. This is a really crucial key in understanding what you need to know and
how you move into this disaggregated world.

23. The lower is the more likely future

25. • There are three different ways to think about a business or a company that is working into the
future. The first is what I would consider to be data-oblivious, or process-driven. So, for this
perspective, what I mean here is I mean their primary focus is on the business process, on this last
part. So you can see the lines here get really wide around this part. So these businesses are very
focused on the product they're making, they're very focused on the process of making that
product, of selling that product, and they're tend to not pay much attention to the data. The data is
either not very important, or these businesses consider the data to be a bit of a cost center, or
largely as a cost center. A second way of looking at a business is to see it as data-aware. In this
particular case, we do have more concern about data and applications, you can see that the spread
is a little bit wider down here than it is with a data-oblivious or process-driven company. But you're
still very focused on the business process. And then the third kind of company you might see out
there is gonna be what I consider to be data-driven. And here what you see is you see, there's the
big, the big area in the chart is around the data rather than the applications. The applications are
built in order to extract value from the data, rather than focusing on the process of the business
itself. So in this particular case, the data is used as a productive feedback mechanism for the
business itself. So you're seriously thinking about data sources, uses, and data privacy. So these
types of things are very important in a data-driven business. So the reason this is so important is
that you begin to think about, if data is the driver in the business, then the handling of that data is
important in that business.

26. Data gravity