< draft-clemm-nmrg-dist-intent-00.txt   draft-clemm-nmrg-dist-intent-01.txt >
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Futurewei Technologies, Inc. Internet-Draft Huawei
Intended status: Informational L. Ciavaglia Intended status: Informational L. Ciavaglia
Expires: May 3, 2018 Nokia Expires: January 19, 2019 Nokia
L. Granville L. Granville
Federal University of Rio Grande do Sul (UFRGS) Federal University of Rio Grande do Sul (UFRGS)
October 30, 2017 July 18, 2018
Distinguishing Intent, Policy, and Service Models Clarifying the Concepts of Intent and Policy
draft-clemm-nmrg-dist-intent-00 draft-clemm-nmrg-dist-intent-01
Abstract Abstract
This document presents existing definitions of the Intent, Policy, Intent and Intent-Based Networking are taking the industry by storm.
and Service Models concepts, analyses their differences and At the same time, those terms are used loosely and often
commonalities, and how the concepts relate to one another. The inconsistently, in many cases overlapping with other concepts such as
document is intended to clarify the different concepts and converge "policy". This document is therefore intended to clarify the concept
towards a common and shared understanding, and then use this of "Intent" and how it relates to other concepts. The goal is to
foundation to guide further definition of valid research and contribute towards a common and shared understanding of terms and
engineering problems and their solutions. concepts which can then be used as foundation to guide further
definition of valid 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 May 3, 2018. This Internet-Draft will expire on January 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 5 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 5 4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 4
4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 5 4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 4
4.2. Policy and Policy-Based Management . . . . . . . . . . . 6 4.2. Policy and Policy-Based Management . . . . . . . . . . . 6
4.3. Intent and Intent-Based Management . . . . . . . . . . . 7 4.3. Intent and Intent-Based Management . . . . . . . . . . . 7
5. Distinguishing between Intent, Policy, and Service Models . . 9 5. Distinguishing between Intent, Policy, and Service Models . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Items for Discussion . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 the individual network features and operations has focused on individual network and device features.
devices. The emphasis has generally been on aspects that needed to Standardization emphasis has generally been put on management
be provided by a networking device. A prime example for this is instrumentation that needed to be provided by a networking device. A
SNMP-based management and the 200+ MIBs that have been defined by the prime example for this is SNMP-based management and the 200+ MIBs
IETF over the years. More recent examples include NETCONF, RESTCONF, that have been defined by the IETF over the years. More recent
and YANG data model definitions including aspects such as interface examples include YANG data model definitions for aspects such as
configuration, ACL configuration, or Syslog configuration. However, interface configuration, ACL configuration, or Syslog configuration.
recent years have seen an increased interest in addressing also upper
layers of management and managing end-to-end concepts. Examples
include the definition of YANG models for network topology, or the
explanation of service models in the context of service orchestration
and controllers. In addition, this interest has been fueled by the
discussion about how to manage autonomic networks as discussed in the
ANIMA working group. Autonomic networks are driven by the need to
lower operational expenses and make management exceptionally easy,
putting it at odds with the need to manage the network one device and
one feature at a time.
It has been recognized for a long time that comprehensive management
solutions cannot operate only at the level of individual devices and
low-level configurations. ITU-T's TMN model introduced a set of
management layers as part of the TMN pyramid, consisting of network
element, network, service, and business management. High-level
operational objectives would propagate in top-down fashion from upper
to lower layers. The associated abstraction hierarchy was key to
decompose management complexity into separate areas of concerns.
This abstraction hierarchy was accompanied by an information
hierarchy that concerned itself at the lowest level with device-
specific information, but that would, at higher layers, include, for
example, end-to-end service instances.
Accordingly, there is generally a recognition that to be able to There is a sense that managing networks by configuring myriads of
manage networks efficiently end-to-end, management needs to be "nerd knobs" on a device-by-device basis is no longer sustainable in
applied at higher levels of abstraction than that of low-level device modern network environments. Big challenges arise with keeping
details. Instead, it is required to take a more holistic view, in device configurations not only consistent across a network, but
which device-specific details and data models are low-level artifacts consistent with the needs of services they are supposed to enable.
that should ideally be derived from higher-level concepts. This can At the same time, operations need to be streamlined and automated
be achieved, for example, by higher-level systems that break down wherever possible to not only lower operational expenses, but allow
higher-level concepts (such as an instance of a service) into for rapid reconfiguration of networks at sub-second time scales.
specific device configurations. Examples of such systems include SDN
controllers or service provisioning systems. Potentially, this can
be even done by intelligent devices themselves, for example, in case
of autonomic nodes in an autonomic network. The goal here is that
ultimately nodes are able to understand high-level concepts and
automatically coordinate with other nodes to achieve the desired end-
to-end behavior, without need for intermediate systems. While
autonomic networks are intended to exhibit "self-management"
properties, they still require input from an operator or outside
system to provide operational guidance and information about the
goals, purposes, and service instances that the network is to serve.
In the case of autonomic networks, the high-level guidance given to Accordingly, IETF has begun to address end-to-end management aspects
the network is commonly referred to as "Intent" [RFC7575]. The idea that go beyond the realm of individual devices in isolation.
behind Intent is that a user provides guidance to the network, for
example, communicate expectations regarding service level objectives
and service instances or regarding operational goals, such as whether
to optimize utilization or service levels in a certain operational
context. At the same time, the user should have neither to revert to
low-level configurations nor ideally have to learn a specific
language of the network. Instead, the user should be able to simply
express what the network should accomplish - to convey the user's
intent. Ideally, the network would be able to infer the intent using
a very high-level, natural language or conversational user interface.
The autonomic network would be able to interpret this intent and
break it down into low-level configurations as needed, even
automatically coordinating between nodes to negotiate and tune
behaviors. Intent would be conveyed to the autonomic network as a
whole; propagation of intent among devices would occur automatically,
as the user should not be concerned with individual nodes nor the
instantiation of intent across these nodes.
The vision of giving the user the ability to communicate to the Examples include the definition of YANG models for network topology
network in very simple, high-level terms what the network needs to [RFC8345] or the introduction of service models used by service
provide and have the network do the rest seems like the Holy Grail of orchestration systems and controllers [RFC8309]. In addition, a lot
intuition and ease-of-use for how to interact with a network. of interest has been fueled by the discussion about how to manage
Accordingly, the term "intent" has caught on rapidly and spread like autonomic networks as discussed in the ANIMA working group.
wildfire, being rapidly adopted also by SDN controllers and by Autonomic networks are driven by the desire to lower operational
management solutions, all proclaiming the higher-level abstractions expenses and make management of the network as a whole exceptionally
exposed of their own northbound interfaces as "intent". However, easy, putting it at odds with the need to manage the network one
somewhat overlooked in all this is the fact that, as mentioned above, device and one feature at a time. However, while autonomic networks
the concept of management or control abstraction hierarchies was not are intended to exhibit "self-management" properties, they still
invented with Intent. This concept has been known for a long time require input from an operator or outside system to provide
and variations of this concept incarnated in different forms in the operational guidance and information about the goals, purposes, and
past. Specifically: service instances that the network is to serve. It is in this
context that the term "intent" was coined for the first time.
Policy-based management has the goal of defining high-level This vision has since caught on with the industry in a big way,
policies that are subsequently translated and rendered into lower- leading to countless offerings that tout "intent-based management"
level actions and parameter settings at devices. Policies are that promise network providers to manage networks holistically at a
frequently defined in terms of rules, consisting of events (that higher level of abstraction and as a system that happens to consist
trigger a rule), conditions (that are assessed when the rule is of interconnected components, as opposed to a set of independent
triggered), and actions (that are carried out when the condition devices (that happen to be interconnected). Those offerings include
holds). However, many different categories of policies and ways SDN controllers (offering a single point of control and
to define them exist, ranging from ACL-style matching rules to administration for a network) as well as network management and
high-level declarative policy languages such as Ponder. Operations Support Systems (OSS).
[REFERENCES]
Service models define end-to-end service instances, which are in However, it has been recognized for a long time that comprehensive
turn mapped onto low-level configurations (often expressed via management solutions cannot operate only at the level of individual
device data models) that are applied across devices and resources devices and low-level configurations. In this sense, the vision of
in the network. "intent" is not entirely new. In the past, ITU-T's model of a
Telecommunications Management Network, TMN, introduced a set of
management layers that defined a management hierarchy, consisting of
network element, network, service, and business management. High-
level operational objectives would propagate in top-down fashion from
upper to lower layers. The associated abstraction hierarchy was key
to decompose management complexity into separate areas of concerns.
This abstraction hierarchy was accompanied by an information
hierarchy that concerned itself at the lowest level with device-
specific information, but that would, at higher layers, include, for
example, end-to-end service instances. Similarly, the concept of
"policy-based management" has for a long time touted the ability to
allow users to manage networks by specifying high-level management
policies, with policy systems automatically "rendering" those
policies, i.e. breaking them down into low-level configurations and
control logic.
This raises the question in which ways intent, policy, and service What is missing, however, is putting these concepts into a more
models are really different. Terms that are trending can become current context and defining a reference model that goes beyond a
easily overloaded and may end up being used as synonyms for terms TMN. This document attempts to clarify terminology and explain how
that had already been well-established before, not just for the new intent relates to other, similar concepts, in hope that a common and
and differentiating concept for which they were introduced. In order shared understanding of terms and concepts can be used as a
to avoid this situation, this document aims to provide a clear foundation to articulate research and engineering problems and their
distinction between these terms and what they represent. solutions.
Specifically, it aims to answer the question whether "intent" is just
a new term for "policy" (or "service model") or whether it represents
something genuinely different.
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
skipping to change at page 5, line 31 skipping to change at page 4, line 43
4. Introduction of Concepts 4. Introduction of Concepts
The following subsections provide an overview of the concepts of The following subsections provide an overview of the concepts of
service models, of policies respectively policy-based management, and service models, of policies respectively policy-based management, and
of intent respectively intent-based management. While the of intent respectively intent-based management. While the
descriptions are intentionally kept brief and do not provide detailed descriptions are intentionally kept brief and do not provide detailed
tutorials, they should convey the bigger picture of the purpose of tutorials, they should convey the bigger picture of the purpose of
each concept and provide a sense where those concepts are similar and each concept and provide a sense where those concepts are similar and
where they differ. With this background, the differences between where they differ. With this background, the differences between
them are summarized in the subsequent section. them are subsequently summarized in in another section.
4.1. Service Models 4.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. An example of a service could be a Layer 3 by a network to a user. Per [RFC8309], a service model describes a
VPN service, a Network Slice, or residential Internet access. service and its parameters in a portable way that can be used
Service models represent service instances as entities in their own independent of the equipment and operating environment on which the
right. Services have their own parameters, actions, and lifecycles. service is realized. Two subcategories are distinguished: a
Typically, service instances can be bound to end users, who might be "Customer Service Model" describes an instance of a service as
billed for the service. provided to a customer, possibly associated with a service order. A
"Service Delivery Model" describes how a service is instantiated over
existing networking infrastructure.
An example of a service could be a Layer 3 VPN service [RFC8299], a
Network Slice, or residential Internet access. Service models
represent service instances as entities in their own right. Services
have their own parameters, actions, and lifecycles. Typically,
service instances can be bound to end users, who might be billed for
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 Resources need to be allocated, such as IP addresses, interfaces,
bandwidth, or memory. 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 Bindings need to be maintained between upper- and lower-level
objects. objects.
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 conducted using a "push" provisioning logic. Orchestration itself is generally conducted
model, in which the controller/manager initiates the operations as using a "push" model, in which the controller/manager initiates the
required, pushing down the specific configurations to the device. operations as required, pushing down the specific configurations to
The device itself is typically agnostic to the service or the fact the device. The device itself typically remains agnostic to the
that its resources or configurations are part of a service/concept at service or the fact that its resources or configurations are part of
a higher layer. a service/concept at a higher layer.
Instantiated service models map to instantiated lower-layer models. Instantiated service models map to instantiated lower-layer network
Examples include instances of paths, or instances of specific port and device models. Examples include instances of paths, or instances
configurations. The service model typically also models dependencies of specific port configurations. The service model typically also
and layering of services over lower-layer networking resources that models dependencies and layering of services over lower-layer
are used to provide services. This facilitates management by networking resources that are used to provide services. This
allowing to follow dependencies for troubleshooting activities, to facilitates management by allowing to follow dependencies for
perform impact analysis in which events in the network are assessed troubleshooting activities, to perform impact analysis in which
regarding their impact on services and customers Services are events in the network are assessed regarding their impact on services
typically orchestrated or provisioned top-to-bottom, and to keep and customers Services are typically orchestrated and provisioned
track of the assignment of network resources. top-to-bottom, which also facilitates keeping track of the assignment
of network resources.
Service models also associate 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.
4.2. Policy and Policy-Based Management 4.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 today present 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
skipping to change at page 6, line 47 skipping to change at page 6, line 28
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 an 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, rules follow consists of events policy as a "rule". Typically, the definition of a rule consists of
(whose occurrence triggers a rule), conditions (that get assessed an event (whose occurrence triggers a rule), a set of conditions
before any actions are actually "fired"), and actions that 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
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.
Using policies, management can in effect be defined as a set of Using policies, management can in effect be defined as a set of
simple control loops. This makes policy-based management a suitable simple control loops. This makes policy-based management a suitable
technology to implement autonomic behavior that can exhibit self-* technology to implement autonomic behavior that can exhibit self-*
management properties including self-configuration, self-healing, management properties including self-configuration, self-healing,
self-optimization, and self-protection. In effect, policies define self-optimization, and self-protection. In effect, policies define
simple control loops typically used to define management as a set of simple control loops typically used to define management as a set of
skipping to change at page 7, line 24 skipping to change at page 7, line 5
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 the device subsequently "renders" the
policy, i.e., translates the canonical model into a device-specific policy, i.e., translates the canonical model into a device-specific
representation. This concept allows to apply the same policy across representation. This concept allows to apply the same policy across
a wide range of devices, which leads to operational scale and allows a wide range of devices without needing to define multiple variants.
network operators and authors of policies to think in higher terms of This enables operational scale and allows network operators and
abstraction than device specifics. authors of policies to think in higher terms of abstraction than
device specifics.
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
visibility and context with which to make policy decisions. Whenever visibility and context with which to make policy decisions. Whenever
a network device observes an event that is associated with a policy, a network device observes an event that is associated with a policy,
but lacks the full definition of the policy or the ability to reach a but lacks the full definition of the policy or the ability to reach a
conclusion regarding the expected action, it reaches out to the PDP conclusion regarding the expected action, it reaches out to the PDP
for a decision. Subsequently, the device carries out the decision as for a decision (reached, for example, by deciding on an action based
returned by the PDP - the device "enforces" the policy and hence acts on various conditions). Subsequently, the device carries out the
as a PEP (Policy Enforcement Point). Either way, PBM architectures decision as returned by the PDP - the device "enforces" the policy
typically involve a central component from which policies are and hence acts as a PEP (Policy Enforcement Point). Either way, PBM
deployed across the network, and/or policy decisions served. architectures typically involve a central component from which
policies are deployed across the network, and/or policy decisions
served.
4.3. Intent and Intent-Based Management 4.3. Intent and Intent-Based Management
In the context of Autonomic Networks, Intent is defined in as "an In the context of Autonomic Networks, Intent is defined as "an
abstract, high-level policy used to operate a network". According to abstract, high-level policy used to operate a network" [RFC7575].
this definition, an intent is a specific type of policy. However, to According to this definition, an intent is a specific type of policy.
avoid using "intent" simply as a synonym for "policy, a clearer However, to avoid using "intent" simply as a synonym for "policy, a
distinction needs to be introduced that distinguishes intent clearly clearer distinction needs to be introduced that distinguishes intent
from other types of policies. clearly from other types of policies.
Autonomic networks are expected to "self-manage" and operate with Autonomic networks are expected to "self-manage" and operate with
minimal outside intervention. However, autonomic networks are not minimal outside intervention. However, autonomic networks are not
clairvoyant and have no way of automatically knowing particular clairvoyant and have no way of automatically knowing particular
operational goals nor what instances of networking services to operational goals nor what 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 by what informally constitutes This still needs to be communicated by what informally constitutes
"intent". "intent".
More specifically, intent is a declaration of high-level operational More specifically, intent is a declaration of high-level operational
goals or services that are to be provided by the network, without goals that a network should meet, without specifying how to achieve
specifying how to achieve them. Those goals are defined in a manner them. Those goals are defined in a manner that is purely declarative
that is purely declarative - they specify what to accomplish or what - they specify what to accomplish or what the desired outcome for the
the desired outcome for the network operator is, not how to achieve network operator is, not how to achieve it. This encompasses
it or even when to spring into action. In addition, Intent (at least abstraction from low-level device configurations, as well as
in an Autonomic Network) should be rendered by network devices abstraction from particular management and control logic such as when
themselves, i.e., translated into device specific rules and courses to spring into action.
of action. It should not be orchestrated or broken down by a higher-
level, centralized system. Intent holds for the network as a whole, In an autonomic network, intent should be rendered by the network
not individual devices, and is hence automatically disseminated 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 across all devices in the network, which can themselves decide
whether they need to act on it. This facilitates management even whether they need to act on it. This facilitates management even
further, since it obviates the need for a higher-layer system to further, since it obviates the need for a higher-layer system to
break down and decompose higher-level intent, and because there is no 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 need to even discover and maintain an inventory of the network to be
able to manage it. able to manage it. Intent thus constitutes declarative policy with a
network-wide scope. A human operator defines 'what' is expected, and
Intent thus constititutes declarative policy with a network-wide the network computes a solution meeting the requirements. This
scope. A human operator defines 'what' is expected, and the network computation can occur in distributed or even decentralized fashion by
computes a solution meeting the requirements. This computation can auonomic functions that reside on network nodes.
occur in distributed or even decentralized fashion by auonomic
functions that reside on network nodes.
Other definitions of intent exist such as [ONF TR 523] and will be Other definitions of intent exist such as [TR523] and will be
investigated in future revisions of this document. Likewise, some investigated in future revisions of this document. Likewise, some
definitions of intent allow for the presence of a centralized definitions of intent allow for the presence of a centralized
function that renders the intent into lower-level policies or function that renders the intent into lower-level policies or
instructions and orchestrates them across the network. While to the instructions and orchestrates them across the network. While to the
end user the concept of "intent" appears the same regardless of its end user the concept of "intent" appears the same regardless of its
method of rendering, this interpretation opens a slippery slope of method of rendering, this interpretation opens a slippery slope of
how to clearly distinguish "intent" from other higher-layer how to clearly distinguish "intent" from other higher-layer
abstractions. Again, these notions will be further investigated in abstractions. Again, these notions will be further investigated in
future revisions of this document and in collaboration with NMRG. future revisions of this document and in collaboration with NMRG.
skipping to change at page 9, line 18 skipping to change at page 9, line 5
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 Service model is a data model with dependencies onto lower models. o A service model is a data model that is used to describe instances
It requires orchestration by a system; the logic to of services that are provided to customers. A service model has
orchestrate/manage/provide the service model is not included as dependencies on lower models (device and network models) when
part of the model itself. describing how the service is mapped onto underlying network and
IT infrastructure. Instantiating a service model requires
orchestration by a system; the logic for how to
orchestrate/manage/provide the service model and how to map it
onto underlying resources is not included as part of the model
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. intervention by outside system. Policy is used to define what to
do under what circumstances, but it does not specify a desired
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, not individual devices. It is used to define
operational goals and desired outcomes without the need to outcomes and high-level operational goals, without the need to
enumerate specific events, conditions, and actions. Intent is enumerate specific events, conditions, and actions. Ideally,
rendered by the network itself; also the dissemination of intent intent is rendered by the network itself; also the dissemination
across the network and any required coordination between nodes is of intent across the network and any required coordination between
resolved by the network itself without the need for outside nodes is resolved by the network itself without the need for
systems. outside systems.
6. IANA Considerations The TM Forum's Business Process Framework for network service
providers [eTOM] categorizes network operations broadly into three
categories: Fulfillment, Assurance, and Billing. Intent is generally
tied to fulfillment, broadly defined as all activities and processes
having to do with configuration of the network to fulfill a given
purpose. It is not tied to assurance, broadly defined as all
activities and processes having to do with keeping the network and
services running (including monitoring, measuring, reporting,
assessing compliance of service levels with service level objectives,
diagnostics, etc). Policy, on the other hand, aligns more closely
with assurance.
6. Items for Discussion
Arguably, given the popularity of the term intent, its use could be
broadened to encompass also known concepts ("intent-washing"). For
example, it is conceivable to introduce intent-based terms for
various concepts that, although already known, are related to the
context of intent. Each of those terms could then designate an
intent subcategory, for example:
o Operational Intent: defines intent related to operational goals of
an operator; corresponds to the original "intent" term.
o Rule Intent: a synonym for policy rules regarding what to do when
certain events occur.
o Service intent: a synonym for customer service model [RFC8309].
o Flow Intent: A synonym for a Service Level Objective for a given
flow.
Whether to do so is an item for discussion by the Research Group.
7. IANA Considerations
Not applicable Not applicable
7. Security Considerations 8. Security Considerations
Not applicable Not applicable
8. References 9. References
8.1. Normative References 9.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>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>.
[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>.
8.2. Informative References 9.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.",
February 2018.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[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.",
October 2016.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Futurewei Technologies, Inc. Huawei
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
 End of changes. 41 change blocks. 
211 lines changed or deleted 260 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/