Network Working Group A. Clemm
Internet-Draft Futurewei Technologies, Inc.
Intended status: Informational L. Ciavaglia
Expires: May 3, 2018 Nokia
L. Granville
Federal University of Rio Grande do Sul (UFRGS)
October 30, 2017
Distinguishing Intent, Policy, and Service Models
draft-clemm-nmrg-dist-intent-00
Abstract
This document presents existing definitions of the Intent, Policy,
and Service Models concepts, analyses their differences and
commonalities, and how the concepts relate to one another. The
document is intended to clarify the different concepts and converge
towards a common and shared understanding, and then use this
foundation to guide further definition of valid research and
engineering problems and their solutions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Clemm, et al. Expires May 3, 2018 [Page 1]
Internet-Draft October 2017
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5
4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 5
4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 5
4.2. Policy and Policy-Based Management . . . . . . . . . . . 6
4.3. Intent and Intent-Based Management . . . . . . . . . . . 7
5. Distinguishing between Intent, Policy, and Service Models . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Traditionally in the IETF, interest with regard to management and
operations has focused on the individual network features and
devices. The emphasis has generally been on aspects that needed to
be provided by a networking device. A prime example for this is
SNMP-based management and the 200+ MIBs that have been defined by the
IETF over the years. More recent examples include NETCONF, RESTCONF,
and YANG data model definitions including aspects such as interface
configuration, ACL configuration, or Syslog configuration. However,
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
Clemm, et al. Expires May 3, 2018 [Page 2]
Internet-Draft October 2017
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
manage networks efficiently end-to-end, management needs to be
applied at higher levels of abstraction than that of low-level device
details. Instead, it is required to take a more holistic view, in
which device-specific details and data models are low-level artifacts
that should ideally be derived from higher-level concepts. This can
be achieved, for example, by higher-level systems that break down
higher-level concepts (such as an instance of a service) into
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
the network is commonly referred to as "Intent" [RFC7575]. The idea
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.
Clemm, et al. Expires May 3, 2018 [Page 3]
Internet-Draft October 2017
The vision of giving the user the ability to communicate to the
network in very simple, high-level terms what the network needs to
provide and have the network do the rest seems like the Holy Grail of
intuition and ease-of-use for how to interact with a network.
Accordingly, the term "intent" has caught on rapidly and spread like
wildfire, being rapidly adopted also by SDN controllers and by
management solutions, all proclaiming the higher-level abstractions
exposed of their own northbound interfaces as "intent". However,
somewhat overlooked in all this is the fact that, as mentioned above,
the concept of management or control abstraction hierarchies was not
invented with Intent. This concept has been known for a long time
and variations of this concept incarnated in different forms in the
past. Specifically:
Policy-based management has the goal of defining high-level
policies that are subsequently translated and rendered into lower-
level actions and parameter settings at devices. Policies are
frequently defined in terms of rules, consisting of events (that
trigger a rule), conditions (that are assessed when the rule is
triggered), and actions (that are carried out when the condition
holds). However, many different categories of policies and ways
to define them exist, ranging from ACL-style matching rules to
high-level declarative policy languages such as Ponder.
[REFERENCES]
Service models define end-to-end service instances, which are in
turn mapped onto low-level configurations (often expressed via
device data models) that are applied across devices and resources
in the network.
This raises the question in which ways intent, policy, and service
models are really different. Terms that are trending can become
easily overloaded and may end up being used as synonyms for terms
that had already been well-established before, not just for the new
and differentiating concept for which they were introduced. In order
to avoid this situation, this document aims to provide a clear
distinction between these terms and what they represent.
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Clemm, et al. Expires May 3, 2018 [Page 4]
Internet-Draft October 2017
3. Definitions and Acronyms
ACL: Access Control List
Intent: An abstract, high-level policy used to operate a network
[RFC7575].
Policy: A rule, or set of rules, that governs the choices in
behavior of a system.
PDP: Policy Decision Point
PEP: Policy Enforcement Point
Service Model: A model that represents a service that is provided
by a network to a user.
4. Introduction of Concepts
The following subsections provide an overview of the concepts of
service models, of policies respectively policy-based management, and
of intent respectively intent-based management. While the
descriptions are intentionally kept brief and do not provide detailed
tutorials, they should convey the bigger picture of the purpose of
each concept and provide a sense where those concepts are similar and
where they differ. With this background, the differences between
them are summarized in the subsequent section.
4.1. Service Models
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
VPN service, 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:
o Resources need to be allocated, such as IP addresses, interfaces,
bandwidth, or memory.
o How to map services to the resources needs to be defined.
Multiple mappings are often possible, which to select may depend
on context (such as which type of access is available to connect
the end user with the service).
Clemm, et al. Expires May 3, 2018 [Page 5]
Internet-Draft October 2017
o Bindings need to be maintained between upper- and lower-level
objects.
They involve a system, such as a controller, that provides
provisioning logic. Orchestration itself is conducted using a "push"
model, in which the controller/manager initiates the operations as
required, pushing down the specific configurations to the device.
The device itself is typically 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 models.
Examples include instances of paths, or instances of specific port
configurations. The service model typically also models dependencies
and layering of services over lower-layer networking resources that
are used to provide services. This facilitates management by
allowing to follow dependencies for troubleshooting activities, to
perform impact analysis in which events in the network are assessed
regarding their impact on services and customers Services are
typically orchestrated or provisioned top-to-bottom, and to keep
track of the assignment of network resources.
4.2. Policy and Policy-Based Management
Policy-based management (PBM) is a management paradigm that separates
the rules that govern the behavior of a system from the functionality
of the system. It promises to reduce maintenance costs of
information and communication systems while improving flexibility and
runtime adaptability. It is today present at the heart of a
multitude of management architectures and paradigms including SLA-
driven, Business-driven, autonomous, adaptive, and self-* management
[Boutaba07]. The interested reader is asked to refer to the rich set
of existing literature which includes this and many other references.
In the following, we an only provide a much-abridged and distilled
overview.
At the heart of policy-based management is the concept of a policy.
Multiple definitions of policy exist: "Policies are rules governing
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
maintaining of the state of one or more managed objects"
[Strassner03]. Common to most definitions is the definition of a
policy as a "rule". Typically, rules follow consists of events
(whose occurrence triggers a rule), conditions (that get assessed
before any actions are actually "fired"), and actions that are
carried out when the condition holds.
Clemm, et al. Expires May 3, 2018 [Page 6]
Internet-Draft October 2017
Policy-based management can be considered an imperative management
paradigm: Policies specify precisely what needs to be done when.
Using policies, management can in effect be defined as a set of
simple control loops. This makes policy-based management a suitable
technology to implement autonomic behavior that can exhibit self-*
management properties including self-configuration, self-healing,
self-optimization, and self-protection. In effect, policies define
simple control loops typically used to define management as a set of
simple control loops.
Policies typically involve a certain degree of abstraction in order
to cope with heterogeneity of networking devices. Rather than having
a device-specific policy that defines events, conditions, and actions
in terms of device-specific commands, parameters, and data models,
policy is defined at a higher-level of abstraction involving a
canonical model of systems and devices to which the policy is to be
applied. A policy agent on the device subsequently "renders" the
policy, i.e., translates the canonical model into a device-specific
representation. This concept allows to apply the same policy across
a wide range of devices, which leads to operational scale and allows
network operators and authors of policies to think in higher terms of
abstraction than device specifics.
Policy-based management is typically "push-based": Policies are
pushed onto devices where they are rendered and enforced. The push
operations are conducted by a manager or controller, which is
responsible for deploying policies across the network and monitor
their proper operation. That said, other policy architectures are
possible. For example, policy-based management can also include a
pull-component in which the decision regarding which action to take
is delegated to a so-called Policy Decision Point (PDP). This PDP
can reside outside the managed device itself and has typically global
visibility and context with which to make policy decisions. Whenever
a network device observes an event that is associated with a policy,
but lacks the full definition of the policy or the ability to reach a
conclusion regarding the expected action, it reaches out to the PDP
for a decision. Subsequently, the device carries out the decision as
returned by the PDP - the device "enforces" the policy and hence acts
as a PEP (Policy Enforcement Point). Either way, PBM 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
In the context of Autonomic Networks, Intent is defined in as "an
abstract, high-level policy used to operate a network". 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
Clemm, et al. Expires May 3, 2018 [Page 7]
Internet-Draft October 2017
distinction needs to be introduced that distinguishes intent clearly
from other types of policies.
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 or services that are to be provided by the network, 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 or even when to spring into action. In addition, Intent (at least
in an Autonomic Network) should be rendered by network devices
themselves, i.e., translated into device specific rules and courses
of action. It should not be orchestrated or broken down by a higher-
level, centralized system. Intent holds for the network as a whole,
not individual devices, and is hence 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 constititutes 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 [ONF TR 523] 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.
Clemm, et al. Expires May 3, 2018 [Page 8]
Internet-Draft October 2017
5. Distinguishing between Intent, Policy, and Service Models
What Intent, Policy, and Service Models all have in common is the
fact that they involve a higher-layer of abstraction of a network
that does not involve device-specifics, that generally transcends
individual devices, and that makes the network easier to manage for
applications and human users compared to having to manage the network
one device at a time. Beyond that, differences emerge. Service
models have less in common with policy and intent than policy and
intent do with each other.
Summarized differences:
o Service model is a data model with dependencies onto lower models.
It requires orchestration by a system; the logic to
orchestrate/manage/provide the service model is not included as
part of the model itself.
o Policy is a set of rules, typically modeled around a variation of
events/conditions/actions, used to express simple control loops
that can be rendered by devices themselves, without requiring
intervention by outside system.
o Intent is a higher-level declarative policy that operates at the
level of a network, not individual devices. It is used to define
operational goals and desired outcomes without the need to
enumerate specific events, conditions, and actions. Intent is
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.
6. IANA Considerations
Not applicable
7. Security Considerations
Not applicable
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Clemm, et al. Expires May 3, 2018 [Page 9]
Internet-Draft October 2017
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[Boutaba07]
Boutaba, R. and I. Aib, "Policy-Based Management: A
Historical perspective. Journal of Network and Systems
Management (JNSM), Springer, Vol. 15 (4).", December 2007.
[Sloman94]
Sloman, M., "Policy Driven Management for Distributed
Systems. Journal of Network and Systems Management (JNSM),
Springer, Vol. 2 (4).", December 1994.
[Strassner03]
Strassner, J., "Policy-Based Network Management.
Elsevier.", 2003.
Authors' Addresses
Alexander Clemm
Futurewei Technologies, Inc.
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ludwig@clemm.org
Laurent Ciavaglia
Nokia
Route de Villejust
Nozay 91460
FR
Email: laurent.ciavaglia@nokia.com
Clemm, et al. Expires May 3, 2018 [Page 10]
Internet-Draft October 2017
Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Goncalves
Porto Alegre 9500
BR
Email: granville@inf.ufrgs.br
Clemm, et al. Expires May 3, 2018 [Page 11]