Verification and Intent-Based Networking: Closing the Control Loop

Intent-based networking (IBN) is an approach to architecting and operating networks that lets engineers focus on intent – that is, the end-to-end business objective – rather than spelling out each detail of the configuration that implements that objective.

The idea of intent has been simmering in the research and open-source SDN communities for several years but has recently gathered steam. In November 2016, Google described how post-mortem incident reports showed that 70% of failures occurred during changes to the network, motivating their intent-based Zero Touch Network infrastructure. In February 2017, Gartner identified four startups, including Veriflow, as innovating in intent-based networking. And at Cisco Live last month, Cisco threw their hat into the ring with the DNA controller.

Amid all this action, the space is beginning to take form with a set of key attributes. One of the keys is network verification: a new technology that assures, in a mathematically rigorous way, that the reality of network state matches the intent, or pinpoints any vulnerabilities. (You can read more about the basics of verification technology in our whitepaper or our introductory blog post.)

Of course, verification is near to our hearts here at Veriflow. In this post, I’ll tackle the question: Where does network verification fit in the IBN world, and why is it so essential?

Here are three key points.

(1) Verification closes the control loop.

Fundamentally, IBN is about automation: connecting a high-level intent with the low-level implementation. That of course includes automating the “translation” or control of the network that maps intent (“I want my network to be resilient”) to implementation (thousands of configuration files).

But what would happen if you stopped there, having automated control without automating understanding? The most obvious risk is that without a verification step, any mistake or bug that does arise can be amplified in scope by network automation – which happened in Amazon’s February outage where a typo impacted many web sites. Another risk is that in many ways, automated control actually makes the network more complex, since multiple control infrastructures have to work together. Networks now include new components like hybrid cloud, virtual overlays and physical underlays (that may be hard to correlate with each other), in addition to traditional infrastructure. With traditional tools, then, it could be even harder than usual to figure out the root cause of an incident.

This suggests a basic principle that our understanding of the network needs to keep pace with control of the network. As control becomes more automated, so must our understanding. One could call that closed-loop control for the network.

Intent-based Networking loop

As an example, Google’s aforementioned Zero Touch Network can observe the progress of an update to the network and automatically roll back changes which violate intent.

Gartner also describes verification or assurance of intent as a key component of IBN in a framework set out by Andrew Lerner. One could summarize that framework for IBN architecture as including:

  • Translation of high-level business intent into low-level configurations that realize it network-wide, and automated implementation or deployment of these configurations.
  • Awareness of the state of multi-vendor devices network wide, and assurance or verification that this state matches the original intent, potentially with automated remediation.

A distilled version of that framework is illustrated above. This is a simplification, of course – for example, an IBN system may additionally perform verification of the translated configurations before deployment.

(2) Verification is more than just monitoring.

What exactly does it mean for understanding to “keep pace with control” in an intent-based network? Don’t we already have plenty of monitoring tools?

Traditionally, enterprises monitor packets flowing through the network and events on network devices. One problem is that this is too low level: individual packets and flows sampled at certain locations are far removed from an intent like “all critical flows are resilient to a single device failure”. In order for our understanding to keep up with automated control in a large network, we need to understand automatically how low-level events relate to high-level intent.

But there’s another limitation of monitoring: it’s fundamentally reactive, only seeing problems after user traffic is experiencing them (or after attackers are exploiting vulnerabilities!). This means that for most intent goals, monitoring can never give a positive assurance that intent is met; it can only say, “I’m not seeing a problem right now, but who knows what’ll happen when the next packet arrives.” Taking a quote that has been attributed to Enrico Fermi:

Enrico FermiThere are two possible outcomes: if the result confirms the hypothesis, then you’ve made a measurement. If the result is contrary to the hypothesis, then you’ve made a discovery.

Rather than adversaries and users making these unwanted “discoveries”, we’d like the IBN system and engineers to be empowered with the information proactively.

So, verification should be able to understand intent and give an assurance of whether or not the intent is met by the network’s implementation.

That’s the idea behind continuous network verification, which applies techniques from the field of formal verification to mathematically verify network infrastructure. After arising in the academic research community within the last 5-7 years or so – including early work by Veriflow’s founders – network verification has matured, with Microsoft and Google deploying purpose-built technology for internal use and companies like Veriflow providing more general verification technology suitable for enterprises.

(3) Verification is a stand-alone entry point into IBN.

Beginning with a network where that intent is manually baked into the network and maintained manually during change, how can we move to a design that’s more automated?

One option is to begin with a small part of the network or a greenfield cluster and deploy an IBN system in it. This has the advantage of achieving the full automated control loop, but the disadvantages are that it requires the IBN system to support the complete necessary architecture and requires a change to the network’s operational procedures (and possibly a hardware refresh, for at least one IBN vendor!).

A second option is to begin with verification, in an otherwise traditionally-managed network. Taking a step back, intent itself isn’t new. Every network was built with some intent in mind even if it wasn’t built as an IBN. The network architect designed it knowing that “the PCI-compliant zone should be segmented from the rest of the data center”, or that “critical traffic should achieve low latency”, and so on. Even in a legacy network, that intent can be verified, providing assurance about the state of the network that’s proactive and valuable because it’s connected directly to the end-to-end business goal (i.e., the intent).

Ultimately, I expect IBN deployments will proceed along both avenues independently depending on the enterprise’s needs. With technology in this space advancing quickly but with enterprises needing to focus on their existing infrastructure, deployability will have to be a key goal for all IBN products.

In summary, in intent-based networks, it’s more important than ever to automate understanding of the network, so that our speed of understanding matches the speed and complexity of network control. The emerging field of network verification provides a way to do that, rigorously validating whether intent matches operational reality. In fact, since verification can be deployed in a passive manner network-wide across existing multi-vendor infrastructure, without affecting hardware or operational procedures, it’s a practical and low-risk way to get started in intent-based networking.