rfc9315.original   rfc9315.txt 
Network Working Group A. Clemm Internet Research Task Force (IRTF) A. Clemm
Internet-Draft Futurewei Request for Comments: 9315 Futurewei
Intended status: Informational L. Ciavaglia Category: Informational L. Ciavaglia
Expires: 22 September 2022 Rakuten Mobile ISSN: 2070-1721 Nokia
L. Z. Granville L. Z. Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
J. Tantsura J. Tantsura
Microsoft Microsoft
March 2022 October 2022
Intent-Based Networking - Concepts and Definitions Intent-Based Networking - Concepts and Definitions
draft-irtf-nmrg-ibn-concepts-definitions-09
Abstract Abstract
Intent and Intent-Based Networking (IBN) are taking the industry by Intent and Intent-Based Networking are taking the industry by storm.
storm. At the same time, IBN-related terms are often used loosely At the same time, terms related to Intent-Based Networking are often
and inconsistently, in many cases overlapping and confused with other used loosely and inconsistently, in many cases overlapping and
concepts such as "Policy." This document clarifies the concept of confused with other concepts such as "policy." This document
"Intent" and provides an overview of the functionality that is clarifies the concept of "intent" and provides an overview of the
associated with it. The goal is to contribute towards a common and functionality that is associated with it. The goal is to contribute
shared understanding of terms, concepts, and functionality that can towards a common and shared understanding of terms, concepts, and
be used as the foundation to guide further definition of associated functionality that can be used as the foundation to guide further
research and engineering problems and their solutions. definition of associated research and engineering problems and their
solutions.
This document is a product of the IRTF Network Management Research This document is a product of the IRTF Network Management Research
Group (NMRG). It reflects the consensus of the research group, Group (NMRG). It reflects the consensus of the research group,
having received many detailed and positive reviews by RG having received many detailed and positive reviews by research group
participants. It is published for informational purposes. participants. It is published for informational purposes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Network
Management Research Group of the Internet Research Task Force (IRTF).
Documents approved for publication by the IRSG are not candidates for
any level of Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 2 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9315.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 6 2. Definitions and Acronyms
3. Introduction of Concepts . . . . . . . . . . . . . . . . . . 7 3. Introduction of Concepts
3.1. Intent and Intent-Based Management . . . . . . . . . . . 7 3.1. Intent and Intent-Based Management
3.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 11 3.2. Related Concepts
3.2.1. Service Models . . . . . . . . . . . . . . . . . . . 11 3.2.1. Service Models
3.2.2. Policy and Policy-Based Network Management . . . . . 13 3.2.2. Policy and Policy-Based Network Management
3.2.3. Distinguishing between Intent, Policy, and Service 3.2.3. Distinguishing between Intent, Policy, and Service
Models . . . . . . . . . . . . . . . . . . . . . . . 15 Models
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Principles
5. Intent-Based Networking - Functionality . . . . . . . . . . . 19 5. Intent-Based Networking - Functionality
5.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 19 5.1. Intent Fulfillment
5.1.1. Intent Ingestion and Interaction with Users . . . . . 19 5.1.1. Intent Ingestion and Interaction with Users
5.1.2. Intent Translation . . . . . . . . . . . . . . . . . 20 5.1.2. Intent Translation
5.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 20 5.1.3. Intent Orchestration
5.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 21 5.2. Intent Assurance
5.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Monitoring
5.2.2. Intent Compliance Assessment . . . . . . . . . . . . 21 5.2.2. Intent Compliance Assessment
5.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 21 5.2.3. Intent Compliance Actions
5.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 22 5.2.4. Abstraction, Aggregation, Reporting
6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Life Cycle
7. Additional Considerations . . . . . . . . . . . . . . . . . . 24 7. Additional Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 10. Informative References
11. Informative References . . . . . . . . . . . . . . . . . . . 26 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses
1. Introduction 1. Introduction
This document is a product of the IRTF Network Management Research This document is a product of the IRTF Network Management Research
Group (NMRG). It reflects the consensus of the RG, receiving reviews Group (NMRG). It reflects the consensus of the RG, receiving reviews
and explicit support from many participants. It is published for and explicit support from many participants. It is published for
informational purposes. informational purposes.
In the past, interest regarding management and operations in the IETF In the past, interest regarding management and operations in the IETF
has focused on individual network and device features. has focused on individual network and device features.
Standardization emphasis has generally been put on management Standardization emphasis has generally been put on management
instrumentation that needed to be provided to a networking device. A instrumentation that needed to be provided to a networking device. A
prime example of this is SNMP-based management [RFC3411] and the 200+ prime example of this is SNMP-based management [RFC3411] and the 200+
MIBs that have been defined by the IETF over the years. More recent MIBs that have been defined by the IETF over the years. More recent
examples include YANG data model definitions [RFC7950] for aspects examples include YANG data model definitions [RFC7950] for aspects
such as interface configuration, ACL configuration, and Syslog such as interface configuration, Access Control List (ACL)
configuration. configuration, and Syslog configuration.
There is a clear sense and reality that managing networks by There is a clear sense and reality that managing networks by
configuring myriads of "nerd knobs" on a device-by-device basis is no configuring myriads of "nerd knobs" on a device-by-device basis is no
longer an option in modern network environments. Significant longer an option in modern network environments. Significant
challenges arise with keeping device configurations not only challenges arise with keeping device configurations not only
consistent across a network but also consistent with the needs of consistent across a network but also consistent with the needs of
services and service features they are supposed to enable. services and service features they are supposed to enable.
Additional challenges arise with regard to being able to rapidly Additional challenges arise with regard to being able to rapidly
adapt the network as needed and to be able to do so at scale. At the adapt the network as needed and to be able to do so at scale. At the
same time, operations need to be streamlined and automated wherever same time, operations need to be streamlined and automated wherever
skipping to change at page 4, line 11 skipping to change at line 131
data, perform analytics, and dynamically take actions in a way that data, perform analytics, and dynamically take actions in a way that
is aware of context as well as intended outcomes at near real-time is aware of context as well as intended outcomes at near real-time
speeds. speeds.
Accordingly, the IETF has begun to address end-to-end management Accordingly, the IETF has begun to address end-to-end management
aspects that go beyond the realm of individual devices in isolation. aspects that go beyond the realm of individual devices in isolation.
Examples include the definition of YANG models for network topology Examples include the definition of YANG models for network topology
[RFC8345] or the introduction of service models used by service [RFC8345] or the introduction of service models used by service
orchestration systems and controllers [RFC8309]. Much of the orchestration systems and controllers [RFC8309]. Much of the
interest has been fueled by the discussion about how to manage interest has been fueled by the discussion about how to manage
autonomic networks, as discussed in the ANIMA working group. autonomic networks as discussed in the ANIMA Working Group.
Autonomic networks are driven by the desire to lower operational Autonomic networks are driven by the desire to lower operational
expenses and make the management of the network as a whole more expenses and make the management of the network as a whole more
straightforward, putting it at odds with the need to manage the straightforward, putting it at odds with the need to manage the
network one device and one feature at a time. However, while network one device and one feature at a time. However, while
autonomic networks are intended to exhibit "self-management" autonomic networks are intended to exhibit "self-management"
properties, they still require input from an operator or outside properties, they still require input from an operator or outside
system to provide operational guidance and information about the system to provide operational guidance and information about the
goals, purposes, and service instances that the network is to serve. goals, purposes, and service instances that the network is to serve.
This input and operational guidance are commonly referred to as This input and operational guidance are commonly referred to as
"intent," and networks that allow network operators to provide their "intent," and a network that allows network operators to provide
input using intent as "Intent-Based Networks" (IBN) and the systems their input using intent is referred to as an "Intent-Based Network"
that help implement intent as "Intent-Based Systems" (IBS). Those (IBN), while a system that helps implement intent is referred to as
systems can manifest themselves in a number of ways, for example as a an "Intent-Based System" (IBS). Those systems can manifest
controller or managemement system that are implemented as an themselves in a number of ways -- for example, as a controller or
application that runs on a server or set of servers, or as a set of management system that is implemented as an application that runs on
functions that are distributed across a network and that collectively a server or set of servers, or as a set of functions that are
perform their intent-based functionality. distributed across a network and that collectively perform their
intent-based functionality.
However, intent is about more than just enabling a form of operator However, intent is about more than just enabling a form of operator
interaction with the network that involves higher-layer abstractions. interaction with the network that involves higher-layer abstractions.
It is also about the ability to let operators focus on what they want It is also about the ability to let operators focus on what they want
their desired outcomes to be while leaving details about how those their desired outcomes to be while leaving details to the IBN
outcomes would, in fact, be achieved to the IBN (respectively IBS). (respectively IBS) about how those outcomes would be achieved.
This, in turn, enables much greater operational efficiency at greater Focusing on the outcome enables much greater operational efficiency
scale, in shorter time scales, with less dependency on human and flexibility at greater scale, in shorter time scales, and with
activities (and possibility for mistakes), and an ideal candidate, less dependency on human activities (and therefore less possibility
e.g., for artificial intelligence techniques that can bring about the for mistakes). This also makes Intent-Based Networking an ideal
next level of network automation [Clemm20]. candidate for artificial intelligence techniques that can bring about
the next level of network automation [CLEMM20].
This vision has since caught on with the industry, leading to a This vision has since caught on with the industry, leading to a
significant number of solutions that offer Intent-Based Management significant number of solutions that offer Intent-Based Management
that promise network providers to manage networks holistically at a that promise network providers to manage networks holistically at a
higher level of abstraction and as a system that happens to consist higher level of abstraction and as a system that happens to consist
of interconnected components, as opposed to a set of independent of interconnected components as opposed to a set of independent
devices (that happen to be interconnected). Those offerings include devices (that happen to be interconnected). Those offerings include
IBN and IBS (offering a full lifecycle of intent), SDN controllers IBNs and IBSs (offering a full life cycle of intent), Software-
(offering a single point of control and administration for a Defined Network (SDN) controllers (offering a single point of control
network), and network management and Operations Support Systems and administration for a network), and network management and
(OSS). Operations Support Systems (OSSs).
It has been recognized for a long time that comprehensive management It has been recognized for a long time that comprehensive management
solutions cannot operate only at the level of individual devices and solutions cannot operate only at the level of individual devices and
low-level configurations. In this sense, the vision of intent is not low-level configurations. In this sense, the vision of intent is not
entirely new. In the past, ITU-T's model of a Telecommunications entirely new. In the past, ITU-T's model of a Telecommunications
Management Network (TMN) introduced a set of management layers that Management Network (TMN) introduced a set of management layers that
defined a management hierarchy, consisting of network element, defined a management hierarchy consisting of network element,
network, service, and business management [M3010]. High-level network, service, and business management [M3010]. High-level
operational objectives would propagate in a top-down fashion from operational objectives would propagate in a top-down fashion from
upper to lower layers. The associated abstraction hierarchy was upper to lower layers. The associated abstraction hierarchy was
crucial to decompose management complexity into separate areas of crucial to decompose management complexity into separate areas of
concern. This abstraction hierarchy was accompanied by an concern. This abstraction hierarchy was accompanied by an
information hierarchy that concerned itself at the lowest level with information hierarchy that concerned itself at the lowest level with
device-specific information, but that would, at higher layers, device-specific information, but that would, at higher layers,
include, for example, end-to-end service instances. Similarly, the include, for example, end-to-end service instances. Similarly, the
concept of Policy-Based Network Management (PBNM) has, for a long concept of Policy-Based Network Management (PBNM) has, for a long
time, touted the ability to allow users to manage networks by time, touted the ability to allow users to manage networks by
specifying high-level management policies, with policy systems specifying high-level management policies, with policy systems
automatically "rendering" those policies, i.e., breaking them down automatically "rendering" those policies, i.e., breaking them down
into low-level configurations and control logic. (As a note, in the into low-level configurations and control logic.
context of this document, "users" generally refers to operators and
administrators who are responsible for the management and operation | As a note, in the context of this document, "users" generally
of communication services and networking infrastructures, not to "end | refers to operators and administrators who are responsible for
users" of communication services.) | the management and operation of communication services and
| networking infrastructures, not to "end users" of communication
| services.
What has been missing, however, is putting these concepts into a more What has been missing, however, is putting these concepts into a more
current context and updating them to account for current technology current context and updating them to account for current technology
trends. This document clarifies the concepts behind intent. It trends. This document clarifies the concepts behind intent. It
differentiates intent from related concepts. It also provides an differentiates intent from related concepts. It also provides an
overview of first-order principles of IBN as well as the associated overview of first-order principles of Intent-Based Networking as well
functionality. The goal is to contribute to a common and shared as the associated functionality. The goal is to contribute to a
understanding that can be used as a foundation to articulate research common and shared understanding that can be used as a foundation to
and engineering problems in the area of IBN. articulate research and engineering problems in the area of Intent-
Based Networking.
It should be noted that the articulation of IBN-related research It should be noted that the articulation of IBN-related research
problems is beyond the scope of this document. However, it should be problems is beyond the scope of this document. However, it should be
recognized that IBN has become an important topic in the research recognized that Intent-Based Networking has become an important topic
community. Per IEEE Xplore [IEEEXPLORE], as of December 2021, in the in the research community. Per IEEE Xplore [IEEEXPLORE], as of
past decade since 2012, there have been 1138 papers with the index December 2021, in the past decade since 2012, there have been 1138
term "intent", of which 411 specifically mention networking. The papers with the index term "intent", of which 411 specifically
time period since 2020 alone accounts for 316 papers on intent and mention networking. The time period since 2020 alone accounts for
153 for intent networking, indicating accelerating interest. In 316 papers on intent and 153 for intent networking, indicating
addition, workshops dedicated to this theme are beginning to appear, accelerating interest. In addition, workshops dedicated to this
such as the IEEE International Workshop on Intent-Based Networking theme are beginning to appear, such as the IEEE International
[WIN21], as well as various special journal issues [IEEE-TITS21] Workshop on Intent-Based Networking [WIN21], as well as various
[MDPI22]. A survey of current intent-driven networking research has special journal issues [IEEE-TITS21] [MDPI22]. A survey of current
been published in [Pang20], listing among the most pressing current intent-driven networking research has been published in [PANG20],
research challenges aspects such as intent translation and listing among the most pressing current research challenges aspects
understanding, intent interfaces, and security. such as intent translation and understanding, intent interfaces, and
security.
2. Definitions and Acronyms 2. Definitions and Acronyms
ACL: Access Control List ACL: Access Control List
API: Application Programming Interface
Intent: A set of operational goals (that a network should meet)
and outcomes (that a network is supposed to deliver), defined in a
declarative manner without specifying how to achieve or implement
them.
IBA: Intent-Based Analytics - Analytics that are defined and API: Application Programming Interface
derived from users' intent and used to validate the intended
state.
Intent-Based Management - The concept of performing management IBA: Intent-Based Analytics. Analytics that are defined and derived
based on the concept of intent. from users' intent and used to validate the intended state.
IBN: Intent-Based Network - A network that can be managed using IBN: Intent-Based Network. A network that can be managed using
intent. intent.
IBS: Intent-Based System - A system that supports management IBS: Intent-Based System. A system that supports management
functions that can be guided using intent. functions that can be guided using intent.
PBNM: Policy-Based Network Management Intent: A set of operational goals (that a network should meet) and
outcomes (that a network is supposed to deliver) defined in a
declarative manner without specifying how to achieve or implement
them.
Policy: A set of rules that governs the choices in behavior of a Intent-Based Management: The concept of performing management based
system. on the concept of intent.
PDP: Policy Decision Point PBNM: Policy-Based Network Management
PEP: Policy Enforcement Point PDP: Policy Decision Point
Service Model: A model that represents a service that is provided PEP: Policy Enforcement Point
by a network to a user.
SSoT: Single Source of Truth - A functional block in an IBN system Policy: A set of rules that governs the choices in behavior of a
system.
Service Model: A model that represents a service that is provided by
a network to a user.
SSoT: Single Source of Truth. A functional block in an IBN system
that normalizes users' intent and serves as the single source of that normalizes users' intent and serves as the single source of
data for the lower layers. data for the lower layers.
SVoT: Single Version of Truth Statement of Intent: A specification of one particular aspect or
component of intent, also referred to as an intent statement.
User: In the context of this document, an operator and/or SVoT: Single Version of Truth
User: In the context of this document, an operator and/or
administrator responsible for the management and operation of administrator responsible for the management and operation of
communication services and networking infrastructure (as opposed communication services and networking infrastructure (as opposed
to an end user of a communication service) to an end user of a communication service).
3. Introduction of Concepts 3. Introduction of Concepts
The following section provides an overview of the concept of intent The following section provides an overview of the concept of intent
and Intent-Based Management. It also provides an overview of the and Intent-Based Management. It also provides an overview of the
related concepts of service models and policies (and Policy-Based related concepts of service models and policies (and Policy-Based
Network Management), and explains how they relate to intent and Network Management), and explains how they relate to intent and
Intent-Based Management. Intent-Based Management.
3.1. Intent and Intent-Based Management 3.1. Intent and Intent-Based Management
In this document, intent is defined as a set of operational goals 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 (that a network is supposed to meet) and outcomes (that a network is
supposed to deliver), defined in a declarative manner without supposed to deliver) defined in a declarative manner without
specifying how to achieve or implement them. specifying how to achieve or implement them.
The term "intent" was first introduced in the context of Autonomic The term "intent" was first introduced in the context of Autonomic
Networks, where it is defined as "an abstract, high-level policy used Networks, where it is defined as "an abstract, high-level policy used
to operate a network" [RFC7575]. According to this definition, an to operate the network" [RFC7575]. According to this definition, an
intent is a specific type of policy provided by a user to provide intent is a specific type of policy provided by a user to provide
guidance to the Autonomic Network that would otherwise operate guidance to the Autonomic Network that would otherwise operate
without human intervention. However, to avoid using intent simply as without human intervention. However, to avoid using intent simply as
a synonym for policy, a distinction that differentiates intent a synonym for policy, a distinction that differentiates intent
clearly from other types of policies needs to be introduced. clearly from other types of policies needs to be introduced.
| One note regarding the use of the plural form of "intent": in
| the English language, the term "intent" is generally used only
| in singular form. However, the specification of intent as a
| whole usually involves the specification of several individual
| statements of intent, or intent statements. In some cases,
| intent statements are colloquially also referred to as
| "intents", although in general, the use of the term "intents"
| is discouraged.
Intent-Based Management aims to lead towards networks that are Intent-Based Management aims to lead towards networks that are
fundamentally simpler to manage and operate, requiring only minimal fundamentally simpler to manage and operate, requiring only minimal
outside intervention. Networks, even when they are autonomic, are outside intervention. Networks, even when they are autonomic, are
not clairvoyant and have no way of automatically knowing particular not clairvoyant and have no way of automatically knowing particular
operational goals nor which instances of networking services to operational goals nor which instances of networking services to
support. In other words, they do not know what the intent of the 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. network provider is that gives the network the purpose of its being.
This still needs to be communicated to the network by what informally This still needs to be communicated to the network by what informally
constitutes intent. That being said, the concept of intent is not constitutes intent. That being said, the concept of intent is not
limited just to autonomic networks, such as networks that feature an limited just to autonomic networks, such as networks that feature an
Autonomic Control Plane [RFC8994], but applies to any network. Autonomic Control Plane [RFC8994], but applies to any network.
Intent defines goals and outcomes in a manner that is purely Intent defines goals and outcomes in a manner that is purely
declarative, specifying what to accomplish, not how to achieve it. declarative, specifying what to accomplish, not how to achieve it.
Intent thus applies several important concepts simultaneously: Intent thus applies several important concepts simultaneously:
* It provides data abstraction: users do not need to be concerned * It provides data abstraction: Users do not need to be concerned
with low-level device configuration and nerd knobs. with low-level device configuration and nerd knobs.
* It provides functional abstraction from particular management and * It provides functional abstraction from particular management and
control logic: users do not need to be concerned even with how to control logic: Users do not need to be concerned even with how to
achieve a given intent. What is specified is the desired outcome, achieve a given intent. What is specified is the desired outcome
with the IBS automatically figuring out a course of action (e.g., with the IBS automatically figuring out a course of action (e.g.,
using an algorithm or applying a set of rules derived from the using an algorithm or applying a set of rules derived from the
intent) for how to achieve the outcome. intent) for how to achieve the outcome.
The following are some examples of intent, expressed in natural The following are some examples of intent, expressed in natural
language for the sake of clarity (actual interfaces used to convey language for the sake of clarity (actual interfaces used to convey
intent may differ): intent may differ):
* "Steer networking traffic originating from endpoints in one * "Steer networking traffic originating from endpoints in one
geography away from a second geography, unless the destination geography away from a second geography, unless the destination
lies in that second geography." (States what to achieve, not lies in that second geography." (states what to achieve, not how.)
how.)
* "Avoid routing networking traffic originating from a given set of * "Avoid routing networking traffic originating from a given set of
endpoints (or associated with a given customer) through a endpoints (or associated with a given customer) through a
particular vendor's equipment, even if this occurs at the expense particular vendor's equipment, even if this occurs at the expense
of reduced service levels." (States what to achieve, not how, of reduced service levels." (states what to achieve, not how,
providing additional guidance for how to trade off between providing additional guidance for how to trade off between
different goals when necessary) different goals when necessary.)
* "Maximize network utilization even if it means trading off service * "Maximize network utilization even if it means trading off service
levels (such as latency, loss) unless service levels have levels (such as latency, loss) unless service levels have
deteriorated 20% or more from their historical mean." (A desired deteriorated 20% or more from their historical mean." (a desired
outcome, with a set of constraints for additional guidance, which outcome, with a set of constraints for additional guidance, that
does not specify how to achieve this.) does not specify how to achieve this.)
* "VPN service must have path protection at all times for all * "Ensure VPN services have path protection at all times for all
paths." (A desired outcome of which it may not be clear how it paths." (a desired outcome of which it may not be clear how it can
can be precisely accommodated.) be precisely accommodated.)
* "Generate in-situ OAM data and network telemetry for later offline * "Generate in situ Operations, Administration, and Maintenance
analysis whenever significant fluctuations in latency across a (OAM) data and network telemetry for later offline analysis
path are observed." (Goes beyond traditional event-condition- whenever significant fluctuations in latency across a path are
action by not being specific about what constitutes "significant" observed." (goes beyond event-condition-action by not being
and what specific data to collect) specific about what constitutes "significant" and what specific
data to collect.)
* "Route traffic in a Space Information Network in a way that * "Route traffic in a Space Information Network in a way that
minimizes dependency on stratospheric balloons unless the intended minimizes dependency on stratospheric balloons unless the intended
destination is an aircraft." (Does not specify how to precisely destination is an aircraft." (does not specify how to precisely
achieve this; extrapolates on scenarios mentioned in [Pang20]) achieve this; extrapolates on scenarios mentioned in [PANG20].)
* "For a smart city service, ensure traffic signal control traffic * "For a smart city service, ensure traffic signal control traffic
uses dedicated and redundant slices that avoid fate sharing." (A uses dedicated and redundant slices that avoid fate sharing." (a
desired outcome with a set of constraints and additional guidance desired outcome with a set of constraints and additional guidance
without specifying how to precisely achieve this; extrapolates on without specifying how to precisely achieve this; extrapolates on
scenarios from [Gharbaoui21]). scenarios from [GHARBAOUI21].)
In contrast, the following are examples of what would not constitute In contrast, the following are examples of what would not constitute
intent (again, expressed in natural language for the sake of intent (again, expressed in natural language for the sake of
clarity): clarity):
* "Configure a given interface with an IP address." This would be * "Configure a given interface with an IP address." (This would be
considered device configuration and fiddling with configuration considered device configuration and fiddling with configuration
knobs, not intent. knobs, not intent.)
* "When interface utilization exceeds a specific threshold, emit an * "When interface utilization exceeds a specific threshold, emit an
alert." This would be a rule that can help support network alert." (This would be a rule that can help support network
automation, but a simple rule is not an intent. automation, but a simple rule is not an intent.)
* "Configure a VPN with a tunnel from A to B over path P." This * "Configure a VPN with a tunnel from A to B over path P." (This
would be considered as a configuration of a service. would be considered as a configuration of a service.)
* "Deny traffic to prefix P1 unless it is traffic from prefix P2." * "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, (This would be an example of an access policy or a firewall rule,
not intent. not intent.)
In networks, in particular in networks that are deemed autonomic, In networks, in particular in networks that are deemed autonomic,
intent should ideally be rendered by the network itself, i.e., intent should ideally be rendered by the network itself, i.e.,
translated into device-specific rules and courses of action. translated into device-specific rules and courses of action.
Ideally, intent would not need to be orchestrated or broken down by a Ideally, intent would not need to be orchestrated or broken down by a
higher-level, centralized system but by the network devices higher-level, centralized system but by the network devices
themselves using a combination of distributed algorithms and local themselves using a combination of distributed algorithms and local
device abstractions. In this idealized vision, because intent holds device abstractions. In this idealized vision, because intent holds
for the network as a whole, intent should ideally be automatically for the network as a whole, intent should ideally be automatically
disseminated across all devices in the network, which can themselves disseminated across all devices in the network, which can themselves
decide whether they need to act on it. decide whether they need to act on it.
However, such decentralization will not be practical in all cases. However, such decentralization will not be practical in all cases.
Certain functions will need to be at least conceptually centralized. Certain functions will need to be at least conceptually centralized.
For example, users may require a single conceptual point of For example, users may require a single conceptual point of
interaction with the network. The system providing this points acts interaction with the network. The system providing this point acts
as the operational front end for the network through which users can as the operational front end for the network through which users can
direct requests at the network and from which they can receive direct requests at the network and from which they can receive
updates about the network. It may appear to users as a single updates about the network. It may appear to users as a single
system, even if it is implemented in a distributed manner. In turn, system, even if it is implemented in a distributed manner. In turn,
it interacts with and manages other systems in the network as needed it interacts with and manages other systems in the network as needed
in order to realize (i.e., to fulfill and to assure) the desired in order to realize (i.e., to fulfill and to assure) the desired
intent. Likewise, the vast majority of network devices may be intent. Likewise, the vast majority of network devices may be
intent-agnostic and focus only (for example) on the actual forwarding intent-agnostic and focus only (for example) on the actual forwarding
of packets. Many devices may also be constrained in terms of their of packets. Many devices may also be constrained in terms of their
processing resources. This means that not every device may be able processing resources. This means that not every device may be able
to act on intent on its own. Again, intent in those cases can be to act on intent on its own. Again, intent in those cases can be
achieved by a separate system which performs the required actions. achieved by a separate system that performs the required actions.
Another reason to provide intent functionality from a conceptually Another reason to provide intent functionality from a conceptually
centralized point is in cases where the the realization of a certain centralized point is in cases where the realization of a certain type
type of intent benefits from global knowledge of a network and its of intent benefits from global knowledge of a network and its state.
state. In many cases, such a global view may be impractical to In many cases, such a global view may be impractical to maintain by
maintain by individual devices, for example due to the volume of data individual devices, for example due to the volume of data and time
and time lags that are involved. It may even be impractical for lags that are involved. It may even be impractical for devices to
devices to simply access such a view from another remote system if simply access such a view from another remote system if such were
such were available. available.
All of this implies that in many cases, certain intent functionality All of this implies that in many cases, certain intent functionality
needs to be provided by functions that are specialized for that needs to be provided by functions that are specialized for that
purpose and that may be provided by dedicated systems (which in some purpose and that may be provided by dedicated systems (which in some
cases could also co-host other networking functions). For example, cases could also co-host other networking functions). For example,
the translation of specific types of intent into corresponding the translation of specific types of intent into corresponding
courses of action and algorithms to achieve the desired outcomes may courses of action and algorithms to achieve the desired outcomes may
need to be provided by such specialized functions. Of course, to need to be provided by such specialized functions. Of course, to
avoid single points of failure, the implementation and hosting of avoid single points of failure, the implementation and hosting of
such functions may still be distributed, even if conceptually such functions may still be distributed even if conceptually
centralized. centralized.
Regardless of its particular implementation in centralized or Regardless of its particular implementation in a centralized or
decentralized manner, an IBN is a network that can be managed using decentralized manner, an IBN is a network that can be managed using
intent. This means that it is able to recognize and ingest intent of 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 an operator or user and configure and adapt itself according to the
user intent, achieving an intended outcome (i.e., a desired state or user intent, achieving an intended outcome (i.e., a desired state or
behavior) without requiring the user to specify the detailed behavior) without requiring the user to specify the detailed
technical steps for how to achieve the outcome. Instead, the IBN 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. 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 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 using intent. Such a system will serve as a point of interaction
with users and implement the functionality that is necessary to with users and implement the functionality that is necessary to
skipping to change at page 11, line 4 skipping to change at line 469
Other definitions of intent exist, such as [TR523]. Intent there is Other definitions of intent exist, such as [TR523]. Intent there is
simply defined as a declarative interface that is typically provided simply defined as a declarative interface that is typically provided
by a controller. It implies the presence of a centralized function by a controller. It implies the presence of a centralized function
that renders the intent into lower-level policies or instructions and that renders the intent into lower-level policies or instructions and
orchestrates them across the network. While this is certainly one orchestrates them across the network. While this is certainly one
way of implementation, the definition that is presented here is more way of implementation, the definition that is presented here is more
encompassing and ambitious, as it emphasizes the importance of encompassing and ambitious, as it emphasizes the importance of
managing the network by specifying desired outcomes without the managing the network by specifying desired outcomes without the
specific steps to be taken in order to achieve the outcome. A specific steps to be taken in order to achieve the outcome. A
controller API that simply provides a network-level of abstraction is controller API that simply provides abstraction at the network level
more limited and would not necessarily qualify as intent. Likewise, is more limited and would not necessarily qualify as intent.
ingestion and recognition of intent may not necessarily occur via a Likewise, ingestion and recognition of intent may not necessarily
traditional API but may involve other types of human-machine occur via an API based on function invocations and simple request-
interactions. response interactions but may involve other types of human-machine
interactions such as dialogs to provide clarifications and
refinements to requests.
3.2. Related Concepts 3.2. Related Concepts
3.2.1. Service Models 3.2.1. Service Models
A service model is a model that represents a service that is provided A service model is a model that represents a service that is provided
by a network to a user. Per [RFC8309], a service model describes a by a network to a user. Per [RFC8309], a service model describes a
service and its parameters in a portable/implementation-agnostic way service and its parameters in a portable and implementation-agnostic
that can be used independently of the equipment and operating way that can be used independently of the equipment and operating
environment on which the service is realized. Two subcategories are environment on which the service is realized. Two subcategories are
distinguished: a "Customer Service Model" describes an instance of a distinguished: a "Customer Service Model" describes an instance of a
service as provided to a customer, possibly associated with a service service as provided to a customer, possibly associated with a service
order. A "Service Delivery Model" describes how a service is order, and a "Service Delivery Model" describes how a service is
instantiated over existing networking infrastructure. instantiated over existing networking infrastructure.
An example of a service could be a Layer 3 VPN service [RFC8299], a An example of a service could be a Layer 3 VPN service [RFC8299], a
Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or Network Slice [NETWORK-SLICE], or residential Internet access.
residential Internet access. Service models represent service Service models represent service instances as entities in their own
instances as entities in their own right. Services have their own right. Services have their own parameters, actions, and life cycles.
parameters, actions, and lifecycles. Typically, service instances Typically, service instances can be bound to end users of
can be bound to end users of communication services, who might be communication services who might be billed for the services provided.
billed for the services provided.
Instantiating a service typically involves multiple aspects: Instantiating a service typically involves multiple aspects:
* A user (or northbound system) needs to define and/or request a * A user (or northbound system) needs to define and/or request a
service to be instantiated. service to be instantiated.
* Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, * Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools,
interfaces, bandwidth, or memory need to be allocated. interfaces, bandwidth, or memory need to be allocated.
* How to map services to the resources needs to be defined. * How to map services to the resources needs to be defined.
Multiple mappings are often possible, which to select may depend Multiple mappings are often possible, which to select may depend
on context (such as which type of access is available to connect on context (such as which type of access is available to connect
the end user of a communication service with the service). the end user of a communication service with the service).
* Bindings between upper and lower-level objects need to be * Bindings between upper- and lower-level objects need to be
maintained. maintained.
* Once instantiated, the service operational state needs to be * Once instantiated, the service operational state needs to be
validated and assured to ensure that the network indeed delivers validated and assured to ensure that the network indeed delivers
the service as requested. the service as requested.
The realization of service models involves a system, such as a The realization of service models involves a system, such as a
controller, that provides provisioning logic. This includes breaking controller, that provides provisioning logic. This includes breaking
down high-level service abstractions into lower-level device down high-level service abstractions into lower-level device
abstractions, identifying and allocating system resources, and abstractions, identifying and allocating system resources, and
orchestrating individual provisioning steps. Orchestration orchestrating individual provisioning steps. Orchestration
operations are generally conducted using a "push" model in which the operations are generally conducted using a "push" model in which the
controller/manager initiates the operations as required, then pushes controller/manager initiates the operations as required, then pushes
down the specific configurations to the device and validates whether down the specific configurations to the device and validates whether
the new changes have been accepted and the new operational/derived the new changes have been accepted and the new operational/derived
states are achieved and in sync with the intent/desired state. In states are achieved and in sync with the intent/desired state. In
addition to instantiating and creating new instances of a service, addition to instantiating and creating new instances of a service,
updating, modifying, and decommissioning services need to be also updating, modifying, and decommissioning services also need to be
supported. The device itself typically remains agnostic to the supported. The device itself typically remains agnostic to the
service or the fact that its resources or configurations are part of service or the fact that its resources or configurations are part of
a service/concept at a higher layer. a service/concept at a higher layer.
Instantiated service models map to instantiated lower-layer network Instantiated service models map to instantiated lower-layer network
and device models. Examples include instances of paths or instances and device models. Examples include instances of paths or instances
of specific port configurations. The service model typically also of specific port configurations. The service model typically also
models dependencies and layering of services over lower-layer models dependencies and layering of services over lower-layer
networking resources that are used to provide services. This networking resources that are used to provide services. This
facilitates management by allowing to follow dependencies for facilitates management by allowing to follow dependencies for
troubleshooting activities, to perform impact analysis in which troubleshooting activities and to perform impact analysis in which
events in the network are assessed regarding their impact on services events in the network are assessed regarding their impact on services
and customers. Services are typically orchestrated and provisioned and customers. Services are typically orchestrated and provisioned
top-to-bottom, which also facilitates keeping track of the assignment top to bottom, which also facilitates keeping track of the assignment
of network resources (composition), while troubleshooted bottom-up of network resources (composition), while troubleshooted bottom up
(decomposition). Service models might also be associated with other (decomposition). Service models might also be associated with other
data that does not concern the network but provides business context. data that does not concern the network but provides business context.
This includes things such as customer data (such as billing This includes things such as customer data (such as billing
information), service orders and service catalogs, tariffs, service information), service orders and service catalogs, tariffs, service
contracts, and Service Level Agreements (SLAs), including contractual contracts, and Service Level Agreements (SLAs), including contractual
agreements regarding remediation actions. agreements regarding remediation actions.
[I-D.ietf-teas-te-service-mapping-yang] is an example of a data model [SERVICE-MAPPING-YANG] is an example of a data model that provides a
that provides a mapping for customer service models (e.g., the L3VPN mapping for customer service models (e.g., the L3VPN Service Model)
Service Model) to Traffic Engineering (TE) models (e.g., the TE to Traffic Engineering (TE) models (e.g., the TE Tunnel or the
Tunnel or the Abstraction and Control of Traffic Engineered Networks Abstraction and Control of Traffic Engineered Networks Virtual
Virtual Network model) Network model).
Like intent, service models provide higher layers of abstraction. Like intent, service models provide higher layers of abstraction.
Service models are often also complemented with mappings that capture Service models are often also complemented with mappings that capture
dependencies between service and device or network configurations. dependencies between service and device or network configurations.
Unlike intent, service models do not allow to define a desired Unlike intent, service models do not allow to define a desired
"outcome" that would be automatically maintained by an IBS. Instead, "outcome" that would be automatically maintained by an IBS. Instead,
the management of service models requires the development of the management of service models requires the development of
sophisticated algorithms and control logic by network providers or sophisticated algorithms and control logic by network providers or
system integrators. system integrators.
3.2.2. Policy and Policy-Based Network Management 3.2.2. Policy and Policy-Based Network Management
Policy-Based Network Management (PBNM) is a management paradigm that Policy-Based Network Management (PBNM) is a management paradigm that
separates the rules that govern the behavior of a system from the separates the rules that govern the behavior of a system from the
functionality of the system. It promises to reduce maintenance costs functionality of the system. It promises to reduce maintenance costs
of information and communication systems while improving flexibility of information and communication systems while improving flexibility
and runtime adaptability. It is present today at the heart of a and runtime adaptability. It is present today at the heart of a
multitude of management architectures and paradigms, including SLA- multitude of management architectures and paradigms, including SLA-
driven, Business-driven, autonomous, adaptive, and self-* management driven, business-driven, autonomous, adaptive, and self-* management
[Boutaba07]. The interested reader is asked to refer to the rich set [BOUTABA07]. The interested reader is asked to refer to the rich set
of existing literature, which includes this and many other of existing literature, which includes this and many other
references. In the following, we will only provide a much-abridged references. In the following, we will only provide a much-abridged
and distilled overview. and distilled overview.
At the heart of policy-based management is the concept of a policy. At the heart of policy-based management is the concept of a policy.
Multiple definitions of policy exist: "Policies are rules governing Multiple definitions of policy exist: "Policies are rules governing
the choices in the behavior of a system" [Sloman94]. "Policy is a the choices in the behavior of a system" [SLOMAN94]. "Policy is a
set of rules that are used to manage and control the changing and/or set of rules that are used to manage and control the changing and/or
maintaining of the state of one or more managed objects" maintaining of the state of one or more managed objects"
[Strassner03]. Common to most definitions is the definition of a [STRASSNER03]. Common to most definitions is the definition of a
policy as a "rule." Typically, the definition of a rule consists of policy as a "rule." Typically, the definition of a rule consists of
an event (whose occurrence triggers a rule), a set of conditions an event (whose occurrence triggers a rule), a set of conditions
(which get assessed and which must be true before any actions are (which get assessed and which must be true before any actions are
actually "fired"), and, finally, a set of one or more actions that actually "fired"), and finally, a set of one or more actions that are
are carried out when the condition holds. carried out when the condition holds.
Policy-based management can be considered an imperative management Policy-based management can be considered an imperative management
paradigm: Policies precisely specified what needs to be done when and paradigm: Policies precisely specify what needs to be done when and
in which circumstance. By using policies, management can, in effect, in which circumstance. By using policies, management can, in effect,
be defined as a set of simple control loops. This makes policy-based be defined as a set of simple control loops. This makes policy-based
management a suitable technology to implement autonomic behavior that management a suitable technology to implement autonomic behavior that
can exhibit self-* management properties, including self- can exhibit self-* management properties, including self-
configuration, self-healing, self-optimization, and self-protection. configuration, self-healing, self-optimization, and self-protection.
This is notwithstanding the fact that policy-based management may This is notwithstanding the fact that policy-based management may
make use of the concept of abstractions (such as, "Bob gets gold make use of the concept of abstractions (such as, "Bob gets gold
service") that hide from the user the specifics of how that service") that hide from the user the specifics of how that
abstraction is rendered in a particular deployment. abstraction is rendered in a particular deployment.
Policies typically involve a certain degree of abstraction in order Policies typically involve a certain degree of abstraction in order
to cope with the heterogeneity of networking devices. Rather than to cope with the heterogeneity of networking devices. Rather than
having a device-specific policy that defines events, conditions, and having a device-specific policy that defines events, conditions, and
actions in terms of device-specific commands, parameters, and data actions in terms of device-specific commands, parameters, and data
models, a policy is defined at a higher level of abstraction models, a policy is defined at a higher level of abstraction
involving a canonical model of systems and devices to which the involving a canonical model of systems and devices to which the
policy is to be applied. A policy agent on a controller or the policy is to be applied. A policy agent on a controller or the
device subsequently "renders" the policy, i.e., translates the device subsequently "renders" the policy, i.e., translates the
canonical model into a device-specific representation. This concept canonical model into a device-specific representation. This concept
allows applying the same policy across a wide range of devices allows applying the same policy across a wide range of devices
without needing to define multiple variants. In other words - policy without needing to define multiple variants. In other words, policy
definition is de-coupled from policy instantiation and policy definition is decoupled from policy instantiation and policy
enforcement. This enables operational scale and allows network enforcement. This enables operational scale and allows network
operators and authors of policies to think in higher terms of operators and authors of policies to think in higher terms of
abstraction than device specifics and be able to reuse the same, abstraction than device specifics and be able to reuse the same,
high-level definition across different networking domains, WAN, DC, high-level definition across different networking domains, WAN, data
or public cloud. center (DC), or public cloud.
PBNM is typically "push-based": Policies are pushed onto devices PBNM is typically "push-based": Policies are pushed onto devices
where they are rendered and enforced. The push operations are where they are rendered and enforced. The push operations are
conducted by a manager or controller, which is responsible for conducted by a manager or controller that is responsible for
deploying policies across the network and monitoring their proper deploying policies across the network and monitoring their proper
operation. That being said, other policy architectures are possible. operation. That being said, other policy architectures are possible.
For example, policy-based management can also include a pull- For example, policy-based management can also include a pull
component in which the decision regarding which action to take is component in which the decision regarding which action to take is
delegated to a so-called Policy Decision Point (PDP). This PDP can delegated to a so-called Policy Decision Point (PDP). This PDP can
reside outside the managed device itself and has typically global reside outside the managed device itself and has typically global
visibility and context with which to make policy decisions. Whenever visibility and context with which to make policy decisions. Whenever
a network device observes an event that is associated with a policy a network device observes an event that is associated with a policy
but lacks the full definition of the policy or the ability to reach a but lacks the full definition of the policy or the ability to reach a
conclusion regarding the expected action, it reaches out to the PDP conclusion regarding the expected action, it reaches out to the PDP
for a decision (reached, for example, by deciding on an action based for a decision (reached, for example, by deciding on an action based
on various conditions). Subsequently, the device carries out the on various conditions). Subsequently, the device carries out the
decision as returned by the PDP - the device "enforces" the policy decision as returned by the PDP; the device "enforces" the policy and
and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM hence acts as a PEP (Policy Enforcement Point). Either way, PBNM
architectures typically involve a central component from which architectures typically involve a central component from which
policies are deployed across the network and/or policy decisions policies are deployed across the network and/or policy decisions
served. served.
Like Intent, policies provide a higher layer of abstraction. Policy Like intent, policies provide a higher layer of abstraction. Policy
systems are also able to capture dynamic aspects of the system under systems are also able to capture dynamic aspects of the system under
management through the specification of rules that allow defining management through the specification of rules that allow defining
various triggers for specific courses of action. Unlike intent, the various triggers for specific courses of action. Unlike intent, the
definition of those rules (and courses of action) still needs to be definition of those rules (and courses of action) still needs to be
articulated by users. Since the intent is unknown, conflict articulated by users. Since the intent is unknown, conflict
resolution within or between policies requires interactions with a resolution within or between policies requires interactions with a
user or some kind of logic that resides outside of PBNM. In that user or some kind of logic that resides outside of PBNM. In that
sense, policy constitutes a lower level of abstraction than intent, sense, policy constitutes a lower level of abstraction than intent,
and it is conceivable for Intent-Based Systems to generate policies and it is conceivable for IBSs to generate policies that are
that are subsequently deployed by a PBNM system, allowing PBNM to subsequently deployed by a PBNM system, allowing PBNM to support
support Intent-Based Networking. Intent-Based Networking.
3.2.3. Distinguishing between Intent, Policy, and Service Models 3.2.3. Distinguishing between Intent, Policy, and Service Models
What Intent, Policy, and Service Models all have in common is the What intent, policy, and service models all have in common is the
fact that they involve a higher-layer of abstraction of a network fact that they involve a higher layer of abstraction of a network
that does not involve device-specifics, that generally transcends that does not involve device specifics, generally transcends
individual devices, and that makes the network easier to manage for individual devices, and makes the network easier to manage for
applications and human users compared to having to manage the network applications and human users compared to having to manage the network
one device at a time. Beyond that, differences emerge. one device at a time. Beyond that, differences emerge.
Summarized differences: Summarized differences:
* A service model is a data model that is used to describe instances * A service model is a data model that is used to describe instances
of services that are provided to customers. A service model has of services that are provided to customers. A service model has
dependencies on lower-level models (device and network models) dependencies on lower-level models (device and network models)
when describing how the service is mapped onto the underlying when describing how the service is mapped onto the underlying
network and IT infrastructure. Instantiating a service model network and IT infrastructure. Instantiating a service model
skipping to change at page 15, line 45 skipping to change at line 697
goals, without specifying how those outcomes should be achieved or goals, without specifying how those outcomes should be achieved or
how goals should specifically be satisfied, and without the need how goals should specifically be satisfied, and without the need
to enumerate specific events, conditions, and actions. Which to enumerate specific events, conditions, and actions. Which
algorithm or rules to apply can be automatically "learned/derived algorithm or rules to apply can be automatically "learned/derived
from intent" by the IBS. In the context of autonomic networking, from intent" by the IBS. In the context of autonomic networking,
intent is ideally rendered by the network itself; also, the intent is ideally rendered by the network itself; also, the
dissemination of intent across the network and any required dissemination of intent across the network and any required
coordination between nodes is resolved by the network without the coordination between nodes is resolved by the network without the
need for external systems. need for external systems.
One analogy to capture the difference between policy and Intent-Based One analogy to capture the difference between policy-based systems
Systems is that of Expert Systems and Learning Systems in the field and IBSs is that of Expert Systems and Learning Systems in the field
of Artificial Intelligence. Expert Systems operate on knowledge of Artificial Intelligence. Expert Systems operate on knowledge
bases with rules that are supplied by users, analogous to policy bases with rules that are supplied by users, analogous to policy
systems whose policies are supplied by users. They are able to make systems whose policies are supplied by users. They are able to make
automatic inferences based on those rules but are not able to "learn" automatic inferences based on those rules but are not able to "learn"
new rules on their own. Learning Systems (popularized by deep new rules on their own. Learning Systems (popularized by deep
learning and neural networks), on the other hand, are able to learn learning and neural networks), on the other hand, are able to learn
without depending on user programming or articulation of rules. without depending on user programming or articulation of rules.
However, they do require a learning or training phase requiring large However, they do require a learning or training phase requiring large
data sets; explanations of actions that the system actually takes data sets; explanations of actions that the system actually takes
provide a different set of challenges. Analogous to intent-based provide a different set of challenges. Analogous to IBSs, users
systems, users focus on what they would like the learning system to focus on what they would like the learning system to accomplish but
accomplish but not how to do it. not how to do it.
4. Principles 4. Principles
The following main operating principles allow characterizing the The following main operating principles allow characterizing the
intent-based/-driven/-defined nature of a system. intent-based/-driven/-defined nature of a system.
1. Single Source of Truth (SSoT) and Single Version/View of Truth 1. Single Source of Truth (SSoT) and Single Version of Truth (SVoT).
(SVoT). The SSoT is an essential component of an intent-based The SSoT is an essential component of an IBS as it enables
system as it enables several important operations. The set of several important operations. The set of validated intent
validated intent expressions is the system's SSoT. SSoT and the expressions is the system's SSoT. SSoT and the records of the
records of the operational states enable comparing the intended/ operational states enable comparing the intended/desired state
desired state and actual/operational states of the system and and actual/operational states of the system and determining drift
determining drift between them. SSoT and the drift information between them. SSoT and the drift information provide the basis
provide the basis for corrective actions. If the IBS is equipped for corrective actions. If the IBS is equipped with the means to
with the means to predict states, it can further develop predict states, it can further develop strategies to anticipate,
strategies to anticipate, plan, and pro-actively act on any plan, and pro-actively act on any diverging trends with the aim
diverging trends with the aim to minimize their impact. Beyond to minimize their impact. Beyond providing a means for
providing a means for consistent system operation, SSoT also consistent system operation, SSoT also allows for better
allows for better traceability to validate if/how the initial traceability to validate if/how the initial intent and associated
intent and associated business goals have been properly met, to business goals have been properly met in order to evaluate the
evaluate the impacts of changes in the intent parameters and impacts of changes in the intent parameters and impacts and
impacts and effects of the events occurring in the system. effects of the events occurring in the system.
Single Version (or View) of Truth derives from the SSoT and can Single Version (or View) of Truth derives from the SSoT and can
be used to perform other operations, such as querying, polling, be used to perform other operations such as querying, polling, or
or filtering measured and correlated information in order to filtering measured and correlated information in order to create
create so-called "views." These views can serve the users of the so-called "views." These views can serve the users of the IBS.
intent-based system. In order to create intents as single In order to create intent statements as single sources of truth,
sources of truth, the IBS must follow well-specified and well- the IBS must follow well-specified and well-documented processes
documented processes and models. In other contexts, SSoT is also and models. In other contexts, SSoT is also referred to as the
referred to as the invariance of the intent [Lenrow15]. invariance of the intent [LENROW15].
2. One-touch but not one-shot. In an ideal intent-based system, the 2. One touch but not one shot. In an ideal IBS, the user expresses
user expresses intent in one form or another, and then the system intent in one form or another, and then the system takes over all
takes over all subsequent operations (one-touch). A zero-touch subsequent operations (one touch). A zero-touch approach could
approach could also be imagined in the case where the intent- also be imagined in the case where the IBS has the capabilities
based system has the capabilities or means to recognize or means to recognize intentions in any form of data. However,
intentions in any form of data. However, the zero- or one-touch the zero- or one-touch approach should not distract from the fact
approach should not distract from the fact that reaching the that reaching the state of a well-formed and valid intent
state of a well-formed and valid intent expression is not a one- expression is not a one-shot process. On the contrary, the
shot process. On the contrary, the interfacing between the user interfacing between the user and the IBS could be designed as an
and the intent-based system could be designed as an interactive interactive and iterative process. Depending on the level of
and iterative process. Depending on the level of abstraction, abstraction, the intent expressions may initially contain more or
the intent expressions may initially contain more or less less implicit parts and imprecise or unknown parameters and
implicit parts and unprecise or unknown parameters and constraints. The role of the IBS is to parse, understand, and
constraints. The role of the intent-based system is to parse, refine the intent expression to reach a well-formed and valid
understand, and refine the intent expression to reach a well- intent expression that can be further used by the system for the
formed and valid intent expression that can be further used by fulfillment and assurance operations. An intent refinement
the system for the fulfillment and assurance operations. An process could use a combination of iterative steps involving the
intent refinement process could use a combination of iterative user to validate the proposed refined intent and to ask the user
steps involving the user to validate the proposed refined intent for clarifications in case some parameters or variables could not
and to ask the user for clarifications in case some parameters or be deduced or learned by means of the system itself. In
variables could not be deduced or learned by means of the system addition, the IBS will need to moderate between conflicting
itself. In addition, the Intent-Based System will need to intent, helping users to properly choose between intent
moderate between conflicting intent, helping users to properly alternatives that may have different ramifications.
choose between intent alternatives that may have different
ramifications.
3. Autonomy and Supervision. A desirable goal for an intent-based 3. Autonomy and Supervision. A desirable goal for an IBS is to
system is to offer a high degree of flexibility and freedom on offer a high degree of flexibility and freedom on both the user
both the user side and system side, e.g., by giving the user the side and system side, e.g., by giving the user the ability to
ability to express intents using the user's own terms, by express intent using the user's own terms, by supporting
supporting different forms of expression of intents and being different forms of expression for individual statements of intent
capable of refining the intent expressions to well-formed and and being capable of refining the intent expressions to well-
exploitable expressions. The dual principle of autonomy and formed and exploitable expressions. The dual principle of
supervision allows operating a system that will have the autonomy and supervision allows operating a system that will have
necessary levels of autonomy to conduct its tasks and operations the necessary levels of autonomy to conduct its tasks and
without requiring the intervention of the user and taking its own operations without requiring the intervention of the user and
decisions (within its areas of concern and span of control) as taking its own decisions (within its areas of concern and span of
how to perform and meet the user expectations in terms of control) as how to perform and meet the user expectations in
performance and quality, while at the same time providing the terms of performance and quality, while at the same time
proper level of supervision to satisfy the user requirements for providing the proper level of supervision to satisfy the user
reporting and escalation of relevant information. requirements for reporting and escalation of relevant
information.
4. Learning. An intent-based system is a learning system. In 4. Learning. An IBS is a learning system. In contrast to an
contrast to an imperative-type of system, such as Event- imperative type of system, such as Event-Condition-Action policy
Condition-Action policy rules, where the user defines beforehand rules, where the user defines beforehand the expected behavior of
the expected behavior of the system to various events and the system to various events and conditions, in an IBS, the user
conditions, in an intent-based system, the user only declares only declares what the system is supposed to achieve and not how
what the system is supposed to achieve and not how to achieve to achieve these goals. There is thus a transfer of reasoning/
these goals. There is thus a transfer of reasoning/rationality rationality from the human (domain knowledge) to the system.
from the human (domain knowledge) to the system. This transfer This transfer of cognitive capability also implies the
of cognitive capability also implies the availability in the availability in the IBS of capabilities or means for learning,
intent-based system of capabilities or means for learning,
reasoning, and knowledge representation and management. The reasoning, and knowledge representation and management. The
learning abilities of an IBS can apply to different tasks such as learning abilities of an IBS can apply to different tasks such as
optimization of the intent rendering or intent refinement optimization of the intent rendering or intent refinement
processes. The fact that an intent-based system is a processes. The fact that an IBS is a continuously evolving
continuously evolving system creates the condition for continuous system creates the condition for continuous learning and
learning and optimization. Other cognitive capabilities such as optimization. Other cognitive capabilities such as planning can
planning can also be leveraged in an intent-based system to also be leveraged in an IBS to anticipate or forecast future
anticipate or forecast future system state and response to system state and response to changes in intent or network
changes in intents or network conditions and thus elaboration of conditions and thus elaboration of plans to accommodate the
plans to accommodate the changes while preserving system changes while preserving system stability and efficiency in a
stability and efficiency in a trade-off with cost and robustness trade-off with cost and robustness of operations.
of operations.
5. Capability exposure. Capability exposure consists in the need 5. Capability exposure. Capability exposure consists in the need
for expressive network capabilities, requirements, and for expressive network capabilities, requirements, and
constraints to be able to compose/decompose intents and map the constraints to be able to compose/decompose intent and map the
user's expectations to the system capabilities. user's expectations to the system capabilities.
6. Abstract and outcome-driven. Users do not need to be concerned 6. Abstract and outcome-driven. Users do not need to be concerned
with how intent is achieved and are empowered to think in terms with how intent is achieved and are empowered to think in terms
of outcomes. In addition, they can refer to concepts at a higher of outcomes. In addition, they can refer to concepts at a higher
level of abstractions, independent e.g. of vendor-specific level of abstractions, independent, e.g., of vendor-specific
renderings. renderings.
The described principles are perhaps the most prominent, but they are The described principles are perhaps the most prominent, but they are
not an exhaustive list. There are additional aspects to consider, not an exhaustive list. There are additional aspects to consider,
such as: such as:
* Intent targets are not individual devices but typically * Intent targets are not individual devices but typically
aggregations (such as groups of devices adhering to a common aggregations (such as groups of devices adhering to a common
criteria, such as devices of a particular role) or abstractions criteria, such as devices of a particular role) or abstractions
(such as service types, service instances, topologies). (such as service types, service instances, or topologies).
* Abstraction and inherent virtualization: agnostic to * Abstraction and inherent virtualization: agnostic to
implementation details. implementation details.
* Human-tailored network interaction: IBN should speak the language * Human-tailored network interaction: IBN should speak the language
of the user as opposed to requiring the user to speak the language of the user as opposed to requiring the user to speak the language
of the device/network. of the device/network.
* Explainability as an important IBN function, detection and IBN- * Explainability as an important IBN function, detection and IBN-
aided resolution of conflicting intent, reconciliation of what the aided resolution of conflicting intent, and reconciliation of what
user wants and what the network can actually do. the user wants and what the network can actually do.
* Inherent support, verification, and assurance of trust. * Inherent support, verification, and assurance of trust.
All of these principles and considerations have implications on the All of these principles and considerations have implications on the
design of intent-based systems and their supporting architecture. design of IBSs and their supporting architecture. Accordingly, they
Accordingly, they need to be considered when deriving functional and need to be considered when deriving functional and operational
operational requirements. requirements.
5. Intent-Based Networking - Functionality 5. Intent-Based Networking - Functionality
Intent-Based Networking involves a wide variety of functions that can Intent-Based Networking involves a wide variety of functions that can
be roughly divided into two categories: be roughly divided into two categories:
* Intent Fulfillment provides functions and interfaces that allow * Intent Fulfillment provides functions and interfaces that allow
users to communicate intent to the network and that perform the users to communicate intent to the network and that perform the
necessary actions to ensure that intent is achieved. This necessary actions to ensure that intent is achieved. This
includes algorithms to determine proper courses of action and includes algorithms to determine proper courses of action and
functions that learn to optimize outcomes over time. In addition, functions that learn to optimize outcomes over time. In addition,
it also includes more traditional functions such as any required it also includes functions such as any required orchestration of
orchestration of coordinated configuration operations across the coordinated configuration operations across the network and
network and rendering of higher-level abstractions into lower- rendering of higher-level abstractions into lower-level parameters
level parameters and control knobs. and control knobs.
* Intent Assurance provides functions and interfaces that allow * Intent Assurance provides functions and interfaces that allow
users to validate and monitor that the network is indeed adhering users to validate and monitor that the network is indeed adhering
to and complying with intent. This is necessary to assess the to and complying with intent. This is necessary to assess the
effectiveness of actions taken as part of fulfillment, providing effectiveness of actions taken as part of fulfillment, providing
important feedback that allows those functions to be trained or important feedback that allows those functions to be trained or
tuned over time to optimize outcomes. In addition, Intent tuned over time to optimize outcomes. In addition, Intent
Assurance is necessary to address "intent drift." Intent is not Assurance is necessary to address "intent drift." Intent is not
meant to be transactional, i.e. "set and forget", but expected to meant to be transactional, i.e., "set and forget", but is expected
be remain in effect over time (unless explicitly stated to remain in effect over time (unless explicitly stated
otherwise). Intent drift occurs when a system originally meets otherwise). Intent drift occurs when a system originally meets
the intent, but over time gradually allows its behavior to change the intent, but over time gradually allows its behavior to change
or be affected until it no longer does or does so in a less or be affected until it no longer does or does so in a less
effective manner. effective manner.
The following sections provide a more comprehensive overview of those The following sections provide a more comprehensive overview of those
functions. functions.
5.1. Intent Fulfillment 5.1. Intent Fulfillment
Intent fulfillment is concerned with the functions that take intent Intent fulfillment is concerned with the functions that take intent
from its origination by a user (generally, an administrator of the from its origination by a user (generally, an administrator of the
responsible organization) to its realization in the network. responsible organization) to its realization in the network.
5.1.1. Intent Ingestion and Interaction with Users 5.1.1. Intent Ingestion and Interaction with Users
The first set of functions is concerned with "ingesting" intent, The first set of functions is concerned with "ingesting" intent,
i.e., obtaining intent through interactions with users. They provide i.e., obtaining intent through interactions with users. They provide
functions that recognize intent from interaction with the user as functions that recognize intent from interaction with the user as
well as functions that allow users to refine their intent and well as functions that allow users to refine their intent and
articulate it in such ways so that it becomes actionable by an articulate it in such ways so that it becomes actionable by an IBS.
Intent-Based System. Typically, those functions go beyond those Typically, those functions go beyond those provided by a non-intent-
provided by a traditional API, although APIs may still be provided based API, although non-intent-based APIs may also still be provided
(and needed for interactions beyond human users, i.e., with other (and needed for interactions beyond human users, i.e., with other
machines). Many cases would also involve a set of intuitive and machines). Many cases would also involve a set of intuitive and
easy-to-navigate workflows that guide users through the intent easy-to-navigate workflows that guide users through the intent
ingestion phase, making sure that all inputs that are necessary for ingestion phase, making sure that all inputs that are necessary for
intent modeling and consecutive translation have been gathered. They intent modeling and consecutive translation have been gathered. They
may support unconventional human-machine interactions, in which a may support unconventional human-machine interactions, in which a
human will not simply give simple commands but which may involve a human will not simply give commands but instead a human-machine
human-machine dialog to provide clarifications, to explain dialog is used to provide clarifications, to explain ramifications
ramifications and trade-offs, and to facilitate refinements. and trade-offs, and to facilitate refinements.
The goal is ultimately to make IBSs as easy and natural to use and The goal is ultimately to make IBSs as easy and natural to use and
interact with as possible, in particular allowing human users to interact with as possible, in particular allowing human users to
interact with the IBS in ways that do not involve a steep learning interact with the IBS in ways that do not involve a steep learning
curve that forces the user to learn the "language" of the system. curve that forces the user to learn the "language" of the system.
Ideally, it will be the Intent-Based Systems that is increasingly be Ideally, it will be the IBSs that are increasingly able to learn how
able to learn how to understand the user as opposed to the other way to understand the user, as opposed to the other way around. Of
round. Of course, further research will be required to make this a course, further research will be required to make this a reality.
reality.
5.1.2. Intent Translation 5.1.2. Intent Translation
A second set of functions needs to translate user intent into courses A second set of functions needs to translate user intent into courses
of action and requests to take against the network, which will be of action and requests to take against the network, which will be
meaningful to network configuration and provisioning systems. These meaningful to network configuration and provisioning systems. These
functions lie at the core of IBS, bridging the gap between functions lie at the core of IBS, bridging the gap between
interaction with users on the one hand and the traditional management interaction with users on the one hand and the management and
and operations side that will need to orchestrate provisioning and operations side that will need to orchestrate provisioning and
configuration across the network. configuration across the network.
Beyond merely breaking down a higher layer of abstraction (intent) Beyond merely breaking down a higher layer of abstraction (intent)
into a lower layer of abstraction (policies, device configuration), into a lower layer of abstraction (policies and device
Intent Translation functions can be complemented with functions and configuration), Intent Translation functions can be complemented with
algorithms that perform optimizations and that are able to learn and functions and algorithms that perform optimizations and that are able
improve over time in order to result in the best outcomes, to learn and improve over time in order to result in the best
specifically in cases where multiple ways of achieving those outcomes outcomes, specifically in cases where multiple ways of achieving
are conceivable. For example, satisfying an intent may involve those outcomes are conceivable. For example, satisfying an intent
computation of paths and other parameters that will need to be may involve computation of paths and other parameters that will need
configured across the network. Heuristics and algorithms to do so to be configured across the network. Heuristics and algorithms to do
may evolve over time to optimize outcomes that may depend on a myriad so may evolve over time to optimize outcomes that may depend on a
of dynamic network conditions and context. myriad of dynamic network conditions and context.
5.1.3. Intent Orchestration 5.1.3. Intent Orchestration
A third set of functions deals with the actual configuration and A third set of functions deals with the actual configuration and
provisioning steps that need to be orchestrated across the network provisioning steps that need to be orchestrated across the network
and that were determined by the previous intent translation step. and that were determined by the previous intent translation step.
5.2. Intent Assurance 5.2. Intent Assurance
Intent assurance is concerned with the functions that are necessary Intent Assurance is concerned with the functions that are necessary
to ensure that the network indeed complies with the desired intent to ensure that the network indeed complies with the desired intent
once it has been fulfilled. once it has been fulfilled.
5.2.1. Monitoring 5.2.1. Monitoring
A first set of assurance functions monitors and observes the network A first set of assurance functions monitors and observes the network
and its exhibited behavior. This includes all the usual assurance and its exhibited behavior. This includes all the usual assurance
functions such as monitoring the network for events and performance functions such as monitoring the network for events and performance
outliers, performing measurements to assess service levels that are outliers, performing measurements to assess service levels that are
being delivered, generating and collecting telemetry data. being delivered, and generating and collecting telemetry data.
Monitoring and observation are required as the basis for the next set Monitoring and observation are required as the basis for the next set
of functions that assess whether the observed behavior is in fact in of functions that assess whether the observed behavior is in fact in
compliance with the behavior that is expected based on the intent. compliance with the behavior that is expected based on the intent.
5.2.2. Intent Compliance Assessment 5.2.2. Intent Compliance Assessment
At the core of Intent Assurance are functions that compare the actual At the core of Intent Assurance are functions that compare the actual
network behavior that is being monitored and observed with the network behavior that is being monitored and observed with the
intended behavior that is expected per the intent and is held by intended behavior that is expected per the intent and is held by
SSoT. These functions continuously assess and validate whether the SSoT. These functions continuously assess and validate whether the
skipping to change at page 21, line 39 skipping to change at line 970
assessing the effectiveness of intent fulfillment actions, including assessing the effectiveness of intent fulfillment actions, including
verifying that the actions had the desired effect and assessing the verifying that the actions had the desired effect and assessing the
magnitude of the effect as applicable. It can also include functions magnitude of the effect as applicable. It can also include functions
that perform analysis and aggregation of raw observation data. The that perform analysis and aggregation of raw observation data. The
results of the assessment can be fed back to facilitate learning results of the assessment can be fed back to facilitate learning
functions that optimize outcomes. functions that optimize outcomes.
Intent compliance assessment also includes assessing whether intent Intent compliance assessment also includes assessing whether intent
drift occurs over time. Intent drift can be caused by a control drift occurs over time. Intent drift can be caused by a control
plane or lower-level management operations that inadvertently cause plane or lower-level management operations that inadvertently cause
behavior changes which conflict with intent that was orchestrated behavior changes that conflict with intent that was orchestrated
earlier. Intent-Based Systems and Networks need to be able to detect earlier. IBSs and Networks need to be able to detect when such drift
when such drift occurs or is about to occur as well as assess the occurs or is about to occur as well as assess the severity of the
severity of the drift. drift.
5.2.3. Intent Compliance Actions 5.2.3. Intent Compliance Actions
When intent drift occurs or network behavior is inconsistent with When intent drift occurs or network behavior is inconsistent with
desired intent, functions that are able to trigger corrective actions desired intent, functions that are able to trigger corrective actions
are needed. This includes actions needed to resolve intent drift and are needed. This includes actions needed to resolve intent drift and
bring the network back into compliance. Alternatively, and where bring the network back into compliance. Alternatively, and where
necessary, reporting functions need to be triggered that alert necessary, reporting functions need to be triggered that alert
operators and provide them with the necessary information and tools operators and provide them with the necessary information and tools
to react appropriately, e.g., by helping them articulate to react appropriately, e.g., by helping them articulate
skipping to change at page 22, line 21 skipping to change at line 1001
This requires a set of functions that are able to analyze, aggregate, This requires a set of functions that are able to analyze, aggregate,
and abstract the results of the observations accordingly. In many and abstract the results of the observations accordingly. In many
cases, lower-level concepts such as detailed performance statistics cases, lower-level concepts such as detailed performance statistics
and observations related to low-level settings need to be "up- and observations related to low-level settings need to be "up-
leveled" to concepts the user can relate to and take action on. leveled" to concepts the user can relate to and take action on.
The required aggregation and analysis functionality needs to be The required aggregation and analysis functionality needs to be
complemented with functions that report intent compliance status and complemented with functions that report intent compliance status and
provide adequate summarization and visualization to human users. provide adequate summarization and visualization to human users.
6. Lifecycle 6. Life Cycle
Intent is subject to a lifecycle: it comes into being, may undergo Intent is subject to a life cycle: it comes into being, may undergo
changes over the course of time, and may at some point be retracted. changes over the course of time, and may at some point be retracted.
This lifecycle is closely tied to various interconnection functions This life cycle is closely tied to various interconnection functions
that are associated with the intent concept. that are associated with the intent concept.
Figure 1 depicts an intent lifecycle and its main functions. The Figure 1 depicts an intent life cycle and its main functions. The
functions were introduced in Section 5 and are divided into two functions were introduced in Section 5 and are divided into two
functional (horizontal) planes, reflecting the distinction between functional (horizontal) planes reflecting the distinction between
fulfillment and assurance. In addition, they are divided into three fulfillment and assurance. In addition, they are divided into three
(vertical) spaces. (vertical) spaces.
The spaces indicate the different perspectives and interactions with The spaces indicate the different perspectives and interactions with
different roles that are involved in addressing the functions: different roles that are involved in addressing the functions:
* The User Space involves the functions that interface the network * The User Space involves the functions that interface the network
and intent-based system with the human user. It involves the and IBS with the human user. It involves the functions that allow
functions that allow users to articulate and the intent-based users to articulate and the IBS to recognize that intent. It also
system to recognize that intent. It also involves the functions involves the functions that report back the status of the network
that report back the status of the network relative to the intent relative to the intent and that allow users to assess outcomes and
and that allow users to assess outcomes and whether their intent whether their intent has the desired effect.
has the desired effect.
* The Translation, or Intent-Based System (IBS) Space involves the * The Translation, or Intent-Based System (IBS) Space involves the
functions that bridge the gap between intent users and the network functions that bridge the gap between intent users and the network
operations infrastructure. This includes the functions used to operations infrastructure. This includes the functions used to
translate an intent into a course of action as well as the translate an intent into a course of action as well as the
algorithms that are used to plan and optimize those courses of algorithms that are used to plan and optimize those courses of
action also in consideration of feedback and observations from the action also in consideration of feedback and observations from the
network. It also includes the functions to analyze and aggregate network. It also includes the functions to analyze and aggregate
observations from the network in order to validate compliance with observations from the network in order to validate compliance with
the intent and to take corrective actions as necessary. In the intent and to take corrective actions as necessary. In
addition, it includes functions that abstract observations from addition, it includes functions that abstract observations from
the network in ways that relate them to the intent as communicated the network in ways that relate them to the intent as communicated
by users. This facilitates the reporting functions in the user by users. This facilitates the reporting functions in the user
space. space.
* The Network Operations Space, finally, involves the traditional * The Network Operations Space, finally, involves orchestration,
orchestration, configuration, monitoring, and measurement configuration, monitoring, and measurement functions, which are
functions, which are used to effectuate the rendered intent and used to effectuate the rendered intent and observe its effects on
observe its effects on the network. the network.
User Space : Translation / IBS : Network Ops User Space : Translation / IBS : Network Ops
: Space : Space : Space : Space
: : : :
+----------+ : +----------+ +-----------+ : +-----------+ +----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision | |generate | | | | plan/ | | provision |
|intent |<--- | refine | | render | : | | |intent |<--- | refine | | render | : | |
+----^-----+ : +----------+ +-----^-----+ : +-----------+ +----^-----+ : +----------+ +-----^-----+ : +-----------+
| : | : | | : | : |
.............|................................|................|..... .............|................................|................|.....
| : +----+---+ : v | : +----+---+ : v
| : |validate| : +----------+ | : |validate| : +----------+
| : +----^---+ <----| monitor/ | | : +----^---+ <----| monitor/ |
Assure +---+---+ : +---------+ +-----+---+ : | observe/ | Assure +---+---+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| | |report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+ +-------+ : +---------+ |aggregate| : +----------+
: +---------+ : : +---------+ :
Figure 1: Intent Lifecycle Figure 1: Intent Life Cycle
When carefully inspecting the diagram, it becomes apparent that the When carefully inspecting the diagram, it becomes apparent that the
intent lifecycle, in fact, involves two cycles, or loops: intent life cycle, in fact, involves two cycles, or loops:
* The "inner" intent control loop between IBS and Network Operations * The "inner" intent control loop between IBS and Network Operations
space is completely autonomic and does not involve any human in space is completely autonomic and does not involve any human in
the loop. It represents closed-loop automation that involves the loop. It represents closed-loop automation that involves
automatic analysis and validation of intent based on observations automatic analysis and validation of intent based on observations
from the network operations space. Those observations are fed from the network operations space. Those observations are fed
into the function that plans the rendering of networking intent in into the function that plans the rendering of networking intent in
order to make adjustments as needed in the configuration of the order to make adjustments as needed in the configuration of the
network. The loop addresses and counteracts any intent drift that network. The loop addresses and counteracts any intent drift that
may be occuring, using observations to assess the degree of the may be occurring, using observations to assess the degree of the
network's intent compliance and automatically prompting actions to network's intent compliance and automatically prompting actions to
address any discrepancies. Likewise, the loop allows to assess address any discrepancies. Likewise, the loop allows to assess
the effectiveness of any actions that are taken in order to the effectiveness of any actions that are taken in order to
continuously learn and improve how intent needs to be rendered in continuously learn and improve how intent needs to be rendered in
order to achieve the desired outcomes. order to achieve the desired outcomes.
* The "outer" intent control loop extends to the user space. It * The "outer" intent control loop extends to the user space. It
includes the user taking action and adjusting their intent based includes the user taking action and adjusting their intent based
on observations and feedback from the IBS. Intent is thus on observations and feedback from the IBS. Intent is thus
subjected to a lifecycle: It comes into being, may undergo subjected to a life cycle: It comes into being, may undergo
refinements, modifications, and changes of time, and may at some refinements, modifications, and changes of time, and may at some
point in time even get retracted. point in time even get retracted.
7. Additional Considerations 7. Additional Considerations
Given the popularity of the term "intent," it is tempting to broaden Given the popularity of the term "intent," it is tempting to broaden
it use to encompass also other related concepts, resulting in its use to encompass other related concepts, resulting in "intent-
"intent-washing" that paints those concepts in a new light by simply washing" that paints those concepts in a new light by simply applying
applying new intent terminology to them. A common example concerns new intent terminology to them. A common example concerns referring
referring to the northbound interface of SDN controllers as "intent to the northbound interface of SDN controllers as "intent interface."
interface". However, in some cases, this actually makes sense not However, in some cases, this actually makes sense not just as a
just as a marketing ploy but as a way to better relate previously marketing ploy but as a way to better relate previously existing and
existing and new concepts. new concepts.
In that sense and regards to intent, it makes sense to distinguish In that sense and with regards to intent, it makes sense to
various subcategories of intent as follows: distinguish various subcategories of intent as follows:
* Operational Intent: defines intent related to operational goals of Operational Intent: defines intent related to operational goals of
an operator; corresponds to the original "intent" term and the an operator; it corresponds to the original "intent" term and the
concepts defined in this document. concepts defined in this document.
* Rule Intent: a synonym for policy rules regarding what to do when Rule Intent: a synonym for policy rules regarding what to do when
certain events occur. certain events occur.
* Service intent: a synonym for customer service model [RFC8309]. Service Intent: a synonym for customer service model [RFC8309].
* Flow Intent: A synonym for a Service Level Objective for a given Flow Intent: a synonym for a Service Level Objective for a given
flow. flow.
A comprehensive set of classifications of different concepts and A comprehensive set of classifications of different concepts and
categories of intent will be described in a separate document. categories of intent will be described in a separate document.
8. IANA Considerations 8. IANA Considerations
Not applicable This document has no IANA actions.
9. Security Considerations 9. Security Considerations
This document describes concepts and definitions of Intent-Based This document describes concepts and definitions of Intent-Based
Networking. As such, the below security considerations remain high Networking. As such, the below security considerations remain high
level, i.e. in the form of principles, guidelines or requirements. level, i.e., in the form of principles, guidelines, or requirements.
More detailed security considerations will be described in the More detailed security considerations will be described in the
documents that specify the architecture and functionality. documents that specify the architecture and functionality.
Security in Intent-Based Networking can apply to different facets: Security in Intent-Based Networking can apply to different facets:
* Securing the intent-based system itself. * Securing the IBS itself.
* Mitigating the effects of erroneous, harmful or compromised * Mitigating the effects of erroneous, harmful, or compromised
intents. intent statements.
* Expressing security policies or security-related parameters with * Expressing security policies or security-related parameters with
intents. intent statements.
Securing the intent-based system aims at making the intent-based Securing the IBS aims at making the IBS operationally secure by
system operationally secure by implementing security mechanisms and implementing security mechanisms and applying security best
applying security best practices. In the context of Intent-based practices. In the context of Intent-Based Networking, such
Networking, such mechanisms and practices may consist in intent mechanisms and practices may consist of intent verification and
verification and validation; operations on intents by authenticated validation, operations on intent by authenticated and authorized
and authorized users only; protection against or detection of users only, and protection against or detection of tampered
tampered intents. Such mechanisms may also include the introduction statements of intent. Such mechanisms may also include the
of multiple levels of intent. For example, intent related to introduction of multiple levels of intent. For example, intent
securing the network should occur at a "deeper" level that overrides related to securing the network should occur at a "deeper" level that
other levels of intent if necessary, and that is not subject to overrides other levels of intent if necessary, and that is not
modification through regular operations but through ones that are subject to modification through regular operations but through ones
specifically secured. Use of additional mechanisms such as that are specifically secured. Use of additional mechanisms such as
explanation components that describe the security ramifications and explanation components that describe the security ramifications and
trade-off should be considered as well. trade-offs should be considered as well.
Mitigating the effects of erroneous or compromised intents aims at Mitigating the effects of erroneous or compromised statements of
making the intent-based system operationally safe by providing intent aims at making the IBS operationally safe by providing
checkpoint and safeguard mechanisms and operating principles. In the checkpoint and safeguard mechanisms and operating principles. In the
context of Intent-based Networking, such mechanisms and principles context of Intent-Based Networking, such mechanisms and principles
may consist in the ability to automatically detect unintended, may consist of the ability to automatically detect unintended,
detrimental or abnormal behavior; the ability to automatically (and detrimental, or abnormal behavior; the ability to automatically (and
gracefully) rollback or fallback to a previous "safe" state; the gracefully) roll back or fall back to a previous "safe" state; the
ability to prevent or contain error amplification (due to the ability to prevent or contain error amplification (due to the
combination of a higher degree of automation and the intrinsic higher combination of a higher degree of automation and the intrinsic higher
degree of freedom, ambiguity, and implicitly conveyed by intents); degree of freedom, ambiguity, and implicit information conveyed by
dynamic levels of supervision and reporting to make the user aware of intent statements); and dynamic levels of supervision and reporting
the right information, at the right time with the right level of to make the user aware of the right information at the right time
context. Erroneous or harmful intents may inadvertently propagate with the right level of context. Erroneous or harmful intent
and compromise security. In addition, compromised intents, for statements may inadvertently propagate and compromise security. In
example, intent forged by an inside attacker, may sabotage or harm addition, compromised intent statements (for example, forged by an
the network resources and make them vulnerable to further, larger inside attacker) may sabotage or harm the network resources and make
attacks, e.g., by defeating certain security mechanisms. them vulnerable to further, larger attacks, e.g., by defeating
certain security mechanisms.
Expressing security policies or security-related parameters with Expressing security policies or security-related parameters as intent
intents consists of using the intent formalism (a high-level, consists of using the intent formalism (a high-level, declarative
declarative abstraction), or part(s) of an intent statement to define abstraction) or part(s) of an intent statement to define security-
security-related aspects such as data governance, level(s) of related aspects such as:
confidentiality in data exchange, level(s) of availability of system
resources, of protection in forwarding paths, of isolation in * data governance;
processing functions, level(s) of encryption, authorized entities for
given operations, etc. * level(s) of confidentiality in data exchange;
* level(s) of availability of system resources, of protection in
forwarding paths, and of isolation in processing functions;
* level(s) of encryption; and
* authorized entities for given operations.
The development and introduction of Intent-Based Networking in The development and introduction of Intent-Based Networking in
operational environments will certainly create new security concerns. operational environments will certainly create new security concerns.
Such security concerns have to be anticipated at the design and Such security concerns have to be anticipated at the design and
specification time. However, Intent-Based Networking may also be specification time. However, Intent-Based Networking may also be
used as an enabler for better security. For instance, security and used as an enabler for better security. For instance, security and
privacy rules could be expressed in a more human-friendly and generic privacy rules could be expressed in a more human-friendly and generic
way and be less technology-specific and less complex, leading to way and be less technology specific and less complex, leading to
fewer low-level configuration mistakes. The detection of threats or fewer low-level configuration mistakes. The detection of threats or
attacks could also be made more simple and comprehensive thanks to attacks could also be made more simple and comprehensive thanks to
conflict detection at higher-level or at coarser granularity conflict detection at higher level or at coarser granularity.
More thorough security analyses should be conducted as our More thorough security analyses should be conducted as our
understanding of Intent-Based Networking technology matures. understanding of Intent-Based Networking technology matures.
10. Acknowledgments 10. Informative References
We would like to thank the members of the IRTF Network Management
Research Group (NMRG) for many valuable discussions and feedback. In
particular, we would like to acknowledge the feedback and support
from Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis
Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li,
William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu
Song, Peter Szilagyi, and Csaba Vulkan. Of those, we would like to
thank the following persons who went one step further and also
provided reviews of the document: Remi Badonnel, Walter Cerroni,
Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje,
Peter Szilagyi, and Csaba Vulkan.
11. Informative References
[Boutaba07] [BOUTABA07]
Boutaba, R. and I. Aib, "Policy-Based Management: A Boutaba, R. and I. Aib, "Policy-Based Management: A
Historical perspective. Journal of Network and Systems Historical Perspective", Journal of Network and Systems
Management (JNSM), Springer, Vol. 15 (4).", December 2007. Management (JNSM), Vol. 15, Issue 4,
DOI 10.1007/s10922-007-9083-8, November 2007,
<https://doi.org/10.1007/s10922-007-9083-8>.
[Clemm20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network [CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network
Management 2030: Operations and Control of Network 2030 Management 2030: Operations and Control of Network 2030
Services. Journal of Network and Systems Management Services", Journal of Network and Systems Management
(JNSM), Springer, Vol. 28 (4).", October 2020. (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0,
October 2020,
<https://doi.org/10.1007/s10922-020-09517-0>.
[Gharbaoui21] [GHARBAOUI21]
Gharbaoui, M., Martini, B., and P. Castoldi, Gharbaoui, M., Martini, B., and P. Castoldi,
""Implementation of an Intent Layer for SDN-enabled and "Implementation of an Intent Layer for SDN-enabled and
QoS-aware Network Slicing", in IEEE 7th Int. Conference on QoS-Aware Network Slicing", 2021 IEEE 7th International
Network Softwarization (NetSoft), pp 17-23, doi: 10.1109/ Conference on Network Softwarization (NetSoft), pp. 17-23,
NetSoft51509.2021.9492643", June 2021. DOI 10.1109/NetSoft51509.2021.9492643, June 2021,
<https://doi.org/10.1109/NetSoft51509.2021.9492643>.
[I-D.ietf-teas-ietf-network-slice-definition]
Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and
J. Tantsura, "Definition of IETF Network Slices", Work in
Progress, Internet-Draft, draft-ietf-teas-ietf-network-
slice-definition-01, 22 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
network-slice-definition-01.txt>.
[I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D.,
and J. Tantsura, "Traffic Engineering (TE) and Service
Mapping YANG Model", Work in Progress, Internet-Draft,
draft-ietf-teas-te-service-mapping-yang-10, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-te-
service-mapping-yang-10.txt>.
[IEEE-TITS21] [IEEE-TITS21]
Garg, S., "Special Issue on Intent-Based Networking for Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad,
5G-Envisioned Internet of Connected Vehicles, in IEEE N., and R. R. V. Prasad, "Guest Editorial Special Issue on
Transactions on Intelligent Transportation Systems, vol. Intent-Based Networking for 5G-Envisioned Internet of
22, no. 8, DOI: 10.1109/TITS.2021.3101259", August 2021. Connected Vehicles", IEEE Transactions on Intelligent
Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017,
DOI 10.1109/TITS.2021.3101259, August 2021,
<https://doi.org/10.1109/TITS.2021.3101259>.
[IEEEXPLORE] [IEEEXPLORE]
IEEE, "IEEE eXplore, https://ieeexplore.ieee.org/", 2021. IEEE, "IEEE Xplore", <https://ieeexplore.ieee.org/>.
[Lenrow15] Lenrow, D., "Intent As The Common Interface to Network [LENROW15] Lenrow, D., "Intent As The Common Interface to Network
Resources, Intent Based Network Summit 2015 ONF Boulder: Resources", Intent Based Network Summit 2015 ONF Boulder:
IntentNBI", February 2015. IntentNBI, February 2015.
[M3010] ITU-T, "M.3010 : Principles for a telecommunications [M3010] ITU-T, "Principles for a telecommunications management
management network.", February 2000. network", ITU-T Recommendation M.3010, February 2000.
[MDPI22] Gharbaoui, M., "Special Issue "Intent-Based Software- [MDPI22] Gharbaoui, M., Ed., "Special Issue "Intent-Based Software-
Defined Networks", in Computers (MDPI) (to appear)", 2022. Defined Networks"", Computers (MDPI), 2022.
[Pang20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A [NETWORK-SLICE]
Survey on Intent-Driven Networks", in IEEE Access Vol 8 Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
pp. 22862-22873, DOI: 10:110/ACCESS.2020.2969208", 2020. Makhijani, K., Contreras, L. M., and J. Tantsura,
"Framework for IETF Network Slices", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3
August 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-ietf-network-slices-14>.
[PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A
Survey on Intent-Driven Networks", IEEE Access, Vol. 8,
pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January
2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002, DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>. <https://www.rfc-editor.org/info/rfc3411>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994, Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>. <https://www.rfc-editor.org/info/rfc8994>.
[Sloman94] Sloman, M., "Policy Driven Management for Distributed [SERVICE-MAPPING-YANG]
Systems. Journal of Network and Systems Management (JNSM), Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q.,
Springer, Vol. 2 (4).", December 1994. Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering
(TE) and Service Mapping YANG Data Model", Work in
Progress, Internet-Draft, draft-ietf-teas-te-service-
mapping-yang-11, 11 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-
service-mapping-yang-11>.
[Strassner03] [SLOMAN94] Sloman, M., "Policy Driven Management for Distributed
Strassner, J., "Policy-Based Network Management. Systems", Journal of Network and Systems Management
Elsevier.", 2003. (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.
[TR523] Foundation, O. N., "Intent NBI - Definition and [STRASSNER03]
Principles. ONF TR-523.", October 2016. Strassner, J., "Policy-Based Network Management", August
2003.
[WIN21] Ciavaglia, L. and E. Renault, "1st IEEE International [TR523] Open Networking Foundation, "Intent NBI - Definition and
Workshop on Intent-Based Networking, Principles", ONF TR-523, October 2016.
https://netsoft2021.ieee-netsoft.org/program/workshops/
win-2021/", June 2021. [WIN21] Ciavaglia, L. and E. Renault, "1st International Workshop
on Intent-Based Networking", IEEE International Conference
on Network Softwarization, June 2021,
<https://netsoft2021.ieee-netsoft.org/program/workshops/
win-2021/>.
Acknowledgments
We would like to thank the members of the IRTF Network Management
Research Group (NMRG) for many valuable discussions and feedback. In
particular, we would like to acknowledge the feedback and support
from Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis
Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li,
William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu
Song, Peter Szilagyi, and Csaba Vulkan. Of those, we would like to
thank the following persons who went one step further and also
provided reviews of the document: Remi Badonnel, Walter Cerroni,
Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje,
Peter Szilagyi, and Csaba Vulkan.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara,, CA 95050 Santa Clara, CA 95050
United States of America United States of America
Email: ludwig@clemm.org Email: ludwig@clemm.org
Laurent Ciavaglia Laurent Ciavaglia
Rakuten Mobile Nokia
Email: laurent.ciavaglia@rakuten.com Route de Villejust
91620 Nozay
France
Email: laurent.ciavaglia@nokia.com
Lisandro Zambenedetti Granville Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves Av. Bento Gonçalves
Porto Alegre- Porto Alegre-RS
9500 9500
Brazil Brazil
Email: granville@inf.ufrgs.br Email: granville@inf.ufrgs.br
Jeff Tantsura Jeff Tantsura
Microsoft Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 155 change blocks. 
504 lines changed or deleted 533 lines changed or added

This html diff was produced by rfcdiff 1.48.