Traditional IT systems have been created by smart individuals (or teams) who understand what's needed and translate that intent into an implementation optimized for its performance. The result are specific configurations for network equipment, servers, storage, and security. The definition of what is often lost in the details of how it's implemented.
Take a QoS definition for example. I might see a definition for a real-time express forwarding (EF) traffic queue with an allocation of 1 Mbps applied to a Gigabit Ethernet interface. The intent could have been to allocate 1% of the link to the EF queue. Or the intent could have been to support 10 G.711 voice calls over an MPLS circuit with VLAN tagging, where each call consumes about 100 Kbps (it's actually a bit less than 100 Kbps per call, but allowing for some additional bandwidth is good practice). Without knowing the intent, determining the correctness of the how configuration is difficult.
Intent-based systems avoid this confusion by directly expressing the desired intent (what) and turning that into the necessary configuration that becomes the how. The intent policy that allocates 1% of each link's bandwidth to the EF queue might be a policy that's implemented across an entire network. The call volume policy requires knowing the anticipated number of calls transiting a link.
Defining Intent Policy
Getting the definition of intent right will be a learned skill. It may also depend on the source of data upon which the intent is based. Looking closer at our QoS example above, we can create a third definition, based on actual call volume instead of static values. This definition might be something like the following:
The intent policy may also create an alert if the policy result exceeds some other threshold, such as an allocation that's more than 50% of the link bandwidth. A definition that's driven from other dynamic parameters is self-maintaining. The alert threshold is a way to allow the intent policy to request help when the policy's results exceed expected values.
Another definition might be a soft QoS allocation in which the EF queue is allowed to exceed its allocation if enough bandwidth is available to support the excess bandwidth. Generating an alert when this happens would be valuable, so that an adjustment to the allocation could be considered. Even better would be to have the alert triggered only after some number of occurrences in a period of time (e.g., 10 per month). Can you see that intent policies could get pretty complex? We'll need to learn what kind of intent definitions make sense and which ones are needlessly adding complexity.
Policy Conflicts
What happens in the case of policy conflicts? In our QoS example, let's say bandwidth requirements for other queues grew concurrently with the EF traffic requirements. This might happen when the number of employees at a particular location grows, resulting in traffic increases across all QoS queues. The right answer to this situation might be to add more bandwidth, but until that happens, the intent-based system must determine the right allocation of the existing bandwidth to all queues.
More importantly, transient conflicts require automatic handling. For more discussion of the challenges associated with conflicting policies, see the IETF Autonomic Networking Integrated Model and Approach working group presentation, Intent-based Policy Management (starting at slide 8).
Another example is in network security. We may have one policy that provides access to an application and another policy that restricts access due to a vulnerability. The two policies may result in a configuration in which the two sets of security rules conflict with one another. The conflict may also depend on where the rules are applied. Merging policies is a tricky process to get right. Perhaps some really sharp people can determine how to resolve such conflicts while keeping the policy definitions simple.
New Abstractions
The greatest benefit of intent-based systems will be the ability to create one policy for use across large portions of the network, which will lead to simplified configurations. Consider applying one QoS policy across an entire enterprise network, incorporating differences for WAN vs. LAN. The system should create alerts where it is having problems meeting the policy, perhaps on low-bandwidth links. Hiding the details of QoS policy configuration for devices with different configuration syntax will be nice.
We can also have abstract versions of white-list connectivity rules, applied to endpoint groups. Instead of defining individual firewall rules, I'd like to build an intent policy that creates an application access profile, based on a database of connectivity requirements needed for that application. The protocols, port numbers, and packet sizes should be looked up in an application connectivity database. I shouldn't have to work directly with those details. A natural outcome of this abstraction is that when a part of the network no longer needs access to this application, the system knows which firewall rules to modify or delete.
Converting Intent into Configuration
One of the major hurdles engineers must solve is converting intent into network device configuration. The translation of intent into configuration is currently done manually by smart network engineers. It is a fairly mundane and error-prone task, but one that must be done every time a device configuration changes. This interpretation and configuration change is the source of many network outages.
Summary
I'm very excited about intent-based networking. This technology is going to revolutionize the networking industry. Ultimately, networking should be able to function at the same timescales as compute and storage configuration (i.e., seconds or minutes, not days or weeks). More importantly, we will begin to work with the network on a higher level of abstraction than we've been able to do since the 1980s.
