The Future of Intent-based Networking and Multi-domain Architectures: Part I
In this article
Over the past few decades, the networking industry has experienced several major architectural shifts. One such example is when Token Ring was set aside in favor of Ethernet switching. Another is the evolution of applications away from centralized mainframes to being hosted in multiple data centers simultaneously. Yet another architectural shift is ongoing presently.
Over the last few years, WWT has started to see the major OEMs offering traditional campus, branch and data center networking domains being managed by software-defined networking (SDN) controllers. WWT is also starting to see organizations migrating the workloads to the cloud and container-based platforms and they are struggling to understand those networking constructs as they are accustomed to more traditional networking.
Before we get into the concepts of IBN, let's look at a few SDN concepts. While WWT works with organizations that have converted one or more of their networking domains (campus, branch, data center) to SDN, we still have many clients that utilize traditional three-tier architectures and have not been exposed to SDN.
The current landscape
First, let's take a quick look at how we do things today. As I mentioned earlier, networking today is based on the way a device that forwards a network packet learns where to send the packet. This is the same concept whether it's a switch and a layer 2 frame or a router and a layer 3 packet. Each networking device has a control plane that is used to manipulate the forwarding table (FIB) or data plane which controls how the device forwards the packet. The control planes are updated and troubleshot separately on each of the devices and managed, configured and upgraded individually from a configuration standpoint, and upgraded.
If there is a need to make a change, perform a device upgrade or troubleshoot, the network administrator must log in to each device and verify that the control plane (RIB Table) is correct as well as data plane forwarding (FIB) is correct. As networks have grown and become more complicated, mean time to repair (MTTR) increases and requires specialized skill sets. This architecture has been around a very long time and it does work well when there are no issues such as misconfiguration, code bugs or hardware problems.
Enter SDN
The concept of SDN has been around since 2008 when a collaboration between Stanford and Berkeley Universities created the OpenFlow protocol. Many different SDN protocols exist today, but OpenFlow was the first.
What OpenFlow, as well as other SDN protocols, enables is the ability to manage and direct traffic on a device by programming the control plane of the device from a single top-level or "source of truth" controller. If we recall in our original "old school" diagram of each device having a separate control plane, what SDN allows us to do is have a centralized control plane or single controller. This single control plane allows the SDN controller to program the forwarding tables of all the devices.
Now add controllers and devices
The last piece is how the controller and devices communicate. Network operators will configure the controller using a Northbound API. There are various methods for interacting with the API that all work well, such as the GUI or automation tools such as Ansible or Postman. There is a huge business benefit from being able to configure, upgrade and troubleshoot your network from a single point of view or pane of glass. Add in the ability to automate these tasks, and we find that a controller-based SDN network becomes very nimble.
Automation makes it easier to both modify and troubleshoot, both of which reduce operational expenditure (OpEx). The controller will interact with each device through an agent that takes the configuration pushed from the controller and programs the device.
This process can be bidirectional; the agents can push information about the device's health, state and telemetry information back to the controller. So not only is the controller a single point to push configuration, but it is also a single point to receive information on the health of the entire infrastructure. The result is we can not only troubleshoot faster but proactively monitor the network for issues.
Today, we see many OEMs offer SDN-based network domain controllers such as SD-WAN, SD-Access and SD-Data Center. An additional innovation is that some data center solutions can control container networking as well as public cloud networking. This can be a difficult landscape to navigate, and WWT can help customers by offering a non-biased view of what's best from a business point of view, instead of who has the best features today.
Why use SDN versus traditional networking?
From a business standpoint, why are customers turning to SDN over traditional networking when they have a refresh or to alleviate performance and outage issues?
- First, the software-defined network provides agility and rapid service enablement since we can automate the configuration. This allows us to adapt to market transitions.
- Next, an SDN enabled network allows us to simplify the everyday care and feeding of the network. SDN can reduce operational complexity and decrease the total cost of ownership by allowing the use of automation to manage the infrastructure.
- Security in the infrastructure has become paramount due to everyday breaches. SDN allows for micro-segmentation of workloads that help detect and mitigate threats.
- We can also differentiate business services which allow us to monetize the network leading to cost-saving.
- Because SDN offers centralized policy and configuration management, compliance and audits become much easier.
- SDN solutions also offer application mobility between data centers by easily enabling disaster recovery options for applications
- Finally, SDN reduces costs by extending what the network can do from a capital expenditure standpoint. It allows for greater capability, faster time to deploy using automation and reducing MTTR using telemetry information.