Intent-Based Networking – Concepts and Definitions

The following section provides an overview of the concept of intent and Intent-Based Management. It also provides an overview of the related concepts of service models and policies (and Policy-Based Network Management), and explains how they relate to intent and Intent-Based Management.¶

In this document, intent is defined as a set of operational goals (that a network is supposed to meet) and outcomes (that a network is supposed to deliver), defined in a declarative manner without specifying how to achieve or implement them.¶

The term “intent” was first introduced in the context of Autonomic Networks,
where it is defined as “an abstract, high-level policy used to operate a network”
[RFC7575].
According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the Autonomic Network that would otherwise operate without human intervention.
However, to avoid using intent simply as a synonym for policy, a distinction that differentiates intent clearly from other types of policies needs to be introduced.¶

Intent-Based Management aims to lead towards networks that are fundamentally simpler to manage and operate, requiring only minimal outside intervention.
Networks, even when they are autonomic, are not clairvoyant and have no way of automatically knowing particular operational goals
nor which instances of networking services to support.
In other words, they do not know what the intent of the network provider is that gives the network the purpose of its being. This still needs to be communicated to the network by what informally constitutes intent.
That being said, the concept of intent is not limited just to autonomic networks, such as networks that feature an Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], but applies to any network.¶

More specifically, intent is a declaration of a set of operational goals that a network is supposed to meet and outcomes that the network is supposed to deliver, without specifying how to achieve or how to implement them. Those goals and outcomes are defined in a manner that is purely declarative – they specify what to accomplish, not how to achieve it. Intent thus applies several important concepts simultaneously:¶

• It provides data abstraction: users do not need to be concerned with low-level device configuration and nerd knobs.¶
• It provides functional abstraction from particular management and control logic: users do not need to be concerned even with how to achieve a given intent. What is specified is the desired outcome, with the IBS automatically figuring out a course of action (e.g., using an algorithm or applying a set of rules derived from the intent) for how to achieve the outcome.¶

The following are some examples of intent, expressed in natural language for the sake of clarity (actual interfaces used to convey intent may differ):¶

• “Steer networking traffic originating from endpoints in one geography away from a second geography, unless the destination lies in that second geography.” (States what to achieve, not how.)¶
• “Avoid routing networking traffic originating from a given set of endpoints (or associated with a given customer) through a particular vendor’s equipment, even if this occurs at the expense of reduced service levels.” (States what to achieve, not how, providing additional guidance for how to trade off between different goals when necessary)¶
• “Maximize network utilization even if it means trading off service levels (such as latency, loss) unless service levels have deteriorated 20% or more from their historical mean.” (A desired outcome, with a set of constraints for additional guidance, which does not specify how to achieve this.)¶
• “VPN service must have path protection at all times for all paths.” (A desired outcome of which it may not be clear how it can be precisely accommodated.)¶
• “Generate in-situ OAM data and network telemetry for later offline analysis whenever significant fluctuations in latency across a path are observed.” (Goes beyond traditional event-condition-action by not being specific about what constitutes “significant” and what specific data to collect)¶

In contrast, the following are examples of what would not constitute intent (again, expressed in natural language for the sake of clarity):¶

• “Configure a given interface with an IP address.” This would be considered device configuration and fiddling with configuration knobs, not intent.¶
• “When interface utilization exceeds a specific threshold, emit an alert.” This would be a rule that can help support network automation, but a simple rule is not an intent.¶
• “Configure a VPN with a tunnel from A to B over path P.” This would be considered as a configuration of a service.¶
• “Deny traffic to prefix P1 unless it is traffic from prefix P2.” This would be an example of an access policy or a firewall rule, not intent.¶

In networks, in particular in networks that are deemed autonomic, intent should ideally be rendered by the network itself, i.e., translated into device-specific rules and courses of action. Ideally, intent would not need to be orchestrated or broken down by a higher-level, centralized system but by the network devices themselves using a combination of distributed algorithms and local device abstractions. In this idealized vision, because intent holds for the network as a whole, intent should ideally be automatically disseminated across all devices in the network, which can themselves decide whether they need to act on it.¶

However, such decentralization will not be practical in all cases. Certain functions will need to be at least conceptually centralized. For example, users may require a single conceptual point of interaction with the network. Likewise, the vast majority of network devices may be intent-agnostic and focus only (for example) on the actual forwarding of packets. Many devices may also be constrained in their processing resources and hence their ability to act on intent. Depending on the intent, not every devices needs to be aware of certain intent, for example when it does not affect them and when they play no role in achieving the desired outcome. In addition, certain functions may benefit from global knowledge of a network and its state, which may not be known or too expensive to maintain or access from individual network devices.
This implies that certain intent functionality needs to be provided by functions that are specialized for that purpose (which, depending on the scenario, may be hosted on dedicated systems or co-hosted with other networking functions). For example, the translation of specific types of intent into corresponding courses of action and algorithms to achieve the desired outcomes may need to be provided by such specialized functions. Of course, to avoid single points of failure, the implementation and hosting of those functions may still be distributed, even if conceptually centralized.¶

Accordingly, an IBN is a network that can be managed using intent. This means that it is able to recognize and ingest intent of an operator or user and configure and adapt itself according to the user intent, achieving an intended outcome (i.e., a desired state or behavior) without requiring the user to specify the detailed technical steps for how to achieve the outcome. Instead, the IBN will be able to figure out on its own how to achieve the outcome.
Similarly, an IBS is a system that allows users to manage a network using intent. Such a system will serve as a point of interaction with users and implement the functionality that is necessary to achieve the intended outcomes, interacting for that purpose with the network as required.¶

Other definitions of intent exist, such as [TR523]. Intent there is simply defined as a declarative interface that is typically provided by a controller. It implies the presence of a centralized function that renders the intent into lower-level policies or instructions and orchestrates them across the network. While this is certainly one way of implementation, the definition that is presented here is more encompassing and ambitious, as it emphasizes the importance of managing the network by specifying desired outcomes without the specific steps to be taken in order to achieve the outcome. A controller API that simply provides a network-level of abstraction is more limited and would not necessarily qualify as intent. Likewise, ingestion and recognition of intent may not necessarily occur via a traditional API but may involve other types of human-machine interactions.¶