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

Previously in this series, we've learned that there are many players in the market offering intent-based WAN, intent-based data center and a few doing intent-based campus/branch/wireless.

And while we've discussed how we are still a while away before we can connect all these domains, an organization looking into adopting SDN in a domain needs to be aware of this subset of networking now. Even organizations undergoing minor refreshes of hardware and possibly adopting SDN in the future should consider the ability to connect all of these domains end-to-end.

A main hurdle before achieving the IBN future

The challenge we've observed is that, by definition, intent-based networking (IBN) is supposed to be hardware agnostic. However, upon examining what the OEMs are producing, that is certainly not the case. 

The first iterations will be OEM-specific, however, manufacturers are saying that they want IBN to be open to all hardware. The challenge for the OEMs will be normalizing the policy, telemetry and assurance from vendor A and vendor B so they can communicate. 

Currently, there are no standards for the implementation of policy, telemetry and assurance. SD-WAN vendors primarily utilize IPSEC or GRE for the data plane encapsulation. Campus/wireless and data center vendors appear to have settled on VXLAN encapsulation. However, the various vendors are not using the same VXLAN headers and this could lead to data-plane normalization problems. 

Some vendors, such as VMware, have co-developed new data-plane protocols such as GENEVE. Integrating between these new protocols and a VXLAN-based campus will pose challenges. As OEMs create the integrations between the five major technology domains of intent-based networking, customers planning to deploy one or more of these domains need to be aware of future integrations.

As organizations explore and convert each of their networking domains to SDN, they need to consider the reality of observing and operating the network as a single end-to-end management domain. WWT is intimately involved with all the major SDN domain manufacturers, and what we are seeing is that very few have a cohesive vision of end-to-end policy, assurance and telemetry. As organizations are exploring and starting to deploy SDN solutions, WWT is helping guide them in viewing their network as a single end-to-end infrastructure that will be SDN controlled. 

Connecting the dots (or domains)

As organizations begin their journey into the world of software-defined networking, they must ask the various OEMs what their plans are as it relates to joining the various technology domains together. Most of the leading manufacturers use a policy-based approach and APIs to make changes in how the network behaves. Most also have a form of assurance engine and the ability to gather telemetry data. 

However, these capabilities only apply to that domain, not across domains. What we envision happening shortly is the OEMs will create a type of multi-domain orchestration platform. This new platform will be able to apply a unified policy, pull data from assurance engines and view individual flow data from the telemetry feedback from each domain. 

The vision of IBN is for a business owner to ask IT to allow access to applications, no matter where the consumer of the application is or where the provider of that application resides. The second part of the IBN vision is for IT to then create policies that specify the connectivity, SLA and security of that consumer/provider relationship. These multi-domain policies can be monitored using assurance engines and telemetry data. 

Service-level agreements (SLAs) can then applied for proactive monitoring of consumer-provider connectivity. Troubleshooting will be simplified as all the assurance and telemetry data is in one place. 

Many roads to a solution

As AI platforms become more powerful and integrated into these solutions, the idea of "self-healing" networks becomes a reality. This is possible because the multi-domain orchestration engines can analyze the state of the network while monitoring programmed SLAs and apply changes when required. The vision of self-healing networks is likely years away from being fully realized, though some OEMs are developing the first integrations. 

The challenge for customers is that the first iterations will be specific to the platforms, so if another vendor's "domain" is in place, it will break this end-to-end potential. The true goal for intent-based networking is to not only offer policy, visibility and assurance in and across domains but to also be vendor agnostic.

Customers should be aware of what is possible and where the manufacturers are going, especially if they are making design decisions and implementing a single SDN domain. In the future, all networking will be configured via some type of controller. The advances in automation, machine learning and complexity of the network dictate it. 

What are the business benefits of a multi-domain intent-based network?

• A single end-to-end policy linking consumers of applications to their provided apps no matter where the consumer or provider resides: This policy would include security and SLAs via assurance engines to constantly monitor the entire path from consumer to provider.
• A single policy that allows for increased compliance for standards such as HIPAA and PCI: Audits will be simplified as the policy can be examined and verified from a single interface.
• The network functioning at optimum levels as the SDN controllers will apply configurations that maximize the performance of the infrastructure: Outages caused by configuration mistakes or bad design will be reduced significantly as there will be less manual human intervention.
• Telemetry information that shows end-to-end traffic flows across all the managed domains from a single pane of glass: This allows our network operators to be proactive when they see an SLA not being met before they get a phone call that the network is slow.
• Troubleshooting made much easier by inputting the individual consumer or group of consumers and the provided application into a natural language search: The aggregated assurance engine and flow data would show the path and how long it took for flows to reach their destinations and if there are any issues. Additionally, this data could be queried if the issue happened the night before or even weeks before. The possibilities for enhancing network performance and ease of troubleshooting are endless since all the data will be in one place.

WWT will be building these new architectures as manufacturers start offering them; we are currently working on integrating domains as feature integration becomes available today. We see Cisco as a leader in multi-domain architectures, as they have mature SDN models that offer single policy, assurance engines and telemetry for each of the domains discussed. 

VMware is a close second, as they have a good SD-WAN offering and NSX-T in the data center and cloud. However, VMware currently lacks a campus solution. WWT continuously monitors the market for other SDN manufacturers offering more than just a single domain of control as well as vendors that can link disparate OEM domains together.

We are building out the above architecture and already have some multi-domain integrations in place. The individual domains are connected and are awaiting the ability to create a holistic policy.

Make sure to stay tuned for future updates as we make this future of networking a reality for our enterprise customers.