Intent-Based Networking Perspective
IBN can be seen as a perspective on a Cisco DNA-based network infrastructure that describes how the network can be managed, operated, and enable a digital business. It translates an intent within the business into the configuration of the network required for that specific intent. This is achieved by defining the intent as a number of (repetitive) steps that can be deployed. The IBN perspective uses all aspects of Cisco DNA (design principles, concepts, and so on) to accomplish this method of approaching the network.
The IBN perspective is based on a systematic approach where the network infrastructure is seen as a holistic system.
Figure 5-1 shows this systematic approach.
)
FIGURE 5-1 IBN Systematic Approach to the Network
This approach resembles the functional approach of Cisco DNA a lot. It is, of course, a perspective on how a Cisco DNA-based network infrastructure is operated. This approach is based on six steps in a continuous loop.
Request an intent: A part of the business, whether a process, front-end application, or operator, specifies a specific Intent request to the network infrastructure. This is of course based on a number of available intents, where the variety of the Intent also depends on the organization and the level of availability.
The translation process, receiving the request for Intent, translates the specific intent into a number of repetitive executable required steps. This is, for deploying a network Intent, perhaps one of the most important aspects of Intent-Based Networking. These steps need to be designed, tested, and defined within the translation process. Depending on the solution, these steps could be predefined templates or specific pieces of network configuration specific to the enterprise. The implementation of these repetitive executable steps needs to be as predictable as possible and is quite often defined by the network designer.
For example, if the intent is a new IoT network, the Intent is translated into steps like create a new network, assign an IP-pool to that network, and place this network into a single logically separated compartment.
Request steps: Once the required steps for the specific intent are defined and created, the requested steps are sent to the Activation process. This process receives the requested steps and translates these steps into device-specific configuration changes that are required on the network infrastructure. The Activation process knows which configuration changes are required on which devices and uses automation to activate the changes on the applicable network devices. In turn the Activation process pushes the required changes to the network infrastructure.
Based on the earlier example of intent, the Activation process translates the new network into a new VRF on a number of core switches in the network and allocates a new VLAN where the IoT devices are placed. The allocated IP pool is translated into a DHCP scope on the device that provides DHCP services to the network. A security policy can automatically be added to detect and authorize the new IoT devices.
Execution of configuration changes: This is the step where the Activation process actually connects to the network devices and deploys the changes to the network infrastructure. At this stage the requested Intent has been translated into a specific configuration on the network infrastructure. The requested intent is implemented. Although the Activation process performs pre- and postchecks to validate if the configuration of the network infrastructure devices was successful, the Activation process cannot determine whether the deployed configuration has the desired outcome.
Network-driven feedback: In this step, the network infrastructure devices provide feedback to the assurance process. The feedback is based on a number of data flows, including the generated network configuration, telemetry on the network, which client is connected, and how clients behave on the network. The network-driven feedback is used to validate if the executed configuration changes from step 3 have resulted in the desired outcome.
Using the same example, the IoT devices are now connected to the network and assigned to the specific VLAN and VRF. Telemetry data on whether the IoT device gets an IP address and which communication flows are seen by the network are sent to the Assurance process.
Validation & metrics: In this step the Assurance process has analyzed and validated the different data flows received from the network infrastructure devices. The received data is combined and analyzed, and potential issues or correct operation is sent back to the Translation process. This step provides the feedback on whether the requested intent is working as expected, and which IP addresses clients have received, including metrics on the usage, are provided to the Translation process.
Within the same example, the status of the intent, including client-related information is sent to the translation process.
Intent-based feedback: The translation process receives metrics and the validation of the requested intent operation. The Translation process checks the status of the requested intent continuously and determines whether problems exist with the requested intent. In case of a problem, the operations team is informed of the failed state, and the business can request the status of the requested intent as well. Similarly, statistics on the usage of the requested intent are provided to the business layer using application-based metrics such as number of devices, accumulated data usage, and availability statistics, some of the most often used key performance indicators for the business.
Within the same example, this step provides a positive status back to the business that the requested intent is operating as requested and provides an aggregated overview on availability and bandwidth usage to the business. The new IoT application is running successfully on the network.
These individual steps are executed for every requested intent. A large network can quickly have hundreds of requested intents to be added and run on the network. In addition to the requirement that these steps can run in parallel for different intents, the network must also be able to validate whether the requested intents are still working as expected. Therefore these steps, including the validation, are run in a continuous loop (shown by the dotted arrows in Figure 5-1) to validate whether the network is operating and working as designed. This allows the network to provide intelligent support to the operation teams on the performance and operation of the network.
The first three steps of IBN are common in today’s campus networks. They are commonly deployed where automation is gaining momentum using a wide range of automation tools. The key difference between classic networks and an Intent-Based Network is that with IBN there is automated validation of the changes made to the configuration. The testing and validation of a configuration, also in operation, is unique to Intent-Based Networking and raises the quality and capability of the network.
Another key difference is that for IBN all steps and communication are based on APIs and models, conforming to Cisco DNA’s design principles. This provides a new unique approach to the network, where applications can now automatically request intent to the network without the network operations team requiring to perform these changes. The feedback, based on the assurance, is also provided via APIs, so the same applications can validate that the requested intent is working as operated.
These two aspects of IBN—automatically validating changes of the network, as well as providing the network as a platform to software engineers—allow the enterprise to use the network in new, intuitive ways and enable the digital business.