The Future of Intent-based Networking and Multi-domain Architectures: Part II

From the previous article, we have learned the business reasons that are driving organizations to explore and begin adopting controller-based networking. We have also learned how software-defined networking (SDN) uses a single control plane or controller and agents to programmatically configure the network, as well as gather telemetry, hardware state and health information from the network.

The easiest way to understand a software-defined network is to think of it as a large networking device that users and workloads attach to, which is managed from a single pane of glass. Adding a new "blade" or "device" to the network would be as simple as cabling the device into the network and going through the steps of allowing the controller to manage it. Once managed, the new device can be configured as just another line card in the large switch. 

What are the benefits of central network management?

When we allow our network to be managed centrally, we gain the following enhancements:

• The ability to gather telemetry from each device allows for a single pane of glass for visibility and health of the network as well as for troubleshooting.
• Best practice configurations are deployed consistently. When OEMs create these SDN-based networks, they use best practice settings on all configurations pushed. This means no more fat fingers, and no more 500 pages of validated design guides for all the tweaks to make the network perform at its best.
• Back-end integrations to other devices through the controller's API allow telemetry, assurance and automation to be integrated.
• You have the ability to pull state information (is a link down or flapping, power supply dead, port dropping packets due to buffer overruns?). This state information is paramount in troubleshooting and this is a daily operational task staff perform, however, it is box by box.
• Single policy on each device gives us the ability to make sure that a standard policy is applied, enhancing security and compliance.

How does intent impact the network?

Next, let us discuss what intent is and how we use it today. There are usually two main forms of intent: business intent and IT intent. A second concept that may be familiar to those who have worked with ACI is the idea of consumers and providers. A consumer can be users or devices, and they need connectivity to the providers of applications and services. Consumers can also be part of an application, such as a web server that needs to consume data provided from a back-end database. 

The goal of intent-based networking is to connect consumers and devices to provider applications and apply business and IT intent-based policies. 

How do we use intent in the network today?

First, we have a typical scenario in a corporate setting. "ABC Corporation" recently relocated its human resources department personnel to a new building. Business management wants everyone in the HR department to have access to HR applications that live in the data center. That simple statement is what is known as business intent. 

The IT intent is that there are also finance and contract workloads on that same network as the HR applications and from a compliance and security standpoint, HR should not be able to access that network. So, we create access control lists on devices and use firewalls to maintain the IT intent as well as the business intent of connecting HR in the new building. 

For every network engineer today, this is a daily routine, and we must convert the business and IT intent into configurations that we apply across the network. Manually converting these intents to configuration and then applying them can be a time-consuming task and is a large part of what an operational engineer does.

In a second example, the business intent is for HR personnel, as well as any guests they are meeting within the new building, to have wireless. IT wants to do this securely and in an automated fashion. Before the advent of wireless controllers (SDN controlled), the IT intent would be configuring multiple individual wireless access points for the proper channels, configure an Employee and Guest SSID, create 802.1x authentication on each device, then manually place the devices so the radio channels don't overlap. A network administrator would connect to each device console and configure the IT intent which was very time-consuming. 

Now that we have enabled our wireless networking domains to use SDN-based controllers, we simply log into a single controller, configure the relevant settings (IT intent), and when the access point joins the controller the configuration is applied. The result is that both the business and IT intent has been realized on the network.

The ideas behind IBN are not new, but what has changed recently is the ability of machine learning for processing the telemetry data and automation of the device configuration. WWT has observed some manufacturers going down the path of developing IBN solutions, and as organizations start exploring these concepts there are four major parts to understand.

First, an IBN system must perform the translation of business and IT intent into policy, verify the policy is valid and push the policy to the physical and virtual infrastructures. Because all IBN systems must be SDN controlled, we receive the benefit of best practices from the manufacturer being deployed to the infrastructure. And while the command line junkies complain that IBN has taken away the "nerd knobs," it has provided the business with a much more stable and nimbler infrastructure.

Next, the policy must be deployed in an automated fashion to create the desired business outcomes. As we discussed earlier, agents on the networking devices are used to program the infrastructure and modify existing policies. We now can automate the programming down to the ASIC level, allowing real-time changes across the entire network.

One thing that has been missing is the validation of the state of the infrastructure. With newer hardware that can stream telemetry and other data back to the controllers, we now can look at the network as a single infrastructure and determine its state in real-time.

The last piece that was missing for IBN to be a reality is the assurance of the infrastructure. We now have hardware that can report the state of the infrastructure, and advanced machine learning to compare this state with what was programmed via the translation of business and IT intent. These assurance systems will be able to provide dynamic feedback so that eventually we will have self-healing networks that will constantly monitor and change the network based on the business and IT intent policies applied.

One bonus that comes from the ability to look at state and assurance is that we can now have a single pane of glass insight into the state of the network and how it is performing. We can see flow monitoring as well as the health of the devices (link down, power supplies down, flapping links, etc.) that we never would be able to see from a single view.

Impact for the future

WWT is truly excited about this next step in networking. The reality of linking multiple networking domains together is coming close to fruition. Some OEMs can do IBN with SD-WAN, SD-Campus/Branch, cloud edge solutions in carrier neutral facilities (CNF) such as Equinix, SDN-Data Center and container platforms and public cloud.

However, each of these domain solutions currently is stand-alone, and we see the OEMs integrating these domains. It is only a matter of time before we can integrate all these domains into a holistic end-to-end solution. 

We'll touch on this strategy in our third article, where we'll see how we can link IBN domains together and what the business and IT impacts are from this new way of networking.