Welcome to part two in our NetDevOps Primer series! Our first post in this series covered the evolution of network operations - essentially a brief history of network automation. The rest of the series will focus on the building blocks of modern network automation. Those interrelated concepts, trends, and methodologies that are worth understanding before starting to build and operate your own intent-based network (IBN) and NetDevOps (Network Development Operations) practice.
What is SDN?
While the words “software defined networking” could be interpreted literally to mean any networking defined by software, the term and its acronym “SDN” were coined to refer to something far more specific. The concept that SDN is commonly accepted to name is defined by the complete separation of control and forwarding planes.
In a typical network, control is provided by device configurations (which capture the operator’s intent) and routing protocol messages (which coordinate forwarding paths between devices). Since routing protocol messages are transmitted between devices over the same physical and logical networks as any other data (routed protocol messages), there is some mixing of the control and forwarding planes. More so, the devices that are responsible for forwarding are complicit in choosing (controlling) those forwarding paths based on their individual configuration and operational state. Every network device is thus a controller and a forwarder.
With SDN, on the other hand, device based configurations and routing protocol messages are not the primary source of control. Instead, there is a centralized controller which collects telemetry and mandates forwarding paths through an out of band (OOB) control channel to an API on each device (the OpenFlow protocol defines such an API along with the required message formats). In this way, control of network forwarding is totally decoupled from the forwarding function itself. The controller controls and the forwarders (network devices and functions) forward.
SDN Advantages
The primary advantages of SDN are twofold, and both relate to the centralized control over the network that is the cornerstone of the concept. First, by moving control to a centralized function we provide a single point of management for the network. No longer do you need to login to individual forwarding devices (or functions) to troubleshoot issues or to make configuration changes. With SDN you have a centralized interface (provided by the controller) that delivers complete visibility and control over the entire network.
Second, this centralization of control also provides theoretically limitless processing power. Rather than being reliant on, and constrained by the CPU and storage fitted into each forwarding device (switch/router/firewall/etc) the SDN controller is an application that can run on whatever server hardware or cloud platform you deem necessary. This allows you to scale the resources available, as you would for any other application. It also allows you to tie into virtually any data source. And all of that opens up possibilities for new and more advanced approaches to routing, policing, and otherwise controlling network traffic. In fact, the initial use case for OpenFlow was to allow researchers to try out new routing algorithms on production networks, without needing to swap out the forwarding device hardware or software.
Additional, second and third order benefits accrue from these first two. Faster issue resolution due to centralized visibility and potentially powerful root cause identification lead to lower downtime. More agile policy and configuration management due to centralized control and potentially powerful automation and orchestration lead to faster time to market for new network enabled services. This is where things can often get confused though. Many of the benefits of SDN that folks tout are actually benefits of automation, orchestration, validation, and virtualization. To avoid confusion, we maintain the original and specific definition of SDN: The separation of the forwarding and control planes.
Do We Need SDN?
When viewed from that narrow perspective, SDN is not strictly required for most benefits often attributed to it. And, like anything, it brings some challenges of its own. The biggest of these is interoperability and backwards compatibility. While many claim that SDN allows for heterogeneous vendor-neutral networks, that is only true if all the devices and functions support a “Northbound” API compatible with the selected controller. This was the promise of OpenFlow – an open standard API and set of message formats to allow the controller function to “talk to” the forwarding functions across vendors, platforms, and operating systems.
In practice, this never really materialized. It’s a beautiful idea in a greenfield network, where you can install only OpenFlow (or some other network API) compatible devices and functions. But as any network engineer knows, greenfields are few and far between. In most cases we are expanding or advancing an existing network. At the very least we need to inter-operate with an existing network. So, while some vendors leveraged OpenFlow in their own proprietary solutions to some success, most folks moved on to find other, less restrictive ways to manifest the dreams ignited by the idea of SDN.
What Do We Need?
In the next 10 posts, we’ll explore automation, orchestration, feedback, validation, observability, virtualization (both of networks and network functions), infrastructure as code (IaC), intent based networking (IBN), and ultimately NetDevOps. Stay tuned and watch this space! =)
Excited to read the rest right NOW? Well, you’re in luck: Everything in this series is available RIGHT NOW in this FullCtl whitepaper: The NetDevOps Primer.