In my view, Intent Based Networking (IBN) is going to be journey. It’s not a specific thing like ‘routing’ or ‘traffic shaping’. It’s not a product or a feature.
IBN is a general category that includes a group of technologies. It’s a broad definition, just like Software Defined Networking.
I think I can see a way to classify how IBN is going to evolve. And defining an evolution means you need a taxonomy to judge how you are progressing along the path.
Forthwith here is my taxonomy for six levels of Intent Based Networking (loosely on the five levels of driving automation):
- Manual Operations
- Data Analysis and Awareness
- Reactive, Predictive Self Operation
Let’s go through them.
I’m hoping for feedback on the on these ideas – please leave comments, or email me [email protected] if you can’t speak publicly.
1. Manual Operations
Summary: Skilled Operators are responsible for all activities.
Network engineers translate business intent into network operation through configuration changes, network knowledge, and simple monitoring over legacy APIs. Not really a level but this is where most people are today.
Summary: Replace manual tasks with robots (scripts) and improve the quality of manual operations.
Organizations derive short term value from accuracy, repeatability, and speed of operation. Automation creates a new problem to solve – visibility. You cannot scale automation without visibility to measure, validate and inspect the result of those changes. This drives the next level.
Common Mistake: Intent is translated into action via the programmed tasks. This programming is faster and more accurate, which creates a sense of dynamism and purpose but fundamentally you haven’t changed the nature of ownership or change. Automation will improve existing process/work but it won’t transform or re-engineer it.
3. Visibility and Visualisation
Summary: Tools and applications provide deep visibility into the running status of the network including the changing, variable, temporal state plus the static, operational state.
Core Technologies: Sub-second accuracy of transient states of hardware and software are key elements. Constant streaming of the data from all network devices to a central software application for collection. Management and sustenance of data lakes is key in visibility . Important elements are the data repository, the learning engine, and the graphical interface that presents the data to the engineer.
Technologies like formal verification, streaming telemetry, data models, APIs, protocols such as gRPC are creating data lakes of information about the fixed and temporal state of the entire network. Risk of this level of visibility is information overload where a human operator will be paralyzed by data and unable to correctly.
Modern web interfaces are using visualisation tools that can present data in a useful, meaningful ways. Tool makers are increasingly focused on UI/UX to improve the value to the customer.
Common Mistake: Having network visibility can create a false of sense of control or awareness. A network changes over short and long intervals. It also requires substantial effort to sustain a monitoring system although automation can assist. A monitoring system should not be an ‘add-on’ to the network but a critical element.
Common Mistake: This is not the monitoring tools available today that are based on poor quality data from SNMP, syslog and CLI scraping. It not possible to realise the true state of the network with legacy approached based on low speed polling and incoherent data sources like syslog.
4. Data Analysis and Realization
Summary: Extract meaning from the available information.
Configuration, architecture, flow levels, path changes, and device issues are just of the some of analysis that needs to occur. This analysis must then be “realized” into something that’s meaningful to humans. Existing technologies will be adapted into networking use cases, modelled into standard modes by large-scale cloud Machine Learning operations and then delivered to a local network controller. The local network controller will attempt to map the network datum stream onto the use cases to provide ‘intelligent’ assessment.
The models, likely provided by vendors, are key to success of this analysis. The business model here is attractive to the people who make key decisions. Today, the network owner/architect/designer lacks for predictive analysis tools and data analysis about outages, failures and issues. By analysing the data, the customer will be informed about device reliability and performance. Automated metrics surrounding MTTR, MTTF and operational defects will be dynamically created and updated so that buying decisions are based on hard data instead of ‘gut feel’ and personal preference.
5. Reactive, Predictive Self Operation
Summary : Network operations become a closed loop that executes configuration within defined parameters and monitors device, path, and performance to make reactive changes and adapts the network within defined boundaries.
All functions are defined by a software platform that can modify the network services offered. This includes operation of NFV instances for security, DOS, path selection, identity, and so forth. The predictive nature is such that known or well understood activities or tasks are handled entirely by software.
This combines the previous two stages of visibility and realization to modify the network configuration. Recognition of repeated patterns, outages, known failure conditions, trends and events are beyond what a human can achieve (thus super human). The IBN platform has the ability to react and adapt through change by executing tasks such as device configuration, path management and service chaining.
For example, this will result in self-operated load shifting, path activation and removal, multi-party traffic shifting. The restrictions is that tasks will be patterned from learned data models and only activate inside defined success criteria and learned parameters.
Common Mistake: This is coherent with dynamic orchestration but exceeds this concept. The IBN system is has a series of actions that it can learn, test and implement as needed without human intervention. The constraints of the models will assure the human owners that tasks are reliable and precede Level 6 Full Autonomy.
Summary: The network becomes self-training and self-operating.
The logic engines behind the modelling have the expertise to become self-operating networks. Day-to-day operations are performed by the Intent Systems while Network Engineers spend time reviewing the process, deployment and design of the network. The day is consumed in research and design activities that directly add value to the business.
The EtherealMind View
Networking changes slowly. As a federated system, that is the nature of a networked system. I think that we can predict the paths of change from the position that we are in today.
What do you think ?