Intent-Based Networking: Beyond the Hype
11/19/2017 Category: Intent-Based Networking
Remember when Software Defined Networking was as much marketing hoopla as it was any kind of tangible product? When it was teetering at the Peak of Inflated Expectations on the Gartner Hype Cycle, practically every vendor on the planet was hitting you with some sort of SDN slideware (and very few were hitting you with anything that actually worked), and “Software Defined” was such a happy crappy buzzword that you were hearing about Software Defined Security / Data Center / Cloud / WAN / Infrastructure / Storage / Compute / Lunch?
Okay, I might have made up the part about Software Defined Lunch.
I spent a number of years back then doing presentations to customers on what SDN actually was and how to separate reality from BS.
You can still find people who say SDN is just hand-waving or that the term has been so diluted we should call it something else. But for the most part, SDN has zoomed along the downhill side of the Peak of Inflated Expectations, lost most of its thick coating of baloney in the Trough of Disillusionment, and is now cruising up the Slope of Enlightenment.
Not to worry, kids, there’s a brand-new buzzword for marketing departments everywhere to abuse: Intent-Based Networking!
Randomly visit a few vendor websites, search for Intent-Based, and you’ll more likely than not find some lovely white papers or web pages extolling IBN and how it’s going to change your life. And just as in the early days of SDN, most vendors are trying to define IBN to comply with their own product lines and roadmaps.
Intent-Based Networking has been around for a few years in academic papers and there’s at least one vendor that’s been selling an IBN product for more than a year now. But the real excitement around IBN came in June of this year when Cisco announced its Digital Network Architecture. They were slow off the mark with SDN, at first denying that it would ever amount to much, then stepping into the SDN waters with their Insieme acquisition, and finally getting firmly into the game with OSC and ACI. They’re certainly not making the same missteps with IBN. They’re pouring serious money into development.
Shoot, they even hired Tyrion Lannister to get us all excited about what they’re calling The Network Intuitive.
But is there anything to IBN beyond marketing fluff? I actually think there is, and I think it’s going to transform the way we operate networks. If you look past the oh-so-serious atmospherics of the Cisco commercial, Tyrion – I mean, Peter Dinklage – does a good job of telling you what Intent-Based Networking is (ahem) intended to do.
What is Intent?
We all know what intent is, of course, but what is it in the context of networking?
When I was doing all that traipsing around trying to give customers a clear definition of SDN, I often ended my presentation with some speculation of where the software-defined / network abstraction / network programmability trend might be taking us. I had never heard of Intent-Based Networking back then, so I came up with my own term: Application-Defined Networks.
My admittedly naïve idea was for an arbitration / orchestration middleware that takes in network intelligence from a controller-maintained model of the physical infrastructure. The intelligence includes not only capabilities and capacities, but also up-to-the-second telemetry on state, load, availability, and other variables. Applications attach through the arbitration middleware and present in real time their requirements. The middleware then pushes the necessary configurations to the network to meet those requirements, or notifies the application and operations when the network can’t comply.
No humans are in the flow reconfiguring the network on the fly as applications are added or changed, and the network is constantly adapting to changing demands.
It turns out that that’s not too far off from what IBN is intended to do. We’re not there yet, but that’s where we’re going. I’m tempted to say that we’re taking baby steps, but actually we’re moving that direction pretty quickly. An illustration from a Gartner report earlier this year shows the high-level building blocks of an intent-Based Networking System.
Automation is an obvious component, as is closed-loop telemetry and orchestration. But the heart of the system is built from machine learning algorithms that interpret expressed business logic and translate it from context (what is the need?) to intent (what do I do about it?) to prescription (how do I do it?). There are loads of examples of the context / intent / prescription relationship out there; here’s mine:- Context: I’m hungry.
- Intent: I want a peanut butter and jelly sandwich.
- Prescription: Collect two pieces of bread, a jar of peanut butter, a jar of strawberry jelly, and a knife. Using the knife, cover one side of piece of bread with 1/8” layer of peanut butter. Again using the knife, cover one side of the other piece of bread with 1/4” jelly. Gently press the covered sides of the two pieces of bread together.
A networking example might be:
- Context: I need VoIP communications between sites A, B, and C.
- Intent: A VoIP VPN is required between these three sites, with the following QoS, security, and availability parameters…
- Prescription: A set of configurations for each node involved in setting up the VoIP service. Or perhaps a generalized set of prescriptions pushed to an SDN controller that then takes care of vendor-specific configurations to each node.
The prescription – the step-by-step instruction set for implementing the intent – is an easily understood end result. Intent itself, on the other hand, is not so clear. This is where vendors can bend definitions to their own purposes, based on what they can actually do.
Business Intent vs Technical Intent
Business intent is much closer to context than technical intent is. It also comes closer to what Cisco is calling an Intuitive Network. A network that knows what it’s business mission is and how to continually adjust itself to that mission. A network that [adopting my best growly Peter Dinklage voice here] “Has insight. Context. Learns. Adapts. Predicts.” Insert your own mood music.
Well sorry Mr. Dinklage, it’s not “Here. Now. Among us.”
What is among us right now is something closer to the prescriptive end: technical intent. Apstra provides an example of intent in one of their white papers:
“Provide connectivity to 1000 servers, using L2 and/or L3 access at the edge, with
oversubscription in the core of 1:1 (no oversubscription), with endpoints such as hosts,
VMs or containers grouped into isolation domains (including both traffic and address
space isolation). Have some endpoints reachable via the rest of the world and some
not, with policies associated with isolation domains governing both security and load
balancing, with connectivity to the rest of the world via at least n links to support the
external traffic and protect from possible failures.”
There are certainly general technical prescriptions in there, but the work of translating that into a repeatable blueprint and then producing and deploying the exact node-by-node configurations is far from a trivial process. This is technical intent, and it’s here and now.
Getting to the point where we can express business intent to the network – an Application-Defined Network where we deploy an app and it tells the network what it needs – is still a ways away. Although maybe not as far away as you might think. There’s already plenty of talk about removing “human middleware.”
Translating Intent
The way networks have always worked is that business intent is expressed to network architects – let’s call them the architect plane – and the architects translate the intent into configurations that are applied to the control plane. There’s a significant time lag during that translation, no guarantee that any two given architects are going to interpret or translate intent in exactly the same way, and no guarantee that the interpretation is going to be accurate.
The Intent Engine in an IBN system replaces the architect plane with declarative algorithms that translate high-level business intent into consistent, validated configurations. Automation then pushes the configurations to the infrastructure.
This doesn’t mean that the architects are out of a job by any means. They are simply no longer a part of the mundane tactical flow from intent to functionality, and can focus on network strategy. Most importantly, their interaction with the process is an interaction with the machine learning
Does it sound like I’m going off the deep end? Isn’t the idea of a robotic system listening to humans expressing what they want and translating it into tangible technical results the realm of science fiction rather than the hard-boiled reality of networking architecture? And even if we come up with such systems, are network operators going to be willing to take their hands off the wheel and let the network run itself?
I think you see where I’m going here.
The Self-Driving Network
When I spoke to a Cisco users group about IBN a couple of weeks ago, someone questioned whether anyone would be willing to allow an IBN system to “learn” on their production network. It’s a good question, and the answer depends on how sophisticated the ML algorithms in the system are, and how much control we allow them to have: How much we trust the system.
Already, we put much more than our networks in the hands of algorithms. Most airline passengers, for example, are unaware of how often the planes they are traveling in are flying and even landing themselves. Pilots of Boeing 777s report that on an average flight they spend just seven minutes manually flying the plane; Airbus pilots spend even less than that. A pilot will be quick to emphasize, however, that while the autopilot is performing all the manual tasks of flying the plane, the pilot is still in control. His or her role, similar to our network architect of the future, is to input instructions and expectations (intent) and then let the computer control the process under the pilot’s supervision.
And then there are autonomous cars.
I remember reading a science fiction story when I was in high school (not long after teachers were invented) in which everyone’s car drove itself, very close together and at very high speeds. When someone took manual control of their car it was usually with the intention of committing suicide and taking many other people with them.
Although the idea of self-driving cars was only in the realm of science fiction for a very long time, recent leaps in AI and machine learning have quickly taken us from the Batmobile to those goofy looking early Google cars to self-driving Teslas. Uber is even experimentally deploying a fleet of autonomous cars.
People react distrustfully to autonomous cars, but even in their infancy they are proving much safer than human-operated cars. (Ever driven in Boston or Dallas?) Insurance rates will start going down for people who can prove that they are letting their car do the driving. Some manufacturers, such as Volvo, are even talking about assuming full liability for their autonomous cars, which could make personal liability insurance a thing of the past.
Could cars with no manual controls be far in the future? Not very far: Michigan has already approved the testing of cars with no steering wheels on public roads. Human-operated cars, with poorer safety and slower reaction times, could eventually become illegal or at least require specialized operators’ permits.
I’m making such a big deal about autonomous cars because [Tyrion voice on] “They’re here. Now. Among us.” If machine learning algorithms are sophisticated enough to get us safely through traffic, even amidst Boston drivers, they’re sophisticated enough to make network configuration decisions. What we have to learn, in both cases, is to trust them. An Intel study performed a Trust Interaction Study with autonomous vehicle passengers, and identified seven human-to-machine interaction tension points. Most of these points are instructive for gaining trust with IBN systems:
- Human vs machine judgement: On the one hand, people worry about taking human judgement out of the picture. On the other, they recognize the value of eliminating human error and second-guessing. I think anyone in networking recognizes the value of this – in networking as in driving, the majority of undesired outcomes are the result of human error.
- Personalized space vs lack of assistance: People like the idea of their ride time being free for other things besides driving, but worry about the lack of interaction with a human driver and the lack of accountability. This can be extended to the network world in that architects are freed up to do more important jobs, but there could be concern about lack of visibility into what the IBNS is doing.
- Awareness vs too much information: Related to the last point, people felt that once they have confidence in the system, too many alerts and notifications could become distracting and annoying. An IBN system should allow the user to customize the level of feedback to their level of comfort.
- Giving up control vs gaining new control: Participants reported that the sight of vehicular controls such as the steering wheel under autonomous movement is unnerving, especially if the controls are out of reach. They suggested that removing such visual cues completely – such as the aforementioned cars with no steering wheel – might actually help. They also cited the appeal of new kinds of control, such as summoning the car, the disabled and minors being able to use the car unassisted, and reduced stress associated with driving. For IBN systems, the ability to predict problems, document the network, and sometimes autonomously repair the network can be appealing.
- How it works vs proof it works: When people encounter a new technology, they want to understand how it works before being willing to trust it. Once the technology is proven and trusted, understanding the underlying technology becomes less important. This is true of both autonomous vehicles and IBN systems.
- Tell me vs listen to me: While people like systems that use a simulated human voice to convey information – from autonomous cars to autopilots to navigation apps – they also want to be able to speak to the system in the same way they would a human driver. It’s important because people change their minds about where they want to go, want to amend their trip (“Oooh, a taco truck! Pull over!”), or just want conversational feedback (“Why did you take the 105 instead of going up First Street?”). I doubt we’ll ever be giving an IBN system a connection into the boardroom to conversationally discuss business intent, but what about an interpretive capability that takes loosely expressed business intent and interacts with humans to refine that intent before creating technical specifics?
- Rule-following machines vs human interpretation of the rules: Most of us have been guilty of loosely interpreting traffic rules. Estimating how far over the posted speed limit the cops will let us get away with. Fiddling with the radio or talking on the phone instead of paying attention to our driving. A “rolling stop” when no one else is at the intersection. We tend to do the same thing in networking, taking shortcuts in configurations that we plan to fix later on (and never do), stepping outside our own design principles for the sake of convenience, or sidestepping change control procedures. For an autonomous system, a rule is a rule. 35 MPH means 35 MPH. A stop sign means stop. Designated design and documentation policies are not to be violated.
It’s Everywhere
I think I used the word “intent” about 437 times in this blog alone. You’re going to hear the word more and more over the next couple of years. Some of it will be realistic, and a great deal of it will be hype. Count on the term getting as abused and washed out as “cloud” and “software-defined.”
But if you can wave away the fog, you’ll find that there is plenty of legitimate development behind Intent-Based Networking, and some solid produts being incrementally deployed. Keep an eye on companies like Apstra, Forward Networks, Veriflow, and Cisco. Keep your other eye on open initiatives from Open Daylight, OpenSourceSDN.org, ONOS, Metro Ethernet Forum, and OpenStack. The innovation happening there is going to change the way you operate your network, probably much sooner than you think.