Skip to content 
Intent-Based Networking is a paradigm shift in the way we think of and execute networking. But the distance between Intent and Networking is as easy and, yet, as slippery as the one between the cup and the lip. Let’s see why.
It is hard to miss. Lately, there is a lot of talk about Intent-based networking or IBN. Vendors of all stripes and domains are coming out with their opinions and their viewpoints on how they perceive Intent-based Networking will pan out.
IBN is expected to provide a “Siri” or “Alexa” like experience for networks. A virtual genie of sorts that can magically fulfill all your networking wishes. You could place a request such as “I need my video conferencing app to be available all the time, and at high quality” and IBN will take over from there. It will, magically and intuitively, understand and configure all the underlying network resources as per your wish and whim.
While this looks to be an exciting and new way of communicating with our networks, it’s still a tad futuristic. We still have many more steps and turns to traverse before we can achieve actual and limitless IBN. The Tomorrowland is in view, but we still need to unbolt the gates and cross some valleys.
That means accomplishing both the parts well – I and N. Intent and Networking.
What is Intent ?
Intent-based Networking starts with an ‘Intent’. So what is an ‘Intent’? Put simply, it is a method to declare or define policies and outcomes at a high level. Something like “I need my zoom and Webex to work at HD Quality from 8 AM to 8 PM on weekdays”. This intent needs to be parsed and translated to network commands. Parsing of intent definition happens through model-to-model conversion across the many layers that envelope this aspect.
In the beginning, most vendors will have a proprietary user-interface, but eventually, a standard for an intent-declaration will have to be developed for faster and smoother communication between various vendor devices.
How does IBN work?
Realizing even a simple intent will require multiple levels of translations. The figure below provides a glimpse of possible levels of translations.
Business ‘Intent’ has to be translated over multiple layers to device CLIs and APIs. Constant monitoring and rapid feedback are imperatives of IBNS to uphold the ‘Intent’ at all times. Alerts and thresholds help IBNS to validate existing network behavior and automatically take appropriate remediation actions on any violations. This is not as easy as ‘a rabbit out of a hat’. It is also not as elusive as a hard-to-pronounce magic spell. All it needs is a well-mapped process and approach.
Step 1: Business intent-to-network ‘Intent’ translation
The business ‘Intent’ that we defined before has to be converted to one or more networking ‘Intents’. Relevant network ‘Intents’ for a video conferencing business ‘Intent’ could be something like this:
- Check device availability of 99.999% (device failure will lead to lower quality)
- Check Network interface’s utilization < 80% (High interface utilization will lead to more drops)
- Ensure QoS for voice, video, multimedia conferencing
- Ensure High-availability
Deriving network ‘Intents’ from business ‘Intents’ will not be an easy process. It will involve incorporation of the latest scripting and modeling technologies. Artificial Intelligence and Machine learning will play a crucial role in discovering relevant networking ‘Intents’ by evaluating historical patterns, predicting future consumption of resources and, possibly, even learning from other similar networks.
The initial IBN deployments may not accommodate this level of complexity. The network administrators and architects, who will come into play here, will start the process by directly defining network ‘Intent’.
Step 2: Intent Realization
Based on the ‘Intent’ definition, the software now has to figure out what tasks to run. It has to answer the following key questions:
- Which devices constitute the intent?
- What services have to be modified?
- How are the approval processes structured?
- Which services are stateful and atomic?
- What metrics need to be monitored?
- How can one enforce auto-remediation?
- How can QoS be enforced?
All of this has to be covered, keeping in view the existing company policies like HIPAA, PCI, SOX, and others.
AI and ML maybe, eventually, used to carry out these activities; but at the nascent stages, the vendors will look to compile a big list of service models and workflows. The ‘Intent’ engine will analyze the requirements and select all applicable entities.
Step 3: Monitoring, Provisioning, and feedback
Till step 2, we have drilled down ‘What to do’ from a high-level user construct to a much more detailed device-construct. Now our focus is on ‘How’ to uphold the ‘Intent’. IBN has to monitor and check the device-state constantly. It has to provision and configure the devices accordingly.
Monitoring through streaming telemetry will be ideal for IBN. Streaming telemetry allows IBN to subscribe only to the metrics required for this ‘Intent’. Traditional monitoring methods of SNMP, SNMP Traps, and Syslogs can provide additional context. The metrics pushed by the device are checked and validated against the ‘Intent’ requirements.
The feedback that is received from the devices has to be closely monitored and leveraged well to provision and maintain services in a better way.
Step 4: Low-level CLIs
Finally, we need to generate and configure the devices using the language they understand. For the IBN solution, the key here is to understand multi-vendor CLIs and APIs. A big collection of MIBs and telemetry sensors will help scale IBN to a bigger network.
So! What do you need for a good IBN solution?
- Integration with multiple vendors and many types of entities – Whether it’s ITSM or OSS/BSS or traditional switches, routers, and firewalls; IBN should have open APIs to integrate with all kinds of network elements.
- Diverse data collection capabilities – IBN should be able to ingest voluminous data that’s being stored in microseconds across various sources like SNMP, SNMP Trap, Syslog or telemetry
- Easy Intent development interface – To graphically develop ‘Intent’ customized for business logic.
- Rich support of programming languages – Which enables usage of expressions and conditions to define actions and helps in tying various data and network entities together
- A framework to audit intent – IBN is expected to perform many tasks automatically. Auditing of Intent and reporting of actions enable admins to understand the system and maintenance areas better
- A horizontally-scalable platform – IBN should cover your entire network to allow a single source of truth. Scalability becomes key to achieve this level
In other words, it needs a specific level of rigor, depth, helicopter-view details, and the knack of understanding networks viscerally to make IBN work its real magic.
Only a player with a whole level of expertise and one that is armed with an ability to see how IBN works in totality can really add the I to the N. They don’t need to be glued together. They need to be woven together. Understanding this difference – now that’s the magic of IBN.
