Taking advantage of intent-based networking automation

Telecoms.com periodically invites third parties to share their views on the industry’s most pressing issues. In this piece David Erickson, co-founder and CEO of Forward Networks, makes the case for intent-based networking and its use in existing networks.

Perhaps the most exciting network evolution in recent years is intent-based networking (IBN). IBN is a visionary approach to network automation and management that aligns the intended high-level behavior and policies of the network with the actual network design and configurations.

Implicit in this definition is that there is a great deal of automated intelligence that understands how to design efficient, error-free networks, as well as how to reason about the resulting behavior from an extremely large number of various design and configuration details. Although still in its infancy, IBN systems have started to automate error detection and analysis, change window verification and network upgrades and roll-outs.

Looking to take advantage of this kind of automated intelligence, carrier-grade providers frequently ask if IBN technology can be deployed on existing networks, or if the integration issues and technology upgrades lend themselves only to greenfield deployments? To answer that question, let’s break down IBN into two functional areas: design and verification.

If you start with your network policy objectives and want to drive the configurations and management of network devices, that is design-oriented IBN. Going the other way, if you want to analyze your current network design and verify that it conforms to your stated objectives, that is intent-based verification. The good news is that verification of existing network designs is a much more thoroughly solved problem and completely lends itself to any existing network today (assuming the IBN system has the capability to model and analyze the various vendors, devices and protocols in the underlying network).

Verifying network behavior requires reasoning and intelligence

IBN verification allows service providers to automate the analysis of existing network paths end-to-end, based on the collected information from every network device and modeling the behavior for all possible traffic at each hop. The end-to-end path behavior can then be verified against similar end-to-end network requirements and policy statements. Some examples of end-to-end behavior that IBN can verify easily:

IBN systems have the capability of understanding such high-level, generalized requirements and verifying them in the context of the current network design. IBN effectively bridges the intent and the individual device configurations to reason through and automate the verification process. From an IT perspective, this can proactively identify any latent errors in the network which could eventually lead to outages, while avoiding tedious manual searches to isolate issues or perform root-cause analysis. For example, if a set of configuration changes are proposed or a new service is deployed, IBN can help verify the impact to existing policies in the software model before deploying to the live network, averting possible roll-backs and helping to accelerate change windows.

Verification is a distinctly different methodology than traditional testing environments, because verification is reasoning based on an analysis of the network design, configurations and current network state. It does not look at live traffic flows to determine network activity. Verification can thus do something traditional testing can rarely do: “prove a negative”, by confirming that something can’t happen, such as two networks being unreachable through any path. IBN verification can also identify configuration errors like MTU mismatches, forwarding loops, or IP address duplication anywhere in the network without reviewing devices one by one.

Requirements that allow IBN to be applied to existing networks

IBN systems create a software model of the provider network and can model all possible behaviors the design allows to verify compliance with the intended policies and service descriptions. For an IBN system to work on an existing network, the only conditions that need to be met are: 1) Read-only access must be available to each device to pull configuration files and state information, 2) the IBN software model must accurately model the behavior of each network device (switch, router, firewall and load balancer) for all possible packet flows, and 3) the IBN model must accommodate all carrier class protocols such as EVPN, BGP, MPLS, virtual networking, etc.

Like a secure sandbox or test environment, IBN systems are a separate software model that is non-intrusive to the network, requires no points of integration besides read-only access, and requires no software agents or packet sniffers. For that reason, service providers are finding that they can generally be up and running on existing networks in only a few hours without risk or impact to existing services. Even for legacy architectures and extremely large carrier-grade networks, IBN verification technology can quickly deliver tangible results.

David Erickson is the co-founder and CEO at Forward Networks. David holds a PhD in Computer Science from Stanford. He is a contributor to the OpenFlow spec and the author of Beacon, the OpenFlow controller at the core of commercial products from Big Switch Networks, Cisco, and others, and open source controllers such as Floodlight and OpenDaylight. His thesis used SDN to improve virtualized data center performance.