Industry buzz is growing around intent-based networking (IBN), but there's also a debate emerging both on the definition of IBN and whether it's truly beneficially for driving network automation.

A synonym of intent is "determined, resolute." Do we really want our networks to be intent based? Determined? Resolute? Antonyms of intent are "flexible, unfixed." I think most of us would want our networks to be flexible, unfixed and responsive to current conditions.

IBN or outcome-driven networking attempts to automatically provision networks based on our ability to define our intent or outcome, in an effort to eliminate common mistakes and speed implementation.

With IBN, the underlying network capabilities -- wires, routes, VLANS, MPLS, IPSEC, virtual routing and forwarding (VRF), Network Address Translation IPv6 to IPv4 (NAT64), Border Gateway Protocol (BGP), firewalls, etc. remain unchanged. If we can simply define our intended outcomes, the difficulty in orchestrating all of these technologies and layers will now magically just happen.

But is setting intent enough and will it be effective in increasing network automation? Take the example of the morning commute -- each morning I get in my car with the intention of driving to work. Sadly, each day my commute has a very different real outcome. Some days, it goes well. Other days, traffic is terrible and I take alternative roads. My commute interacts with a large number of other users of the highway. Since all of us have clear intentions, why are our commutes so different day to day?

Enabling applications
To accurately define network requirements for a single instance of an application is hard -- applications require different network resources that vary over time, and have highly variable usage rates. This process is even harder for aggregates of multiple applications, and it is impossible to define the required network intent for a single application without massive over estimation. For historical traffic patterns of aggregates of applications, intent may be much easier to define, and may be more accurate. But when defining intent for historical aggregates, one must agree this is how we have always run our networks.

To compete with the OTT players, telcos need to be nimbler by accelerating network automation. Join us in Austin, Texas from May 14-16 for our fifth annual Big Communications Event as we tackle challenges like automation. The event is free for communications service providers – secure your seat today!

Adding flexibility to the equation
What about network flexibility? What if IP networks could route on alternative pathways when primary pathways are busy? Wouldn't that maintain networking intent without re-provisioning? Imagine driving to work, and the only way you could take an alternative route was when your primary route was declared down. Flexibility is what is missing from our current networks. We can't use secondary pathways easily. Even using multiple parallel pathways is complex, as they have to be declared exactly equal.

For the first time in history, software-based networking products are actually performing true multi-path routing and application recognition as inputs to policy. This is the beginning of a new wave of artificially intelligent, flexible networking based on intelligence and feedback loops. When the routing layer becomes session stateful, routing can be optimized on a session-by-session, service-by-service basis. This flexibility will be preferred by most over defining intents for aggregates of services, and ultimately will manage the intent of the aggregates by default.

Provisioning elements is not enough
Any outcome-driven network or intent-based network should do more than automatically provision elements. It needs to understand the application view. The network needs to be able to measure the key application performance metrics that matter. Latency, packet loss, jitter, retransmissions, time to first byte, maximum bandwidth, window size, session length, common name (from cert), and entropy are all metrics that are based on the session layer (TCP/QUIC).

Sessions are the language of applications. Every application is constructed by using one or more sessions in combination -- and understanding them as a group is important. For example, a web front-end server may appear sluggish when a back-end database is overloaded. The networks are "perfect," but to the end customer, the website is slow. Understanding that a collection of related sessions is the language of defining intent is important.

Outcomes and intents do not start and end at ingress or egress; rather intent extends to the entire domain of an application, from the client all the way to the server through multiple networks. Networking needs a session-based architecture to measure application metrics such as time to first packet. Networking also needs metrics like latency of network links and segments, and feedback on how to forward future sessions. IBN will evolve to become application aware only when networking equipment is session based.

Sessions are key to true intent based networking
Orchestrated provisioning of access control lists (ACLs), type of service (ToS) bits, static routes, quality of service (QoS), VRFs, and VLANs solve one piece of the problem -- making provisioning simpler and more error free. But true intent-based networking will require the careful analysis of sessions at each network routing point. Network routers with advanced intentions will know application performance in real time, and route subsequent sessions based on this information.

Software intelligence can turn equal cost multi-path based networks into true multi-path networks. This type of routing can understand intent, and deliver the outcomes without massive overprovisioning.

Understanding service and session requirements is the very first step in efficient networking outcomes. The proper intent is to have a network that is efficient, and enables applications and services. The proper outcome is to use each network link optimally for each application and service instance.

— Patrick MeLampy, Co-founder and chief operating officer, 128 Technology