rfc9315xml2.original.xml   rfc9315.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<?rfc comments="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc compact="no"?> <!ENTITY nbhy "&#8209;">
<?rfc inline="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="info" docName="draft-irtf-nmrg-ibn-concepts-definitions-09" ipr="
trust200902">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-nmrg-ibn-con
<title abbrev="">Intent-Based Networking - Concepts and Definitions</title> cepts-definitions-09" number="9315" ipr="trust200902" obsoletes="" updates="" su
bmissionType="IRTF" category="info" consensus="true" xml:lang="en" sortRefs="tru
e" symRefs="true" tocInclude="true" tocDepth="5" version="3">
<author fullname="Alexander Clemm" initials="A." <front>
surname="Clemm"> <title abbrev="Intent-Based Networking - Overview">Intent-Based Networking -
<organization>Futurewei</organization> Concepts and Definitions</title>
<address> <seriesInfo name="RFC" value="9315"/>
<author fullname="Alexander Clemm" initials="A." surname="Clemm">
<organization>Futurewei</organization>
<address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>2330 Central Expressway</street>
<city>Santa Clara,</city> <city>Santa Clara</city>
<country>USA</country> <code>95050</code>
<code>CA 95050</code> <region>CA</region>
<country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<email>ludwig@clemm.org</email> <email>ludwig@clemm.org</email>
</address> </address>
</author> </author>
<author fullname="Laurent Ciavaglia" initials="L"
surname="Ciavaglia">
<organization>Rakuten Mobile</organization>
<address>
<email>laurent.ciavaglia@rakuten.com</email>
</address>
</author>
<author fullname="Lisandro Zambenedetti Granville" initials="L. Z." <author fullname="Laurent Ciavaglia" initials="L" surname="Ciavaglia">
surname="Granville"> <organization>Nokia</organization>
<organization>Federal University of Rio Grande do Sul (UFRGS)</organization> <address>
<address> <postal>
<postal> <street>Route de Villejust</street>
<street>Av. Bento Gonçalves</street> <code>91620</code>
<code>9500</code> <city>Nozay</city>
<city>Porto Alegre</city> <country>France</country>
<country>BR</country> </postal>
</postal> <email>laurent.ciavaglia@nokia.com</email>
<email>granville@inf.ufrgs.br</email> </address>
</address> </author>
</author>
<author fullname="Jeff Tantsura" initials="J" <author fullname="Lisandro Zambenedetti Granville" initials="L. Z." surname=
surname="Tantsura"> "Granville">
<organization>Microsoft</organization> <organization>Federal University of Rio Grande do Sul (UFRGS)</organizatio
<address> n>
<email>jefftant.ietf@gmail.com</email> <address>
</address> <postal>
</author> <street>Av. Bento Gonçalves</street>
<date month="March" year="2022" /> <code>9500</code>
<city>Porto Alegre</city>
<region>RS</region>
<country>Brazil</country>
</postal>
<email>granville@inf.ufrgs.br</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Microsoft</organization>
<address>
<email>jefftant.ietf@gmail.com</email>
</address>
</author>
<date month="October" year="2022"/>
<abstract> <workgroup>Network Management</workgroup>
<t>
Intent and Intent-Based Networking (IBN) are taking the industry
by storm. At the same time, IBN-related terms are
often used loosely and inconsistently, in many cases overlapping and con
fused with other concepts such as "Policy."
This document clarifies the concept of "Intent" and provides an overview of
the functionality that is associated with it.
The goal is to contribute towards a common and shared understanding of terms
, concepts, and functionality that can be used as the foundation to guide furthe
r definition of associated research and engineering problems and their solutions
.
</t>
<t>
This document is a product of the IRTF Network Management Research Group (NM
RG).
It reflects the consensus of the research group, having received many detail
ed and positive reviews by RG participants. It is published for informational p
urposes.
</t>
</abstract>
</front> <keyword>Autonomic networking</keyword>
<keyword>Network management</keyword>
<keyword>Intent-based management</keyword>
<keyword>Intent-based management</keyword>
<keyword>Policy-based management</keyword>
<keyword>policy</keyword>
<keyword>policy-based network management</keyword>
<keyword>abstraction</keyword>
<middle> <abstract>
<section anchor="intro" title="Introduction"> <t>
<t> Intent and Intent-Based Networking are taking the industry by
storm. At the same time, terms related to Intent-Based Networkin
g are often used
loosely and inconsistently, in many cases overlapping and
confused with other concepts such as "policy." This document
clarifies the concept of "intent" and provides an overview of
the functionality that is associated with it. The goal is to
contribute towards a common and shared understanding of terms,
concepts, and functionality that can be used as the foundation
to guide further definition of associated research and
engineering problems and their solutions.
</t>
<t>
This document is a product of the IRTF Network Management Research Group (NM
RG).
It reflects the consensus of the research group, having received many detail
ed and positive reviews by research group participants. It is published for inf
ormational purposes.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
This document is a product of the IRTF Network Management Research Group (NM RG). This document is a product of the IRTF Network Management Research Group (NM RG).
It reflects the consensus of the RG, receiving reviews and explicit support from many participants. It is published for informational purposes. It reflects the consensus of the RG, receiving reviews and explicit support from many participants. It is published for informational purposes.
</t> </t>
<t> <t>
In the past, interest regarding management and operations in the IETF has foc used on individual network and device features. Standardization emphasis has gen erally been put on management instrumentation that needed to be provided to a ne tworking device. In the past, interest regarding management and operations in the IETF has foc used on individual network and device features. Standardization emphasis has gen erally been put on management instrumentation that needed to be provided to a ne tworking device.
A prime example of this is SNMP-based management <xref target= "RFC3411"/> a A prime example of this is SNMP-based management <xref target="RFC3411" form
nd the 200+ MIBs that have been defined by the IETF over the years. More recent at="default"/> and the 200+ MIBs that have been defined by the IETF over the yea
examples include YANG data model definitions <xref target="RFC7950"/> for aspect rs. More recent examples include YANG data model definitions <xref target="RFC79
s such as interface configuration, ACL configuration, and Syslog configuration. 50" format="default"/> for aspects such as interface configuration, Access Contr
</t> ol List (ACL) configuration, and Syslog configuration.
<t> </t>
<t>
There is a clear sense and reality that managing networks by configuring myr iads of "nerd knobs" on a device-by-device basis is no longer an option in moder n network environments. There is a clear sense and reality that managing networks by configuring myr iads of "nerd knobs" on a device-by-device basis is no longer an option in moder n network environments.
Significant challenges arise with keeping device configurations not only con sistent across a network but also consistent with the needs of services and serv ice features they are supposed to enable. Additional challenges arise with regar d to being able to rapidly adapt the network as needed and to be able to do so a t scale. Significant challenges arise with keeping device configurations not only con sistent across a network but also consistent with the needs of services and serv ice features they are supposed to enable. Additional challenges arise with regar d to being able to rapidly adapt the network as needed and to be able to do so a t scale.
At the same time, operations need to be streamlined and automated wherever p ossible to not only lower operational expenses but also allow for rapid reconfig uration of networks at sub-second time scales and to ensure that networks are de livering their functionality as expected. Among other things, this requires the ability to consume operational data, perform analytics, and dynamically take ac tions in a way that is aware of context as well as intended outcomes at near rea l-time speeds. At the same time, operations need to be streamlined and automated wherever p ossible to not only lower operational expenses but also allow for rapid reconfig uration of networks at sub-second time scales and to ensure that networks are de livering their functionality as expected. Among other things, this requires the ability to consume operational data, perform analytics, and dynamically take ac tions in a way that is aware of context as well as intended outcomes at near rea l-time speeds.
</t> </t>
<t>
Accordingly, the IETF has begun to address end-to-end management aspects tha <t>
t go beyond the realm of individual devices in isolation. Accordingly, the IETF has begun to address end-to-end management aspects
Examples include the definition of YANG models for network topology <xref ta that go beyond the realm of individual devices in isolation. Examples
rget="RFC8345"/> or the introduction of service models used by service orchestra include the definition of YANG models for network topology <xref
tion systems and controllers <xref target="RFC8309"/>. target="RFC8345" format="default"/> or the introduction of service models
Much of the interest has been fueled by the discussion about how to manage a used by service orchestration systems and controllers <xref
utonomic networks, target="RFC8309" format="default"/>. Much of the interest has been fueled
as discussed in the ANIMA working group. by the discussion about how to manage autonomic networks as discussed in
Autonomic networks are driven by the desire to lower operational expenses an the ANIMA Working Group. Autonomic networks are driven by the desire to
d make the management of the network as a whole more straightforward, putting it lower operational expenses and make the management of the network as a
at odds with the need to manage the network one device and one feature at a tim whole more straightforward, putting it at odds with the need to manage the
e. However, while autonomic networks are intended to exhibit "self-management" p network one device and one feature at a time. However, while autonomic
roperties, they still require input from an operator or outside system to provid networks are intended to exhibit "self-management" properties, they still
e operational guidance and information about the goals, require input from an operator or outside system to provide operational
purposes, and service instances that the network is to serve. guidance and information about the goals, purposes, and service instances
</t> that the network is to serve.
<t> </t>
This input and operational guidance are commonly referred to as "intent," and
networks that allow network operators to provide their input using intent as "I <t>
ntent-Based Networks" (IBN) and the systems that help implement intent as "Inten This input and operational guidance are commonly referred to as "intent,"
t-Based Systems" (IBS). Those systems can manifest themselves in a number of wa and a network that allows network operators to provide their input using
ys, for example as a controller or managemement system that are implemented as a intent is referred to as an "Intent-Based Network" (IBN), while a system
n application that runs on a server or set of servers, or as a set of functions that helps implement intent is referred to as an "Intent-Based System"
that are distributed across a network and that collectively perform their intent (IBS). Those systems can manifest themselves in a number of ways -- for
-based functionality. example, as a controller or management system that is implemented as an
</t> application that runs on a server or set of servers, or as a set of
<t> functions that are distributed across a network and that collectively
However, intent is about more than just enabling a form of operator interacti perform their intent-based functionality.
on with the network that involves higher-layer abstractions. It is also about t </t>
he ability to let operators focus on what they want their desired outcomes to be
while leaving details about how those outcomes would, in fact, be achieved to t <t>
he IBN (respectively IBS). This, in turn, enables much greater operational effi However, intent is about more than just enabling a form of operator inter
ciency at greater scale, in shorter time scales, with less dependency on human a action with the network that involves higher-layer abstractions.
ctivities (and possibility for mistakes), and an ideal candidate, e.g., for arti
ficial intelligence techniques that can bring about the next level of network au It is also about the ability to let operators focus on what they want
tomation <xref target="Clemm20"/>. their desired outcomes to be while leaving details to the IBN (respectively IBS)
</t> about how those outcomes would be achieved.
<t>
This vision has since caught on with the industry, leading to a significant Focusing on the outcome enables much greater operational efficiency and
number of solutions that offer Intent-Based Management that promise network prov flexibility at greater scale, in shorter time scales, and with less dependency o
iders to manage networks holistically at a higher level of abstraction and as a n
system that happens to consist of interconnected components, human activities (and therefore less possibility for mistakes). This also makes
as opposed to a set of independent devices (that happen to be interconnected Intent-Based Networking an ideal
). Those offerings include IBN and IBS (offering a full lifecycle of intent), S candidate for artificial intelligence techniques that can bring about the next
DN controllers (offering a single point of control and administration for a netw level of network automation <xref target="CLEMM20" format="default"/>.
ork), and network management and Operations Support Systems (OSS).
</t> </t>
<t>
<t>
This vision has since caught on with the industry, leading to a significant
number of solutions that offer Intent-Based Management that promise network prov
iders to manage networks holistically at a higher level of abstraction and as a
system that happens to consist of interconnected components
as opposed to a set of independent devices (that happen to be interconnected
). Those offerings include IBNs and IBSs (offering a full life cycle of intent)
, Software-Defined Network (SDN) controllers (offering a single point of control
and administration for a network), and network management and Operations Suppor
t Systems (OSSs).
</t>
<t>
It has been recognized for a long time that comprehensive management solutio ns cannot operate only at the level of individual devices and low-level configur ations. In this sense, the vision of intent is not entirely new. It has been recognized for a long time that comprehensive management solutio ns cannot operate only at the level of individual devices and low-level configur ations. In this sense, the vision of intent is not entirely new.
In the past, ITU-T's model of a Telecommunications Management Network (TMN) introduced a set of management layers that defined a management hierarchy, consi sting of network element, network, service, and business management <xref target =" M3010"/>. In the past, ITU-T's model of a Telecommunications Management Network (TMN) introduced a set of management layers that defined a management hierarchy consis ting of network element, network, service, and business management <xref target= "M3010" format="default"/>.
High-level operational objectives would propagate in a top-down fashion from upper to lower layers. The associated abstraction hierarchy was crucial to dec ompose management complexity into separate areas of concern. High-level operational objectives would propagate in a top-down fashion from upper to lower layers. The associated abstraction hierarchy was crucial to dec ompose management complexity into separate areas of concern.
This abstraction hierarchy was accompanied by an information hierarchy that concerned itself at the lowest level with device-specific information, but that would, at higher layers, include, for example, end-to-end service instances. This abstraction hierarchy was accompanied by an information hierarchy that concerned itself at the lowest level with device-specific information, but that would, at higher layers, include, for example, end-to-end service instances.
Similarly, the concept of Policy-Based Network Management (PBNM) has, for a Similarly, the concept of Policy-Based Network Management (PBNM) has, for a
long time, touted the ability to allow users to manage networks by specifying hi long time, touted the ability to allow users to manage networks by specifying hi
gh-level management policies, with policy systems automatically "rendering" thos gh-level management policies, with policy systems automatically "rendering" thos
e policies, i.e., breaking them down into low-level configurations and control l e policies, i.e., breaking them down into low-level configurations and control l
ogic. (As a note, in the context of this document, "users" generally refers to ogic.
operators and administrators who are responsible for the management and operatio </t>
n of communication services and networking infrastructures, not to "end users" o
f communication services.)
</t>
<t>What has been missing, however, is putting these concepts into a more cur
rent context and updating them to account for current technology trends. This
document clarifies the concepts behind intent. It differentiates intent from re
lated concepts. It also provides an overview of first-order principles of IBN a
s well as the associated functionality.
The goal is to contribute to a common and shared understanding that can be u
sed as a foundation to articulate research and engineering problems in the area
of IBN.
</t>
<t>It should be noted that the articulation of IBN-related research problems
is beyond the scope of this document. However, it should be recognized that
IBN has become an important topic in the research community. Per IEEE Xplor
e <xref target="IEEEXPLORE"/>, as of December 2021, in the past decade since 201
2, there have been 1138 papers with the index term "intent", of which 411 specif
ically mention networking. The time period since 2020 alone accounts for 316 pa
pers on intent and 153 for intent networking, indicating accelerating interest.
In addition, workshops dedicated to this theme are beginning to appear, such as
the IEEE International Workshop on Intent-Based Networking
<xref target="WIN21"/>, as well as various special journal issues <xref targ
et="IEEE-TITS21"/> <xref target="MDPI22"/>. A survey of current intent-driven n
etworking research has been published in <xref target="Pang20"/>, listing among
the most pressing current research challenges aspects such as intent translation
and understanding, intent interfaces, and security.
</t>
</section>
<section title="Definitions and Acronyms">
<t> <aside><t>As a note, in the context of this document, "users" generally re
<list style="empty"> fers to operators and administrators who are responsible for the management and
<t>ACL: Access Control List</t> operation of communication services and networking infrastructures, not to "end
<t>API: Application Programming Interface</t> users" of communication services.</t>
<t>Intent: A set of operational goals (that </aside>
a network should meet) and outcomes (that a network is supposed to
deliver), defined in a declarative manner without specifying how to achieve o
r implement them. </t>
<t>IBA: Intent-Based Analytics - Analytics that are defined and derived from
users' intent and used to validate the intended state.</t>
<t>Intent-Based Management - The concept of performing management based on t
he concept of intent. </t>
<t>IBN: Intent-Based Network - A network that can be managed using intent.</
t>
<t>IBS: Intent-Based System - A system that supports management functions th
at can be guided using intent.</t>
<t>PBNM: Policy-Based Network Management </t>
<t>Policy: A set of rules that governs the choices in behavior of a system.<
/t>
<t>PDP: Policy Decision Point</t>
<t>PEP: Policy Enforcement Point</t>
<t>Service Model: A model that represents a service that is provided by a ne
twork to a user.</t>
<t>SSoT: Single Source of Truth - A functional block in an IBN system that n
ormalizes users' intent and serves as the single source of data for the lower la
yers.</t>
<t>SVoT: Single Version of Truth</t>
<t>User: In the context of this document, an operator and/or administrator r
esponsible for the management and operation of communication services and networ
king infrastructure (as opposed to an end user of a communication service)</t>
</list>
</t>
</section>
<section title="Introduction of Concepts" anchor="Concepts"> <t>What has been missing, however, is putting these concepts into a more c
urrent context and updating them to account for current technology trends. Thi
s document clarifies the concepts behind intent. It differentiates intent from
related concepts. It also provides an overview of first-order principles of Int
ent-Based Networking as well as the associated functionality.
The goal is to contribute to a common and shared understanding that can be u
sed as a foundation to articulate research and engineering problems in the area
of Intent-Based Networking.
</t>
<t>It should be noted that the articulation of IBN-related research proble
ms is beyond the scope of this document. However, it should be recognized that
Intent-Based Networking has become an important topic in the research commun
ity. Per IEEE Xplore <xref target="IEEEXPLORE" format="default"/>, as of Decemb
er 2021, in the past decade since 2012, there have been 1138 papers with the ind
ex term "intent", of which 411 specifically mention networking. The time period
since 2020 alone accounts for 316 papers on intent and 153 for intent networkin
g, indicating accelerating interest. In addition, workshops dedicated to this t
heme are beginning to appear, such as the IEEE International Workshop on Intent-
Based Networking
<xref target="WIN21" format="default"/>, as well as various special journal
issues <xref target="IEEE-TITS21" format="default"/> <xref target="MDPI22" forma
t="default"/>. A survey of current intent-driven networking research has been p
ublished in <xref target="PANG20" format="default"/>, listing among the most pre
ssing current research challenges aspects such as intent translation and underst
anding, intent interfaces, and security.
</t>
</section>
<section numbered="true" toc="default">
<name>Definitions and Acronyms</name>
<t>The following section provides an overview of the concept of intent and Inten <dl newline="false" spacing="normal">
t-Based Management. It also provides an overview of the related concepts of ser <dt>ACL:</dt>
vice models and policies (and Policy-Based Network Management), and explains how <dd>Access Control List</dd>
they relate to intent and Intent-Based Management. <dt>API:</dt>
<dd>Application Programming Interface</dd>
<dt>IBA:</dt>
<dd>Intent-Based Analytics. Analytics that are defined and derived from user
s' intent and used to validate the intended state.</dd>
<dt>IBN:</dt>
<dd>Intent-Based Network. A network that can be managed using intent.</dd>
<dt>IBS:</dt>
<dd>Intent-Based System. A system that supports management functions that ca
n be guided using intent.</dd>
<dt>Intent:</dt>
<dd>A set of operational goals (that a network should meet) and outcomes (th
at a network is supposed to deliver) defined in a declarative manner without spe
cifying how to achieve or implement them.</dd>
<dt>Intent-Based Management:</dt>
<dd>The concept of performing management based on the concept of intent.</dd
>
<dt>PBNM:</dt>
<dd>Policy-Based Network Management</dd>
<dt>PDP:</dt>
<dd>Policy Decision Point</dd>
<dt>PEP:</dt>
<dd>Policy Enforcement Point</dd>
<dt>Policy:</dt>
<dd>A set of rules that governs the choices in behavior of a system.</dd>
<dt>Service Model:</dt>
<dd>A model that represents a service that is provided by a network to a use
r.</dd>
<dt>SSoT:</dt>
<dd>Single Source of Truth. A functional block in an IBN system that normali
zes users' intent and serves as the single source
of data for the lower layers.</dd>
<dt>Statement of Intent:</dt>
<dd>A specification of one particular aspect or component of intent, also re
ferred to as an intent statement.</dd>
<dt>SVoT:</dt>
<dd>Single Version of Truth</dd>
<dt>User:</dt>
<dd>In the context of this document, an operator and/or administrator respon
sible for the management and operation of
communication services and networking infrastructure (as opposed to an end u
ser of a communication service).</dd>
</dl>
</section>
<section anchor="Concepts" numbered="true" toc="default">
<name>Introduction of Concepts</name>
<t>The following section provides an overview of the concept of intent and
Intent-Based Management. It also provides an overview of the related concepts
of service models and policies (and Policy-Based Network Management), and explai
ns how they relate to intent and Intent-Based Management.
</t> </t>
<section numbered="true" toc="default">
<section title="Intent and Intent-Based Management"> <name>Intent and Intent-Based Management</name>
<t> <t>
In this document, intent is defined as a set of operational goals (that a netwo In this document, intent is defined as a set of operational goals (that a netwo
rk is supposed to meet) and outcomes (that a network is supposed to deliver), de rk is supposed to meet) and outcomes (that a network is supposed to deliver) def
fined in a declarative manner without specifying how to achieve or implement the ined in a declarative manner without specifying how to achieve or implement them
m. .
</t> </t>
<t> <t>
The term "intent" was first introduced in the context of Autonomic Networks, The term "intent" was first introduced in the context of Autonomic Networks,
where it is defined as "an abstract, high-level policy used to operate a network where it is defined as "an abstract, high-level policy used to operate the netwo
" rk"
<xref target= "RFC7575"/>. <xref target="RFC7575" format="default"/>.
According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the Autonomic Network that would otherwise operat e without human intervention. According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the Autonomic Network that would otherwise operat e without human intervention.
However, to avoid using intent simply as a synonym for policy, a distinction tha t differentiates intent clearly from other types of policies needs to be introdu ced. However, to avoid using intent simply as a synonym for policy, a distinction tha t differentiates intent clearly from other types of policies needs to be introdu ced.
</t> </t>
<aside>
<t> <t>
One note regarding the use of the plural form of "intent": in the English langua
ge, the term "intent" is generally used only in singular form. However, the spe
cification of intent as a whole usually involves the specification of several in
dividual statements of intent, or intent statements. In some cases, intent stat
ements are colloquially also referred to as "intents", although in general, the
use of the term "intents" is discouraged.
</t>
</aside>
<t>
Intent-Based Management aims to lead towards networks that are fundamentally sim pler to manage and operate, requiring only minimal outside intervention. Intent-Based Management aims to lead towards networks that are fundamentally sim pler to manage and operate, requiring only minimal outside intervention.
Networks, even when they are autonomic, are not clairvoyant and have no way of a utomatically knowing particular operational goals Networks, even when they are autonomic, are not clairvoyant and have no way of a utomatically knowing particular operational goals
nor which instances of networking services to support. nor which instances of networking services to support.
In other words, they do not know what the intent of the network provider is that gives the network the purpose of its being. This still needs to be communicate d to the network by what informally constitutes intent. In other words, they do not know what the intent of the network provider is that gives the network the purpose of its being. This still needs to be communicate d to the network by what informally constitutes intent.
That being said, the concept of intent is not limited just to autonomic networks , such as networks that feature an Autonomic Control Plane <xref target="RFC8994 "/>, but applies to any network. That being said, the concept of intent is not limited just to autonomic networks , such as networks that feature an Autonomic Control Plane <xref target="RFC8994 " format="default"/>, but applies to any network.
</t> </t>
<t> <t>
Intent defines goals and outcomes in a manner that is purely declarative, speci fying what to accomplish, Intent defines goals and outcomes in a manner that is purely declarative, speci fying what to accomplish,
not how to achieve it. Intent thus applies several important not how to achieve it. Intent thus applies several important
concepts simultaneously: concepts simultaneously:
<list style="symbols"> </t>
<t>It provides data abstraction: users do not need to be concerned with low-lev <ul spacing="normal">
el device configuration and nerd knobs. </t> <li>It provides data abstraction: Users do not need to be concerned wi
<t>It provides functional abstraction from particular management and control lo th low-level device configuration and nerd knobs. </li>
gic: users do not need to be concerned even with how to achieve a given intent. <li>It provides functional abstraction from particular management and
What is specified is the desired outcome, with the IBS automatically figuring o control logic: Users do not need to be concerned even with how to achieve a give
ut a course of action (e.g., using an algorithm or applying a set of rules deriv n intent. What is specified is the desired outcome with the IBS automatically f
ed from the intent) for how to achieve the outcome. </t> iguring out a course of action (e.g., using an algorithm or applying a set of ru
</list> les derived from the intent) for how to achieve the outcome. </li>
</t> </ul>
<t>
<t>
The following are some examples of intent, expressed in natural language for th e sake of clarity (actual interfaces used to convey intent may differ): The following are some examples of intent, expressed in natural language for th e sake of clarity (actual interfaces used to convey intent may differ):
<list style="symbols"> </t>
<t> "Steer networking traffic originating from endpoints in one geography away <ul spacing="normal">
from a second geography, unless the destination lies in that second geography."
(States what to achieve, not how.) </t> <li> "Steer networking traffic originating from endpoints in one geogr
<t> "Avoid routing networking traffic originating from a given set of endpoint aphy away from a second geography, unless the destination lies in that second ge
s (or associated with a given customer) through a particular vendor's equipment, ography." (states what to achieve, not how.) </li>
even if this occurs at the expense of reduced service levels." (States what to <li> "Avoid routing networking traffic originating from a given set of
achieve, not how, providing additional guidance for how to trade off between dif endpoints (or associated with a given customer) through a particular vendor's e
ferent goals when necessary)</t> quipment, even if this occurs at the expense of reduced service levels." (states
<t> "Maximize network utilization even if it means trading off service levels what to achieve, not how, providing additional guidance for how to trade off be
(such as latency, loss) unless service levels have deteriorated 20% or more from tween different goals when necessary.)</li>
their historical mean." (A desired outcome, with a set of constraints for addit <li> "Maximize network utilization even if it means trading off servic
ional guidance, which does not specify how to achieve this.) </t> e levels (such as latency, loss) unless service levels have deteriorated 20% or
<t> "VPN service must have path protection at all times for all paths." (A desi more from their historical mean." (a desired outcome, with a set of constraints
red outcome of which it may not be clear how it can be precisely accommodated.) for additional guidance, that does not specify how to achieve this.)</li>
</t>
<t> "Generate in-situ OAM data and network telemetry for later offline analysis <li> "Ensure VPN services have path protection at all times for all pa
whenever significant fluctuations in latency across a path are observed." (Goes ths." (a desired outcome of which it may not be clear how it can be precisely ac
beyond traditional event-condition-action by not being specific about what cons commodated.)</li>
titutes “significant” and what specific data to collect)</t>
<t>"Route traffic in a Space Information Network in a way that minimizes depend <li> "Generate in situ Operations, Administration, and Maintenance (OAM) data an
ency on stratospheric balloons unless the intended destination is an aircraft." d network telemetry for later offline analysis whenever significant fluctuations
(Does not specify how to precisely achieve this; extrapolates on scenarios menti in latency across a path are observed." (goes beyond event-condition-action by
oned in <xref target="Pang20"/>) </t> not being specific about what constitutes "significant" and what specific data t
<t>"For a smart city service, ensure traffic signal control traffic uses dedica o collect.)</li>
ted and redundant slices that avoid fate sharing." (A desired outcome with a set
of constraints and additional guidance without specifying how to precisely achi <li>"Route traffic in a Space Information Network in a way that minimi
eve this; zes dependency on stratospheric balloons unless the intended destination is an a
extrapolates on scenarios from <xref target="Gharbaoui21"/>). </t> ircraft." (does not specify how to precisely achieve this; extrapolates on scena
</list> rios mentioned in <xref target="PANG20" format="default"/>.)</li>
</t> <li>"For a smart city service, ensure traffic signal control traffic u
<t> ses dedicated and redundant slices that avoid fate sharing." (a desired outcome
with a set of constraints and additional guidance without specifying how to prec
isely achieve this;
extrapolates on scenarios from <xref target="GHARBAOUI21" format="default"/>.)<
/li>
</ul>
<t>
In contrast, the following are examples of what would not constitute intent (ag ain, expressed in natural language for the sake of clarity): In contrast, the following are examples of what would not constitute intent (ag ain, expressed in natural language for the sake of clarity):
<list style="symbols"> </t>
<t> "Configure a given interface with an IP address." This would be considered <ul spacing="normal">
device configuration and fiddling with configuration knobs, not intent.</t> <li> "Configure a given interface with an IP address." (This would be
<t> "When interface utilization exceeds a specific threshold, emit an alert." T considered device configuration and fiddling with configuration knobs, not inten
his would be a rule that can help support network automation, but a simple rule t.)</li>
is not an intent. </t> <li> "When interface utilization exceeds a specific threshold, emit an
<t> "Configure a VPN with a tunnel from A to B over path P." This would be cons alert." (This would be a rule that can help support network automation, but a s
idered as a configuration of a service.</t> imple rule is not an intent.) </li>
<t> "Deny traffic to prefix P1 unless it is traffic from prefix P2." This would <li> "Configure a VPN with a tunnel from A to B over path P." (This wo
be an example of an access policy or a firewall rule, not intent. </t> uld be considered as a configuration of a service.)</li>
</list> <li> "Deny traffic to prefix P1 unless it is traffic from prefix P2."
</t> (This would be an example of an access policy or a firewall rule, not intent.)
<t> </li>
In networks, in particular in networks that are deemed autonomic, intent should </ul>
ideally be rendered by the network itself, i.e., translated into device-specifi
c rules and courses of action. Ideally, intent would not need to be orchestrate <t>
d or broken down by a higher-level, centralized system but by the network device In networks, in particular in networks that are deemed autonomic, intent should
s themselves using a combination of distributed algorithms and local device abst ideally be rendered by the network itself, i.e., translated into device-specific
ractions. In this idealized vision, because intent holds for the network as a w rules and courses of action. Ideally, intent would not need to be orchestrated
hole, intent should ideally be automatically disseminated across all devices in or broken down by a higher-level, centralized system but by the network devices
the network, which can themselves decide whether they need to act on it. themselves using a combination of distributed algorithms and local device abstr
</t> actions. In this idealized vision, because intent holds for the network as a wh
<t> ole, intent should ideally be automatically disseminated across all devices in t
he network, which can themselves decide whether they need to act on it.
</t>
<t>
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. interaction with the network.
The system providing this points acts as the operational front end for the ne twork through which users can direct requests at the network and from which they can receive updates about the network. It may appear to users as a single syst em, even if it is implemented in a distributed manner. In turn, it interacts wi th and manages other systems in the network as needed in order to realize (i.e., to fulfill and to assure) the desired intent. The system providing this point acts as the operational front end for the net work through which users can direct requests at the network and from which they can receive updates about the network. It may appear to users as a single syste m, even if it is implemented in a distributed manner. In turn, it interacts wit h and manages other systems in the network as needed in order to realize (i.e., to fulfill and to assure) the desired intent.
Likewise, the vast majority of network Likewise, the vast majority of network
devices may be intent-agnostic and focus only (for example) on the devices may be intent-agnostic and focus only (for example) on the
actual forwarding of packets. Many devices may also be constrained actual forwarding of packets. Many devices may also be constrained
in terms of their processing resources. in terms of their processing resources.
This means that not every device may be able to act on intent on its own. This means that not every device may be able to act on intent on its own.
Again, intent in those cases can be achieved by a separate system which perfo Again, intent in those cases can be achieved by a separate system that perfor
rms the required actions. ms the required actions.
</t> </t>
<t>
<t>
Another reason to provide intent functionality from a conceptually centralized point is in Another reason to provide intent functionality from a conceptually centralized point is in
cases where the the realization of a certain type of intent benefits from glo bal knowledge of a network and cases where the realization of a certain type of intent benefits from global knowledge of a network and
its state. In many cases, such a global view may be impractical to maintain by individual devices, for example due to the volume of data and time lags that are involved. It may even be impractical for devices to simply access such a vi ew from another remote system if such were available. its state. In many cases, such a global view may be impractical to maintain by individual devices, for example due to the volume of data and time lags that are involved. It may even be impractical for devices to simply access such a vi ew from another remote system if such were available.
</t> </t>
<t> <t>
All of this implies that in many cases, certain All of this implies that in many cases, certain
intent functionality needs to be provided by functions that are specialized f or that purpose and that intent functionality needs to be provided by functions that are specialized f or that purpose and that
may be provided by dedicated systems (which in some cases could also co-host other networking functions). For example, the translation of specific types of intent may be provided by dedicated systems (which in some cases could also co-host other networking functions). For example, the translation of specific types of intent
into corresponding courses of action and algorithms to achieve the into corresponding courses of action and algorithms to achieve the
desired outcomes may need to be provided by such specialized desired outcomes may need to be provided by such specialized
functions. Of course, to avoid single points of failure, the functions. Of course, to avoid single points of failure, the
implementation and hosting of such functions may still be implementation and hosting of such functions may still be
distributed, even if conceptually centralized. distributed even if conceptually centralized.
</t> </t>
<t> <t>
Regardless of its particular implementation in centralized or decentralized mann Regardless of its particular implementation in a centralized or decentralized ma
er, an IBN is a network that can be managed using intent. This means that it is nner, an IBN is a network that can be managed using intent. This means that it
able to recognize and ingest intent of an operator or user and configure and ad is able to recognize and ingest intent of an operator or user and configure and
apt itself according to the user intent, achieving an intended outcome (i.e., a adapt itself according to the user intent, achieving an intended outcome (i.e.,
desired state or behavior) without requiring the user to specify the detailed te a desired state or behavior) without requiring the user to specify the detailed
chnical steps for how to achieve the outcome. Instead, the IBN will be able to f technical steps for how to achieve the outcome. Instead, the IBN will be able to
igure out on its own how to achieve the outcome. figure out on its own how to achieve the outcome.
Similarly, an IBS is a system that allows users to manage a network using intent . Such a system will serve as a point of interaction with users and implement t he functionality that is necessary to achieve the intended outcomes, interacting for that purpose with the network as required. Similarly, an IBS is a system that allows users to manage a network using intent . Such a system will serve as a point of interaction with users and implement t he functionality that is necessary to achieve the intended outcomes, interacting for that purpose with the network as required.
</t> </t>
<t>
Other definitions of intent exist, such as <xref target="TR523"/>. Intent ther
e is simply defined as a declarative interface that is typically provided by a c
ontroller. It implies the presence of a centralized function that renders the i
ntent into lower-level policies or instructions and orchestrates them across the
network. While this is certainly one way of implementation, the definition tha
t is presented here is more encompassing and ambitious, as it emphasizes the imp
ortance of managing the network by specifying desired outcomes without the speci
fic steps to be taken in order to achieve the outcome. A controller API that si
mply provides a network-level of abstraction is more limited and would not neces
sarily qualify as intent. Likewise, ingestion and recognition of intent may not
necessarily occur via a traditional API but may involve other types of human-ma
chine interactions.
</t>
</section> <t>
Other definitions of intent exist, such as <xref target="TR523" format="defaul
t"/>. Intent there is simply defined as a declarative interface that is typical
ly provided by a controller. It implies the presence of a centralized function
that renders the intent into lower-level policies or instructions and orchestrat
es them across the network. While this is certainly one way of implementation,
the definition that is presented here is more encompassing and ambitious, as it
emphasizes the importance of managing the network by specifying desired outcomes
without the specific steps to be taken in order to achieve the outcome.
<section title="Related Concepts"> A controller API that simply provides abstraction at the network level is more l imited and would not necessarily qualify as intent.
<section title="Service Models"> Likewise, ingestion and recognition of intent may not necessarily occur via an A
<t> PI based on function invocations and simple request-response interactions but ma
A service model is a model that represents a service that is provided by a netwo y involve other types of human-machine interactions such as dialogs to provide c
rk to a user. Per <xref target=" RFC8309"/>, a service model describes a service larifications and refinements to requests.
and its parameters in a portable/implementation-agnostic way that can be used i
ndependently of the equipment and operating environment on which the service is </t>
realized. Two subcategories are distinguished: a "Customer Service Model" descri
bes an instance of a service as provided to a customer, possibly associated with </section>
a service order. A "Service Delivery Model" describes how a service is instant <section numbered="true" toc="default">
iated over existing networking infrastructure. <name>Related Concepts</name>
</t> <section numbered="true" toc="default">
<t> <name>Service Models</name>
An example of a service could be a Layer 3 VPN service <xref target="RFC8 <t>
299"/>, a Network Slice <xref target=" I-D.ietf-teas-ietf-network-slice-definiti A service model is a model that represents a service that is provided by a netwo
on"/>, or residential Internet access. rk to a user. Per <xref target="RFC8309" format="default"/>, a service model des
cribes a service and its parameters in a portable and implementation-agnostic wa
y that can be used independently of the equipment and operating environment on w
hich the service is realized. Two subcategories are distinguished: a "Customer S
ervice Model" describes an instance of a service as provided to a customer, poss
ibly associated with a service order, and a "Service Delivery Model" describes h
ow a service is instantiated over existing networking infrastructure.
</t>
<t>
An example of a service could be a Layer 3 VPN service <xref target="RFC8
299" format="default"/>, a Network Slice <xref target="I-D.ietf-teas-ietf-networ
k-slices" format="default"/>, or residential Internet access.
Service models represent service instances as entities in their own right . Service models represent service instances as entities in their own right .
Services have their own parameters, actions, and lifecycles. Services have their own parameters, actions, and life cycles.
Typically, service instances can be bound to end users of communication s Typically, service instances can be bound to end users of communication s
ervices, who might be billed for the services provided. ervices who might be billed for the services provided.
</t> </t>
<t> <t>
Instantiating a service typically involves multiple aspects: Instantiating a service typically involves multiple aspects:
<list style="symbols">
<t>A user (or northbound system) needs to define and/or request a service to b
e instantiated.</t>
<t>Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, interface
s, bandwidth, or memory need to be allocated.</t>
<t>How to map services to the resources needs to be defined. Multiple mapping
s are often possible,
which to select may depend on context (such as which type of access is availab
le to connect the end user of a communication service with the service). </t>
<t>Bindings between upper and lower-level objects need to be maintained. </t>
<t>Once instantiated, the service operational state needs to be validated and
assured to ensure that the network indeed delivers the service as requested.</t>
</list>
</t> </t>
<t> <ul spacing="normal">
<li>A user (or northbound system) needs to define and/or request a s
ervice to be instantiated.</li>
<li>Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools
, interfaces, bandwidth, or memory need to be allocated.</li>
<li>How to map services to the resources needs to be defined. Multi
ple mappings are often possible,
which to select may depend on context (such as which type of access is availab
le to connect the end user of a communication service with the service). </li>
<li>Bindings between upper- and lower-level objects need to be maint
ained. </li>
<li>Once instantiated, the service operational state needs to be val
idated and assured to ensure that the network indeed delivers the service as req
uested.</li>
</ul>
<t>
The realization of service models involves a system, such as a controller, that provides provisioning logic. This includes breaking down high-level service abs tractions into lower-level device abstractions, identifying and allocating syste m resources, and orchestrating individual provisioning steps. The realization of service models involves a system, such as a controller, that provides provisioning logic. This includes breaking down high-level service abs tractions into lower-level device abstractions, identifying and allocating syste m resources, and orchestrating individual provisioning steps.
Orchestration operations are generally conducted using a "push" model in which t he controller/manager initiates the operations as required, then pushes down the specific configurations to the device and validates whether the new changes hav e been accepted and the new operational/derived states are achieved and in sync with the intent/desired state. In addition to instantiating and creating new ins tances of a service, updating, modifying, and decommissioning services need to b e also supported. Orchestration operations are generally conducted using a "push" model in which t he controller/manager initiates the operations as required, then pushes down the specific configurations to the device and validates whether the new changes hav e been accepted and the new operational/derived states are achieved and in sync with the intent/desired state. In addition to instantiating and creating new ins tances of a service, updating, modifying, and decommissioning services also need to be supported.
The device itself typically remains agnostic to the service or the fact that its resources or configurations are part of a service/concept at a higher layer. The device itself typically remains agnostic to the service or the fact that its resources or configurations are part of a service/concept at a higher layer.
</t> </t>
<t> <t>
Instantiated service models map to instantiated lower-layer network and device m odels. Examples include instances of paths or instances of specific port config urations. Instantiated service models map to instantiated lower-layer network and device m odels. Examples include instances of paths or instances of specific port config urations.
The service model typically also models dependencies and layering of services ov er lower-layer networking resources that are used to provide services. The service model typically also models dependencies and layering of services ov er lower-layer networking resources that are used to provide services.
This facilitates management by allowing to follow dependencies for troubleshooti
ng activities, to perform impact analysis in which events in the network are ass This facilitates management by allowing to follow dependencies for troubleshooti
essed regarding their impact on services and customers. ng activities and to perform impact analysis in which events in the network are
Services are typically orchestrated and provisioned top-to-bottom, which also fa assessed regarding their impact on services and customers.
cilitates keeping track of the assignment of network resources (composition), wh
ile troubleshooted bottom-up (decomposition). Services are typically orchestrated and provisioned top to bottom, which also fa
cilitates keeping track of the assignment of network resources (composition), wh
ile troubleshooted bottom up (decomposition).
Service models might also be associated with other data that does not concern th e network but provides business context. Service models might also be associated with other data that does not concern th e network but provides business context.
This includes things such as customer data (such as billing information), servic e orders and service catalogs, tariffs, service contracts, and Service Level Agr eements (SLAs), including contractual agreements regarding remediation actions. This includes things such as customer data (such as billing information), servic e orders and service catalogs, tariffs, service contracts, and Service Level Agr eements (SLAs), including contractual agreements regarding remediation actions.
</t> </t>
<t><xref target= "I-D.ietf-teas-te-service-mapping-yang"/> is an example of a <t><xref target="I-D.ietf-teas-te-service-mapping-yang" format="defaul
data model that provides a mapping for customer service t"/> is an example of a data model that provides a mapping for customer service
models (e.g., the L3VPN Service Model) to Traffic Engineering (TE) models (e. models (e.g., the L3VPN Service Model) to Traffic Engineering (TE) models (e.
g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks
Virtual Network model)</t> Virtual Network model).</t>
<t> <t>
Like intent, service models provide higher layers of abstraction. Service model s are often also complemented with mappings that capture dependencies between se rvice and device or network configurations. Like intent, service models provide higher layers of abstraction. Service model s are often also complemented with mappings that capture dependencies between se rvice and device or network configurations.
Unlike intent, service models do not allow to define a desired "outcome" that wo uld be automatically maintained by an IBS. Unlike intent, service models do not allow to define a desired "outcome" that wo uld be automatically maintained by an IBS.
Instead, the management of service models requires the development of sophistica ted algorithms and control logic by network providers or system integrators. Instead, the management of service models requires the development of sophistica ted algorithms and control logic by network providers or system integrators.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Policy and Policy-Based Network Management"> <name>Policy and Policy-Based Network Management</name>
<t> <t>
Policy-Based Network Management (PBNM) is a management paradigm that separates t he rules that govern the behavior of a system from the functionality of the syst em. It promises to reduce maintenance costs of information and communication sy stems while improving flexibility and runtime adaptability. Policy-Based Network Management (PBNM) is a management paradigm that separates t he rules that govern the behavior of a system from the functionality of the syst em. It promises to reduce maintenance costs of information and communication sy stems while improving flexibility and runtime adaptability.
It is present today at the heart of a multitude of management architectures and
paradigms, including SLA-driven, Business-driven, autonomous, adaptive, and self It is present today at the heart of a multitude of management architectures
-* management <xref target=" Boutaba07"/>. and paradigms, including SLA-driven, business-driven, autonomous, adaptive,
and self-* management <xref target="BOUTABA07" format="default"/>.
The interested reader is asked to refer to the rich set of existing literature, which includes this and many other references. In the following, we will only p rovide a much-abridged and distilled overview. The interested reader is asked to refer to the rich set of existing literature, which includes this and many other references. In the following, we will only p rovide a much-abridged and distilled overview.
</t> </t>
<t> <t>
At the heart of policy-based management is the concept of a policy. Multiple de At the heart of policy-based management is the concept of a policy. Multiple de
finitions of policy exist: "Policies are rules governing the choices in the beha finitions of policy exist: "Policies are rules governing the choices in the beha
vior of a system" <xref target=" Sloman94"/>. vior of a system" <xref target="SLOMAN94" format="default"/>.
"Policy is a set of rules that are used to manage and control the changing and/o "Policy is a set of rules that are used to manage and control the changing and/o
r maintaining of the state of one or more managed objects" <xref target=" Strass r maintaining of the state of one or more managed objects" <xref target="STRASSN
ner03"/>. Common to most definitions is the definition of a policy as a "rule." ER03" format="default"/>. Common to most definitions is the definition of a pol
Typically, the definition of a rule consists of an event (whose occurrence trigg icy as a "rule."
ers a rule), a set of conditions (which get assessed and which must be true befo Typically, the definition of a rule consists of an event (whose occurrence trigg
re any actions are actually "fired"), and, finally, a set of one or more actions ers a rule), a set of conditions (which get assessed and which must be true befo
that are carried out when the condition holds. re any actions are actually "fired"), and finally, a set of one or more actions
that are carried out when the condition holds.
</t> </t>
<t> <t>
Policy-based management can be considered an imperative management paradigm: Pol Policy-based management can be considered an imperative management paradigm: Pol
icies precisely specified what needs to be done when and in which circumstance. icies precisely specify what needs to be done when and in which circumstance. B
By using policies, management can, in effect, be defined as a set of simple con y using policies, management can, in effect, be defined as a set of simple contr
trol loops. ol loops.
This makes policy-based management a suitable technology to implement autonomic
behavior that can exhibit self-* management properties, including self-configura This makes policy-based management a suitable technology to implement
tion, self-healing, self-optimization, and self-protection. This is notwithstan autonomic behavior that can exhibit self-* management properties, including
ding the fact that policy-based management may make use of the concept of abstra self-configuration, self-healing, self-optimization, and self-protection. This
ctions (such as, "Bob gets gold service") that hide from the user the specifics is notwithstanding the fact that policy-based management may make use of the
of how that abstraction is rendered in a particular deployment. concept of abstractions (such as, "Bob gets gold service") that hide from the
user the specifics of how that abstraction is rendered in a particular
deployment.
</t> </t>
<t> <t>
Policies typically involve a certain degree of abstraction in order to cope with the heterogeneity of networking devices. Policies typically involve a certain degree of abstraction in order to cope with the heterogeneity of networking devices.
Rather than having a device-specific policy that defines events, conditions, and actions in terms of device-specific commands, parameters, and data models, Rather than having a device-specific policy that defines events, conditions, and actions in terms of device-specific commands, parameters, and data models,
a policy is defined at a higher level of abstraction involving a canonical model of systems and devices to which the policy is to be applied. a policy is defined at a higher level of abstraction involving a canonical model of systems and devices to which the policy is to be applied.
A policy agent on a controller or the device subsequently "renders" the policy, i.e., translates the canonical model into a device-specific representation. A policy agent on a controller or the device subsequently "renders" the policy, i.e., translates the canonical model into a device-specific representation.
This concept allows applying the same policy across a wide range of devices with This concept allows applying the same policy across a wide range of devices with
out needing to define multiple variants. In other words - policy definition is out needing to define multiple variants. In other words, policy definition is d
de-coupled from policy instantiation and policy enforcement. ecoupled from policy instantiation and policy enforcement.
This enables operational scale and allows network operators and authors of polic This enables operational scale and allows network operators and authors of polic
ies to think in higher terms of abstraction than device specifics and be able to ies to think in higher terms of abstraction than device specifics and be able to
reuse the same, high-level definition across different networking domains, WAN, reuse the same, high-level definition across different networking domains, WAN,
DC, or public cloud. data center (DC), or public cloud.
</t> </t>
<t> <t>
PBNM is typically "push-based": Policies are pushed onto devices where they are PBNM is typically "push-based": Policies are pushed onto devices where they are
rendered and enforced. The push operations are conducted by a manager or contr rendered and enforced. The push operations are conducted by a manager or contr
oller, which is responsible for deploying policies across the network and monito oller that is responsible for deploying policies across the network and monitori
ring their proper operation. ng their proper operation.
That being said, other policy architectures are possible. For example, policy- That being said, other policy architectures are possible. For example, policy-
based management can also include a pull-component in which the decision regardi based management can also include a pull component in which the decision regardi
ng which action to take is delegated to a so-called Policy Decision Point (PDP). ng which action to take is delegated to a so-called Policy Decision Point (PDP).
This PDP can reside outside the managed device itself and has typically global visibility and context with which to make policy decisions. Whenever a network device observes an event that is associated with a policy but lacks the full def inition of the policy or the ability to reach a conclusion regarding the expecte d action, it reaches out to the PDP for a decision (reached, for example, by dec iding on an action based on various conditions). This PDP can reside outside the managed device itself and has typically global visibility and context with which to make policy decisions. Whenever a network device observes an event that is associated with a policy but lacks the full def inition of the policy or the ability to reach a conclusion regarding the expecte d action, it reaches out to the PDP for a decision (reached, for example, by dec iding on an action based on various conditions).
Subsequently, the device carries out the decision as returned by the PDP - the device "enforces" the policy and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM architectures typically involve a central component from whic h policies are deployed across the network and/or policy decisions served. Subsequently, the device carries out the decision as returned by the PDP; the d evice "enforces" the policy and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM architectures typically involve a central component from which policies are deployed across the network and/or policy decisions served.
</t> </t>
<t> <t>
Like Intent, policies provide a higher layer of abstraction. Policy systems are Like intent, policies provide a higher layer of abstraction. Policy systems are
also able to capture dynamic aspects of the system under management through the also able to capture dynamic aspects of the system under management through the
specification of rules that allow defining various triggers for specific course specification of rules that allow defining various triggers for specific course
s of action. s of action.
Unlike intent, the definition of those rules (and courses of action) still needs to be articulated by users. Since the intent is unknown, conflict resolution w ithin or between policies requires interactions with a user or some kind of logi c that resides outside of PBNM. Unlike intent, the definition of those rules (and courses of action) still needs to be articulated by users. Since the intent is unknown, conflict resolution w ithin or between policies requires interactions with a user or some kind of logi c that resides outside of PBNM.
In that sense, policy constitutes a lower level of abstraction than intent, and it is conceivable for Intent-Based Systems to generate policies that are subsequ ently deployed by a PBNM system, allowing PBNM to support Intent-Based Networkin g. In that sense, policy constitutes a lower level of abstraction than intent, and it is conceivable for IBSs to generate policies that are subsequently deployed b y a PBNM system, allowing PBNM to support Intent-Based Networking.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title= "Distinguishing between Intent, Policy, and Service Models"> <name>Distinguishing between Intent, Policy, and Service Models</name>
<t> <t>
What Intent, Policy, and Service Models all have in common is the fact that they What intent, policy, and service models all have in common is the fact that they
involve a higher-layer of abstraction of a network that does not involve device involve a higher layer of abstraction of a network that does not involve device
-specifics, that generally transcends individual devices, and that makes the net specifics, generally transcends individual devices, and makes the network easie
work easier to manage for applications and human users compared to having to man r to manage for applications and human users compared to having to manage the ne
age the network one device at a time. twork one device at a time.
Beyond that, differences emerge. Beyond that, differences emerge.
</t> </t>
<t>
<t>
Summarized differences: Summarized differences:
<list style="symbols">
<t>A service model is a data model that is used to describe instances of service
s that are provided to customers. A service model has dependencies on lower-lev
el models (device and network models) when describing how the service is mapped
onto the underlying network and IT infrastructure.
Instantiating a service model requires orchestration by a system; the logic for
how to orchestrate/manage/provide the service model and how to map it onto under
lying resources is not included as part of the model itself.
</t> </t>
<t> Policy is a set of rules, typically modeled around a variation of events/con <ul spacing="normal">
ditions/actions, used to express simple control loops that can be rendered by de <li>A service model is a data model that is used to describe instanc
vices without requiring intervention by the outside system. es of services that are provided to customers. A service model has dependencies
on lower-level models (device and network models) when describing how the servi
ce is mapped onto the underlying network and IT infrastructure.
Instantiating a service model requires orchestration by a system; the logic for
how to orchestrate/manage/provide the service model and how to map it onto under
lying resources is not included as part of the model itself.
</li>
<li> Policy is a set of rules, typically modeled around a variation
of events/conditions/actions, used to express simple control loops that can be r
endered by devices without requiring intervention by the outside system.
Policies let users define what to do under what circumstances, but they do not s pecify the desired outcome. Policies let users define what to do under what circumstances, but they do not s pecify the desired outcome.
</t> </li>
<t>Intent is a high-level, declarative goal that operates at the level of a netw <li>Intent is a high-level, declarative goal that operates at the le
ork and services it provides, not individual devices. It is used to define outc vel of a network and services it provides, not individual devices. It is used t
omes and high-level operational goals, without specifying how those outcomes sho o define outcomes and high-level operational goals, without specifying how those
uld be achieved or how goals should specifically be satisfied, and without the n outcomes should be achieved or how goals should specifically be satisfied, and
eed to enumerate specific events, conditions, and actions. without the need to enumerate specific events, conditions, and actions.
Which algorithm or rules to apply can be automatically "learned/derived from int ent" by the IBS. Which algorithm or rules to apply can be automatically "learned/derived from int ent" by the IBS.
In the context of autonomic networking, intent is ideally rendered by the networ k itself; also, the dissemination of intent across the network and any required coordination between nodes is resolved by the network without the need for exter nal systems. In the context of autonomic networking, intent is ideally rendered by the networ k itself; also, the dissemination of intent across the network and any required coordination between nodes is resolved by the network without the need for exter nal systems.
</t> </li>
</list> </ul>
</t>
<t> <t>
One analogy to capture the difference between policy and Intent-Based Systems is One analogy to capture the difference between policy-based systems and IBSs is t
that of Expert Systems and Learning Systems in the field of Artificial Intellig hat of Expert Systems and Learning Systems in the field of Artificial Intelligen
ence. Expert Systems operate on knowledge bases with rules that are supplied by ce. Expert Systems operate on knowledge bases with rules that are supplied by u
users, analogous to policy systems whose policies are supplied by users. sers, analogous to policy systems whose policies are supplied by users.
They are able to make automatic inferences based on those rules but are not able to "learn" new rules on their own. Learning Systems (popularized by deep learn ing and neural networks), on the other hand, are able to learn without depending on user programming or articulation of rules. They are able to make automatic inferences based on those rules but are not able to "learn" new rules on their own. Learning Systems (popularized by deep learn ing and neural networks), on the other hand, are able to learn without depending on user programming or articulation of rules.
However, they do require a learning or training phase requiring large data sets; explanations of actions that the system actually takes provide a different set of challenges. Analogous to intent-based systems, users focus on what they woul d like the learning system to accomplish but not how to do it. However, they do require a learning or training phase requiring large data sets; explanations of actions that the system actually takes provide a different set of challenges. Analogous to IBSs, users focus on what they would like the learn ing system to accomplish but not how to do it.
</t> </t>
</section>
</section>
</section>
<section numbered="true" toc="default">
<name>Principles</name>
<t>
The following main operating principles allow characterizing the intent-based/-d
riven/-defined nature of a system.
</t>
</section> <ol spacing="normal" type="1"><li>
</section>
</section>
<section title="Principles"> <t>Single Source of Truth (SSoT) and Single Version of Truth (SVoT).
<t>
The following main operating principles allow characterizing the intent-based/-d The SSoT is an essential component of an IBS as
riven/-defined nature of a system. it enables several important operations. The set of validated
</t> intent expressions is the system's SSoT. SSoT and the records of
<t><list style="numbers"> the operational states enable comparing the intended/desired state
<t> Single Source of Truth (SSoT) and Single Version/View of Truth (SVoT). and actual/operational states of the system and determining drift
The SSoT is an essential component of an intent-based system as it enables sever between them. SSoT and the drift information provide the basis for
al important operations. The set of validated intent expressions is the system's corrective actions. If the IBS is equipped with the means to predict
SSoT. states, it can further develop strategies to anticipate, plan, and
SSoT and the records of the operational states enable comparing the intended/des pro-actively act on any diverging trends with the aim to minimize
ired state and actual/operational states of the system and determining drift bet their impact. Beyond providing a means for consistent system
ween them. operation, SSoT also allows for better traceability to validate
SSoT and the drift information provide the basis for corrective actions. If the if/how the initial intent and associated business goals have been
IBS is equipped with the means to predict states, it can further develop strateg properly met in order to evaluate the impacts of changes in the intent
ies to anticipate, plan, and pro-actively act on any diverging trends with the a parameters and impacts and effects of the events occurring in the
im to minimize their impact. system.
Beyond providing a means for consistent system operation, SSoT also allows for b
etter traceability to validate if/how the initial intent and associated business
goals have been properly met, to evaluate the impacts of changes in the intent
parameters and impacts and effects of the events occurring in the system.
<vspace/>
Single Version (or View) of Truth derives from the SSoT and can be used to perfo
rm other operations, such as querying, polling, or filtering measured and correl
ated information in order to create so-called "views." These views can serve the
users of the intent-based system.
In order to create intents as single sources of truth, the IBS must follow well-
specified and well-documented processes and models.
In other contexts, SSoT is also referred to as the invariance of the intent <xre
f target=" Lenrow15"/>.
</t> </t>
<t> One-touch but not one-shot. <t>
In an ideal intent-based system, the user expresses intent in one form or anoth Single Version (or View) of Truth derives from the SSoT and can be used to perfo
er, and then the system takes over all subsequent operations (one-touch). A zero rm other operations such as querying, polling, or filtering measured and correla
-touch approach could also be imagined in the case where the intent-based system ted information in order to create so-called "views." These views can serve the
has the capabilities or means to recognize intentions in any form of data. users of the IBS.
However, the zero- or one-touch approach should not distract from the fact that In order to create intent statements as single sources of truth, the IBS must fo
reaching the state of a well-formed and valid intent expression is not a one-sho llow well-specified and well-documented processes and models.
t process. On the contrary, the interfacing between the user and the intent-base In other contexts, SSoT is also referred to as the invariance of the intent <xre
d system could be designed as an interactive and iterative process. f target="LENROW15" format="default"/>.
Depending on the level of abstraction, the intent expressions may initially cont
ain more or less implicit parts and unprecise or unknown parameters and constrai
nts. The role of the intent-based system is to parse, understand, and refine the
intent expression to reach a well-formed and valid intent expression that can b
e further used by the system for the fulfillment and assurance operations.
An intent refinement process could use a combination of iterative steps involvin
g the user to validate the proposed refined intent and to ask the user for clari
fications in case some parameters or variables could not be deduced or learned b
y means of the system itself.
In addition, the Intent-Based System will need to moderate between conflicting i
ntent, helping users to properly choose between intent alternatives that may hav
e different ramifications.
</t> </t>
</li>
<t> Autonomy and Supervision. <li><t>One touch but not one shot.
A desirable goal for an intent-based system is to offer a high degree of flexibi
lity and freedom on both the user side and system side, e.g., by giving the user
the ability to express intents using the user's own terms, by supporting differ
ent forms of expression of intents and being capable of refining the intent expr
essions to well-formed and exploitable expressions.
The dual principle of autonomy and supervision allows operating a system that wi
ll have the necessary levels of autonomy to conduct its tasks and operations wit
hout requiring the intervention of the user and taking its own decisions (within
its areas of concern and span of control) as how to perform and meet the user e
xpectations in terms of performance and quality, while at the same time providin
g the proper level of supervision to satisfy the user requirements for reporting
and escalation of relevant information.
</t>
<t> Learning. An intent-based system is a learning system. In an ideal IBS, the user expresses intent in one
In contrast to an imperative-type of system, such as Event-Condition-Action poli form or another, and then the system takes over all subsequent
cy rules, where the user defines beforehand the expected behavior of the system operations (one touch). A zero-touch approach could also be imagined
to various events and conditions, in an intent-based system, the user only decla in the case where the IBS has the capabilities or
res what the system is supposed to achieve and not how to achieve these goals. means to recognize intentions in any form of data. However, the zero-
There is thus a transfer of reasoning/rationality from the human (domain knowled or one-touch approach should not distract from the fact that reaching
ge) to the system. This transfer of cognitive capability also implies the availa the state of a well-formed and valid intent expression is not a
bility in the intent-based system of capabilities or means for learning, reasoni one-shot process. On the contrary, the interfacing between the user
ng, and knowledge representation and management. and the IBS could be designed as an interactive and
The learning abilities of an IBS can apply to different tasks such as optimizati iterative process. Depending on the level of abstraction, the intent
on of the intent rendering or intent refinement processes. expressions may initially contain more or less implicit parts and
The fact that an intent-based system is a continuously evolving system creates t imprecise or unknown parameters and constraints. The role of the
he condition for continuous learning and optimization. Other cognitive capabilit IBS is to parse, understand, and refine the intent
ies such as planning can also be leveraged in an intent-based system to anticipa expression to reach a well-formed and valid intent expression that can
te or forecast future system state and response to changes in intents or network be further used by the system for the fulfillment and assurance
conditions and thus elaboration of plans to accommodate the changes while prese operations. An intent refinement process could use a combination of
rving system stability and efficiency in a trade-off with cost and robustness of iterative steps involving the user to validate the proposed refined
operations. intent and to ask the user for clarifications in case some parameters
</t> or variables could not be deduced or learned by means of the system
itself. In addition, the IBS will need to moderate
between conflicting intent, helping users to properly choose between
intent alternatives that may have different ramifications.
</t>
</li>
<li>Autonomy and Supervision.
A desirable goal for an IBS is to offer a high degree of
flexibility and freedom on both the user side and system side, e.g., by giving
the user the ability to express intent using the user's own terms, by
supporting different forms of expression for individual statements of intent and
being capable of
refining the intent expressions to well-formed and exploitable expressions.
The dual principle of autonomy and supervision allows operating a system that
will have the necessary levels of autonomy to conduct its tasks and operations
without requiring the intervention of the user and taking its own decisions
(within its areas of concern and span of control) as how to perform and meet
the user expectations in terms of performance and quality, while at the same
time providing the proper level of supervision to satisfy the user
requirements for reporting and escalation of relevant information.
</li>
<t> Capability exposure. Capability exposure consists in the need for expressive <li>Learning.
network capabilities, requirements, and constraints to be able to compose/decom An IBS is a learning system. In contrast to an
pose intents and map the user's expectations to the system capabilities. imperative type of system, such as Event-Condition-Action policy rules, where
</t> the user defines beforehand the expected behavior of the system to various
events and conditions, in an IBS, the user only declares what
the system is supposed to achieve and not how to achieve these goals. There
is thus a transfer of reasoning/rationality from the human (domain knowledge)
to the system. This transfer of cognitive capability also implies the
availability in the IBS of capabilities or means for learning,
reasoning, and knowledge representation and management. The learning
abilities of an IBS can apply to different tasks such as optimization of the
intent rendering or intent refinement processes. The fact that an
IBS is a continuously evolving system creates the condition
for continuous learning and optimization. Other cognitive capabilities such as
planning can also be leveraged in an IBS to anticipate or
forecast future system state and response to changes in intent or network
conditions and thus elaboration of plans to accommodate the changes while
preserving system stability and efficiency in a trade-off with cost and
robustness of operations.
</li>
<t>Abstract and outcome-driven. Users do not need to be concerned with how inte <li>Capability exposure.
nt is achieved and are empowered to think in terms of outcomes. In addition, t
hey can refer to concepts at a higher level of abstractions, independent e.g. of Capability exposure consists in the need for expressive network
vendor-specific renderings. capabilities, requirements, and constraints to be able to compose/decompose
</t> intent and map the user's expectations to the system capabilities.
</list> </li>
</t> <li>Abstract and outcome-driven.
<t> Users do not need to be concerned with how intent is achieved and are
empowered to think in terms of outcomes. In addition, they can refer to
concepts at a higher level of abstractions, independent, e.g., of
vendor-specific renderings.
</li></ol>
<t>
The described principles are perhaps the most prominent, but they are not an exh austive list. There are additional aspects to consider, such as: The described principles are perhaps the most prominent, but they are not an exh austive list. There are additional aspects to consider, such as:
<list style="symbols">
<t>
Intent targets are not individual devices but typically aggregations (such as gr
oups of devices adhering to a common criteria, such as devices of a particular r
ole) or abstractions (such as service types, service instances, topologies).
</t> </t>
<t>Abstraction and inherent virtualization: agnostic to implementation details.< <ul spacing="normal">
/t> <li>
<t>Human-tailored network interaction: IBN should speak the language of the user Intent targets are not individual devices but typically aggregations (such as gr
as opposed to requiring the user to speak the language of the device/network.</ oups of devices adhering to a common criteria, such as devices of a particular r
t> ole) or abstractions (such as service types, service instances, or topologies).
<t>Explainability as an important IBN function, detection and IBN-aided resoluti </li>
on of conflicting intent, reconciliation of what the user wants and what the net <li>Abstraction and inherent virtualization: agnostic to implementation
work can actually do. </t> details.</li>
<t>Inherent support, verification, and assurance of trust.</t> <li>Human-tailored network interaction: IBN should speak the language of
</list> the user as opposed to requiring the user to speak the language of the device/n
</t> etwork.</li>
<t> <li>Explainability as an important IBN function, detection and IBN-aided
All of these principles and considerations have implications on the design of in resolution of conflicting intent, and reconciliation of what the user wants and
tent-based systems and their supporting architecture. Accordingly, they need to what the network can actually do. </li>
be considered when deriving functional and operational requirements. <li>Inherent support, verification, and assurance of trust.</li>
</ul>
<t>
All of these principles and considerations have implications on the design of IB
Ss and their supporting architecture. Accordingly, they need to be considered wh
en deriving functional and operational requirements.
</t> </t>
</section> </section>
<section anchor="Functionality" numbered="true" toc="default">
<section title="Intent-Based Networking - Functionality" anchor="Functionality"> <name>Intent-Based Networking - Functionality</name>
<t> <t>
Intent-Based Networking involves a wide variety of functions that can be roughly divided into two categories: Intent-Based Networking involves a wide variety of functions that can be roughly divided into two categories:
<list style="symbols">
<t>Intent Fulfillment provides functions and interfaces that allow users to comm
unicate intent to the network and that perform the necessary actions to ensure t
hat intent is achieved. This includes algorithms to determine proper courses of
action and functions that learn to optimize outcomes over time. In addition, i
t also includes more traditional functions such as any required orchestration of
coordinated configuration operations across the network and rendering of higher
-level abstractions into lower-level parameters and control knobs.
</t> </t>
<t>Intent Assurance provides functions and interfaces that allow users to valida <ul spacing="normal">
te and monitor that the network is indeed adhering to and complying with intent. <li>Intent Fulfillment provides functions and interfaces that allow user
This is necessary to assess the effectiveness of actions taken as part of fulf s to communicate intent to the network and that perform the necessary actions to
illment, providing important feedback that allows those functions to be trained ensure that intent is achieved. This includes algorithms to determine proper c
or tuned over time to optimize outcomes. In addition, Intent Assurance is neces ourses of action and functions that learn to optimize outcomes over time. In ad
sary to address "intent drift." Intent is not meant to be transactional, i.e. " dition, it also includes functions such as any required orchestration of coordin
set and forget", but expected to be remain in effect over time (unless explicitl ated configuration operations across the network and rendering of higher-level a
y stated otherwise). Intent drift occurs when a system originally meets the int bstractions into lower-level parameters and control knobs.
ent, but over time gradually allows its behavior to change or be affected until </li>
it no longer does or does so in a less effective manner. <li>Intent Assurance provides functions and interfaces that allow users
</t> to validate and monitor that the network is indeed adhering to and complying wit
</list> h intent. This is necessary to assess the effectiveness of actions taken as par
</t> t of fulfillment, providing important feedback that allows those functions to be
<t> trained or tuned over time to optimize outcomes. In addition, Intent Assurance
is necessary to address "intent drift." Intent is not meant to be transactiona
l, i.e., "set and forget", but is expected to remain in effect over time (unless
explicitly stated otherwise). Intent drift occurs when a system originally mee
ts the intent, but over time gradually allows its behavior to change or be affec
ted until it no longer does or does so in a less effective manner.
</li>
</ul>
<t>
The following sections provide a more comprehensive overview of those functions. The following sections provide a more comprehensive overview of those functions.
</t> </t>
<section title="Intent Fulfillment"> <section numbered="true" toc="default">
<t>Intent fulfillment is concerned with the functions that take intent from its <name>Intent Fulfillment</name>
origination by a user (generally, an administrator of the responsible organizati <t>Intent fulfillment is concerned with the functions that take intent f
on) to its realization in the network. rom its origination by a user (generally, an administrator of the responsible or
ganization) to its realization in the network.
</t> </t>
<section title="Intent Ingestion and Interaction with Users"> <section numbered="true" toc="default">
<t> <name>Intent Ingestion and Interaction with Users</name>
The first set of functions is concerned with "ingesting" intent, i.e., obtaining <t>
intent through interactions with users. They provide functions that recognize The first set of functions is concerned with "ingesting" intent, i.e.
intent from interaction with the user as well as functions that allow users to r , obtaining intent through interactions with users. They provide functions that
efine their intent and articulate it in such ways so that it becomes actionable recognize intent from interaction with the user as well as functions that allow
by an Intent-Based System. Typically, those functions go beyond those provided users to refine their intent and articulate it in such ways so that it becomes
by a traditional API, although APIs may still be provided (and needed for intera actionable by an IBS.
ctions beyond human users, i.e., with other machines). Many cases would also inv
olve a set of intuitive and easy-to-navigate workflows that guide users through Typically, those functions go beyond those provided by a non-intent-b
the intent ingestion phase, making sure that all inputs that are necessary for i ased API, although non-intent-based APIs may also still be provided (and needed
ntent modeling and consecutive translation have been gathered. for interactions beyond human users, i.e., with other machines).
They may support unconventional human-machine interactions, in which a human wil
l not simply give simple commands but which may involve a human-machine dialog t Many cases would also involve a set of intuitive and easy-to-navigate
o provide clarifications, to explain ramifications and trade-offs, and to facili workflows that guide users through the intent ingestion phase, making sure that
tate refinements. all inputs that are necessary for intent modeling and consecutive translation h
ave been gathered.
They may support unconventional human-machine interactions, in which a human
will not simply give commands but instead a human-machine dialog is used to prov
ide clarifications, to explain ramifications and trade-offs, and to
facilitate refinements.
</t> </t>
<t>The goal is ultimately to make IBSs as easy and natural to use and interact w ith as possible, in particular allowing human users to interact with the IBS in ways that do not involve a steep learning curve that forces the user to learn th e "language" of the system. Ideally, it will be the Intent-Based Systems that is increasingly be able to learn how to understand the user as opposed to the othe r way round. Of course, further research will be required to make this a realit y. <t>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 t he IBS in ways that do not involve a steep learning curve that forces the user t o learn the "language" of the system. Ideally, it will be the IBSs that are incr easingly able to learn how to understand the user, as opposed to the other way a round. Of course, further research will be required to make this a reality.
</t> </t>
</section> </section>
<section title="Intent Translation"> <section numbered="true" toc="default">
<t> <name>Intent Translation</name>
A second set of functions needs to translate user intent into courses of action <t>
and requests to take against the network, which will be meaningful to network co A second set of functions needs to translate user intent into courses of action
nfiguration and provisioning systems. These functions lie at the core of IBS, b and requests to take against the network, which will be meaningful to network co
ridging the gap between interaction with users on the one hand and the tradition nfiguration and provisioning systems. These functions lie at the core of IBS, b
al management and operations side that will need to orchestrate provisioning and ridging the gap between interaction with users on the one hand and the managemen
configuration across the network. t and operations side that will need to orchestrate provisioning and configurati
on across the network.
</t> </t>
<t> <t>
Beyond merely breaking down a higher layer of abstraction (intent) into a lower Beyond merely breaking down a higher layer of abstraction (intent) into a lower
layer of abstraction (policies, device configuration), Intent Translation functi layer of abstraction (policies and device configuration), Intent Translation fun
ons can be complemented with functions and algorithms that perform optimizations ctions can be complemented with functions and algorithms that perform optimizati
and that are able to learn and improve over time in order to result in the best ons and that are able to learn and improve over time in order to result in the b
outcomes, specifically in cases where multiple ways of achieving those outcomes est outcomes, specifically in cases where multiple ways of achieving those outco
are conceivable. For example, satisfying an intent may involve computation of p mes are conceivable. For example, satisfying an intent may involve computation o
aths and other parameters that will need to be configured across the network. He f paths and other parameters that will need to be configured across the network.
uristics and algorithms to do so may evolve over time to optimize outcomes that Heuristics and algorithms to do so may evolve over time to optimize outcomes th
may depend on a myriad of dynamic network conditions and context. at may depend on a myriad of dynamic network conditions and context.
</t> </t>
</section> </section>
<section title="Intent Orchestration"> <section numbered="true" toc="default">
<t> <name>Intent Orchestration</name>
<t>
A third set of functions deals with the actual configuration and provisioning st eps that need to be orchestrated across the network and that were determined by the previous intent translation step. A third set of functions deals with the actual configuration and provisioning st eps that need to be orchestrated across the network and that were determined by the previous intent translation step.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Intent Assurance"> <name>Intent Assurance</name>
<t>Intent assurance is concerned with the functions that are necessary to ensure <t>Intent Assurance is concerned with the functions that are necessary t
that the network indeed complies with the desired intent once it has been fulfi o ensure that the network indeed complies with the desired intent once it has be
lled. en fulfilled.
</t> </t>
<section title="Monitoring"> <section numbered="true" toc="default">
<t> <name>Monitoring</name>
A first set of assurance functions monitors and observes the network and its exh <t>
ibited behavior. This includes all the usual assurance functions such as monitor A first set of assurance functions monitors and observes the network and its exh
ing the network for events and performance outliers, performing measurements to ibited behavior. This includes all the usual assurance functions such as monitor
assess service levels that are being delivered, generating and collecting teleme ing the network for events and performance outliers, performing measurements to
try data. Monitoring and observation are required as the basis for the next set assess service levels that are being delivered, and generating and collecting te
of functions that assess whether the observed behavior is in fact in compliance lemetry data. Monitoring and observation are required as the basis for the next
with the behavior that is expected based on the intent. set of functions that assess whether the observed behavior is in fact in complia
nce with the behavior that is expected based on the intent.
</t> </t>
</section> </section>
<section title="Intent Compliance Assessment"> <section numbered="true" toc="default">
<t> <name>Intent Compliance Assessment</name>
<t>
At the core of Intent Assurance are functions that compare the actual network be havior that is being monitored and observed with the intended behavior that is e xpected per the intent and is held by SSoT. These functions continuously assess and validate whether the observation indicates compliance with intent. At the core of Intent Assurance are functions that compare the actual network be havior that is being monitored and observed with the intended behavior that is e xpected per the intent and is held by SSoT. These functions continuously assess and validate whether the observation indicates compliance with intent.
This includes assessing the effectiveness of intent fulfillment actions, includi ng verifying that the actions had the desired effect and assessing the magnitude of the effect as applicable. It can also include functions that perform analys is and aggregation of raw observation data. The results of the assessment can be fed back to facilitate learning functions that optimize outcomes. This includes assessing the effectiveness of intent fulfillment actions, includi ng verifying that the actions had the desired effect and assessing the magnitude of the effect as applicable. It can also include functions that perform analys is and aggregation of raw observation data. The results of the assessment can be fed back to facilitate learning functions that optimize outcomes.
</t> </t>
<t> <t>
Intent compliance assessment also includes assessing whether intent drift occurs Intent compliance assessment also includes assessing whether intent drift occurs
over time. Intent drift can be caused by a control plane or lower-level manage over time. Intent drift can be caused by a control plane or lower-level manage
ment operations that inadvertently cause behavior changes which conflict with in ment operations that inadvertently cause behavior changes that conflict with int
tent that was orchestrated earlier. Intent-Based Systems and Networks need to b ent that was orchestrated earlier. IBSs and Networks need to be able to detect
e able to detect when such drift occurs or is about to occur as well as assess t when such drift occurs or is about to occur as well as assess the severity of th
he severity of the drift. e drift.
</t> </t>
</section> </section>
<section title="Intent Compliance Actions"> <section numbered="true" toc="default">
<t> <name>Intent Compliance Actions</name>
<t>
When intent drift occurs or network behavior is inconsistent with desired intent , functions that are able to trigger corrective actions are needed. This includ es actions needed to resolve intent drift and bring the network back into compli ance. When intent drift occurs or network behavior is inconsistent with desired intent , functions that are able to trigger corrective actions are needed. This includ es actions needed to resolve intent drift and bring the network back into compli ance.
Alternatively, and where necessary, reporting functions need to be triggered tha t alert operators and provide them with the necessary information and tools to r eact appropriately, e.g., by helping them articulate modifications to the origin al intent to moderate between conflicting concerns. Alternatively, and where necessary, reporting functions need to be triggered tha t alert operators and provide them with the necessary information and tools to r eact appropriately, e.g., by helping them articulate modifications to the origin al intent to moderate between conflicting concerns.
</t> </t>
</section> </section>
<section title="Abstraction, Aggregation, Reporting"> <section numbered="true" toc="default">
<t> <name>Abstraction, Aggregation, Reporting</name>
<t>
The outcome of Intent Assurance needs to be reported back to the user in ways th at allow the user to relate the outcomes to their intent. This requires a set o f functions that are able to analyze, aggregate, and abstract the results of the observations accordingly. In many cases, lower-level concepts such as detailed performance statistics and observations related to low-level settings need to b e "up-leveled" to concepts the user can relate to and take action on. The outcome of Intent Assurance needs to be reported back to the user in ways th at allow the user to relate the outcomes to their intent. This requires a set o f functions that are able to analyze, aggregate, and abstract the results of the observations accordingly. In many cases, lower-level concepts such as detailed performance statistics and observations related to low-level settings need to b e "up-leveled" to concepts the user can relate to and take action on.
</t> </t>
<t>The required aggregation and analysis functionality needs to be complemented with functions that report intent compliance status and provide adequate summari zation and visualization to human users. <t>The required aggregation and analysis functionality needs to be com plemented with functions that report intent compliance status and provide adequa te summarization and visualization to human users.
</t> </t>
</section> </section>
</section>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Lifecycle"> <name>Life Cycle</name>
<t> <t>
Intent is subject to a lifecycle: it comes into being, may undergo changes over 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. This lifecycle is close the course of time, and may at some point be retracted. This life cycle is clo
ly tied to various interconnection functions that are associated with the intent sely tied to various interconnection functions that are associated with the inte
concept. nt concept.
</t> </t>
<t><xref target="Fig_Lifecycle"/> depicts an intent lifecycle and its main funct ions. The functions were introduced in <xref target=" Functionality"/> and are divided into two functional (horizontal) planes, reflecting the distinction betw een fulfillment and assurance. In addition, they are divided into three (vertic al) spaces. <t><xref target="Fig_Lifecycle" format="default"/> depicts an intent life cycle and its main functions. The functions were introduced in <xref target="Fu nctionality" format="default"/> and are divided into two functional (horizontal) planes reflecting the distinction between fulfillment and assurance. In additi on, they are divided into three (vertical) spaces.
</t> </t>
<t>The spaces indicate the different perspectives and interactions with di
<t>The spaces indicate the different perspectives and interactions with differen fferent roles that are involved in addressing the functions:
t roles that are involved in addressing the functions:
<list style="symbols">
<t>
The User Space involves the functions that interface the network and intent-base
d system with the human user. It involves the functions that allow users to art
iculate and the intent-based system to recognize that intent. It also involves
the functions that report back the status of the network relative to the intent
and that allow users to assess outcomes and whether their intent has the desired
effect.</t>
<t>
The Translation, or Intent-Based System (IBS) Space involves the functions that
bridge the gap between intent users and the network operations infrastructure.
This includes the functions used to translate an intent into a course of action
as well as the algorithms that are used to plan and optimize those courses of ac
tion also in consideration of feedback and observations from the network. It al
so includes the functions to analyze and aggregate observations from the network
in order to validate compliance with the intent and to take corrective actions
as necessary. In addition, it includes functions that abstract observations fro
m the network in ways that relate them to the intent as communicated by users.
This facilitates the reporting functions in the user space.</t>
<t>
The Network Operations Space, finally, involves the traditional orchestration, c
onfiguration, monitoring, and measurement functions, which are used to effectuat
e the rendered intent and observe its effects on the network.</t>
</list>
</t> </t>
<t> <ul spacing="normal">
<figure anchor="Fig_Lifecycle" title="Intent Lifecycle"> <li>
<artwork> The User Space involves the functions that interface the network and IBS with th
<![CDATA[ e human user. It involves the functions that allow users to articulate and the
IBS to recognize that intent. It also involves the functions that report back t
he status of the network relative to the intent and that allow users to assess o
utcomes and whether their intent has the desired effect.</li>
<li>
The Translation, or Intent-Based System (IBS) Space involves the functions that
bridge the gap between intent users and the network operations infrastructure.
This includes the functions used to translate an intent into a course of action
as well as the algorithms that are used to plan and optimize those courses of ac
tion also in consideration of feedback and observations from the network. It al
so includes the functions to analyze and aggregate observations from the network
in order to validate compliance with the intent and to take corrective actions
as necessary. In addition, it includes functions that abstract observations fro
m the network in ways that relate them to the intent as communicated by users.
This facilitates the reporting functions in the user space.</li>
<li>
The Network Operations Space, finally, involves orchestration, configuration, mo
nitoring, and measurement functions, which are used to effectuate the rendered i
ntent and observe its effects on the network.</li>
</ul>
<figure anchor="Fig_Lifecycle">
<name>Intent Life Cycle</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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| : +----------+
: +---------+ : : +---------+ :
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>
When carefully inspecting the diagram, it becomes apparent that the intent life
cycle, in fact, involves two cycles, or loops:
</t> </t>
<t> <ul spacing="normal">
When carefully inspecting the diagram, it becomes apparent that the intent lifec <li>The "inner" intent control loop between IBS and Network Operations s
ycle, in fact, involves two cycles, or loops: pace is completely autonomic and does not involve any human in the loop. It rep
<list style="symbols"> resents closed-loop automation that involves automatic analysis and validation o
<t>The "inner" intent control loop between IBS and Network Operations space is c f intent based on observations from the network operations space. Those observa
ompletely autonomic and does not involve any human in the loop. It represents c tions are fed into the function that plans the rendering of networking intent in
losed-loop automation that involves automatic analysis and validation of intent order to make adjustments as needed in the configuration of the network. The lo
based on observations from the network operations space. Those observations are op addresses and counteracts any intent drift that may be occurring, using obser
fed into the function that plans the rendering of networking intent in order to vations to assess the degree of the network's intent compliance and automaticall
make adjustments as needed in the configuration of the network. The loop addres y prompting actions to address any discrepancies. Likewise, the loop allows to
ses and counteracts any intent drift that may be occuring, using observations to assess the effectiveness of any actions that are taken in order to continuously
assess the degree of the network's intent compliance and automatically promptin learn and improve how intent needs to be rendered in order to achieve the desire
g actions to address any discrepancies. Likewise, the loop allows to assess the d outcomes.
effectiveness of any actions that are taken in order to continuously learn and </li>
improve how intent needs to be rendered in order to achieve the desired outcomes <li>The "outer" intent control loop extends to the user space. It inclu
. des the user taking action and adjusting their intent based on observations and
feedback from the IBS. Intent is thus subjected to a life cycle: It comes into b
eing, may undergo refinements, modifications, and changes of time, and may at so
me point in time even get retracted. </li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Additional Considerations</name>
<t>
Given the popularity of the term "intent," it is tempting to broaden its use to
encompass other related concepts, resulting in "intent-washing" that paints thos
e concepts in a new light by simply applying new intent terminology to them. A c
ommon example concerns referring to the northbound interface of SDN controllers
as "intent interface." However, in some cases, this actually makes sense not ju
st as a marketing ploy but as a way to better relate previously existing and new
concepts.
</t> </t>
<t>The "outer" intent control loop extends to the user space. It includes the u <t>
ser taking action and adjusting their intent based on observations and feedback In that sense and with regards to intent, it makes sense to distinguish various
from the IBS. Intent is thus subjected to a lifecycle: It comes into being, may subcategories of intent as follows:
undergo refinements, modifications, and changes of time, and may at some point
in time even get retracted. </t>
</list>
</t> </t>
</section>
<section title="Additional Considerations"> <dl>
<t> <dt>Operational Intent:
Given the popularity of the term "intent," it is tempting to broaden it use to e </dt>
ncompass also other related concepts, resulting in "intent-washing" that paints <dd>defines intent related to operational goals of an operator; it
those concepts in a new light by simply applying new intent terminology to them. corresponds to the original "intent" term and the concepts defined in this
A common example concerns referring to the northbound interface of SDN controll document.
ers as "intent interface". However, in some cases, this actually makes sense no </dd>
t just as a marketing ploy but as a way to better relate previously existing and
new concepts. <dt>Rule Intent:
</t> </dt>
<t> <dd>a synonym for policy rules regarding what to do when certain events occur.
In that sense and regards to intent, it makes sense to distinguish various subca </dd>
tegories of intent as follows:
<list style="symbols"> <dt>Service Intent:
<t>Operational Intent: defines intent related to operational goals of an opera </dt>
tor; corresponds to the original "intent" term and the concepts defined in this <dd>a synonym for customer service model <xref target="RFC8309"
document. format="default"/>.
</t> </dd>
<t>Rule Intent: a synonym for policy rules regarding what to do when certain e
vents occur. <dt>Flow Intent:
</t> </dt>
<t>Service intent: a synonym for customer service model <xref target="RFC8309" <dd>a synonym for a Service Level Objective for a given flow.
/>. </dd>
</t> </dl>
<t>Flow Intent: A synonym for a Service Level Objective for a given flow.
</t> <t>
</list>
</t>
<t>
A comprehensive set of classifications of different concepts and categories of i ntent will be described A comprehensive set of classifications of different concepts and categories of i ntent will be described
in a separate document. in a separate document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document describes concepts and definitions of Intent-Based Networ
king. As such, the below security considerations remain high level, i.e., in the
form of principles, guidelines, or requirements. More detailed security conside
rations will be described in the documents that specify the architecture and fun
ctionality.</t>
<t>Security in Intent-Based Networking can apply to different facets:
</t>
<ul spacing="normal">
<li>Securing the IBS itself.</li>
<li>Mitigating the effects of erroneous, harmful, or compromised intent
statements.</li>
<li>Expressing security policies or security-related parameters with int
ent statements.</li>
</ul>
<t>Securing the IBS aims at making the IBS operationally secure by impleme
nting security mechanisms and applying security best practices. In the context o
f Intent-Based Networking, such mechanisms and practices may consist of intent v
erification and validation, operations on intent by authenticated and authorized
users only, and protection against or detection of tampered statements of inten
t.
<section title="IANA Considerations"> Such mechanisms may also include the introduction of multiple levels of intent.
<t> Not applicable </t> For example, intent related to securing the network should occur at a "deeper" l
</section> evel that overrides other levels of intent if necessary, and that is not subject
to modification through regular operations but through ones that are specifical
ly secured. Use of additional mechanisms such as explanation components that de
scribe the security ramifications and trade-offs should be considered as well.</
t>
<t>Mitigating the effects of erroneous or compromised statements of intent aims
at making
the IBS operationally safe by providing checkpoint and
safeguard mechanisms and operating principles.
<section title="Security Considerations"> In the context of Intent-Based
<t>This document describes concepts and definitions of Intent-Based Networking. Networking, such mechanisms and principles may consist of the ability to
As such, the below security considerations remain high level, i.e. in the form o automatically detect unintended, detrimental, or abnormal behavior; the
f principles, guidelines or requirements. More detailed security considerations ability to automatically (and gracefully) roll back or fall back to a previous
will be described in the documents that specify the architecture and functionali "safe" state; the ability to prevent or contain error amplification (due to
ty.</t> the combination of a higher degree of automation and the intrinsic higher
<t>Security in Intent-Based Networking can apply to different facets: degree of freedom, ambiguity, and implicit information conveyed by intent statem
<list style="symbols"> ents); and dynamic
<t>Securing the intent-based system itself.</t> levels of supervision and reporting to make the user aware of the right
<t>Mitigating the effects of erroneous, harmful or compromised intents.</t> information at the right time with the right level of context. Erroneous or
<t>Expressing security policies or security-related parameters with intents.</ harmful intent statements may inadvertently propagate and compromise security. I
t> n
</list></t> addition, compromised intent statements (for example, forged by an inside
<t>Securing the intent-based system aims at making the intent-based system opera attacker) may sabotage or harm the network resources and make them vulnerable
tionally secure by implementing security mechanisms and applying security best p to further, larger attacks, e.g., by defeating certain security
ractices. In the context of Intent-based Networking, such mechanisms and practic mechanisms.</t>
es may consist in intent verification and validation; operations on intents by a
uthenticated and authorized users only; protection against or detection of tampe
red intents.
Such mechanisms may also include the introduction of multiple levels of intent.
For example, intent related to securing the network should occur at a "deeper" l
evel that overrides other levels of intent if necessary, and that is not subject
to modification through regular operations but through ones that are specifical
ly secured. Use of additional mechanisms such as explanation components that de
scribe the security ramifications and trade-off should be considered as well.</t
>
<t>Mitigating the effects of erroneous or compromised intents aims at making the <t>
intent-based system operationally safe by providing checkpoint and safeguard me Expressing security policies or security-related parameters as intent
chanisms and operating principles. In the context of Intent-based Networking, su consists of using the intent formalism (a high-level,
ch mechanisms and principles may consist in the ability to automatically detect declarative abstraction) or part(s) of an intent statement to define
unintended, detrimental or abnormal behavior; the ability to automatically (and security-related aspects such as:
gracefully) rollback or fallback to a previous "safe" state; the ability to prev </t>
ent or contain error amplification (due to the combination of a higher degree of <ul>
automation and the intrinsic higher degree of freedom, ambiguity, and implicitl <li>data governance; </li>
y conveyed by intents); dynamic levels of supervision and reporting to make the <li>level(s) of confidentiality in data exchange;</li>
user aware of the right information, at the right time with the right level of c <li>level(s) of availability of system resources, of protection in
ontext. forwarding paths, and of isolation in processing functions;</li>
Erroneous or harmful intents may inadvertently propagate and compromise security <li>level(s) of encryption; and</li>
. In addition, compromised intents, for example, intent forged by an inside atta <li>authorized entities for given operations.</li>
cker, may sabotage or harm the network resources and make them vulnerable to fur </ul>
ther, larger attacks, e.g., by defeating certain security mechanisms.</t>
<t>Expressing security policies or security-related parameters with intents cons <t>The development and introduction of Intent-Based Networking in operatio
ists of using the intent formalism (a high-level, declarative abstraction), or p nal environments will certainly create new security concerns. Such security conc
art(s) of an intent statement to define security-related aspects such as data go erns have to be anticipated at the design and specification time. However, Inten
vernance, level(s) of confidentiality in data exchange, level(s) of availability t-Based Networking may also be used as an enabler for better security. For insta
of system resources, of protection in forwarding paths, of isolation in process nce, security and privacy rules could be expressed in a more human-friendly and
ing functions, level(s) of encryption, authorized entities for given operations, generic way and be less technology specific and less complex, leading to fewer l
etc.</t> ow-level configuration mistakes. The detection of threats or attacks could also
be made more simple and comprehensive thanks to conflict detection at higher lev
el or at coarser granularity.</t>
<t>More thorough security analyses should be conducted as our understandin
g of Intent-Based Networking technology matures.</t>
</section>
<t>The development and introduction of Intent-Based Networking in operational en </middle>
vironments will certainly create new security concerns. Such security concerns h <back>
ave to be anticipated at the design and specification time. However, Intent-Base
d Networking may also be used as an enabler for better security. For instance, s
ecurity and privacy rules could be expressed in a more human-friendly and generi
c way and be less technology-specific and less complex, leading to fewer low-lev
el configuration mistakes. The detection of threats or attacks could also be mad
e more simple and comprehensive thanks to conflict detection at higher-level or
at coarser granularity</t>
<t>More thorough security analyses should be conducted as our understanding of I <displayreference target="I-D.ietf-teas-te-service-mapping-yang" to="SERVICE-MAP
ntent-Based Networking technology matures.</t> PING-YANG"/>
</section> <displayreference target="I-D.ietf-teas-ietf-network-slices" to="NETWORK-SLICE"/
<section title="Acknowledgments"> >
<t>
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, Ma
rinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Have
l, 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 fo
llowing persons who went one step further and also provided reviews of the docum
ent: Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Ma
rtini, Stephen Mwanje, Peter Szilagyi, and Csaba Vulkan.
</t>
</section>
</middle>
<back> <references>
<references title="Informative References"> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3411.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8299.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8309.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8345.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8994.xml"/>
<?rfc include="reference.RFC.3411"?> <reference anchor="I-D.ietf-teas-te-service-mapping-yang">
<?rfc include="reference.RFC.7575"?> <front>
<?rfc include="reference.RFC.7950"?> <title>
<?rfc include="reference.RFC.8174"?> Traffic Engineering (TE) and Service Mapping YANG Data Model
<?rfc include="reference.RFC.8299"?> </title>
<?rfc include="reference.RFC.8309"?> <author initials="Y" surname="Lee" fullname="Young Lee" role="editor">
<?rfc include="reference.RFC.8345"?> <organization>Samsung Electronics</organization>
<?rfc include="reference.RFC.8994"?> </author>
<?rfc include="reference.I-D.ietf-teas-te-service-mapping-yang"?> <author initials="Dhruv" surname="Dhody" fullname="Dhruv Dhody" role="editor">
<?rfc include="reference.I-D.ietf-teas-ietf-network-slice-definition"?> <organization>Huawei Technologies</organization>
</author>
<author initials="G" surname="Fioccola" fullname="Giuseppe Fioccola">
<organization>Huawei Technologies</organization>
</author>
<author initials="Q" surname="Wu" fullname="Qin Wu" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author initials="D" surname="Ceccarelli" fullname="Daniele Ceccarelli">
<organization>Ericsson</organization>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft</organization>
</author>
<date month="July" day="11" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-te-service-mapping-yang
-11"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-teas-te-se
rvice-mapping-yang-11.txt"/>
</reference>
<reference anchor="M3010"> <reference anchor="I-D.ietf-teas-ietf-network-slices">
<front> <front>
<title>M.3010 : Principles for a telecommunications management network.</tit <title>Framework for IETF Network Slices</title>
le> <author initials="A" surname="Farrel" fullname="Adrian Farrel" role="editor">
<author fullname="ITU-T"> </author> <organization>Old Dog Consulting</organization>
<date month="February" year="2000" /> </author>
</front> <author initials="J" surname="Drake" fullname="John Drake" role="editor">
</reference> <organization>Juniper Networks</organization>
</author>
<author initials="R" surname="Rokui" fullname="Reza Rokui">
<organization>Ciena</organization>
</author>
<author initials="S" surname="Homma" fullname="Shunsuke Homma">
<organization>NTT</organization>
</author>
<author initials="K" surname="Makhijani" fullname="Kiran Makhijani">
<organization>Futurewei</organization>
</author>
<author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica</organization>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft Inc.</organization>
</author>
<date month="August" day="3" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-14"
/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
network-slices-14.txt"/>
</reference>
<reference anchor="TR523"> <reference anchor="M3010">
<front> <front>
<title>Intent NBI - Definition and Principles. ONF TR-523.</title> <title>Principles for a telecommunications management network</title>
<author fullname="Open Networking Foundation"> <author>
<organization>ITU-T</organization>
</author>
<date month="February" year="2000"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="M.3010"/>
</reference>
<reference anchor="TR523">
<front>
<title>Intent NBI - Definition and Principles</title>
<author>
<organization>Open Networking Foundation</organization>
</author> </author>
<date month="October" year="2016" /> <date month="October" year="2016"/>
</front> </front>
</reference> <refcontent>ONF TR-523</refcontent>
</reference>
<reference anchor="Boutaba07"> <reference anchor="BOUTABA07">
<front> <front>
<title>Policy-Based Management: A Historical perspective. Journal of Netw <title>Policy-Based Management: A Historical Perspective</title>
ork and Systems Management (JNSM), Springer, Vol. 15 (4).</title> <author initials="R" surname="Boutaba" fullname="R. Boutaba">
<author initials="R" surname="Boutaba" fullname="Raouf Boutaba">
</author> </author>
<author initials="I" surname="Aib" fullname="Issam Aib"> <author initials="I" surname="Aib" fullname="I. Aib">
</author> </author>
<date month="December" year="2007" /> <date month="November" year="2007"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1007/s10922-007-9083-8"/>
<refcontent>Journal of Network and Systems Management (JNSM), Vol. 15, Is
sue 4</refcontent>
</reference>
<reference anchor="Clemm20"> <reference anchor="CLEMM20">
<front> <front>
<title>Network Management 2030: Operations and Control of Network 2030 Servi <title>Network Management 2030: Operations and Control of Network 2030
ces. Journal of Network and Systems Management (JNSM), Springer, Vol. 28 (4). < Services</title>
/title> <author initials="A" surname="Clemm" fullname="A. Clemm">
<author initials="A" surname="Clemm" fullname="Alexander Clemm">
</author> </author>
<author initials="M" surname="Faten Zhani" fullname="Mohamed Faten Zhani"> <author initials="M" surname="Faten Zhani" fullname="M. F. Zhani">
</author> </author>
<author initials="R" surname="Boutaba" fullname="Raouf Boutaba"> <author initials="R" surname="Boutaba" fullname="R. Boutaba">
</author> </author>
<date month="October" year="2020" /> <date month="October" year="2020"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1007/s10922-020-09517-0"/>
<refcontent>Journal of Network and Systems Management (JNSM), Vol. 28, I
ssue 4</refcontent>
</reference>
<reference anchor="Lenrow15"> <reference anchor="LENROW15">
<front> <front>
<title>Intent As The Common Interface to Network Resources, Intent Based <title>Intent As The Common Interface to Network Resources</title>
Network Summit 2015 ONF Boulder: IntentNBI</title> <author initials="D" surname="Lenrow" fullname="D. Lenrow">
<author fullname="Dave Lenrow">
</author> </author>
<date month="February" year="2015" /> <date month="February" year="2015"/>
</front> </front>
</reference> <refcontent>Intent Based Network Summit 2015 ONF Boulder: IntentNBI</refc
ontent>
</reference>
<reference anchor="Sloman94"> <reference anchor="SLOMAN94">
<front> <front>
<title>Policy Driven Management for Distributed Systems. Journal of Netwo <title>Policy Driven Management for Distributed Systems</title>
rk and Systems Management (JNSM), Springer, Vol. 2 (4).</title> <author initials="M" surname="Sloman" fullname="M. Sloman">
<author initials="M" surname="Sloman" fullname="Morris Sloman">
</author> </author>
<date month="December" year="1994" /> <date month="December" year="1994"/>
</front> </front>
</reference> <refcontent>Journal of Network and Systems Management (JNSM), Vol. 2, Iss
ue 4, pp. 333-360</refcontent>
</reference>
<reference anchor="Strassner03"> <reference anchor="STRASSNER03">
<front> <front>
<title>Policy-Based Network Management. Elsevier.</title> <title>Policy-Based Network Management</title>
<author initials="J" surname="Strassner" fullname="John Strassner"> <author initials="J" surname="Strassner" fullname="J. Strassner">
</author> </author>
<date year="2003" /> <date month="August" year="2003"/>
</front> </front>
</reference> </reference>
<reference anchor="IEEEXPLORE">
<front>
<title> IEEE eXplore, https://ieeexplore.ieee.org/ </title>
<author fullname="IEEE"> </author>
<date year="2021"/>
</front>
</reference>
<reference anchor="WIN21">
<front>
<title> 1st IEEE International Workshop on Intent-Based Networking, https://
netsoft2021.ieee-netsoft.org/program/workshops/win-2021/ </title>
<author initials="L" surname="Ciavaglia" fullname="L. Ciavaglia (co-chair)">
</author>
<author initials="E" surname="Renault" fullname="E. Renault (co-chair)"> </a
uthor>
<date month="June" year="2021"/>
</front>
</reference>
<reference anchor="IEEE-TITS21"> <reference anchor="IEEEXPLORE" target="https://ieeexplore.ieee.org/">
<front> <front>
<title>Special Issue on Intent-Based Networking for 5G-Envisioned Internet o <title>IEEE Xplore</title>
f Connected Vehicles, in IEEE Transactions on Intelligent Transportation Systems <author>
, vol. 22, no. 8, DOI: 10.1109/TITS.2021.3101259</title> <organization>IEEE</organization>
<author initials="S" surname="Garg" fullname="S. Garg et al (Editors)"></aut </author>
hor> </front>
<date month="August" year="2021"/> </reference>
</front>
</reference>
<reference anchor="MDPI22"> <reference anchor="WIN21" target="https://netsoft2021.ieee-netsoft.org/pro
<front> gram/workshops/win-2021/">
<title> Special Issue "Intent-Based Software-Defined Networks", in Computer <front>
s (MDPI) (to appear)</title> <title>1st International Workshop on Intent-Based Networking</title>
<author initials="M" surname="Gharbaoui" fullname="Molka Gharbaoui (editor)" <author initials="L" surname="Ciavaglia" fullname="L. Ciavaglia"> </au
></author> thor>
<date year="2022"/> <author initials="E" surname="Renault" fullname="E. Renault"> </author
</front> >
</reference> <date month="June" year="2021"/>
</front>
<refcontent>IEEE International Conference on Network Softwarization</refc
ontent>
</reference>
<reference anchor="Pang20"> <reference anchor="IEEE-TITS21">
<front> <front>
<title>A Survey on Intent-Driven Networks", in IEEE Access Vol 8 pp. 22862-2 <title>Guest Editorial Special Issue on Intent-Based Networking for
2873, 5G-Envisioned Internet of Connected Vehicles</title>
DOI: 10:110/ACCESS.2020.2969208 </title> <author initials="S" surname="Garg" fullname="S. Garg"/>
<author initials="L" surname="Pang" fullname="L. Pang"> </author> <author initials="M" surname="Guizani" fullname="M. Guizani"/>
<author initials="C" surname="Yang" fullname="C. Yang"> </author> <author initials="Y-C" surname="Liang" fullname="L-C. Liang"/>
<author initials="D" surname="Chen" fullname="D. Chen"> </author> <author initials="F" surname="Granelli" fullname="F. Granelli"/>
<author initials="Y" surname="Song" fullname="Y. Song"> </author> <author initials="N" surname="Prasad" fullname="N. Prasad"/>
<author initials="M" surname="Guizan" fullname="M. Guizan"> </author> <author initials="R. R. V." surname="Prasad" fullname="R. R. V. Prasad"/>
<date year="2020" /> <date month="August" year="2021"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.1109/TITS.2021.3101259"/>
<refcontent>IEEE Transactions on Intelligent Transportation Systems, Vol.
22, Issue 8, pp. 5009-5017</refcontent>
</reference>
<reference anchor="Gharbaoui21"> <reference anchor="MDPI22">
<front> <front>
<title> "Implementation of an Intent Layer for SDN-enabled and QoS-aware Ne <title>Special Issue "Intent-Based Software-Defined Networks"</title>
twork Slicing", in IEEE 7th Int. Conference on Network Softwarization (NetSoft), <author initials="M" surname="Gharbaoui" fullname="M. Gharbaoui" role=
pp 17-23, doi: 10.1109/NetSoft51509.2021.9492643 </title> "editor"/>
<author initials="M" surname="Gharbaoui" fullname="M. Gharbaoui"> </author> <date year="2022"/>
<author initials="B" surname="Martini" fullname="B. Martini"> </author> </front>
<author initials="P" surname="Castoldi" fullname="P. Castoldi"> </author> <refcontent>Computers (MDPI)</refcontent>
<date month="June" year="2021"/> </reference>
</front>
</reference>
</references> <reference anchor="PANG20">
<front>
<title>A Survey on Intent-Driven Networks</title>
<author initials="L" surname="Pang" fullname="L. Pang"> </author>
<author initials="C" surname="Yang" fullname="C. Yang"> </author>
<author initials="D" surname="Chen" fullname="D. Chen"> </author>
<author initials="Y" surname="Song" fullname="Y. Song"> </author>
<author initials="M" surname="Guizan" fullname="M. Guizan"> </author>
<date month="January" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1109/ACCESS.2020.2969208"/>
<refcontent>IEEE Access, Vol. 8, pp.22862-22873</refcontent>
</reference>
</back> <reference anchor="GHARBAOUI21">
<front>
<title>Implementation of an Intent Layer for SDN-enabled and QoS-Aware
Network Slicing</title>
<author initials="M" surname="Gharbaoui" fullname="M. Gharbaoui"> </au
thor>
<author initials="B" surname="Martini" fullname="B. Martini"> </author
>
<author initials="P" surname="Castoldi" fullname="P. Castoldi"> </auth
or>
<date month="June" year="2021"/>
</front>
<seriesInfo name="DOI" value="10.1109/NetSoft51509.2021.9492643"/>
<refcontent>2021 IEEE 7th International Conference on Network Softwarizat
ion (NetSoft), pp. 17-23</refcontent>
</reference>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
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 <contact fullname="Remi Badonnel"/
>, <contact fullname="Walter Cerroni"/>, <contact fullname="Marinos Charalambid
es"/>, <contact fullname="Luis Contreras"/>, <contact fullname="Jerome Francois"
/>, <contact fullname="Molka Gharbaoui"/>, <contact fullname="Olga Havel"/>, <co
ntact fullname="Chen Li"/>, <contact fullname="William Liu"/>, <contact fullname
="Barbara Martini"/>, <contact fullname="Stephen Mwanje"/>, <contact fullname="J
eferson Nobre"/>, <contact fullname="Haoyu Song"/>, <contact fullname="Peter Szi
lagyi"/>, and <contact fullname="Csaba Vulkan"/>. Of those, we would like to th
ank the following persons who went one step further and also provided reviews of
the document: <contact fullname=" Remi Badonnel"/>, <contact fullname="Walter C
erroni"/>, <contact fullname="Jerome Francois"/>, <contact fullname="Molka Gharb
aoui"/>, <contact fullname="Barbara Martini"/>, <contact fullname="Stephen Mwanj
e"/>, <contact fullname="Peter Szilagyi"/>, and <contact fullname="Csaba Vulkan"
/>.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 133 change blocks. 
998 lines changed or deleted 1228 lines changed or added

This html diff was produced by rfcdiff 1.48.