SDN and DevOps may both have a role in automated network device management, but compared to SDN, DevOps has a completely different mission, our expert explains.
The place of software-defined networks is certainly assured in the world of network engineering, if network engineers can agree on what SDN actually is. But a growing misconception is to think of SDN and development operations, or DevOps, as two similar but different ways to achieve automated network device management. To be completely clear, compared with SDN, DevOps is not a different way to achieve automated network configuration.
For those who believe SDN and DevOps have the same goal, the argument goes something like this: SDN moves the management of each device from the device itself to a centralized controller; DevOps automates the management of each device into a centralized controller. The difference is SDN replaces the management plane, and DevOps automates the control plane.
Because DevOps is both a set of tools and a way of working, it requires processes to design automation systems and tools that can do the actual automation. So, DevOps can bring a development-process mentality into network management. But comparing the goals of DevOps and SDN in terms of automation as interchangeable fails to understand the point of a software-defined network.
The concept of DevOps is being extended to mean an application developer's interaction with the configuration management system to change configurations in real time in order to meet application requirements. In other words, the application developer can change a router's route map to apply a different Border Gateway Protocol (BGP) community to a route. This can provide reachability to a server where a particular application is running, or change an access list that filters packets to a particular server. That's why some people say, "Oh, this is just like SDN."
But in real life, it's hard to imagine allowing an application developer to say, "I'm going to build a new feature, and that feature is going to require a different access-list setting on all the routers in the network. So, I'm going to push the access-list change to all the routers so it auto-deploys."
There might be an application owner that takes requirements from an application developer, who then asks network operations to push or approve a change to create an automated network configuration using an automation tool. But that's about the extent of what is going to happen in any realistic network operation.
Why DevOps isn't SDN
Even if we assume developers are allowed to directly push automated network configuration changes to the network based on an application they are developing, this still isn't SDN. In SDN, there is simply no control plane configuration on the individual forwarding device to be managed, because there is no control plane on the device to be configured.
In SDN, there is simply no control plane configuration on the individual forwarding device to be managed, because there is no control plane on the device to be configured.
Part of the confusion is people often consider access lists and BGP configuration to be roughly the same sort of thing. In reality, they are completely different. One tells a protocol how to act; the other tells a forwarding process what to forward -- and these two things are worlds apart. We've lived in an appliance-based, vendor-driven world for so long that the mental categories have all merged together. Part of the challenge of disaggregation, and even SDNs, is to break these things apart and reshape our mental models around a new way of thinking about problems and solutions.
A good place to start in explaining the difference between DevOps and SDN is in a somewhat unexpected place: the humble static route. The static route is a useful starting point because it is probably the most difficult example to understand in terms of what is part of the control plane and what is part of device management. To understand the issue, it is helpful to have a basic component diagram of a router, shown below.
Basic components of a router
In this illustration, pay close attention to the direction of the arrows between each component. Four components are important in understanding the distinction between SDN and DevOps:
1. Management represents the entire command-line interface, counters and other information that can be read from and written to the device.
2. The routing protocols are represented here by Open Shortest Path First Protocol, or OSPF; Intermediate System to Intermediate System, or IS-IS; and BGP.
3. The routing table holds the set of loop-free paths calculated from the information gathered by the routing protocols.
4. The forwarding table holds information derived from the routing table, plus several other tables in the device, such as lower- to upper-layer mapping tables.
Where does the humble static route fall into this diagram? Static routes are configured in the management process, but they have a direct effect on the routing table. This, in turn, has a direct effect on the forwarding table. As a result, the following two cases seem very similar:
An SDN controller installs some routing information directly into the routing or forwarding table.
The local management process is configured through DevOps to install some routing information directly into the routing table, which is then added to the forwarding table.
Looking at DevOps and SDN from this perspective, the two appear to be doing the same thing, which is where the idea that they are similar in scope actually originated. There are several problems with this line of thinking, however.
How SDN and DevOps differ
First, although an automation script -- DevOps -- might install a static route that is then installed into the routing table, this is not the same thing as installing a route directly into the routing table. Other processes can also install routes into the routing table -- specifically, the other routing protocols that happen to be running on the device, or even other processes that engineers might not classify as a routing protocol. For example, when a directly connected interface is configured with an IP address, a route is installed in the routing table to represent that interface.
In fact, installing a static route through the management subsystem is not the same as directly inserting information into the routing table. Even considering this observation, however, it still may seem reasonable to view SDN as a direct replacement for the management subsystem, rather than as a replacement for the control plane.
Second, software-defined networks completely bypass the routing protocols normally used to discover and calculate loop-free paths through the network. But SDN implementations not only bypass the routing protocols, they also bypass the routing table entirely. Not only is the SDN controller replacing the management subsystem in relation to forwarding information, but it is replacing the routing protocols and the routing table, as well. So, implementing a software-defined network is not replacing the management plane; it is actually replacing almost the entire control plane.
The question remains: Is the forwarding table part of the control plane? Traditionally, it is not; it is considered part of the forwarding subsystem. Even if the forwarding table is considered part of the control plane, in an SDN implementation, all of the intelligent parts of the control plane have been replaced. So, SDN has no mechanism for discovering the network topology, nor is there any way to calculate a set of loop-free paths through the network on the router or switch.
In the world of DevOps, even if an automated network system uses static routes to replace all routing protocols, there are still local processes like interfaces that can and do install routes into the routing table. Configuring all of the shortest paths in the network using static routes is not the same as deploying a software-defined network.
In summary, software-defined networks don't simply move the management plane from individual forwarding devices to a controller, which means the concepts of SDN, DevOps and automated networks must be disconnected.
