< draft-clemm-nmrg-dist-intent-01.txt   draft-clemm-nmrg-dist-intent-02.txt >
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Huawei Internet-Draft Futurewei
Intended status: Informational L. Ciavaglia Intended status: Informational L. Ciavaglia
Expires: January 19, 2019 Nokia Expires: January 9, 2020 Nokia
L. Granville L. Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
July 18, 2018 J. Tantsura
Apstra, Inc.
July 8, 2019
Clarifying the Concepts of Intent and Policy Intent-Based Networking - Concepts and Overview
draft-clemm-nmrg-dist-intent-01 draft-clemm-nmrg-dist-intent-02
Abstract Abstract
Intent and Intent-Based Networking are taking the industry by storm. Intent and Intent-Based Networking are taking the industry by storm.
At the same time, those terms are used loosely and often At the same time, those terms are used loosely and often
inconsistently, in many cases overlapping with other concepts such as inconsistently, in many cases overlapping and confused with other
"policy". This document is therefore intended to clarify the concept concepts such as "policy". This document is intended to clarify the
of "Intent" and how it relates to other concepts. The goal is to concept of "Intent" and provide an overview of functionality that
contribute towards a common and shared understanding of terms and associated with it. The goal is to contribute towards a common and
concepts which can then be used as foundation to guide further shared understanding of terms, concepts, and functionality which can
definition of valid research and engineering problems and their be used as foundation to guide further definition of associated
solutions. research and engineering problems and their solutions.
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 January 19, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 4 4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 5
4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 4 4.1. Intent and Intent-Based Management . . . . . . . . . . . 5
4.2. Policy and Policy-Based Management . . . . . . . . . . . 6 4.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 6
4.3. Intent and Intent-Based Management . . . . . . . . . . . 7 4.2.1. Service Models . . . . . . . . . . . . . . . . . . . 7
5. Distinguishing between Intent, Policy, and Service Models . . 8 4.2.2. Policy and Policy-Based Management . . . . . . . . . 8
6. Items for Discussion . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Distinguishing between Intent, Policy, and Service
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Models . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 7. Intent-Based Networking - Functionality . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 10 7.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 17
8. Research Challenges . . . . . . . . . . . . . . . . . . . . . 17
8.1. Intent Interfaces . . . . . . . . . . . . . . . . . . . . 17
8.2. Explanation Component . . . . . . . . . . . . . . . . . . 18
8.3. IBN Metrics to Guide Desired Outcomes . . . . . . . . . . 18
9. Items for Discussion . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Traditionally in the IETF, interest with regard to management and Traditionally in the IETF, interest with regard to management and
operations has focused on individual network and device features. operations 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 by a networking device. A instrumentation that needed to be provided to a networking device. A
prime example for this is SNMP-based management and the 200+ MIBs prime example for this is SNMP-based management and the 200+ MIBs
that have been defined by the IETF over the years. More recent that have been defined by the IETF over the years. More recent
examples include YANG data model definitions for aspects such as examples include YANG data model definitions for aspects such as
interface configuration, ACL configuration, or Syslog configuration. interface configuration, ACL configuration, or Syslog configuration.
There is a sense that managing networks by configuring myriads of There is a sense and reality that in modern network environments
"nerd knobs" on a device-by-device basis is no longer sustainable in managing networks by configuring myriads of "nerd knobs" on a device-
modern network environments. Big challenges arise with keeping by-device basis is no longer sustainable. Big challenges arise with
device configurations not only consistent across a network, but keeping device configurations not only consistent across a network,
consistent with the needs of services they are supposed to enable. but consistent with the needs of services and service features they
At the same time, operations need to be streamlined and automated are supposed to enable. Adoptability to changes at scale is a
wherever possible to not only lower operational expenses, but allow fundamental property of a well designed IBN system, that requires
for rapid reconfiguration of networks at sub-second time scales. abilty to consume and process analytics that are context/intent aware
at near real time speeds. At the same time, operations need to be
streamlined and automated wherever possible to not only lower
operational expenses, but allow for rapid reconfiguration of networks
at sub-second time scales and to ensure networks are delivering their
functionality as expected.
Accordingly, IETF has begun to address end-to-end management aspects Accordingly, IETF has begun to address end-to-end management aspects
that go beyond the realm of individual devices in isolation. that go beyond the realm of individual devices in isolation.
Examples include the definition of YANG models for network topology Examples include the definition of YANG models for network topology
[RFC8345] or the introduction of service models used by service [RFC8345] or the introduction of service models used by service
orchestration systems and controllers [RFC8309]. In addition, a lot orchestration systems and controllers [RFC8309]. In addition, a lot
of interest has been fueled by the discussion about how to manage of interest has been fueled by the discussion about how to manage
autonomic networks as discussed in the ANIMA working group. autonomic networks as discussed in the ANIMA working group.
Autonomic networks are driven by the desire to lower operational Autonomic networks are driven by the desire to lower operational
expenses and make management of the network as a whole exceptionally expenses and make management of the network as a whole exceptionally
easy, putting it at odds with the need to manage the network one easy, putting it at odds with the need to manage the network one
device and one feature at a time. However, while autonomic networks device and one feature at a time. However, while autonomic networks
are intended to exhibit "self-management" properties, they still are intended to exhibit "self-management" properties, they still
require input from an operator or outside system to provide require input from an operator or outside system to provide
operational guidance and information about the goals, purposes, and operational guidance and information about the goals, purposes, and
service instances that the network is to serve. It is in this service instances that the network is to serve.
context that the term "intent" was coined for the first time.
This vision has since caught on with the industry in a big way, This vision has since caught on with the industry in a big way,
leading to countless offerings that tout "intent-based management" leading to a significant number solutions that offer "intent-based
that promise network providers to manage networks holistically at a management" that promise network providers to manage networks
higher level of abstraction and as a system that happens to consist holistically at a higher level of abstraction and as a system that
of interconnected components, as opposed to a set of independent happens to consist of interconnected components, as opposed to a set
devices (that happen to be interconnected). Those offerings include of independent devices (that happen to be interconnected). Those
offerings include IBN systems (offering full lifecycle of intent),
SDN controllers (offering a single point of control and SDN controllers (offering a single point of control and
administration for a network) as well as network management and administration for a network) as well as network management and
Operations Support Systems (OSS). Operations Support Systems (OSS).
However, it has been recognized for a long time that comprehensive However, it has been recognized for a long time that comprehensive
management solutions cannot operate only at the level of individual management solutions cannot operate only at the level of individual
devices and low-level configurations. In this sense, the vision of devices and low-level configurations. In this sense, the vision of
"intent" is not entirely new. In the past, ITU-T's model of a "intent" is not entirely new. In the past, ITU-T's model of a
Telecommunications Management Network, TMN, introduced a set of Telecommunications Management Network, TMN, introduced a set of
management layers that defined a management hierarchy, consisting of management layers that defined a management hierarchy, consisting of
skipping to change at page 3, line 50 skipping to change at page 4, line 20
This abstraction hierarchy was accompanied by an information This abstraction hierarchy was accompanied by an information
hierarchy that concerned itself at the lowest level with device- hierarchy that concerned itself at the lowest level with device-
specific information, but that would, at higher layers, include, for specific information, but that would, at higher layers, include, for
example, end-to-end service instances. Similarly, the concept of example, end-to-end service instances. Similarly, the concept of
"policy-based management" has for a long time touted the ability to "policy-based management" has for a long time touted the ability to
allow users to manage networks by specifying high-level management allow users to manage networks by specifying high-level management
policies, with policy systems automatically "rendering" those policies, with policy systems automatically "rendering" those
policies, i.e. breaking them down into low-level configurations and policies, i.e. breaking them down into low-level configurations and
control logic. control logic.
What is missing, however, is putting these concepts into a more What has been missing, however, is putting these concepts into a more
current context and defining a reference model that goes beyond a current context and updating it to account for current technology
TMN. This document attempts to clarify terminology and explain how trends. This document attempts to clarify the concepts behind
intent relates to other, similar concepts, in hope that a common and intent. It differentiates it from related concepts. It also
shared understanding of terms and concepts can be used as a provides an overview of first-order principles of Intent-Based
foundation to articulate research and engineering problems and their Networking as well as associated functionality. In addition, a
solutions. number of research challenges are highlighted. The goal is to
contribute to a common and shared understanding that can be used as a
foundation to articulate research and engineering problems in the
area of Intent-Based Networking.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions and Acronyms 3. Definitions and Acronyms
ACL: Access Control List ACL: Access Control List
Intent: An abstract, high-level policy used to operate a network Intent: An abstracted, declarative and vendor agnostic set of
[RFC7575]. rules used to provide full lifecycle (Design/Build/Deploy/
Validate) to a network and services it provides.
Policy: A rule, or set of rules, that governs the choices in Policy: A rule, or set of rules, that governs the choices in
behavior of a system. behavior of a system.
SSoT: Single Source of Truth - A functional block in an IBN system
that normalizes user' intent and serves as the single source of
data for the lower layers.
IBA: Intent Based Analytics - Analytics that are defined and
derived from user' intent and used to validate the intended state.
PDP: Policy Decision Point PDP: Policy Decision Point
PEP: Policy Enforcement Point PEP: Policy Enforcement Point
Service Model: A model that represents a service that is provided Service Model: A model that represents a service that is provided
by a network to a user. by a network to a user.
4. Introduction of Concepts 4. Introduction of Concepts
The following subsections provide an overview of the concepts of The following section provides an overview of the concept of intent
service models, of policies respectively policy-based management, and respectively intent-based management. It also provides an overview
of intent respectively intent-based management. While the of the related concepts of service models, and of policies
descriptions are intentionally kept brief and do not provide detailed respectively policy-based management, and explains how they relate to
tutorials, they should convey the bigger picture of the purpose of intent and intent-based management.
each concept and provide a sense where those concepts are similar and
where they differ. With this background, the differences between
them are subsequently summarized in in another section.
4.1. Service Models 4.1. Intent and Intent-Based Management
In the context of Autonomic Networks, Intent is defined as "an
abstract, high-level policy used to operate a network" [RFC7575].
According to this definition, an intent is a specific type of policy.
However, to avoid using "intent" simply as a synonym for "policy, a
clearer distinction needs to be introduced that distinguishes intent
clearly from other types of policies.
For one, while Intent-Based Management clearly aims to lead towards
networks that are dramatically simpler to manage and operate
requiring only minimal outside intervention, the concept of "intent"
is not limited to autonomic networks, but applies to any network.
Networks, even when considered "autonomic", are not clairvoyant and
have no way of automatically knowing particular operational goals nor
what instances of networking services to support. In other words,
they do not know what the "intent" of the network provider is that
gives the network the purpose of its being. This still needs to be
communicated by what informally constitutes "intent".
More specifically, intent is a declaration of operational goals that
a network should meet and outcomes that the network is supposed to
deliver, without specifying how to achieve 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 and operators do not need to
be concerned with low-level device configuration and nerd knobs.
o It provides functional abstraction from particular management and
control logic: Users and operators do not need to be concerned
even with how to achieve a given intent. What is specified is a
desired outcome, with the intent-based system automatically
figuring out a course of action (e.g. a set of rules, an
algorithm) for how to achieve the outcome.
In an autonomic network, intent should be rendered by the network
itself, i.e. translated into device-specific rules and courses of
action. Ideally, it should not even be orchestrated or broken down
by a higher-level, centralized system, but by the network devices
themselves using a combination of distributed algorithms and local
device abstraction. Because intent holds for the network as a whole,
not individual devices, it needs to be automatically disseminated
across all devices in the network, which can themselves decide
whether they need to act on it. This facilitates management even
further, since it obviates the need for a higher-layer system to
break down and decompose higher-level intent, and because there is no
need to even discover and maintain an inventory of the network to be
able to manage it.
Tentative definition for intent-based networks Networks configuring
and adapting autonomously to the user or operator intentions (i.e., a
desired state or behavior) without the need to specify every
technical detail of the process and operations to achieve it (i.e.,
the "machines" will figure out on their own how to realize the user
goal).
Other definitions of intent exist such as [TR523] and will be
investigated in future revisions of this document. Likewise, some
definitions of intent allow for the presence of a centralized
function that renders the intent into lower-level policies or
instructions and orchestrates them across the network. While to the
end user the concept of "intent" appears the same regardless of its
method of rendering, this interpretation opens a slippery slope of
how to clearly distinguish "intent" from other higher-layer
abstractions. Again, these notions will be further investigated in
future revisions of this document and in collaboration with NMRG.
4.2. Related Concepts
4.2.1. Service Models
A service model is a model that represents a service that is provided A service model is a model that represents a service that is provided
by a network to a user. Per [RFC8309], a service model describes a by a network to a user. Per [RFC8309], a service model describes a
service and its parameters in a portable way that can be used service and its parameters in a portable/vendor agnostic way that can
independent of the equipment and operating environment on which the be used independent of the equipment and operating environment on
service is realized. Two subcategories are distinguished: a which the service is realized. Two subcategories are distinguished:
"Customer Service Model" describes an instance of a service as a "Customer Service Model" describes an instance of a service as
provided to a customer, possibly associated with a service order. A provided to a customer, possibly associated with a service order. A
"Service Delivery Model" describes how a service is instantiated over "Service Delivery Model" describes how a service is instantiated over
existing networking infrastructure. 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, or residential Internet access. Service models Network Slice, or residential Internet access. Service models
represent service instances as entities in their own right. Services represent service instances as entities in their own right. Services
have their own parameters, actions, and lifecycles. Typically, have their own parameters, actions, and lifecycles. Typically,
service instances can be bound to end users, who might be billed for service instances can be bound to end users, who might be billed for
the service. the service.
Instantiating a service typically involves multiple aspects: Instantiating a service typically involves multiple aspects:
o Resources need to be allocated, such as IP addresses, interfaces, o A user (or northbound system) needs to define and/or request a
bandwidth, or memory. service to be instantiated.
o Resources need to be allocated, such as IP addresses, AS numbers,
VLAN or VxLAN pools, interfaces, bandwidth, or memory.
o How to map services to the resources needs to be defined. o 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 with the service). the end user with the service).
o Bindings need to be maintained between upper- and lower-level o [I-D.ietf-teas-te-service-mapping-yang] is an example of such
mapping - a data model to map customer service models (e.g., the
L3VPM Service Model) to Traffic Engineering (TE) models (e.g., the
TE Tunnel or the Abstraction and Control of Traffic Engineered
Networks Virtual Network model)
o Bindings need to be maintained between upper and lower-level
objects. objects.
o Once instantiated, the service needs to be validated and assured
to ensure that the network indeed delivers the service as
requested.
They involve a system, such as a controller, that provides They involve a system, such as a controller, that provides
provisioning logic. Orchestration itself is generally conducted provisioning logic. Orchestration itself is generally conducted
using a "push" model, in which the controller/manager initiates the using a "push" model, in which the controller/manager initiates the
operations as required, pushing down the specific configurations to operations as required, pushing down the specific configurations to
the device. The device itself typically remains agnostic to the the device. (In addition to instantiating and creating new instances
service or the fact that its resources or configurations are part of of a service, updating, modifying, and decommissioning services need
a service/concept at a higher layer. to be also 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.
Instantiated service models map to instantiated lower-layer network Instantiated service models map to instantiated lower-layer network
and device models. Examples include instances of paths, or instances and device models. Examples include instances of paths, or instances
of specific port configurations. The service model typically also of specific port configurations. The service model typically also
models dependencies and layering of services over lower-layer models dependencies and layering of services over lower-layer
networking resources that are used to provide services. This networking resources that are used to provide services. This
facilitates management by allowing to follow dependencies for facilitates management by allowing to follow dependencies for
troubleshooting activities, to perform impact analysis in which troubleshooting activities, to perform impact analysis in which
events in the network are assessed regarding their impact on services events in the network are assessed regarding their impact on services
and customers Services are typically orchestrated and provisioned and customers. Services are typically orchestrated and provisioned
top-to-bottom, which also facilitates keeping track of the assignment top-to-bottom, which also facilitates keeping track of the assignment
of network resources. of network resources. Service models might also be associated with
other data that does not concern the network but provides business
context. This includes things such as customer data (such as billing
information), service orders and service catalogues, tariffs, service
contracts, and Service Level Agreements (SLAs) including contractual
agreements regarding remediation actions.
Service models also associate with other data that does not concern Like intent, service models provide higher layers of abstraction.
the network but provides business context. This includes things such Service models are often also complemented with mappings that capture
as customer data (such as billing information), service orders and dependencies between service and device or network configurations.
service catalogues, tariffs, service contracts, and Service Level Unlike intent, service models do not allow to define a desired
Agreements (SLAs) including contractual agreements regarding "outcome" that would be automatically maintained by the intent
remediation actions. system. Instead, management of service models requires development
of sophisticated algorithms and control logic by network providers or
system integrators.
4.2. Policy and Policy-Based Management 4.2.2. Policy and Policy-Based Management
Policy-based management (PBM) is a management paradigm that separates Policy-based management (PBM) is a management paradigm that separates
the rules that govern the behavior of a system from the functionality the rules that govern the behavior of a system from the functionality
of the system. It promises to reduce maintenance costs of of the system. It promises to reduce maintenance costs of
information and communication systems while improving flexibility and information and communication systems while improving flexibility and
runtime adaptability. It is today present at the heart of a runtime adaptability. It is present today at the heart of a
multitude of management architectures and paradigms including SLA- multitude of management architectures and paradigms including SLA-
driven, Business-driven, autonomous, adaptive, and self-* management driven, Business-driven, autonomous, adaptive, and self-* management
[Boutaba07]. The interested reader is asked to refer to the rich set [Boutaba07]. The interested reader is asked to refer to the rich set
of existing literature which includes this and many other references. of existing literature which includes this and many other references.
In the following, we an only provide a much-abridged and distilled In the following, we will only provide a much-abridged and distilled
overview. overview.
At the heart of policy-based management is the concept of a policy. At the heart of policy-based management is the concept of a policy.
Multiple definitions of policy exist: "Policies are rules governing Multiple definitions of policy exist: "Policies are rules governing
the choices in behavior of a system" [Sloman94]. "Policy is a set of the choices in behavior of a system" [Sloman94]. "Policy is a set of
rules that are used to manage and control the changing and/or rules that are used to manage and control the changing and/or
maintaining of the state of one or more managed objects" maintaining of the state of one or more managed objects"
[Strassner03]. Common to most definitions is the definition of a [Strassner03]. Common to most definitions is the definition of a
policy as a "rule". Typically, the definition of a rule consists of policy as a "rule". Typically, the definition of a rule consists of
an event (whose occurrence triggers a rule), a set of conditions an event (whose occurrence triggers a rule), a set of conditions
(that get assessed and that must be true before any actions are (that get assessed and that must be true before any actions are
actually "fired"), and finally a set of one or more actions that are actually "fired"), and finally a set of one or more actions that are
carried out when the condition holds. carried out when the condition holds.
Policy-based management can be considered an imperative management Policy-based management can be considered an imperative management
paradigm: Policies specify precisely what needs to be done when. paradigm: Policies specify precisely what needs to be done when and
Using policies, management can in effect be defined as a set of in which circumstance. Using policies, management can in effect be
simple control loops. This makes policy-based management a suitable defined as a set of simple control loops. This makes policy-based
technology to implement autonomic behavior that can exhibit self-* management a suitable technology to implement autonomic behavior that
management properties including self-configuration, self-healing, can exhibit self-* management properties including self-
self-optimization, and self-protection. In effect, policies define configuration, self-healing, self-optimization, and self-protection.
simple control loops typically used to define management as a set of In effect, policies define management as a set of simple control
simple control loops. loops.
Policies typically involve a certain degree of abstraction in order Policies typically involve a certain degree of abstraction in order
to cope with heterogeneity of networking devices. Rather than having to cope with heterogeneity of networking devices. Rather than having
a device-specific policy that defines events, conditions, and actions a device-specific policy that defines events, conditions, and actions
in terms of device-specific commands, parameters, and data models, in terms of device-specific commands, parameters, and data models,
policy is defined at a higher-level of abstraction involving 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 canonical model of systems and devices to which the policy is to be
applied. A policy agent on the device subsequently "renders" the applied. A policy agent on a controller or the device subsequently
policy, i.e., translates the canonical model into a device-specific "renders" the policy, i.e., translates the canonical model into a
representation. This concept allows to apply the same policy across device-specific representation. This concept allows to apply the
a wide range of devices without needing to define multiple variants. same policy across a wide range of devices without needing to define
This enables operational scale and allows network operators and multiple variants. In other words - policy definition is de-coupled
authors of policies to think in higher terms of abstraction than from policy instantiation and policy enforcement. This enables
device specifics. operational scale and allows network operators and authors of
policies to think in higher terms of abstraction than device
specifics and be able to reuse the same, high level definition
defintion across different networking domains, WAN, DC or public
cloud.
Policy-based management is typically "push-based": Policies are Policy-based management is typically "push-based": Policies are
pushed onto devices where they are rendered and enforced. The push pushed onto devices where they are rendered and enforced. The push
operations are conducted by a manager or controller, which is operations are conducted by a manager or controller, which is
responsible for deploying policies across the network and monitor responsible for deploying policies across the network and monitor
their proper operation. That said, other policy architectures are their proper operation. That said, other policy architectures are
possible. For example, policy-based management can also include a possible. For example, policy-based management can also include a
pull-component in which the decision regarding which action to take pull-component in which the decision regarding which action to take
is delegated to a so-called Policy Decision Point (PDP). This PDP is delegated to a so-called Policy Decision Point (PDP). This PDP
can reside outside the managed device itself and has typically global can reside outside the managed device itself and has typically global
skipping to change at page 7, line 31 skipping to change at page 10, line 17
but lacks the full definition of the policy or the ability to reach a but lacks the full definition of the policy or the ability to reach a
conclusion regarding the expected action, it reaches out to the PDP conclusion regarding the expected action, it reaches out to the PDP
for a decision (reached, for example, by deciding on an action based for a decision (reached, for example, by deciding on an action based
on various conditions). Subsequently, the device carries out the on various conditions). Subsequently, the device carries out the
decision as returned by the PDP - the device "enforces" the policy decision as returned by the PDP - the device "enforces" the policy
and hence acts as a PEP (Policy Enforcement Point). Either way, PBM and hence acts as a PEP (Policy Enforcement Point). Either way, PBM
architectures typically involve a central component from which architectures typically involve a central component from which
policies are deployed across the network, and/or policy decisions policies are deployed across the network, and/or policy decisions
served. served.
4.3. Intent and Intent-Based Management Like Intent, policies provide a higher layer of abstraction. Policy
systems are also able to capture dynamic aspects of the system under
In the context of Autonomic Networks, Intent is defined as "an management through specification of rules that allow to define
abstract, high-level policy used to operate a network" [RFC7575]. various triggers for certain courses of actions. Unlike intent, the
According to this definition, an intent is a specific type of policy. definition of those rules (and courses of actions) still needs to be
However, to avoid using "intent" simply as a synonym for "policy, a articulated by users. Since the intent is unknown, conflict
clearer distinction needs to be introduced that distinguishes intent resolution within or between policies requires interactions with a
clearly from other types of policies. user or some kind of logic that resides outside of PBM.
Autonomic networks are expected to "self-manage" and operate with
minimal outside intervention. However, autonomic networks are not
clairvoyant and have no way of automatically knowing particular
operational goals nor what instances of networking services to
support. In other words, they do not know what the "intent" of the
network provider is that gives the network the purpose of its being.
This still needs to be communicated by what informally constitutes
"intent".
More specifically, intent is a declaration of high-level operational
goals that a network should meet, without specifying how to achieve
them. Those goals are defined in a manner that is purely declarative
- they specify what to accomplish or what the desired outcome for the
network operator is, not how to achieve it. This encompasses
abstraction from low-level device configurations, as well as
abstraction from particular management and control logic such as when
to spring into action.
In an autonomic network, intent should be rendered by the network
itself, i.e. translated into device specific rules and courses of
action. Ideally, it should not even be orchestrated or broken down
by a higher-level, centralized system, but by the network devices
themselves using a combination of distributed algorithms and local
device abstraction. Because intent holds for the network as a whole,
not individual devices, it needs to be automatically disseminated
across all devices in the network, which can themselves decide
whether they need to act on it. This facilitates management even
further, since it obviates the need for a higher-layer system to
break down and decompose higher-level intent, and because there is no
need to even discover and maintain an inventory of the network to be
able to manage it. Intent thus constitutes declarative policy with a
network-wide scope. A human operator defines 'what' is expected, and
the network computes a solution meeting the requirements. This
computation can occur in distributed or even decentralized fashion by
auonomic functions that reside on network nodes.
Other definitions of intent exist such as [TR523] and will be
investigated in future revisions of this document. Likewise, some
definitions of intent allow for the presence of a centralized
function that renders the intent into lower-level policies or
instructions and orchestrates them across the network. While to the
end user the concept of "intent" appears the same regardless of its
method of rendering, this interpretation opens a slippery slope of
how to clearly distinguish "intent" from other higher-layer
abstractions. Again, these notions will be further investigated in
future revisions of this document and in collaboration with NMRG.
5. Distinguishing between Intent, Policy, and Service Models 4.2.3. Distinguishing between Intent, Policy, and Service Models
What Intent, Policy, and Service Models all have in common is the What Intent, Policy, and Service Models all have in common is the
fact that they involve a higher-layer of abstraction of a network fact that they involve a higher-layer of abstraction of a network
that does not involve device-specifics, that generally transcends that does not involve device-specifics, 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. Service one device at a time. Beyond that, differences emerge. Service
models have less in common with policy and intent than policy and models have less in common with policy and intent than policy and
intent do with each other. intent do with each other.
Summarized differences: Summarized differences:
o A service model is a data model that is used to describe instances o 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 models (device and network models) when dependencies on lower level models (device and network models)
describing how the service is mapped onto underlying network and when describing how the service is mapped onto underlying network
IT infrastructure. Instantiating a service model requires and IT infrastructure. Instantiating a service model requires
orchestration by a system; the logic for how to 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 o 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 themselves, without requiring that can be rendered by devices themselves, without requiring
intervention by outside system. Policy is used to define what to intervention by outside system. Policy lets users define what to
do under what circumstances, but it does not specify a desired do under what circumstances, but it does not specify a desired
outcome. outcome.
o Intent is a higher-level declarative policy that operates at the o Intent is a higher-level declarative policy that operates at the
level of a network, not individual devices. It is used to define level of a network and services it provides, not individual
outcomes and high-level operational goals, without the need to devices. It is used to define outcomes and high-level operational
enumerate specific events, conditions, and actions. Ideally, goals, without the need to enumerate specific events, conditions,
intent is rendered by the network itself; also the dissemination and actions. Which algorithm or rules to apply can be
of intent across the network and any required coordination between automatically "learned/derived from intent" by the intent system.
nodes is resolved by the network itself without the need for In the context of autonomic networking, ideally, intent is
outside systems. rendered by the network itself; also the dissemination of intent
across the network and any required coordination between nodes is
resolved by the network itself without the need for outside
systems.
The TM Forum's Business Process Framework for network service One analogy to capture the difference between policy and intent
providers [eTOM] categorizes network operations broadly into three systems is that of Expert Systems and Learning Systems in the field
categories: Fulfillment, Assurance, and Billing. Intent is generally of Artificial Intelligence. Expert Systems operate on knowledge
tied to fulfillment, broadly defined as all activities and processes bases with rules that are supplied by users. They are able to make
having to do with configuration of the network to fulfill a given automatic inferences based on those rules, but are not able to
purpose. It is not tied to assurance, broadly defined as all "learn" on their own. Learning Systems (popularized by deep learning
activities and processes having to do with keeping the network and and neural networks), on the other hand, are able to learn without
services running (including monitoring, measuring, reporting, depending on user programming. However, they do require a learning
assessing compliance of service levels with service level objectives, or training phase and explanations of actions that the system
diagnostics, etc). Policy, on the other hand, aligns more closely actually takes provide a different set of challenges.
with assurance.
6. Items for Discussion 5. Principles
The following operating principles allow characterizing the intent-
based/-driven/-defined nature of a system.
1. Single Source of Truth (SSoT) and Single Version/View of Truth
(SVoT). The SSoT is an essential component of an intent-based
system as it enables several important operations. The set of
validated intent expressions is the system's SSoT. SSoT and the
records of the operational states enable comparing the intented
state and actual state of the system and determining drift
between them. SsoT and the drift information provide the basis
for corrective actions. If the intent-based is equipped with
prediction capabilities or means, it can further develop
strategies to anticipate, plan and pro-actively act on the
diverging trends with the aim to minimize their impact. Beyond
providing a means for consistent system operation, SSoT also
allows for better 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.
Single Version (or View) of Truth derives from the SSoT and can
be used to perform other operations such as query, poll or filter
the measured and correlated information to create so-called
"views". These views can serve the operators and/or the users of
the intent-based system. To create intents as single sources of
truth, the intent-based system must follow well-specified and
well-documented processes and models. In other contexts
[Lenrow15], SSoT is also referred to as the invariance of the
intent.
2. One touch but not one shot. In an ideal intent-based system, the
user expresses its intents in one form or another and then the
system takes over all subsequent operations (one touch). A zero-
touch approach could also be imagined in case where the intent-
based system has the capabilities or means to recognize
intentions in any form of data. However, the zero- or one-touch
approach should not be mistaken the fact that reaching the state
of a well-formed and valid intent expression is not a one-shot
process. On the contrary, the interfacing between the user and
the intent-based system could be designed as an interactive and
interactive process. Depending on the level of abstraction, the
intent expressions will initially contain more or less implicit
parts, and unprecise or unknown parameters and constraints. 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 be further used by the system for the
fulfillment and assurance operations. An intent refinement
process could use a combination of iterative steps involving the
user to validate the proposed refined intent and to ask the user
for clarifications in case some parameters or variables could not
be deduced or learned by the means of the system itself. In
addition, the Intent-Based System will need to moderate between
conflicting intent, helping users to properly choose between
intent alternatives that may have different ramifications.
3. Autonomy and Oversight. A desirable goal for an intent-based
system 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 intents using its own terms, by supporting
different forms of expression of intents and being capable of
refining the intent expressions to well-formed and exploitable
expressions. The dual principle of autonomy and oversight allows
to operate a system that will have the necessary levels of
autonomy to conduct its tasks and operations without requiring
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 expiations in terms of performance and quality, while at
the same time providing the proper level of oversight to satisfy
the user requirements for reporting and escalation of relevant
information. to be added: description for feedback, reporting,
guarantee scope (check points, guard rails, dynamically
provisioned, context rich, regular operation vs. exception/
abnormal, information zoom in-out, and link to SVoT. Accountable
for decisions and efficiency, late binding (leave it to the
system where to place functionality, how to accomplish certain
goals).
4. Learning. An intent-based system is a learning system. By
contrast to imperative type of system, such as Event-Condition-
Action policy rules, where the user define beforehand the
expected behavior of the system to various event and conditions,
in an intent-based system, the user only declare what the system
should 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
implies also the availability in the intent-based system of
capabilities or means for learning, reasoning and knowledge
representation and management. The learning abilities of an
intent-based systems can apply to different tasks such as
optimization of the intent rendering or intent refinement
processes. The fact that an intent-based system 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 intent-based system to
anticipate or forecast future system state and response to
changes in intents 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. Cope with unawareness of users (smart
recommendations).
5. Explainability. Need expressive network capabilities,
requirements and constraints to be able to compose/decompose
intents, map user's expectation to system capabilities.
capability exposure. not just automation of steps that need to
be taken, but of bridging the semantic gap between "intent" and
actionable levels of instructions Context: multi providers, need
discovery and semantic descriptions Explainability: why is a
network doing what it is doing
6. Abstraction - users do not need to be concerned with how intent
is achieved
Additional principles will be described in future revision of this
document addressing aspects such as: Target groups not individual
devices, agnostic to implementation details, user-friendly, user
vocabulary vs. language of the device/network, explainability,
validation and troubleshooting, how to resolve and point out
conflicts (between intents), reconcile the reality of what is
possible with the fiction of what the user would want, "moderate",
awareness of operating within system boundaries, outcome-driven
((what not how, for the user);(what and how/where, for the
operator).not imperative/instruction based.).
The above principles will be further used to understand implications
on the design of intent-based systems and their supporting
architecture, and derive functional and operational requirements.
6. Lifecycle
user related user data <-----<-+--------+
data + + | |
| | | |
+----v------+ +-----v-----+ | |
| recognize +---+ +-----+ generate | | |
user +-----------+ | | +-----------+ | |
space | | | |
+--------------------------------------------------------------------+
system | | | |
space +---v---v---+ +----------+ +-----+-----+ |
| translate <-->+ validate <---> recommend | |
+-----+-----+ +----------+ +-----------+ |
| |
+-----v-----+ |
| normalize | |
+-----+-----+ |
| |
+-----v-----+ |
| decompose | |
+-----+-----+ |
| |
+------v------+ |
| communicate | |
+------+------+ |
preparation | |
phase | |
+-------------------------------------------------------------------+
operation | |
phase +-----v----+ |
| fullfill | |
+-----+----+ |
| |
+----v----+ +--------+ |
| observe +-----> report +-------------------+
+----+----+ +--------+
|
+----v---+
| assure |
+--------+
Figure 1: Intent Lifecycle
The intent lifecycle is work in progress. Todo: Intent attributes,
intent states. Distinguish flow from users to network, and from
network to user.
Another version is depicted below. Some of the aspects worth
highlighting:
o There is a distinction between the traditional network operations
realm on one hand (providing fulfillment and assurance functions),
and the user realm on the other hand (who needs to give direction
to the network and be given information and reports regarding how
the network is doing. Intent-Based Systems provide the link
between those two realms.
o There is a genuine distinction between fulfillment operations,
used to drive intent into the network, orchestrate configuration
operations etc, aand assurance operations intended to gain a sense
of whether the network is performing as intended.
User Space : Translation / IBS : Network Ops
: Space : Space
: :
+---------+ : +----------+ +-----------+ : +---------+
Fulfill |recognize| ---> |translate/|-->|learn/plan/| ---> | config/ |
|intent | <--- | refine | | render | : |provision|
+---------+ : +----------+ +-----^-----+ : +---------+
: | : |
..............................................|..................|.....
: +----+---+ : v
: |validate| : +----------+
: +----^---+ <------| monitor/ |
Assure +-------+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <------| assure |
+-------+ : +---------+ |aggregate| : +----------+
: +---------+ :
Figure 2: Intent Lifecycle 2
7. Intent-Based Networking - Functionality
Intent-Based Networking involves a wide variety of functions which
can be roughly divided into two categories:
o Intent Fulfillment provides functions and interfaces that allow
users to communicate intent to the network, and that orchestrates
the intent, i.e. that breaks down intent abstractions into lower-
level network and device abstractions and performs or coordinates
the configuration operations across the network.
o Intent Assurance provides functions and interfaces that allow
users to validate and monitor that the network is indeed adhering
to and complying with intent. Control plane or lower-level
management operations can cause behavior that inadvertently
conflicts with intent which was orchestrated earlier.
Accordingly, "intent drift" may occur. Network operators need to
be able to detect when such drift occurs, or is about to occur,
and be provided with the necessary functions to resolve such
conflicts. This can occur by either bringing the network back
into compliance, or by articulating modifications to the original
intent to moderate between conflicting interests.
The following sections provide a more comprehensive overview of those
functions.
7.1. Intent Fulfillment
RBD
7.2. Intent Assurance
Ability to reason about system' state by employing closed-loop
validation in the presence of an inevitable change is a fundamental
property of an Intent Assurance part of an IBN system. Since service
expectations are created during intent consumption and modeling
phase, closed-loop intent vaidation should start immidiatelly, with
the service instantiation. Telemetry consumed could then be enriched
with an additional context and must always be processed in context of
the Intent it has been instantiated. Direct relationship between the
Intent and telemetry gathered enables correlation between changes in
states and the Intent and provides contextual base for reasoning
about the changes.
8. Research Challenges
8.1. Intent Interfaces
One goal for intent-based systems is to have the system "infer" the
intent of the user, rather than requiring the users to provide a
precise and complete set of instructions. Instead of forcing users
to speak the language of the system, the system should be able to
adapt to the needs of the user.
This requires new ways of interacting with users. An intent
interface may no longer necessarily involve an interface or API with
a clearly defined syntax and set of parameters. Instead, it may
apply alternative styles, for example of iterative interrogation- or
interview-style interfaces in which the system requests additional
information from the user as needed to provide clarification, to
select between alternatives, to refine intent.
8.2. Explanation Component
In an Intent-Based System, some of the actions taken by the network
or behavior observed may be difficult to understand, analogous to
deep learning systems which may have difficulty explaining their
actions. In a networking environment, this can create some problems
of its own, such as ensuring that the system is indeed functioning
correctly and not compromised, necessary to give network providers
the confidence that the Intent-Based Systems can indeed be relied on
in business-critical applications.
8.3. IBN Metrics to Guide Desired Outcomes
As Intent-Based Networks are driven by desired outcomes, how to
assess the quality of expected outcomes becomes critical.
Corresponding metrics and evaluation functions become the basis by
which IBNs can choose between different alternatives, and assess
their ability to "learn" and make progress.
9. Items for Discussion
Arguably, given the popularity of the term intent, its use could be Arguably, given the popularity of the term intent, its use could be
broadened to encompass also known concepts ("intent-washing"). For broadened to encompass also known concepts ("intent-washing"). For
example, it is conceivable to introduce intent-based terms for example, it is conceivable to introduce intent-based terms for
various concepts that, although already known, are related to the various concepts that, although already known, are related to the
context of intent. Each of those terms could then designate an context of intent. Each of those terms could then designate an
intent subcategory, for example: intent subcategory, for example:
o Operational Intent: defines intent related to operational goals of o Operational Intent: defines intent related to operational goals of
an operator; corresponds to the original "intent" term. an operator; corresponds to the original "intent" term.
skipping to change at page 10, line 18 skipping to change at page 19, line 5
o Rule Intent: a synonym for policy rules regarding what to do when o 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]. o Service intent: a synonym for customer service model [RFC8309].
o Flow Intent: A synonym for a Service Level Objective for a given o Flow Intent: A synonym for a Service Level Objective for a given
flow. flow.
Whether to do so is an item for discussion by the Research Group. Whether to do so is an item for discussion by the Research Group.
7. IANA Considerations 10. IANA Considerations
Not applicable Not applicable
8. Security Considerations 11. Security Considerations
Not applicable Not applicable
9. References 12. References
9.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 12.2. Informative References
[Boutaba07] [Boutaba07]
Boutaba, R. and I. Aib, "Policy-Based Management: A Boutaba, R. and I. Aib, "Policy-Based Management: A
Historical perspective. Journal of Network and Systems Historical perspective. Journal of Network and Systems
Management (JNSM), Springer, Vol. 15 (4).", December 2007. Management (JNSM), Springer, Vol. 15 (4).", December 2007.
[eTOM] "GB 921 Business Process Framework, Release 17.0.1.", [eTOM] TMForum, "GB 921 Business Process Framework, Release
February 2018. 17.0.1.", February 2018.
[I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J.,
Fioccola, G., and Q. Wu, "Traffic Engineering and Service
Mapping Yang Model", draft-ietf-teas-te-service-mapping-
yang-01 (work in progress), March 2019.
[Lenrow15]
Lenrow, D., "Intent As The Common Interface to Network
Resources, Intent Based Network Summit 2015 ONF Boulder:
IntentNBI", February 2015.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
skipping to change at page 11, line 34 skipping to change at page 20, line 28
[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] "Intent NBI - Definition and Principles. ONF TR-523.", [TR523] Foundation, O. N., "Intent NBI - Definition and
October 2016. Principles. ONF TR-523.", October 2016.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Huawei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: ludwig@clemm.org Email: ludwig@clemm.org
Laurent Ciavaglia Laurent Ciavaglia
Nokia Nokia
Route de Villejust Route de Villejust
Nozay 91460 Nozay 91460
FR FR
Email: laurent.ciavaglia@nokia.com Email: laurent.ciavaglia@nokia.com
Lisandro Zambenedetti Granville Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Goncalves Av. Bento Goncalves
Porto Alegre 9500 Porto Alegre 9500
BR BR
Email: granville@inf.ufrgs.br Email: granville@inf.ufrgs.br
Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com
 End of changes. 50 change blocks. 
189 lines changed or deleted 568 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/