< draft-irtf-nmrg-ibn-concepts-definitions-06.txt   draft-irtf-nmrg-ibn-concepts-definitions-07.txt >
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Informational L. Ciavaglia Intended status: Informational L. Ciavaglia
Expires: June 18, 2022 Rakuten Mobile Expires: 22 September 2022 Rakuten Mobile
L. Granville L. Z. Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
J. Tantsura J. Tantsura
Microsoft Microsoft
December 15, 2021 March 2022
Intent-Based Networking - Concepts and Definitions Intent-Based Networking - Concepts and Definitions
draft-irtf-nmrg-ibn-concepts-definitions-06 draft-irtf-nmrg-ibn-concepts-definitions-07
Abstract Abstract
Intent and Intent-Based Networking (IBN) are taking the industry by Intent and Intent-Based Networking (IBN) are taking the industry by
storm. At the same time, IBN-related terms are often used loosely storm. At the same time, IBN-related terms are often used loosely
and inconsistently, in many cases overlapping and confused with other and inconsistently, in many cases overlapping and confused with other
concepts such as "Policy." This document clarifies the concept of concepts such as "Policy." This document clarifies the concept of
"Intent" and provides an overview of the functionality that is "Intent" and provides an overview of the functionality that is
associated with it. The goal is to contribute towards a common and associated with it. The goal is to contribute towards a common and
shared understanding of terms, concepts, and functionality that can shared understanding of terms, concepts, and functionality that can
be used as the foundation to guide further definition of associated be used as the foundation to guide further definition of associated
research and engineering problems and their solutions. research and engineering problems and their solutions.
This document is a product of the IRTF Network Management Research This document is a product of the IRTF Network Management Research
Group (NMRG). It reflects the consensus of the RG, receiving reviews Group (NMRG). It reflects the consensus of the RG, receiving many
and explicit support from many members. It is published for positive votes in support. It also received many detailed and
positive reviews by RG participants. It is published for
informational purposes. informational purposes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 18, 2022. This Internet-Draft will expire on 2 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 6
3. Introduction of Concepts . . . . . . . . . . . . . . . . . . 6 3. Introduction of Concepts . . . . . . . . . . . . . . . . . . 7
3.1. Intent and Intent-Based Management . . . . . . . . . . . 6 3.1. Intent and Intent-Based Management . . . . . . . . . . . 7
3.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 10 3.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Service Models . . . . . . . . . . . . . . . . . . . 10 3.2.1. Service Models . . . . . . . . . . . . . . . . . . . 11
3.2.2. Policy and Policy-Based Network Management . . . . . 12 3.2.2. Policy and Policy-Based Network Management . . . . . 13
3.2.3. Distinguishing between Intent, Policy, and Service 3.2.3. Distinguishing between Intent, Policy, and Service
Models . . . . . . . . . . . . . . . . . . . . . . . 14 Models . . . . . . . . . . . . . . . . . . . . . . . 15
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Intent-Based Networking - Functionality . . . . . . . . . . . 18 5. Intent-Based Networking - Functionality . . . . . . . . . . . 19
5.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 18 5.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 19
5.1.1. Intent Ingestion and Interaction with Users . . . . . 18 5.1.1. Intent Ingestion and Interaction with Users . . . . . 19
5.1.2. Intent Translation . . . . . . . . . . . . . . . . . 19 5.1.2. Intent Translation . . . . . . . . . . . . . . . . . 20
5.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 20 5.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 20
5.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 20 5.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 20 5.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 21
5.2.2. Intent Compliance Assessment . . . . . . . . . . . . 20 5.2.2. Intent Compliance Assessment . . . . . . . . . . . . 21
5.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 21 5.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 21
5.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 21 5.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 22
6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Additional Considerations . . . . . . . . . . . . . . . . . . 23 7. Additional Considerations . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. Informative References . . . . . . . . . . . . . . . . . . . 26 11. Informative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document is a product of the IRTF Network Management Research This document is a product of the IRTF Network Management Research
Group (NMRG). It reflects the consensus of the RG, receiving reviews Group (NMRG). It reflects the consensus of the RG, receiving reviews
and explicit support from many members. It is published for and explicit support from many participants. It is published for
informational purposes. informational purposes.
In the past, interest regarding management and operations in the IETF In the past, interest regarding management and operations in the IETF
has focused on individual network and device features. has focused on individual network and device features.
Standardization emphasis has generally been put on management Standardization emphasis has generally been put on management
instrumentation that needed to be provided to a networking device. A instrumentation that needed to be provided to a networking device. A
prime example of this is SNMP-based management [RFC3411] and the 200+ prime example of this is SNMP-based management [RFC3411] and the 200+
MIBs that have been defined by the IETF over the years. More recent MIBs that have been defined by the IETF over the years. More recent
examples include YANG data model definitions [RFC7950] for aspects examples include YANG data model definitions [RFC7950] for aspects
such as interface configuration, ACL configuration, and Syslog such as interface configuration, ACL configuration, and Syslog
configuration. configuration.
There is a clear sense and reality that managing networks by There is a clear sense and reality that managing networks by
configuring myriads of "nerd knobs" on a device-by-device basis is no configuring myriads of "nerd knobs" on a device-by-device basis is no
longer an option in modern network environments. Significant longer an option in modern network environments. Significant
challenges arise with keeping device configurations not only challenges arise with keeping device configurations not only
consistent across a network but also consistent with the needs of consistent across a network but also consistent with the needs of
services and service features they are supposed to enable. services and service features they are supposed to enable.
Additional challenges arise with regards to being able to rapidly Additional challenges arise with regard to being able to rapidly
adapt the network as needed and to be able to do so at scale. At the adapt the network as needed and to be able to do so at scale. At the
same time, operations need to be streamlined and automated wherever same time, operations need to be streamlined and automated wherever
possible to not only lower operational expenses but also allow for possible to not only lower operational expenses but also allow for
rapid reconfiguration of networks at sub-second time scales and to rapid reconfiguration of networks at sub-second time scales and to
ensure that networks are delivering their functionality as expected. ensure that networks are delivering their functionality as expected.
Among other things, this requires the ability to consume operational Among other things, this requires the ability to consume operational
data, perform analytics, and dynamically take actions in a way that data, perform analytics, and dynamically take actions in a way that
is aware of context as well as intended outcomes at near real-time is aware of context as well as intended outcomes at near real-time
speeds. speeds.
skipping to change at page 4, line 10 skipping to change at page 4, line 24
straightforward, putting it at odds with the need to manage the straightforward, putting it at odds with the need to manage the
network one device and one feature at a time. However, while network one device and one feature at a time. However, while
autonomic networks are intended to exhibit "self-management" autonomic networks are intended to exhibit "self-management"
properties, they still require input from an operator or outside properties, they still require input from an operator or outside
system to provide operational guidance and information about the system to provide operational guidance and information about the
goals, purposes, and service instances that the network is to serve. goals, purposes, and service instances that the network is to serve.
This input and operational guidance are commonly referred to as This input and operational guidance are commonly referred to as
"intent," and networks that allow network operators to provide their "intent," and networks that allow network operators to provide their
input using intent as "Intent-Based Networks" (IBN) and the systems input using intent as "Intent-Based Networks" (IBN) and the systems
that help implement intent as "Intent-Based Systems" (IBS). However, that help implement intent as "Intent-Based Systems" (IBS). Those
intent is about more than just enabling a form of operator systems can manifest themselves in a number of ways, for example as a
controller or managemement system that are implemented as an
application that runs on a server or set of servers, or as a set of
functions that are distributed across a network and that collectively
perform their intent-based functionality.
However, intent is about more than just enabling a form of operator
interaction with the network that involves higher-layer abstractions. interaction with the network that involves higher-layer abstractions.
It is also about the ability to let operators focus on what they want It is also about the ability to let operators focus on what they want
their desired outcomes to be while leaving details about how those their desired outcomes to be while leaving details about how those
outcomes would, in fact, be achieved to the IBN (respectively IBS). outcomes would, in fact, be achieved to the IBN (respectively IBS).
This, in turn, enables much greater operational efficiency at greater This, in turn, enables much greater operational efficiency at greater
scale, in shorter time scales, with less dependency on human scale, in shorter time scales, with less dependency on human
activities (and possibility for mistakes), and an ideal candidate, activities (and possibility for mistakes), and an ideal candidate,
e.g., for artificial intelligence techniques that can bring about the e.g., for artificial intelligence techniques that can bring about the
next level of network automation [Clemm20]. next level of network automation [Clemm20].
This vision has since caught on with the industry in a big way, This vision has since caught on with the industry, leading to a
leading to a significant number of solutions that offer Intent-Based significant number of solutions that offer Intent-Based Management
Management that promise network providers to manage networks that promise network providers to manage networks holistically at a
holistically at a higher level of abstraction and as a system that higher level of abstraction and as a system that happens to consist
happens to consist of interconnected components, as opposed to a set of interconnected components, as opposed to a set of independent
of independent devices (that happen to be interconnected). Those devices (that happen to be interconnected). Those offerings include
offerings include IBN and IBS (offering full a life-cycle of intent), IBN and IBS (offering a full lifecycle of intent), SDN controllers
SDN controllers (offering a single point of control and (offering a single point of control and administration for a
administration for a network), and network management and Operations network), and network management and Operations Support Systems
Support Systems (OSS). (OSS).
It has been recognized for a long time that comprehensive management It has been recognized for a long time that comprehensive management
solutions cannot operate only at the level of individual devices and solutions cannot operate only at the level of individual devices and
low-level configurations. In this sense, the vision of intent is not low-level configurations. In this sense, the vision of intent is not
entirely new. In the past, ITU-T's model of a Telecommunications entirely new. In the past, ITU-T's model of a Telecommunications
Management Network (TMN) introduced a set of management layers that Management Network (TMN) introduced a set of management layers that
defined a management hierarchy, consisting of network element, defined a management hierarchy, consisting of network element,
network, service, and business management [M3010]. High-level network, service, and business management [M3010]. High-level
operational objectives would propagate in a top-down fashion from operational objectives would propagate in a top-down fashion from
upper to lower layers. The associated abstraction hierarchy was upper to lower layers. The associated abstraction hierarchy was
skipping to change at page 7, line 21 skipping to change at page 7, line 41
outside intervention. Networks, even when they are autonomic, are outside intervention. Networks, even when they are autonomic, are
not clairvoyant and have no way of automatically knowing particular not clairvoyant and have no way of automatically knowing particular
operational goals nor which instances of networking services to operational goals nor which instances of networking services to
support. In other words, they do not know what the intent of the support. In other words, they do not know what the intent of the
network provider is that gives the network the purpose of its being. network provider is that gives the network the purpose of its being.
This still needs to be communicated to the network by what informally This still needs to be communicated to the network by what informally
constitutes intent. That being said, the concept of intent is not constitutes intent. That being said, the concept of intent is not
limited just to autonomic networks, such as networks that feature an limited just to autonomic networks, such as networks that feature an
Autonomic Control Plane [RFC8994], but applies to any network. Autonomic Control Plane [RFC8994], but applies to any network.
More specifically, intent is a declaration of a set of operational Intent defines goals and outcomes in a manner that is purely
goals that a network is supposed to meet and outcomes that the declarative, specifying what to accomplish, not how to achieve it.
network is supposed to deliver, without specifying how to achieve or Intent thus applies several important concepts simultaneously:
how to implement them. Those goals and outcomes are defined in a
manner that is purely declarative - they specify what to accomplish,
not how to achieve it. Intent thus applies several important
concepts simultaneously:
o It provides data abstraction: users do not need to be concerned * It provides data abstraction: users do not need to be concerned
with low-level device configuration and nerd knobs. with low-level device configuration and nerd knobs.
o It provides functional abstraction from particular management and * It provides functional abstraction from particular management and
control logic: users do not need to be concerned even with how to control logic: users do not need to be concerned even with how to
achieve a given intent. What is specified is the desired outcome, achieve a given intent. What is specified is the desired outcome,
with the IBS automatically figuring out a course of action (e.g., with the IBS automatically figuring out a course of action (e.g.,
using an algorithm or applying a set of rules derived from the using an algorithm or applying a set of rules derived from the
intent) for how to achieve the outcome. intent) for how to achieve the outcome.
The following are some examples of intent, expressed in natural The following are some examples of intent, expressed in natural
language for the sake of clarity (actual interfaces used to convey language for the sake of clarity (actual interfaces used to convey
intent may differ): intent may differ):
o "Steer networking traffic originating from endpoints in one * "Steer networking traffic originating from endpoints in one
geography away from a second geography, unless the destination geography away from a second geography, unless the destination
lies in that second geography." (States what to achieve, not lies in that second geography." (States what to achieve, not
how.) how.)
o "Avoid routing networking traffic originating from a given set of * "Avoid routing networking traffic originating from a given set of
endpoints (or associated with a given customer) through a endpoints (or associated with a given customer) through a
particular vendor's equipment, even if this occurs at the expense particular vendor's equipment, even if this occurs at the expense
of reduced service levels." (States what to achieve, not how, of reduced service levels." (States what to achieve, not how,
providing additional guidance for how to trade off between providing additional guidance for how to trade off between
different goals when necessary) different goals when necessary)
o "Maximize network utilization even if it means trading off service * "Maximize network utilization even if it means trading off service
levels (such as latency, loss) unless service levels have levels (such as latency, loss) unless service levels have
deteriorated 20% or more from their historical mean." (A desired deteriorated 20% or more from their historical mean." (A desired
outcome, with a set of constraints for additional guidance, which outcome, with a set of constraints for additional guidance, which
does not specify how to achieve this.) does not specify how to achieve this.)
o "VPN service must have path protection at all times for all * "VPN service must have path protection at all times for all
paths." (A desired outcome of which it may not be clear how it paths." (A desired outcome of which it may not be clear how it
can be precisely accommodated.) can be precisely accommodated.)
o "Generate in-situ OAM data and network telemetry for later offline * "Generate in-situ OAM data and network telemetry for later offline
analysis whenever significant fluctuations in latency across a analysis whenever significant fluctuations in latency across a
path are observed." (Goes beyond traditional event-condition- path are observed." (Goes beyond traditional event-condition-
action by not being specific about what constitutes "significant" action by not being specific about what constitutes "significant"
and what specific data to collect) and what specific data to collect)
o "Route traffic in a Space Information Network in a way that * "Route traffic in a Space Information Network in a way that
minimizes dependency on stratospheric balloons unless the intended minimizes dependency on stratospheric balloons unless the intended
destination is an aircraft." (Does not specify how to precisely destination is an aircraft." (Does not specify how to precisely
achieve this; extrapolates on scenarios mentioned in [Pang20]) achieve this; extrapolates on scenarios mentioned in [Pang20])
o "For a smart city service, ensure traffic signal control traffic * "For a smart city service, ensure traffic signal control traffic
uses dedicated and redundant slices that avoid fate sharing." (A uses dedicated and redundant slices that avoid fate sharing." (A
desired outcome with a set of constraints and additional guidance desired outcome with a set of constraints and additional guidance
without specifying how to precisely achieve this; extrapolates on without specifying how to precisely achieve this; extrapolates on
scenarios from [Gharbaoui21]). scenarios from [Gharbaoui21]).
In contrast, the following are examples of what would not constitute In contrast, the following are examples of what would not constitute
intent (again, expressed in natural language for the sake of intent (again, expressed in natural language for the sake of
clarity): clarity):
o "Configure a given interface with an IP address." This would be * "Configure a given interface with an IP address." This would be
considered device configuration and fiddling with configuration considered device configuration and fiddling with configuration
knobs, not intent. knobs, not intent.
o "When interface utilization exceeds a specific threshold, emit an * "When interface utilization exceeds a specific threshold, emit an
alert." This would be a rule that can help support network alert." This would be a rule that can help support network
automation, but a simple rule is not an intent. automation, but a simple rule is not an intent.
o "Configure a VPN with a tunnel from A to B over path P." This * "Configure a VPN with a tunnel from A to B over path P." This
would be considered as a configuration of a service. would be considered as a configuration of a service.
o "Deny traffic to prefix P1 unless it is traffic from prefix P2." * "Deny traffic to prefix P1 unless it is traffic from prefix P2."
This would be an example of an access policy or a firewall rule, This would be an example of an access policy or a firewall rule,
not intent. not intent.
In networks, in particular in networks that are deemed autonomic, In networks, in particular in networks that are deemed autonomic,
intent should ideally be rendered by the network itself, i.e., intent should ideally be rendered by the network itself, i.e.,
translated into device-specific rules and courses of action. translated into device-specific rules and courses of action.
Ideally, intent would not need to be orchestrated or broken down by a Ideally, intent would not need to be orchestrated or broken down by a
higher-level, centralized system but by the network devices higher-level, centralized system but by the network devices
themselves using a combination of distributed algorithms and local themselves using a combination of distributed algorithms and local
device abstractions. In this idealized vision, because intent holds device abstractions. In this idealized vision, because intent holds
for the network as a whole, intent should ideally be automatically for the network as a whole, intent should ideally be automatically
disseminated across all devices in the network, which can themselves disseminated across all devices in the network, which can themselves
decide whether they need to act on it. decide whether they need to act on it.
However, such decentralization will not be practical in all cases. However, such decentralization will not be practical in all cases.
Certain functions will need to be at least conceptually centralized. Certain functions will need to be at least conceptually centralized.
For example, users may require a single conceptual point of For example, users may require a single conceptual point of
interaction with the network. Likewise, the vast majority of network interaction with the network. The system providing this points acts
devices may be intent-agnostic and focus only (for example) on the as the operational front end for the network through which users can
actual forwarding of packets. Many devices may also be constrained direct requests at the network and from which they can receive
in their processing resources and hence their ability to act on updates about the network. It may appear to users as a single
intent. Depending on the intent, not every devices needs to be aware system, even if it is implemented in a distributed manner. In turn,
of certain intent, for example when it does not affect them and when it interacts with and manages other systems in the network as needed
they play no role in achieving the desired outcome. In addition, in order to realize (i.e., to fulfill and to assure) the desired
certain functions may benefit from global knowledge of a network and intent. Likewise, the vast majority of network devices may be
its state, which may not be known or too expensive to maintain or intent-agnostic and focus only (for example) on the actual forwarding
access from individual network devices. This implies that certain of packets. Many devices may also be constrained in terms of their
intent functionality needs to be provided by functions that are processing resources. This means that not every device may be able
specialized for that purpose (which, depending on the scenario, may to act on intent on its own. Again, intent in those cases can be
be hosted on dedicated systems or co-hosted with other networking achieved by a separate system which performs the required actions.
functions). For example, the translation of specific types of intent
into corresponding courses of action and algorithms to achieve the
desired outcomes may need to be provided by such specialized
functions. Of course, to avoid single points of failure, the
implementation and hosting of those functions may still be
distributed, even if conceptually centralized.
Accordingly, an IBN is a network that can be managed using intent. Another reason to provide intent functionality from a conceptually
This means that it is able to recognize and ingest intent of an centralized point is in cases where the the realization of a certain
operator or user and configure and adapt itself according to the user type of intent benefits from global knowledge of a network and its
intent, achieving an intended outcome (i.e., a desired state or 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 view from another remote system if
such were available.
All of this implies that in many cases, certain intent functionality
needs to be provided by functions that are specialized for 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 into corresponding
courses of action and algorithms to achieve the desired outcomes may
need to be provided by such specialized functions. Of course, to
avoid single points of failure, the implementation and hosting of
such functions may still be distributed, even if conceptually
centralized.
Regardless of its particular implementation in centralized or
decentralized manner, an IBN is a network that can be managed using
intent. This means that it is able to recognize and ingest intent of
an operator or user and configure and adapt itself according to the
user intent, achieving an intended outcome (i.e., a desired state or
behavior) without requiring the user to specify the detailed behavior) without requiring the user to specify the detailed
technical steps for how to achieve the outcome. Instead, the IBN technical steps for how to achieve the outcome. Instead, the IBN
will be able to figure out on its own how to achieve the outcome. will be able to figure out on its own how to achieve the outcome.
Similarly, an IBS is a system that allows users to manage a network Similarly, an IBS is a system that allows users to manage a network
using intent. Such a system will serve as a point of interaction using intent. Such a system will serve as a point of interaction
with users and implement the functionality that is necessary to with users and implement the functionality that is necessary to
achieve the intended outcomes, interacting for that purpose with the achieve the intended outcomes, interacting for that purpose with the
network as required. network as required.
Other definitions of intent exist, such as [TR523]. Intent there is Other definitions of intent exist, such as [TR523]. Intent there is
skipping to change at page 10, line 38 skipping to change at page 11, line 28
environment on which the service is realized. Two subcategories are environment on which the service is realized. Two subcategories are
distinguished: a "Customer Service Model" describes an instance of a distinguished: a "Customer Service Model" describes an instance of a
service as provided to a customer, possibly associated with a service service as provided to a customer, possibly associated with a service
order. A "Service Delivery Model" describes how a service is order. A "Service Delivery Model" describes how a service is
instantiated over existing networking infrastructure. instantiated over existing networking infrastructure.
An example of a service could be a Layer 3 VPN service [RFC8299], a An example of a service could be a Layer 3 VPN service [RFC8299], a
Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or
residential Internet access. Service models represent service residential Internet access. Service models represent service
instances as entities in their own right. Services have their own instances as entities in their own right. Services have their own
parameters, actions, and life-cycles. Typically, service instances parameters, actions, and lifecycles. Typically, service instances
can be bound to end users of communication services, who might be can be bound to end users of communication services, who might be
billed for the services provided. billed for the services provided.
Instantiating a service typically involves multiple aspects: Instantiating a service typically involves multiple aspects:
o A user (or northbound system) needs to define and/or request a * A user (or northbound system) needs to define and/or request a
service to be instantiated. service to be instantiated.
o Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, * Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools,
interfaces, bandwidth, or memory need to be allocated. interfaces, bandwidth, or memory need to be allocated.
o How to map services to the resources needs to be defined. * How to map services to the resources needs to be defined.
Multiple mappings are often possible, which to select may depend Multiple mappings are often possible, which to select may depend
on context (such as which type of access is available to connect on context (such as which type of access is available to connect
the end user of a communication service with the service). the end user of a communication service with the service).
o Bindings between upper and lower-level objects need to be * Bindings between upper and lower-level objects need to be
maintained. maintained.
o Once instantiated, the service operational state needs to be * Once instantiated, the service operational state needs to be
validated and assured to ensure that the network indeed delivers validated and assured to ensure that the network indeed delivers
the service as requested. the service as requested.
The realization of service models involves a system, such as a The realization of service models involves a system, such as a
controller, that provides provisioning logic. This includes breaking controller, that provides provisioning logic. This includes breaking
down high-level service abstractions into lower-level device down high-level service abstractions into lower-level device
abstractions, identifying and allocating system resources, and abstractions, identifying and allocating system resources, and
orchestrating individual provisioning steps. Orchestration orchestrating individual provisioning steps. Orchestration
operations are generally conducted using a "push" model in which the operations are generally conducted using a "push" model in which the
controller/manager initiates the operations as required, then pushes controller/manager initiates the operations as required, then pushes
skipping to change at page 14, line 22 skipping to change at page 15, line 16
What Intent, Policy, and Service Models all have in common is the What Intent, Policy, and Service Models all have in common is the
fact that they involve a higher-layer of abstraction of a network fact that they involve a higher-layer of abstraction of a network
that does not involve device-specifics, that generally transcends that does not involve device-specifics, that generally transcends
individual devices, and that makes the network easier to manage for individual devices, and that makes the network easier to manage for
applications and human users compared to having to manage the network applications and human users compared to having to manage the network
one device at a time. Beyond that, differences emerge. one device at a time. Beyond that, differences emerge.
Summarized differences: Summarized differences:
o A service model is a data model that is used to describe instances * A service model is a data model that is used to describe instances
of services that are provided to customers. A service model has of services that are provided to customers. A service model has
dependencies on lower-level models (device and network models) dependencies on lower-level models (device and network models)
when describing how the service is mapped onto the underlying when describing how the service is mapped onto the underlying
network and IT infrastructure. Instantiating a service model network and IT infrastructure. Instantiating a service model
requires orchestration by a system; the logic for how to requires orchestration by a system; the logic for how to
orchestrate/manage/provide the service model and how to map it orchestrate/manage/provide the service model and how to map it
onto underlying resources is not included as part of the model onto underlying resources is not included as part of the model
itself. itself.
o Policy is a set of rules, typically modeled around a variation of * Policy is a set of rules, typically modeled around a variation of
events/conditions/actions, used to express simple control loops events/conditions/actions, used to express simple control loops
that can be rendered by devices without requiring intervention by that can be rendered by devices without requiring intervention by
the outside system. Policies let users define what to do under the outside system. Policies let users define what to do under
what circumstances, but they do not specify the desired outcome. what circumstances, but they do not specify the desired outcome.
o Intent is a high-level, declarative goal that operates at the * Intent is a high-level, declarative goal that operates at the
level of a network and services it provides, not individual level of a network and services it provides, not individual
devices. It is used to define outcomes and high-level operational devices. It is used to define outcomes and high-level operational
goals, without specifying how those outcomes should be achieved or goals, without specifying how those outcomes should be achieved or
how goals should specifically be satisfied, and without the need how goals should specifically be satisfied, and without the need
to enumerate specific events, conditions, and actions. Which to enumerate specific events, conditions, and actions. Which
algorithm or rules to apply can be automatically "learned/derived algorithm or rules to apply can be automatically "learned/derived
from intent" by the IBS. In the context of autonomic networking, from intent" by the IBS. In the context of autonomic networking,
intent is ideally rendered by the network itself; also, the intent is ideally rendered by the network itself; also, the
dissemination of intent across the network and any required dissemination of intent across the network and any required
coordination between nodes is resolved by the network without the coordination between nodes is resolved by the network without the
skipping to change at page 17, line 33 skipping to change at page 18, line 26
6. Abstract and outcome-driven. Users do not need to be concerned 6. Abstract and outcome-driven. Users do not need to be concerned
with how intent is achieved and are empowered to think in terms with how intent is achieved and are empowered to think in terms
of outcomes. In addition, they can refer to concepts at a higher of outcomes. In addition, they can refer to concepts at a higher
level of abstractions, independent e.g. of vendor-specific level of abstractions, independent e.g. of vendor-specific
renderings. renderings.
The described principles are perhaps the most prominent, but they are The described principles are perhaps the most prominent, but they are
not an exhaustive list. There are additional aspects to consider, not an exhaustive list. There are additional aspects to consider,
such as: such as:
o Intent targets are not individual devices but typically * Intent targets are not individual devices but typically
aggregations (such as groups of devices adhering to a common aggregations (such as groups of devices adhering to a common
criteria, such as devices of a particular role) or abstractions criteria, such as devices of a particular role) or abstractions
(such as service types, service instances, topologies). (such as service types, service instances, topologies).
o Abstraction and inherent virtualization: agnostic to * Abstraction and inherent virtualization: agnostic to
implementation details. implementation details.
o Human-tailored network interaction: IBN should speak the language * Human-tailored network interaction: IBN should speak the language
of the user as opposed to requiring the user to speak the language of the user as opposed to requiring the user to speak the language
of the device/network. of the device/network.
o Explainability as an important IBN function, detection and IBN- * Explainability as an important IBN function, detection and IBN-
aided resolution of conflicting intent, reconciliation of what the aided resolution of conflicting intent, reconciliation of what the
user wants and what the network can actually do. user wants and what the network can actually do.
o Inherent support, verification, and assurance of trust. * Inherent support, verification, and assurance of trust.
All of these principles and considerations have implications on the All of these principles and considerations have implications on the
design of intent-based systems and their supporting architecture. design of intent-based systems and their supporting architecture.
Accordingly, they need to be considered when deriving functional and Accordingly, they need to be considered when deriving functional and
operational requirements. operational requirements.
5. Intent-Based Networking - Functionality 5. Intent-Based Networking - Functionality
Intent-Based Networking involves a wide variety of functions that can Intent-Based Networking involves a wide variety of functions that can
be roughly divided into two categories: be roughly divided into two categories:
o Intent Fulfillment provides functions and interfaces that allow * Intent Fulfillment provides functions and interfaces that allow
users to communicate intent to the network and that perform the users to communicate intent to the network and that perform the
necessary actions to ensure that intent is achieved. This necessary actions to ensure that intent is achieved. This
includes algorithms to determine proper courses of action and includes algorithms to determine proper courses of action and
functions that learn to optimize outcomes over time. In addition, functions that learn to optimize outcomes over time. In addition,
it also includes more traditional functions such as any required it also includes more traditional functions such as any required
orchestration of coordinated configuration operations across the orchestration of coordinated configuration operations across the
network and rendering of higher-level abstractions into lower- network and rendering of higher-level abstractions into lower-
level parameters and control knobs. level parameters and control knobs.
o Intent Assurance provides functions and interfaces that allow * Intent Assurance provides functions and interfaces that allow
users to validate and monitor that the network is indeed adhering users to validate and monitor that the network is indeed adhering
to and complying with intent. This is necessary to assess the to and complying with intent. This is necessary to assess the
effectiveness of actions taken as part of fulfillment, providing effectiveness of actions taken as part of fulfillment, providing
important feedback that allows those functions to be trained or important feedback that allows those functions to be trained or
tuned over time to optimize outcomes. In addition, Intent tuned over time to optimize outcomes. In addition, Intent
Assurance is necessary to address "intent drift." Intent is not Assurance is necessary to address "intent drift." Intent is not
meant to be transactional, i.e. "set and forget", but expected to meant to be transactional, i.e. "set and forget", but expected to
be remain in effect over time (unless explicitly stated be remain in effect over time (unless explicitly stated
otherwise). Intent drift occurs when a system originally meets otherwise). Intent drift occurs when a system originally meets
the intent, but over time gradually allows its behavior to change the intent, but over time gradually allows its behavior to change
skipping to change at page 21, line 38 skipping to change at page 22, line 28
complemented with functions that report intent compliance status and complemented with functions that report intent compliance status and
provide adequate summarization and visualization to human users. provide adequate summarization and visualization to human users.
6. Lifecycle 6. Lifecycle
Intent is subject to a lifecycle: it comes into being, may undergo Intent is subject to a lifecycle: it comes into being, may undergo
changes over the course of time, and may at some point be retracted. changes over the course of time, and may at some point be retracted.
This lifecycle is closely tied to various interconnection functions This lifecycle is closely tied to various interconnection functions
that are associated with the intent concept. that are associated with the intent concept.
Figure 1 depicts an intent life-cycle and its main functions. The Figure 1 depicts an intent lifecycle and its main functions. The
functions were introduced in Section 5 and are divided into two functions were introduced in Section 5 and are divided into two
functional (horizontal) planes, reflecting the distinction between functional (horizontal) planes, reflecting the distinction between
fulfillment and assurance. In addition, they are divided into three fulfillment and assurance. In addition, they are divided into three
(vertical) spaces. (vertical) spaces.
The spaces indicate the different perspectives and interactions with The spaces indicate the different perspectives and interactions with
different roles that are involved in addressing the functions: different roles that are involved in addressing the functions:
o The User Space involves the functions that interface the network * The User Space involves the functions that interface the network
and intent-based system with the human user. It involves the and intent-based system with the human user. It involves the
functions that allow users to articulate and the intent-based functions that allow users to articulate and the intent-based
system to recognize that intent. It also involves the functions system to recognize that intent. It also involves the functions
that report back the status of the network relative to the intent that report back the status of the network relative to the intent
and that allow users to assess outcomes and whether their intent and that allow users to assess outcomes and whether their intent
has the desired effect. has the desired effect.
o The Translation, or Intent-Based System (IBS) Space involves the * The Translation, or Intent-Based System (IBS) Space involves the
functions that bridge the gap between intent users and the network functions that bridge the gap between intent users and the network
operations infrastructure. This includes the functions used to operations infrastructure. This includes the functions used to
translate an intent into a course of action as well as the translate an intent into a course of action as well as the
algorithms that are used to plan and optimize those courses of algorithms that are used to plan and optimize those courses of
action also in consideration of feedback and observations from the action also in consideration of feedback and observations from the
network. It also includes the functions to analyze and aggregate network. It also includes the functions to analyze and aggregate
observations from the network in order to validate compliance with observations from the network in order to validate compliance with
the intent and to take corrective actions as necessary. In the intent and to take corrective actions as necessary. In
addition, it includes functions that abstract observations from addition, it includes functions that abstract observations from
the network in ways that relate them to the intent as communicated the network in ways that relate them to the intent as communicated
by users. This facilitates the reporting functions in the user by users. This facilitates the reporting functions in the user
space. space.
o The Network Operations Space, finally, involves the traditional * The Network Operations Space, finally, involves the traditional
orchestration, configuration, monitoring, and measurement orchestration, configuration, monitoring, and measurement
functions, which are used to effectuate the rendered intent and functions, which are used to effectuate the rendered intent and
observe its effects on the network. observe its effects on the network.
User Space : Translation / IBS : Network Ops User Space : Translation / IBS : Network Ops
: Space : Space : Space : Space
: : : :
+----------+ : +----------+ +-----------+ : +-----------+ +----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision | |generate | | | | plan/ | | provision |
skipping to change at page 22, line 44 skipping to change at page 23, line 34
| : | : | | : | : |
.............|................................|................|..... .............|................................|................|.....
| : +----+---+ : v | : +----+---+ : v
| : |validate| : +----------+ | : |validate| : +----------+
| : +----^---+ <----| monitor/ | | : +----^---+ <----| monitor/ |
Assure +---+---+ : +---------+ +-----+---+ : | observe/ | Assure +---+---+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| | |report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+ +-------+ : +---------+ |aggregate| : +----------+
: +---------+ : : +---------+ :
Figure 1: Intent Lifecycle Figure 1: Intent Lifecycle
When carefully inspecting the diagram, it becomes apparent that the When carefully inspecting the diagram, it becomes apparent that the
intent lifecycle, in fact, involves two cycles, or loops: intent lifecycle, in fact, involves two cycles, or loops:
o The "inner" intent control loop between IBS and Network Operations * The "inner" intent control loop between IBS and Network Operations
space is completely autonomic and does not involve any human in space is completely autonomic and does not involve any human in
the loop. It represents closed-loop automation that involves the loop. It represents closed-loop automation that involves
automatic analysis and validation of intent based on observations automatic analysis and validation of intent based on observations
from the network operations space. Those observations are fed from the network operations space. Those observations are fed
into the function that plans the rendering of networking intent in into the function that plans the rendering of networking intent in
order to make adjustments as needed in the configuration of the order to make adjustments as needed in the configuration of the
network. The loop addresses and counteracts any intent drift that network. The loop addresses and counteracts any intent drift that
may be occuring, using observations to assess the degree of the may be occuring, using observations to assess the degree of the
network's intent compliance and automatically prompting actions to network's intent compliance and automatically prompting actions to
address any discrepancies. Likewise, the loop allows to assess address any discrepancies. Likewise, the loop allows to assess
the effectiveness of any actions that are taken in order to the effectiveness of any actions that are taken in order to
continuously learn and improve how intent needs to be rendered in continuously learn and improve how intent needs to be rendered in
order to achieve the desired outcomes. order to achieve the desired outcomes.
o The "outer" intent control loop extends to the user space. It * The "outer" intent control loop extends to the user space. It
includes the user taking action and adjusting their intent based includes the user taking action and adjusting their intent based
on observations and feedback from the IBS. Intent is thus on observations and feedback from the IBS. Intent is thus
subjected to a lifecycle: It comes into being, may undergo subjected to a lifecycle: It comes into being, may undergo
refinements, modifications, and changes of time, and may at some refinements, modifications, and changes of time, and may at some
point in time even get retracted. point in time even get retracted.
7. Additional Considerations 7. Additional Considerations
Given the popularity of the term "intent," it is tempting to broaden Given the popularity of the term "intent," it is tempting to broaden
it use to encompass also other related concepts, resulting in it use to encompass also other related concepts, resulting in
"intent-washing" that paints those concepts in a new light by simply "intent-washing" that paints those concepts in a new light by simply
applying new intent terminology to them. A common example concerns applying new intent terminology to them. A common example concerns
referring to the northbound interface of SDN controllers as "intent referring to the northbound interface of SDN controllers as "intent
interface". However, in some cases, this actually makes sense not interface". However, in some cases, this actually makes sense not
just as a marketing ploy but as a way to better relate previously just as a marketing ploy but as a way to better relate previously
existing and new concepts. existing and new concepts.
In that sense and regards to intent, it makes sense to distinguish In that sense and regards to intent, it makes sense to distinguish
various subcategories of intent as follows: various subcategories of intent as follows:
o Operational Intent: defines intent related to operational goals of * Operational Intent: defines intent related to operational goals of
an operator; corresponds to the original "intent" term and the an operator; corresponds to the original "intent" term and the
concepts defined in this document. concepts defined in this document.
o Rule Intent: a synonym for policy rules regarding what to do when * Rule Intent: a synonym for policy rules regarding what to do when
certain events occur. certain events occur.
o Service intent: a synonym for customer service model [RFC8309]. * Service intent: a synonym for customer service model [RFC8309].
o Flow Intent: A synonym for a Service Level Objective for a given * Flow Intent: A synonym for a Service Level Objective for a given
flow. flow.
A comprehensive set of classifications of different concepts and A comprehensive set of classifications of different concepts and
categories of intent will be described in a separate document. categories of intent will be described in a separate document.
8. IANA Considerations 8. IANA Considerations
Not applicable Not applicable
9. Security Considerations 9. Security Considerations
This document describes concepts and definitions of Intent-Based This document describes concepts and definitions of Intent-Based
Networking. As such, the below security considerations remain high Networking. As such, the below security considerations remain high
level, i.e. in the form of principles, guidelines or requirements. level, i.e. in the form of principles, guidelines or requirements.
More detailed security considerations will be described in the More detailed security considerations will be described in the
documents that specify the architecture and functionality. documents that specify the architecture and functionality.
Security in Intent-Based Networking can apply to different facets: Security in Intent-Based Networking can apply to different facets:
o Securing the intent-based system itself. * Securing the intent-based system itself.
o Mitigating the effects of erroneous, harmful or compromised * Mitigating the effects of erroneous, harmful or compromised
intents. intents.
o Expressing security policies or security-related parameters with * Expressing security policies or security-related parameters with
intents. intents.
Securing the intent-based system aims at making the intent-based Securing the intent-based system aims at making the intent-based
system operationally secure by implementing security mechanisms and system operationally secure by implementing security mechanisms and
applying security best practices. In the context of Intent-based applying security best practices. In the context of Intent-based
Networking, such mechanisms and practices may consist in intent Networking, such mechanisms and practices may consist in intent
verification and validation; operations on intents by authenticated verification and validation; operations on intents by authenticated
and authorized users only; protection against or detection of and authorized users only; protection against or detection of
tampered intents. Such mechanisms may also include the introduction tampered intents. Such mechanisms may also include the introduction
of multiple levels of intent. For example, intent related to of multiple levels of intent. For example, intent related to
skipping to change at page 26, line 26 skipping to change at page 27, line 24
[Gharbaoui21] [Gharbaoui21]
Gharbaoui, M., Martini, B., and P. Castoldi, Gharbaoui, M., Martini, B., and P. Castoldi,
""Implementation of an Intent Layer for SDN-enabled and ""Implementation of an Intent Layer for SDN-enabled and
QoS-aware Network Slicing", in IEEE 7th Int. Conference on QoS-aware Network Slicing", in IEEE 7th Int. Conference on
Network Softwarization (NetSoft), pp 17-23, doi: 10.1109/ Network Softwarization (NetSoft), pp 17-23, doi: 10.1109/
NetSoft51509.2021.9492643", June 2021. NetSoft51509.2021.9492643", June 2021.
[I-D.ietf-teas-ietf-network-slice-definition] [I-D.ietf-teas-ietf-network-slice-definition]
Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and
J. Tantsura, "Definition of IETF Network Slices", draft- J. Tantsura, "Definition of IETF Network Slices", Work in
ietf-teas-ietf-network-slice-definition-01 (work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-
progress), February 2021. slice-definition-01, 22 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
network-slice-definition-01.txt>.
[I-D.ietf-teas-te-service-mapping-yang] [I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D.,
and J. Tantsura, "Traffic Engineering (TE) and Service and J. Tantsura, "Traffic Engineering (TE) and Service
Mapping YANG Model", draft-ietf-teas-te-service-mapping- Mapping YANG Model", Work in Progress, Internet-Draft,
yang-09 (work in progress), October 2021. draft-ietf-teas-te-service-mapping-yang-10, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-te-
service-mapping-yang-10.txt>.
[IEEE-TITS21] [IEEE-TITS21]
Garg, S., "Special Issue on Intent-Based Networking for Garg, S., "Special Issue on Intent-Based Networking for
5G-Envisioned Internet of Connected Vehicles, in IEEE 5G-Envisioned Internet of Connected Vehicles, in IEEE
Transactions on Intelligent Transportation Systems, vol. Transactions on Intelligent Transportation Systems, vol.
22, no. 8, DOI: 10.1109/TITS.2021.3101259", August 2021. 22, no. 8, DOI: 10.1109/TITS.2021.3101259", August 2021.
[IEEEXPLORE] [IEEEXPLORE]
IEEE, "IEEE eXplore, https://ieeexplore.ieee.org/", 2021. IEEE, "IEEE eXplore, https://ieeexplore.ieee.org/", 2021.
[Lenrow15] [Lenrow15] Lenrow, D., "Intent As The Common Interface to Network
Lenrow, D., "Intent As The Common Interface to Network
Resources, Intent Based Network Summit 2015 ONF Boulder: Resources, Intent Based Network Summit 2015 ONF Boulder:
IntentNBI", February 2015. IntentNBI", February 2015.
[M3010] ITU-T, "M.3010 : Principles for a telecommunications [M3010] ITU-T, "M.3010 : Principles for a telecommunications
management network.", February 2000. management network.", February 2000.
[MDPI22] Gharbaoui, M., "Special Issue "Intent-Based Software- [MDPI22] Gharbaoui, M., "Special Issue "Intent-Based Software-
Defined Networks", in Computers (MDPI) (to appear)", 2022. Defined Networks", in Computers (MDPI) (to appear)", 2022.
[Pang20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A [Pang20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A
skipping to change at page 28, line 5 skipping to change at page 29, line 5
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994, Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>. <https://www.rfc-editor.org/info/rfc8994>.
[Sloman94] [Sloman94] Sloman, M., "Policy Driven Management for Distributed
Sloman, M., "Policy Driven Management for Distributed
Systems. Journal of Network and Systems Management (JNSM), Systems. Journal of Network and Systems Management (JNSM),
Springer, Vol. 2 (4).", December 1994. Springer, Vol. 2 (4).", December 1994.
[Strassner03] [Strassner03]
Strassner, J., "Policy-Based Network Management. Strassner, J., "Policy-Based Network Management.
Elsevier.", 2003. Elsevier.", 2003.
[TR523] Foundation, O. N., "Intent NBI - Definition and [TR523] Foundation, O. N., "Intent NBI - Definition and
Principles. ONF TR-523.", October 2016. Principles. ONF TR-523.", October 2016.
[WIN21] Ciavaglia, L. and E. Renault, "1st IEEE International [WIN21] Ciavaglia, L. and E. Renault, "1st IEEE International
Workshop on Intent-Based Networking, Workshop on Intent-Based Networking,
https://netsoft2021.ieee-netsoft.org/program/workshops/ https://netsoft2021.ieee-netsoft.org/program/workshops/
win-2021/", June 2021. win-2021/", June 2021.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara,, CA 95050
USA United States of America
Email: ludwig@clemm.org Email: ludwig@clemm.org
Laurent Ciavaglia Laurent Ciavaglia
Rakuten Mobile Rakuten Mobile
Email: laurent.ciavaglia@rakuten.com Email: laurent.ciavaglia@rakuten.com
Lisandro Zambenedetti Granville Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Goncalves Av. Bento Gonçalves
Porto Alegre 9500 Porto Alegre-
BR 9500
Brazil
Email: granville@inf.ufrgs.br Email: granville@inf.ufrgs.br
Jeff Tantsura Jeff Tantsura
Microsoft Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 70 change blocks. 
143 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/