[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                           A. Clemm
Internet-Draft                                                    Huawei
Intended status: Informational                              L. Ciavaglia
Expires: January 19, 2019                                          Nokia
                                                            L. Granville
                         Federal University of Rio Grande do Sul (UFRGS)
                                                           July 18, 2018


              Clarifying the Concepts of Intent and Policy
                    draft-clemm-nmrg-dist-intent-01

Abstract

   Intent and Intent-Based Networking are taking the industry by storm.
   At the same time, those terms are used loosely and often
   inconsistently, in many cases overlapping with other concepts such as
   "policy".  This document is therefore intended to clarify the concept
   of "Intent" and how it relates to other concepts.  The goal is to
   contribute towards a common and shared understanding of terms and
   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

   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 January 19, 2019.

Copyright Notice

   Copyright (c) 2018 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



Clemm, et al.           Expires January 19, 2019                [Page 1]


Internet-Draft                                                 July 2018


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   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  . . . . . . . . . . . . . . . . . .   4
   4.  Introduction of Concepts  . . . . . . . . . . . . . . . . . .   4
     4.1.  Service Models  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Policy and Policy-Based Management  . . . . . . . . . . .   6
     4.3.  Intent and Intent-Based Management  . . . . . . . . . . .   7
   5.  Distinguishing between Intent, Policy, and Service Models . .   8
   6.  Items for Discussion  . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Traditionally in the IETF, interest with regard to management and
   operations has focused on individual network and device features.
   Standardization emphasis has generally been put on management
   instrumentation 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 YANG data model definitions for aspects such as
   interface configuration, ACL configuration, or Syslog configuration.

   There is a sense that managing networks by configuring myriads of
   "nerd knobs" on a device-by-device basis is no longer sustainable in
   modern network environments.  Big challenges arise with keeping
   device configurations not only consistent across a network, but
   consistent with the needs of services they are supposed to enable.
   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.

   Accordingly, IETF has begun to address end-to-end management aspects
   that go beyond the realm of individual devices in isolation.



Clemm, et al.           Expires January 19, 2019                [Page 2]


Internet-Draft                                                 July 2018


   Examples include the definition of YANG models for network topology
   [RFC8345] or the introduction of service models used by service
   orchestration systems and controllers [RFC8309].  In addition, a lot
   of 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 desire to lower operational
   expenses and make management of the network as a whole exceptionally
   easy, putting it at odds with the need to manage the network one
   device and one feature at a time.  However, 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.  It is in this
   context that the term "intent" was coined for the first time.

   This vision has since caught on with the industry in a big way,
   leading to countless offerings that tout "intent-based management"
   that promise network providers to manage networks holistically at a
   higher level of abstraction and as a system that happens to consist
   of interconnected components, as opposed to a set of independent
   devices (that happen to be interconnected).  Those offerings include
   SDN controllers (offering a single point of control and
   administration for a network) as well as network management and
   Operations Support Systems (OSS).

   However, 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.  In this sense, the vision of
   "intent" is not entirely new.  In the past, ITU-T's model of a
   Telecommunications Management Network, TMN, introduced a set of
   management layers that defined a management hierarchy, 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.

   What is missing, however, is putting these concepts into a more
   current context and defining a reference model that goes beyond a
   TMN.  This document attempts to clarify terminology and explain how



Clemm, et al.           Expires January 19, 2019                [Page 3]


Internet-Draft                                                 July 2018


   intent relates to other, similar concepts, in hope that a common and
   shared understanding of terms and concepts can be used as a
   foundation to articulate research and engineering problems and their
   solutions.

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.

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 subsequently summarized in in another section.

4.1.  Service Models

   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
   service and its parameters in a portable way that can be used
   independent of the equipment and operating environment on which the
   service is realized.  Two subcategories are distinguished: a



Clemm, et al.           Expires January 19, 2019                [Page 4]


Internet-Draft                                                 July 2018


   "Customer Service Model" describes an instance of a service as
   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:

   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).

   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 generally 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 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
   and device 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 and provisioned
   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



Clemm, et al.           Expires January 19, 2019                [Page 5]


Internet-Draft                                                 July 2018


   service catalogues, tariffs, service contracts, and Service Level
   Agreements (SLAs) including contractual agreements regarding
   remediation actions.

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, the definition of a rule consists of
   an event (whose occurrence triggers a rule), a set of conditions
   (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.

   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



Clemm, et al.           Expires January 19, 2019                [Page 6]


Internet-Draft                                                 July 2018


   representation.  This concept allows to apply the same policy across
   a wide range of devices without needing to define multiple variants.
   This enables 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 (reached, for example, by deciding on an action based
   on various conditions).  Subsequently, the device carries out the
   decision as returned by the PDP - the device "enforces" the policy
   and hence acts as a PEP (Policy Enforcement Point).  Either way, 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 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.

   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



Clemm, et al.           Expires January 19, 2019                [Page 7]


Internet-Draft                                                 July 2018


   - 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

   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:




Clemm, et al.           Expires January 19, 2019                [Page 8]


Internet-Draft                                                 July 2018


   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
      dependencies on lower models (device and network models) when
      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
      events/conditions/actions, used to express simple control loops
      that can be rendered by devices themselves, without requiring
      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
      level of a network, not individual devices.  It is used to define
      outcomes and high-level operational goals, without the need to
      enumerate specific events, conditions, and actions.  Ideally,
      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.

   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:





Clemm, et al.           Expires January 19, 2019                [Page 9]


Internet-Draft                                                 July 2018


   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

8.  Security Considerations

   Not applicable

9.  References

9.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>.

   [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>.

9.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.

   [eTOM]     "GB 921 Business Process Framework, Release 17.0.1.",
              February 2018.








Clemm, et al.           Expires January 19, 2019               [Page 10]


Internet-Draft                                                 July 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]
              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.

   [TR523]    "Intent NBI - Definition and Principles. ONF TR-523.",
              October 2016.

Authors' Addresses

   Alexander Clemm
   Huawei
   2330 Central Expressway
   Santa Clara,  CA 95050
   USA

   Email: ludwig@clemm.org










Clemm, et al.           Expires January 19, 2019               [Page 11]


Internet-Draft                                                 July 2018


   Laurent Ciavaglia
   Nokia
   Route de Villejust
   Nozay  91460
   FR

   Email: laurent.ciavaglia@nokia.com


   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 January 19, 2019               [Page 12]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/