<?xml version="1.0"?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>

<?rfc comments="yes"?>
<?rfc compact="no"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-nmrg-ibn-concepts-definitions-09" ipr="trust200902"> number="9315" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" category="info" consensus="true" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="5" version="3">

  <front>
    <title abbrev="">Intent-Based abbrev="Intent-Based Networking - Overview">Intent-Based Networking - Concepts and Definitions</title>
    <seriesInfo name="RFC" value="9315"/>
    <author fullname="Alexander Clemm" initials="A." surname="Clemm">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara,</city>
            <country>USA</country>
            <code>CA 95050</code> Clara</city>
          <code>95050</code>
	  <region>CA</region>
          <country>United States of America</country>
        </postal>
        <phone></phone>
        <phone/>
        <email>ludwig@clemm.org</email>
      </address>
    </author>

    <author fullname="Laurent Ciavaglia" initials="L" surname="Ciavaglia">
    <organization>Rakuten Mobile</organization>
      <organization>Nokia</organization>
      <address>
		<email>laurent.ciavaglia@rakuten.com</email>
	<postal>
	    <street>Route de Villejust</street>
          <code>91620</code>
          <city>Nozay</city>
          <country>France</country>
	</postal>
        <email>laurent.ciavaglia@nokia.com</email>
      </address>
    </author>

    <author fullname="Lisandro Zambenedetti Granville" initials="L. Z." surname="Granville">
      <organization>Federal University of Rio Grande do Sul (UFRGS)</organization>
      <address>
        <postal>
          <street>Av. Bento Gonçalves</street>
          <code>9500</code>
          <city>Porto Alegre</city>
			<country>BR</country>
	  <region>RS</region>
          <country>Brazil</country>
        </postal>
        <email>granville@inf.ufrgs.br</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
      <organization>Microsoft</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <date month="March" year="2022" /> month="October" year="2022"/>

    <workgroup>Network Management</workgroup>

    <keyword>Autonomic networking</keyword>
    <keyword>Network management</keyword>
   <keyword>Intent-based management</keyword>
    <keyword>Intent-based management</keyword>
    <keyword>Policy-based management</keyword>
    <keyword>policy</keyword>
    <keyword>policy-based network management</keyword>
    <keyword>abstraction</keyword>

    <abstract>
      <t>
		Intent and Intent-Based Networking (IBN) are taking the industry by
		storm.  At the same time, IBN-related terms related to Intent-Based Networking are often used
		loosely and inconsistently, in many cases overlapping and
		confused with other concepts such as "Policy." "policy."  This document
		clarifies the concept of "Intent" "intent" and provides an overview of
		the functionality that is associated with it.  The goal is to
		contribute towards a common and shared understanding of terms,
		concepts, and functionality that can be used as the foundation
		to guide further definition of associated research and
		engineering problems and their solutions.
      </t>
      <t>
    This document is a product of the IRTF Network Management Research Group (NMRG).
    It reflects the consensus of the research group, having received many detailed and positive reviews by RG research group participants.  It is published for informational purposes.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
    This document is a product of the IRTF Network Management Research Group (NMRG).
    It reflects the consensus of the RG, receiving reviews and explicit support from many participants.  It is published for informational purposes.
      </t>
      <t>
   In the past, interest regarding management and operations in the IETF has focused on individual network and device features. Standardization emphasis has generally been put on management instrumentation that needed to be provided to a networking device.
    A prime example of this is SNMP-based management <xref target= "RFC3411"/> target="RFC3411" format="default"/> and the 200+ MIBs that have been defined by the IETF over the years. More recent examples include YANG data model definitions <xref target="RFC7950"/> target="RFC7950" format="default"/> for aspects such as interface configuration, ACL Access Control List (ACL) configuration, and Syslog configuration.
      </t>
      <t>
    There is a clear sense and reality that managing networks by configuring myriads of "nerd knobs" on a device-by-device basis is no longer an option in modern network environments.
    Significant challenges arise with keeping device configurations not only consistent across a network but also consistent with the needs of services and service features they are supposed to enable. Additional challenges arise with regard to being able to rapidly adapt the network as needed and to be able to do so at scale.
    At the same time, operations need to be streamlined and automated wherever possible to not only lower operational expenses but also allow for rapid reconfiguration of networks at sub-second time scales and to ensure that networks are delivering their functionality as expected.  Among other things, this requires the ability to consume operational data, perform analytics, and dynamically take actions in a way that is aware of context as well as intended outcomes at near real-time speeds.
      </t>

      <t>
    Accordingly, the IETF has begun to address end-to-end management aspects
    that go beyond the realm of individual devices in isolation.  Examples
    include the definition of YANG models for network topology <xref target="RFC8345"/>
    target="RFC8345" format="default"/> or the introduction of service models
    used by service orchestration systems and controllers <xref target="RFC8309"/>.
    target="RFC8309" format="default"/>.  Much of the interest has been fueled
    by the discussion about how to manage autonomic networks, networks as discussed in
    the ANIMA working group. Working Group.  Autonomic networks are driven by the desire to
    lower operational expenses and make the management of the network as a
    whole more straightforward, 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.
      </t>

      <t>
   This input and operational guidance are commonly referred to as "intent,"
   and networks a network that allow allows network operators to provide their input using
   intent is referred to as an "Intent-Based Networks" (IBN) and the systems Network" (IBN), while a system
   that help helps implement intent is referred to as an "Intent-Based Systems" System"
   (IBS).  Those systems can manifest themselves in a number of ways, ways -- for example
   example, as a controller or managemement management system that are is implemented as an
   application that runs on a server or set of servers, or as a set of
   functions that are distributed across a network and that collectively
   perform their intent-based functionality.
      </t>

      <t>
	However, intent is about more than just enabling a form of operator interaction with the network that involves higher-layer abstractions.

It is also about the ability to let operators focus on what they want
their desired outcomes to be while leaving details to the IBN (respectively IBS)
about how those outcomes would, in fact, would be achieved to achieved.

Focusing on the IBN (respectively IBS).  This, in turn, outcome enables much greater operational efficiency and
flexibility at greater scale, in shorter time scales, and with less dependency on
human activities (and therefore less possibility for mistakes), and mistakes). This also makes Intent-Based Networking an ideal candidate, e.g.,
candidate for artificial intelligence techniques that can bring about the next
level of network automation <xref target="Clemm20"/>. target="CLEMM20" format="default"/>.

      </t>

      <t>
    This vision has since caught on with the industry, leading to a significant number of solutions that offer 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, components
    as opposed to a set of independent devices (that happen to be interconnected).  Those offerings include IBN IBNs and IBS IBSs (offering a full lifecycle life cycle of intent), SDN Software-Defined Network (SDN) controllers (offering a single point of control and administration for a network), and network management and Operations Support Systems (OSS). (OSSs).
      </t>
      <t>
    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, hierarchy consisting of network element, network, service, and business management <xref target=" M3010"/>. target="M3010" format="default"/>.
    High-level operational objectives would propagate in a top-down fashion from upper to lower layers.  The associated abstraction hierarchy was crucial to decompose management complexity into separate areas of concern.
    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 Network Management (PBNM) 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.  (As
      </t>

      <aside><t>As a note, in the context of this document, "users" generally refers to operators and administrators who are responsible for the management and operation of communication services and networking infrastructures, not to "end users" of communication services.)
    </t> services.</t>
</aside>

      <t>What has been missing, however, is putting these concepts into a more current context and updating them to account for current technology trends.   This document clarifies the concepts behind intent.  It differentiates intent from related concepts.  It also provides an overview of first-order principles of IBN Intent-Based Networking as well as the associated functionality.
    The goal is to contribute to a common and shared understanding that can be used as a foundation to articulate research and engineering problems in the area of IBN. Intent-Based Networking.
      </t>
      <t>It should be noted that the articulation of IBN-related research problems is beyond the scope of this document. However, it should be recognized that
    IBN
    Intent-Based Networking has become an important topic in the research community.  Per IEEE Xplore <xref target="IEEEXPLORE"/>, target="IEEEXPLORE" format="default"/>, as of December 2021, in the past decade since 2012, there have been 1138 papers with the index term "intent", of which 411 specifically mention networking.  The time period since 2020 alone accounts for 316 papers on intent and 153 for intent networking, indicating accelerating interest.  In addition, workshops dedicated to this theme are beginning to appear, such as the IEEE International Workshop on Intent-Based Networking
    <xref target="WIN21"/>, target="WIN21" format="default"/>, as well as various special journal issues <xref target="IEEE-TITS21"/> target="IEEE-TITS21" format="default"/> <xref target="MDPI22"/>. target="MDPI22" format="default"/>.  A survey of current intent-driven networking research has been published in <xref target="Pang20"/>, target="PANG20" format="default"/>, listing among the most pressing current research challenges aspects such as intent translation and understanding, intent interfaces, and security.
      </t>
    </section>
    <section title="Definitions and Acronyms">

<t>
<list style="empty">
    <t>ACL: Access numbered="true" toc="default">
      <name>Definitions and Acronyms</name>

     <dl newline="false" spacing="normal">
    <dt>ACL:</dt>
    <dd>Access Control List</t>
    <t>API: Application List</dd>
    <dt>API:</dt>
    <dd>Application Programming Interface</t>
    <t>Intent: Interface</dd>
    <dt>IBA:</dt>
    <dd>Intent-Based Analytics. Analytics that are defined and derived from users' intent and used to validate the intended state.</dd>
    <dt>IBN:</dt>
    <dd>Intent-Based Network. A network that can be managed using intent.</dd>
    <dt>IBS:</dt>
    <dd>Intent-Based System. A system that supports management functions that can be guided using intent.</dd>
    <dt>Intent:</dt>
    <dd>A set of operational goals (that a network should meet) and outcomes (that a network is supposed to
   deliver), deliver) defined in a declarative manner without specifying how to achieve or implement them.  </t>
    <t>IBA: Intent-Based Analytics - Analytics that are defined and derived from users' intent and used to validate the intended state.</t>
    <t>Intent-Based Management - The them.</dd>
    <dt>Intent-Based Management:</dt>
    <dd>The concept of performing management based on the concept of intent. </t>
    <t>IBN: Intent-Based Network - A network that can be managed using intent.</t>
    <t>IBS: Intent-Based System - A system that supports management functions that can be guided using intent.</t>
    <t>PBNM: Policy-Based intent.</dd>
    <dt>PBNM:</dt>
    <dd>Policy-Based Network Management </t>
    <t>Policy: A Management</dd>
    <dt>PDP:</dt>
    <dd>Policy Decision Point</dd>
    <dt>PEP:</dt>
    <dd>Policy Enforcement Point</dd>
    <dt>Policy:</dt>
    <dd>A set of rules that governs the choices in behavior of a system.</t>
    <t>PDP: Policy Decision Point</t>
    <t>PEP: Policy Enforcement Point</t>
    <t>Service Model: A system.</dd>
    <dt>Service Model:</dt>
    <dd>A model that represents a service that is provided by a network to a user.</t>
    <t>SSoT: Single user.</dd>
    <dt>SSoT:</dt>
    <dd>Single Source of Truth - Truth. A functional block in an IBN system that normalizes users' intent and serves as the single source
    of data for the lower layers.</t>
    <t>SVoT: Single layers.</dd>
    <dt>Statement of Intent:</dt>
    <dd>A specification of one particular aspect or component of intent, also referred to as an intent statement.</dd>
    <dt>SVoT:</dt>
    <dd>Single Version of Truth</t>
    <t>User: In Truth</dd>
    <dt>User:</dt>
    <dd>In the context of this document, an operator and/or administrator responsible for the management and operation of
    communication services and networking infrastructure (as opposed to an end user of a communication service)</t>
</list>
</t> service).</dd>
      </dl>
    </section>
    <section title="Introduction anchor="Concepts" numbered="true" toc="default">
      <name>Introduction of Concepts" anchor="Concepts"> Concepts</name>
      <t>The following section provides an overview of the concept of intent and Intent-Based Management.  It also provides an overview of the related concepts of service models and policies (and Policy-Based Network Management), and explains how they relate to intent and Intent-Based Management.
</t>
      <section title="Intent numbered="true" toc="default">
        <name>Intent and Intent-Based Management"> Management</name>
        <t>
 In this document, intent is defined as a set of operational goals (that a network is supposed to meet) and outcomes (that a network is supposed to deliver), deliver) defined in a declarative manner without specifying how to achieve or implement them.
        </t>
        <t>
The term "intent" was first introduced in the context of Autonomic Networks,
where it is defined as "an abstract, high-level policy used to operate a the network"
<xref target= "RFC7575"/>. target="RFC7575" format="default"/>.
According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the Autonomic Network that would otherwise operate without human intervention.
However, to avoid using intent simply as a synonym for policy, a distinction that differentiates intent clearly from other types of policies needs to be introduced.
</t>
<aside>
<t>
One note regarding the use of the plural form of "intent": in the English language, the term "intent" is generally used only in singular form.  However, the specification of intent as a whole usually involves the specification of several individual statements of intent, or intent statements.  In some cases, intent statements are colloquially also referred to as "intents", although in general, the use of the term "intents" is discouraged.
</t>
</aside>

        <t>
Intent-Based Management aims to lead towards networks that are fundamentally simpler to manage and operate, requiring only minimal outside intervention.
Networks, even when they are autonomic, are not clairvoyant and have no way of automatically knowing particular operational goals
nor which 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 to the network by what informally constitutes intent.
That being said, the concept of intent is not limited just to autonomic networks, such as networks that feature an Autonomic Control Plane <xref target="RFC8994"/>, target="RFC8994" format="default"/>, but applies to any network.
</t>
        <t>
 Intent defines goals and outcomes in a manner that is purely declarative, specifying what to accomplish,
   not how to achieve it.  Intent thus applies several important
   concepts simultaneously:
 <list style="symbols">
 <t>It
        </t>
        <ul spacing="normal">
          <li>It provides data abstraction: users Users do not need to be concerned with low-level device configuration and nerd knobs. </t>
 <t>It </li>
          <li>It provides functional abstraction from particular management and control logic: users Users do not need to be concerned even with how to achieve a given intent.  What is specified is the desired outcome, outcome with the IBS automatically figuring out a course of action (e.g., using an algorithm or applying a set of rules derived from the intent) for how to achieve the outcome. </t>
 </list>
 </t> </li>
        </ul>
        <t>
 The following are some examples of intent, expressed in natural language for the sake of clarity (actual interfaces used to convey intent may differ):
 <list style="symbols">
 <t>
        </t>
        <ul spacing="normal">

          <li> "Steer networking traffic originating from endpoints in one geography away from a second geography, unless the destination lies in that second geography." (States (states what to achieve, not how.)  </t>
  <t> </li>
          <li> "Avoid routing networking traffic originating from a given set of endpoints (or associated with a given customer) through a particular vendor's equipment, even if this occurs at the expense of reduced service levels." (States (states what to achieve, not how, providing additional guidance for how to trade off between different goals when necessary)</t>
  <t> necessary.)</li>
          <li> "Maximize network utilization even if it means trading off service levels (such as latency, loss) unless service levels have deteriorated 20% or more from their historical mean." (A (a desired outcome, with a set of constraints for additional guidance, which that does not specify how to achieve this.) </t>
 <t> "VPN service must this.)</li>

          <li> "Ensure VPN services have path protection at all times for all paths." (A (a desired outcome of which it may not be clear how it can be precisely accommodated.)  </t>
 <t> accommodated.)</li>

<li> "Generate in-situ OAM in situ Operations, Administration, and Maintenance (OAM) data and network telemetry for later offline analysis whenever significant fluctuations in latency across a path are observed." (Goes (goes beyond traditional event-condition-action by not being specific about what constitutes “significant” "significant" and what specific data to collect)</t>
 <t>"Route collect.)</li>

          <li>"Route traffic in a Space Information Network in a way that minimizes dependency on stratospheric balloons unless the intended destination is an aircraft." (Does (does not specify how to precisely achieve this; extrapolates on scenarios mentioned in <xref target="Pang20"/>) </t>
 <t>"For target="PANG20" format="default"/>.)</li>
          <li>"For a smart city service, ensure traffic signal control traffic uses dedicated and redundant slices that avoid fate sharing." (A (a desired outcome with a set of constraints and additional guidance without specifying how to precisely achieve this;
 extrapolates on scenarios from <xref target="Gharbaoui21"/>). </t>
 </list>
 </t> target="GHARBAOUI21" format="default"/>.)</li>
        </ul>
        <t>
 In contrast, the following are examples of what would not constitute intent (again, expressed in natural language for the sake of clarity):
 <list style="symbols">
 <t>
        </t>
        <ul spacing="normal">
          <li> "Configure a given interface with an IP address." This (This would be considered device configuration and fiddling with configuration knobs, not intent.</t>
 <t> intent.)</li>
          <li> "When interface utilization exceeds a specific threshold, emit an alert." This (This would be a rule that can help support network automation, but a simple rule is not an intent.  </t>
 <t> intent.)  </li>
          <li> "Configure a VPN with a tunnel from A to B over path P." This (This would be considered as a configuration of a service.</t>
 <t> service.)</li>
          <li> "Deny traffic to prefix P1 unless it is traffic from prefix P2." This (This would be an example of an access policy or a firewall rule, not  intent. </t>
 </list>
 </t>  intent.) </li>
        </ul>

<t>
In networks, in particular in networks that are deemed autonomic, intent should ideally be rendered by the network itself, i.e., translated into device-specific rules and courses of action.  Ideally, intent would not need to 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 abstractions.  In this idealized vision, because intent holds for the network as a whole, intent should ideally be automatically disseminated across all devices in the network, which can themselves decide whether they need to act on it.
        </t>
        <t>
   However, such decentralization will not be practical in all cases.
   Certain functions will need to be at least conceptually centralized.
   For example, users may require a single conceptual point of
   interaction with the network.
   The system providing this points point acts as the operational front end for the network through which users can direct requests at the network and from which they can receive updates about the network.  It may appear to users as a single system, even if it is implemented in a distributed manner.  In turn, it interacts with and manages other systems in the network as needed in order to realize (i.e., to fulfill and to assure) the desired intent.
   Likewise, the vast majority of network
   devices may be intent-agnostic and focus only (for example) on the
   actual forwarding of packets.  Many devices may also be constrained
   in terms of their processing resources.
   This means that not every device may be able to act on intent on its own.
   Again, intent in those cases can be achieved by a separate system which that performs the required actions.
	</t>

        <t>
 Another reason to provide intent functionality from a conceptually centralized point is in
   cases where the the realization of a certain type of intent benefits from global knowledge of a network and
   its state.  In many cases, such a global view may be impractical to maintain by individual devices, for example due to the volume of data and time lags that are involved.  It may even be impractical for devices to simply access such a view from another remote system if such were available.
</t>
        <t>
   All of this implies that in many cases, certain
   intent functionality needs to be provided by functions that are specialized for that purpose and that
   may be provided by dedicated systems (which in some cases could also co-host other networking functions).  For example, the translation of specific types of intent
   into corresponding courses of action and algorithms to achieve the
   desired outcomes may need to be provided by such specialized
   functions.  Of course, to avoid single points of failure, the
   implementation and hosting of such functions may still be
   distributed,
   distributed even if conceptually centralized.

        </t>
        <t>
Regardless of its particular implementation in a centralized or decentralized manner, an IBN is a network that can be managed using intent.  This means that it is able to recognize and ingest intent of an operator or user and configure and adapt itself according to the user intent, achieving an intended outcome (i.e., a desired state or behavior) without requiring the user to specify the detailed technical steps for how to achieve the outcome. Instead, the IBN will be able to figure out on its own how to achieve the outcome.
Similarly, an IBS is a system that allows users to manage a network using intent.  Such a system will serve as a point of interaction with users and implement the functionality that is necessary to achieve the intended outcomes, interacting for that purpose with the network as required.
</t>

<t>
  Other definitions of intent exist, such as <xref target="TR523"/>. target="TR523" format="default"/>.  Intent there is simply defined as a declarative interface that is typically provided by a controller.  It implies the presence of a centralized function that renders the intent into lower-level policies or instructions and orchestrates them across the network.  While this is certainly one way of implementation, the definition that is presented here is more encompassing and ambitious, as it emphasizes the importance of managing the network by specifying desired outcomes without the specific steps to be taken in order to achieve the outcome.

A controller API that simply provides a network-level of abstraction at the network level is more limited and would not necessarily qualify as intent.

Likewise, ingestion and recognition of intent may not necessarily occur via a traditional an API based on function invocations and simple request-response interactions but may involve other types of human-machine interactions. interactions such as dialogs to provide clarifications and refinements to requests.

</t>

      </section>
      <section title="Related Concepts"> numbered="true" toc="default">
        <name>Related Concepts</name>
        <section title="Service Models"> numbered="true" toc="default">
          <name>Service Models</name>
          <t>
A service model is a model that represents a service that is provided by a network to a user. Per <xref target=" RFC8309"/>, target="RFC8309" format="default"/>, a service model describes a service and its parameters in a portable/implementation-agnostic portable and implementation-agnostic way that can be used independently of the equipment and operating environment on which the service is realized. Two subcategories are distinguished: a "Customer Service Model" describes an instance of a service as provided to a customer, possibly associated with a service order.  A order, and a "Service Delivery Model" describes how a service is instantiated over existing networking infrastructure.
          </t>
          <t>
       An example of a service could be a Layer 3 VPN service <xref target="RFC8299"/>, target="RFC8299" format="default"/>, a Network Slice <xref target=" I-D.ietf-teas-ietf-network-slice-definition"/>, target="I-D.ietf-teas-ietf-network-slices" format="default"/>, or residential Internet access.
       Service models represent service instances as entities in their own right.
       Services have their own parameters, actions, and lifecycles. life cycles.
       Typically, service instances can be bound to end users of communication services, services who might be billed for the services provided.
</t>
          <t>
Instantiating a service typically involves multiple aspects:
<list style="symbols">
  <t>A
</t>
          <ul spacing="normal">
            <li>A user (or northbound system) needs to define and/or request a service to be instantiated.</t>
  <t>Resources, instantiated.</li>
            <li>Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, interfaces, bandwidth, or memory need to be allocated.</t>
  <t>How allocated.</li>
            <li>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 of a communication service with the service). </t>
  <t>Bindings </li>
            <li>Bindings between upper upper- and lower-level objects need to be maintained. </t>
  <t>Once </li>
            <li>Once instantiated, the service operational state needs to be validated and assured to ensure that the network indeed delivers the service as requested.</t>
</list>
</t> requested.</li>
          </ul>
          <t>
The realization of service models involves a system, such as a controller, that provides provisioning logic.  This includes breaking down high-level service abstractions into lower-level device abstractions, identifying and allocating system resources, and orchestrating individual provisioning steps.
Orchestration operations are generally conducted using a "push" model in which the controller/manager initiates the operations as required, then pushes down the specific configurations to the device and validates whether the new changes have been accepted and the new operational/derived states are achieved and in sync with the intent/desired state. In addition to instantiating and creating new instances of a service, updating, modifying, and decommissioning services also need to be also supported.
The device itself typically remains agnostic to the service or the fact that its resources or configurations are part of a service/concept at a higher layer.
</t>
          <t>
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, activities and 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, top to bottom, which also facilitates keeping track of the assignment of network resources (composition), while troubleshooted bottom-up bottom up (decomposition).
Service models might also be associated with other data that does not concern the network but provides business context.
This includes things such as customer data (such as billing information), service orders and service catalogs, tariffs, service contracts, and Service Level Agreements (SLAs), including contractual agreements regarding remediation actions.
</t>
          <t><xref target= "I-D.ietf-teas-te-service-mapping-yang"/> target="I-D.ietf-teas-te-service-mapping-yang" format="default"/> is an example of a data model that provides a mapping for customer service
   models (e.g., the L3VPN Service Model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks Virtual Network model)</t> model).</t>
          <t>
Like intent, service models provide higher layers of abstraction.  Service models are often also complemented with mappings that capture dependencies between service and device or network configurations.
Unlike intent, service models do not allow to define a desired "outcome" that would be automatically maintained by an IBS.
Instead, the management of service models requires the development of sophisticated algorithms and control logic by network providers or system integrators.
</t>
        </section>
        <section title="Policy numbered="true" toc="default">
          <name>Policy and Policy-Based Network Management"> Management</name>
          <t>
Policy-Based Network Management (PBNM) 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 present today at the heart of a multitude of management architectures
and paradigms, including SLA-driven, Business-driven, business-driven, autonomous, adaptive,
and self-* management <xref target=" Boutaba07"/>. target="BOUTABA07" format="default"/>.

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 will only provide a much-abridged and distilled overview.
</t>
          <t>
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 the behavior of a system" <xref target=" Sloman94"/>. target="SLOMAN94" format="default"/>.
"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" <xref target=" Strassner03"/>. target="STRASSNER03" format="default"/>.  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 (which get assessed and which must be true before any actions are actually "fired"), and, and finally, a set of one or more actions that are carried out when the condition holds.
</t>
          <t>
Policy-based management can be considered an imperative management paradigm: Policies precisely specified specify what needs to be done when and in which circumstance.  By 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. This
is notwithstanding the fact that policy-based management may make use of the
concept of abstractions (such as, "Bob gets gold service") that hide from the
user the specifics of how that abstraction is rendered in a particular
deployment.
</t>
          <t>
Policies typically involve a certain degree of abstraction in order to cope with the 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,
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 applied.
A policy agent on a controller or the device subsequently "renders" the policy, i.e., translates the canonical model into a device-specific representation.
This concept allows applying the same policy across a wide range of devices without needing to define multiple variants.  In other words - words, policy definition is de-coupled decoupled from policy instantiation and policy enforcement.
This enables operational scale and allows network operators and authors of policies to think in higher terms of abstraction than device specifics and be able to reuse the same, high-level definition across different networking domains, WAN, DC, data center (DC), or public cloud.
</t>
          <t>
 PBNM 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 controller that is responsible for deploying policies across the network and monitoring their proper operation.
 That being said, other policy architectures are possible.  For example, policy-based management can also include a pull-component 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 - PDP; the device "enforces" the policy and hence acts as a PEP (Policy Enforcement Point).  Either way, PBNM architectures typically involve a central component from which policies are deployed across the network and/or policy decisions served.
</t>
          <t>
Like Intent, intent, policies provide a higher layer of abstraction.  Policy systems are also able to capture dynamic aspects of the system under management through the specification of rules that allow defining various triggers for specific courses of action.
Unlike intent, the definition of those rules (and courses of action) still needs to be articulated by users.  Since the intent is unknown, conflict resolution within or between policies requires interactions with a user or some kind of logic that resides outside of PBNM.
In that sense, policy constitutes a lower level of abstraction than intent, and it is conceivable for Intent-Based Systems IBSs to generate policies that are subsequently deployed by a PBNM system, allowing PBNM to support Intent-Based Networking.
</t>
        </section>
        <section title= "Distinguishing numbered="true" toc="default">
          <name>Distinguishing between Intent, Policy, and Service Models"> Models</name>
          <t>
What Intent, Policy, intent, policy, and Service Models service models all have in common is the fact that they involve a higher-layer higher layer of abstraction of a network that does not involve device-specifics, that device specifics, 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.
	  </t>

          <t>
Summarized differences:
<list style="symbols">
<t>A
</t>
          <ul spacing="normal">
            <li>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-level models (device and network models) when describing how the service is mapped onto the 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.
</t>
<t>
</li>
            <li> 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 without requiring intervention by the outside system.
Policies let users define what to do under what circumstances, but they do not specify the desired outcome.
</t>
<t>Intent
</li>
            <li>Intent is a high-level, declarative goal that operates at the level of a network and services it provides, not individual devices.  It is used to define outcomes and high-level operational goals, without specifying how those outcomes should be achieved or how goals should specifically be satisfied, and without the need to enumerate specific events, conditions, and actions.
Which algorithm or rules to apply can be automatically "learned/derived from intent" by the IBS.
In the context of autonomic networking, intent is ideally rendered by the network itself; also, the dissemination of intent across the network and any required coordination between nodes is resolved by the network without the need for external systems.
</t>
</list>
</t>
</li>
          </ul>

          <t>
One analogy to capture the difference between policy policy-based systems and Intent-Based Systems IBSs is that of Expert Systems and Learning Systems in the field of Artificial Intelligence.  Expert Systems operate on knowledge bases with rules that are supplied by users, analogous to policy systems whose policies are supplied by users.
They are able to make automatic inferences based on those rules but are not able to "learn" new rules on their own.  Learning Systems (popularized by deep learning and neural networks), on the other hand, are able to learn without depending on user programming or articulation of rules.
However, they do require a learning or training phase requiring large data sets; explanations of actions that the system actually takes provide a different set of challenges.  Analogous to intent-based systems, IBSs, users focus on what they would like the learning system to accomplish but not how to do it.
</t>
        </section>
      </section>
    </section>
    <section title="Principles"> numbered="true" toc="default">
      <name>Principles</name>
      <t>
The following main operating principles allow characterizing the intent-based/-driven/-defined nature of a system.
      </t>
<t><list style="numbers">
<t> Single

	<ol spacing="normal" type="1"><li>

	  <t>Single Source of Truth (SSoT) and Single Version/View Version of Truth (SVoT).

	   The SSoT is an essential component of an intent-based system IBS as
	  it enables several important operations.  The set of validated
	  intent expressions is the system's SSoT.  SSoT and the records of
	  the operational states enable comparing the intended/desired state
	  and actual/operational states of the system and determining drift
	  between them.  SSoT and the drift information provide the basis for
	  corrective actions. If the IBS is equipped with the means to predict
	  states, it can further develop strategies to anticipate, plan, and
	  pro-actively act on any diverging trends with the aim to minimize
	  their impact.  Beyond providing a means for consistent system
	  operation, SSoT also allows for better traceability to validate
	  if/how the initial intent and associated business goals have been
	  properly met, met in order to evaluate the impacts of changes in the intent
	  parameters and impacts and effects of the events occurring in the
	  system.
<vspace/>
</t>
	            <t>
Single Version (or View) of Truth derives from the SSoT and can be used to perform other operations, operations such as querying, polling, or filtering measured and correlated information in order to create so-called "views." These views can serve the users of the intent-based system. IBS.
In order to create intents intent statements as single sources of truth, the IBS must follow well-specified and well-documented processes and models.
In other contexts, SSoT is also referred to as the invariance of the intent <xref target=" Lenrow15"/>. target="LENROW15" format="default"/>.
</t>
<t> One-touch
	  </li>

	<li><t>One touch but not one-shot. one shot.

	In an ideal intent-based system, IBS, the user expresses intent in one
	form or another, and then the system takes over all subsequent
	operations (one-touch). (one touch). A zero-touch approach could also be imagined
	in the case where the intent-based system IBS has the capabilities or
	means to recognize intentions in any form of data.  However, the zero-
	or one-touch approach should not distract from the fact that reaching
	the state of a well-formed and valid intent expression is not a
	one-shot process. On the contrary, the interfacing between the user
	and the intent-based system IBS could be designed as an interactive and
	iterative process.  Depending on the level of abstraction, the intent
	expressions may initially contain more or less implicit parts and unprecise
	imprecise or unknown parameters and constraints. The role of the intent-based system
	IBS is to parse, understand, and refine the intent
	expression to reach a well-formed and valid intent expression that can
	be further used by the system for the fulfillment and assurance
	operations.  An intent refinement process could use a combination of
	iterative steps involving the user to validate the proposed refined
	intent and to ask the user for clarifications in case some parameters
	or variables could not be deduced or learned by means of the system
	itself.  In addition, the Intent-Based System IBS will need to moderate
	between conflicting intent, helping users to properly choose between
	intent alternatives that may have different ramifications.
	</t>

<t> Autonomy
</li>
<li>Autonomy and Supervision.
A desirable goal for an intent-based system IBS is to offer a high degree of
flexibility and freedom on both the user side and system side, e.g., by giving
the user the ability to express intents intent using the user's own terms, by
supporting different forms of expression for individual statements of intents intent and being capable of
refining the intent expressions to well-formed and exploitable expressions.
The dual principle of autonomy and supervision allows operating a system that
will have the necessary levels of autonomy to conduct its tasks and operations
without requiring the intervention of the user and taking its own decisions
(within its areas of concern and span of control) as how to perform and meet
the user expectations in terms of performance and quality, while at the same
time providing the proper level of supervision to satisfy the user
requirements for reporting and escalation of relevant information.
</t>

<t> Learning.
</li>

<li>Learning.
An intent-based system IBS is a learning system.  In contrast to an imperative-type
imperative type of system, such as Event-Condition-Action policy rules, where
the user defines beforehand the expected behavior of the system to various
events and conditions, in an intent-based system, IBS, the user only declares what
the system is supposed to achieve and not how to achieve these goals.  There
is thus a transfer of reasoning/rationality from the human (domain knowledge)
to the system. This transfer of cognitive capability also implies the
availability in the intent-based system IBS of capabilities or means for learning,
reasoning, and knowledge representation and management.  The learning
abilities of an IBS can apply to different tasks such as optimization of the
intent rendering or intent refinement processes.  The fact that an intent-based system
IBS is a continuously evolving system creates the condition
for continuous learning and optimization. Other cognitive capabilities such as
planning can also be leveraged in an intent-based system IBS to anticipate or
forecast future system state and response to changes in intents intent or network
conditions and thus elaboration of plans to accommodate the changes while
preserving system stability and efficiency in a trade-off with cost and
robustness of operations.
</t>

<t> Capability
</li>

<li>Capability exposure.

Capability exposure consists in the need for expressive network
capabilities, requirements, and constraints to be able to compose/decompose intents
intent and map the user's expectations to the system capabilities.
</t>

<t>Abstract
</li>
<li>Abstract and outcome-driven.
Users do not need to be concerned with how intent is achieved and are
empowered to think in terms of outcomes.  In addition, they can refer to
concepts at a higher level of abstractions, independent e.g. independent, e.g., of
vendor-specific renderings.
</t>
</list>
</t>
</li></ol>

      <t>
The described principles are perhaps the most prominent, but they are not an exhaustive list. There are additional aspects to consider, such as:
<list style="symbols">
<t>
</t>
      <ul spacing="normal">
        <li>
Intent targets are not individual devices but typically aggregations (such as groups of devices adhering to a common criteria, such as devices of a particular role) or abstractions (such as service types, service instances, or topologies).
</t>
<t>Abstraction
</li>
        <li>Abstraction and inherent virtualization: agnostic to implementation details.</t>
<t>Human-tailored details.</li>
        <li>Human-tailored network interaction: IBN should speak the language of the user as opposed to requiring the user to speak the language of the device/network.</t>
<t>Explainability device/network.</li>
        <li>Explainability as an important IBN function, detection and IBN-aided resolution of conflicting intent, and reconciliation of what the user wants and what the network can actually do. </t>
<t>Inherent </li>
        <li>Inherent support, verification, and assurance of trust.</t>
</list>
</t> trust.</li>
      </ul>
      <t>
All of these principles and considerations have implications on the design of intent-based systems IBSs and their supporting architecture. Accordingly, they need to be considered when deriving functional and operational requirements.
</t>
    </section>
    <section title="Intent-Based anchor="Functionality" numbered="true" toc="default">
      <name>Intent-Based Networking - Functionality" anchor="Functionality"> Functionality</name>
      <t>
Intent-Based Networking involves a wide variety of functions that can be roughly divided into two categories:
<list style="symbols">
<t>Intent
</t>
      <ul spacing="normal">
        <li>Intent Fulfillment provides functions and interfaces that allow users to communicate intent to the network and that perform the necessary actions to ensure that intent is achieved.  This includes algorithms to determine proper courses of action and functions that learn to optimize outcomes over time.  In addition, it also includes more traditional functions such as any required orchestration of coordinated configuration operations across the network and rendering of higher-level abstractions into lower-level parameters and control knobs.
</t>
<t>Intent
</li>
        <li>Intent Assurance provides functions and interfaces that allow users to validate and monitor that the network is indeed adhering to and complying with intent.  This is necessary to assess the effectiveness of actions taken as part of fulfillment, providing important feedback that allows those functions to be trained or tuned over time to optimize outcomes.  In addition, Intent Assurance is necessary to address "intent drift."  Intent is not meant to be transactional, i.e. i.e., "set and forget", but is expected to be remain in effect over time (unless explicitly stated otherwise).  Intent drift occurs when a system originally meets the intent, but over time gradually allows its behavior to change or be affected until it no longer does or does so in a less effective manner.
</t>
</list>
</t>
</li>
      </ul>
      <t>
The following sections provide a more comprehensive overview of those functions.
</t>
      <section title="Intent Fulfillment"> numbered="true" toc="default">
        <name>Intent Fulfillment</name>
        <t>Intent fulfillment is concerned with the functions that take intent from its origination by a user (generally, an administrator of the responsible organization) to its realization in the network.
</t>
        <section title="Intent numbered="true" toc="default">
          <name>Intent Ingestion and Interaction with Users"> Users</name>
          <t>
	    The first set of functions is concerned with "ingesting" intent, i.e., obtaining intent through interactions with users.  They provide functions that recognize intent from interaction with the user as well as functions that allow users to refine their intent and articulate it in such ways so that it becomes actionable by an Intent-Based System. IBS.

	    Typically, those functions go beyond those provided by a traditional non-intent-based API, although non-intent-based APIs may also still be provided (and needed for interactions beyond human users, i.e., with other machines).

	    Many cases would also involve a set of intuitive and easy-to-navigate workflows that guide users through the intent ingestion phase, making sure that all inputs that are necessary for intent modeling and consecutive translation have been gathered.

They may support unconventional human-machine interactions, in which a human
will not simply give simple commands but which may involve instead a human-machine dialog is used to provide clarifications, to explain ramifications and trade-offs, and to
facilitate refinements.

</t>
          <t>The goal is ultimately to make IBSs as easy and natural to use and interact with as possible, in particular allowing human users to interact with the IBS in ways that do not involve a steep learning curve that forces the user to learn the "language" of the system. Ideally, it will be the Intent-Based Systems IBSs that is are increasingly be able to learn how to understand the user user, as opposed to the other way round. around.  Of course, further research will be required to make this a reality.
</t>
        </section>
        <section title="Intent Translation"> numbered="true" toc="default">
          <name>Intent Translation</name>
          <t>
A second set of functions needs to translate user intent into courses of action and requests to take against the network, which will be meaningful to network configuration and provisioning systems.  These functions lie at the core of IBS, bridging the gap between interaction with users on the one hand and the traditional management and operations side that will need to orchestrate provisioning and configuration across the network.
</t>
          <t>
Beyond merely breaking down a higher layer of abstraction (intent) into a lower layer of abstraction (policies, (policies and device configuration), Intent Translation functions can be complemented with functions and algorithms that perform optimizations and that are able to learn and improve over time in order to result in the best outcomes, specifically in cases where multiple ways of achieving those outcomes are conceivable. For example, satisfying an intent may involve computation of paths and other parameters that will need to be configured across the network. Heuristics and algorithms to do so may evolve over time to optimize outcomes that may depend on a myriad of dynamic network conditions and context.
</t>
        </section>
        <section title="Intent Orchestration"> numbered="true" toc="default">
          <name>Intent Orchestration</name>
          <t>
A third set of functions deals with the actual configuration and provisioning steps that need to be orchestrated across the network and that were determined by the previous intent translation step.
</t>
        </section>
      </section>
      <section title="Intent Assurance"> numbered="true" toc="default">
        <name>Intent Assurance</name>
        <t>Intent assurance Assurance is concerned with the functions that are necessary to ensure that the network indeed complies with the desired intent once it has been fulfilled.
</t>
        <section title="Monitoring"> numbered="true" toc="default">
          <name>Monitoring</name>
          <t>
A first set of assurance functions monitors and observes the network and its exhibited behavior. This includes all the usual assurance functions such as monitoring the network for events and performance outliers, performing measurements to assess service levels that are being delivered, and generating and collecting telemetry data. Monitoring and observation are required as the basis for the next set of functions that assess whether the observed behavior is in fact in compliance with the behavior that is expected based on the intent.
</t>
        </section>
        <section title="Intent numbered="true" toc="default">
          <name>Intent Compliance Assessment"> Assessment</name>
          <t>
At the core of Intent Assurance are functions that compare the actual network behavior that is being monitored and observed with the intended behavior that is expected per the intent and is held by SSoT.  These functions continuously assess and validate whether the observation indicates compliance with intent.
This includes assessing the effectiveness of intent fulfillment actions, including verifying that the actions had the desired effect and assessing the magnitude of the effect as applicable.  It can also include functions that perform analysis and aggregation of raw observation data. The results of the assessment can be fed back to facilitate learning functions that optimize outcomes.
</t>
          <t>
Intent compliance assessment also includes assessing whether intent drift occurs over time.  Intent drift can be caused by a control plane or lower-level management operations that inadvertently cause behavior changes which that conflict with intent that was orchestrated earlier.  Intent-Based Systems  IBSs and Networks need to be able to detect when such drift occurs or is about to occur as well as assess the severity of the drift.
</t>
        </section>
        <section title="Intent numbered="true" toc="default">
          <name>Intent Compliance Actions"> Actions</name>
          <t>
When intent drift occurs or network behavior is inconsistent with desired intent, functions that are able to trigger corrective actions are needed.  This includes actions needed to resolve intent drift and bring the network back into compliance.
Alternatively, and where necessary, reporting functions need to be triggered that alert operators and provide them with the necessary information and tools to react appropriately, e.g., by helping them articulate modifications to the original intent to moderate between conflicting concerns.
</t>
        </section>
        <section title="Abstraction, numbered="true" toc="default">
          <name>Abstraction, Aggregation, Reporting"> Reporting</name>
          <t>
The outcome of Intent Assurance needs to be reported back to the user in ways that allow the user to relate the outcomes to their intent.  This requires a set of functions that are able to analyze, aggregate, and abstract the results of the observations accordingly.  In many cases, lower-level concepts such as detailed performance statistics and observations related to low-level settings need to be "up-leveled" to concepts the user can relate to and take action on.
</t>
          <t>The required aggregation and analysis functionality needs to be complemented with functions that report intent compliance status and provide adequate summarization and visualization to human users.
</t>
        </section>
      </section>
    </section>
    <section title="Lifecycle"> numbered="true" toc="default">
      <name>Life Cycle</name>

      <t>
Intent is subject to a lifecycle: life cycle: it comes into being, may undergo changes over the course of time, and may at some point be retracted.  This lifecycle life cycle is closely tied to various interconnection functions that are associated with the intent concept.
</t>
      <t><xref target="Fig_Lifecycle"/> target="Fig_Lifecycle" format="default"/> depicts an intent lifecycle life cycle and its main functions.  The functions were introduced in <xref target=" Functionality"/> target="Functionality" format="default"/> and are divided into two functional (horizontal) planes, planes reflecting the distinction between fulfillment and assurance.  In addition, they are divided into three (vertical) spaces.
</t>
      <t>The spaces indicate the different perspectives and interactions with different roles that are involved in addressing the functions:
<list style="symbols">
<t>
</t>
      <ul spacing="normal">
        <li>
The User Space involves the functions that interface the network and intent-based system IBS with the human user.  It involves the functions that allow users to articulate and the intent-based system IBS to recognize that intent.  It also involves the functions that report back the status of the network relative to the intent and that allow users to assess outcomes and whether their intent has the desired effect.</t>
<t> effect.</li>
        <li>
The Translation, or Intent-Based System (IBS) Space involves the functions that bridge the gap between intent users and the network operations infrastructure.  This includes the functions used to translate an intent into a course of action as well as the algorithms that are used to plan and optimize those courses of action also in consideration of feedback and observations from the network.  It also includes the functions to analyze and aggregate observations from the network in order to validate compliance with the intent and to take corrective actions as necessary.  In addition, it includes functions that abstract observations from the network in ways that relate them to the intent as communicated by users.  This facilitates the reporting functions in the user space.</t>
<t> space.</li>
        <li>
The Network Operations Space, finally, involves the traditional orchestration, configuration, monitoring, and measurement functions, which are used to effectuate the rendered intent and observe its effects on the network.</t>
</list>
</t>
<t> network.</li>
      </ul>
      <figure anchor="Fig_Lifecycle" title="Intent Lifecycle">
<artwork>
<![CDATA[ anchor="Fig_Lifecycle">
        <name>Intent Life Cycle</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
         User Space   :       Translation / IBS       :  Network Ops
                      :            Space              :     Space
                      :                               :
        +----------+  :  +----------+   +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->|  learn/   |-->| configure/|
        |generate  |     |          |   |  plan/    |   | provision |
        |intent    |<--- |  refine  |   |  render   | : |           |
        +----^-----+  :  +----------+   +-----^-----+ : +-----------+
             |        :                       |       :        |
.............|................................|................|.....
             |        :                  +----+---+   :        v
             |        :                  |validate|   :  +----------+
             |        :                  +----^---+ <----| monitor/ |
Assure   +---+---+    :  +---------+    +-----+---+   :  | observe/ |
         |report | <---- |abstract |<---| analyze | <----|          |
         +-------+    :  +---------+    |aggregate|   :  +----------+
                      :                 +---------+   :
]]>
</artwork>
]]></artwork>
      </figure>
</t>
      <t>
When carefully inspecting the diagram, it becomes apparent that the intent lifecycle, life cycle, in fact, involves two cycles, or loops:
<list style="symbols">
<t>The
</t>
      <ul spacing="normal">
        <li>The "inner" intent control loop between IBS and Network Operations space is completely autonomic and does not involve any human in the loop.  It represents closed-loop automation that involves automatic analysis and validation of intent based on observations from the network operations space.  Those observations are fed into the function that plans the rendering of networking intent in order to make adjustments as needed in the configuration of the network. The loop addresses and counteracts any intent drift that may be occuring, occurring, using observations to assess the degree of the network's intent compliance and automatically prompting actions to address any discrepancies.  Likewise, the loop allows to assess the effectiveness of any actions that are taken in order to continuously learn and improve how intent needs to be rendered in order to achieve the desired outcomes.
</t>
<t>The
</li>
        <li>The "outer" intent control loop extends to the user space.  It includes the user taking action and adjusting their intent based on observations and feedback from the IBS. Intent is thus subjected to a lifecycle: life cycle: It comes into being, may undergo refinements, modifications, and changes of time, and may at some point in time even get retracted.  </t>
</list>
</t>  </li>
      </ul>
    </section>
    <section title="Additional Considerations"> numbered="true" toc="default">
      <name>Additional Considerations</name>
      <t>
Given the popularity of the term "intent," it is tempting to broaden it its use to encompass also other related concepts, resulting in "intent-washing" that paints those concepts in a new light by simply applying new intent terminology to them. A common example concerns referring to the northbound interface of SDN controllers as "intent interface". interface."  However, in some cases, this actually makes sense not just as a marketing ploy but as a way to better relate previously existing and new concepts.
</t>
      <t>
In that sense and with regards to intent, it makes sense to distinguish various subcategories of intent as follows:
<list style="symbols">
  <t>Operational
</t>

<dl>
  <dt>Operational Intent: defines
  </dt>
  <dd>defines intent related to operational goals of an operator; it
  corresponds to the original "intent" term and the concepts defined in this
  document.
  </t>
  <t>Rule
  </dd>

    <dt>Rule Intent: a
  </dt>
  <dd>a synonym for policy rules regarding what to do when certain events occur.
  </t>
  <t>Service intent: a
  </dd>

    <dt>Service Intent:
  </dt>
  <dd>a synonym for customer service model <xref target="RFC8309"/>.
  </t>
  <t>Flow target="RFC8309"
  format="default"/>.
  </dd>

    <dt>Flow Intent: A
  </dt>
  <dd>a synonym for a Service Level Objective for a given flow.
  </t>
</list>
</t>
  </dd>
</dl>

      <t>
A comprehensive set of classifications of different concepts and categories of intent will be described
in a separate document.
</t>
    </section>
    <section title="IANA Considerations">
<t> Not applicable </t> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document describes concepts and definitions of Intent-Based Networking. As such, the below security considerations remain high level, i.e. i.e., in the form of principles, guidelines guidelines, or requirements. More detailed security considerations will be described in the documents that specify the architecture and functionality.</t>
      <t>Security in Intent-Based Networking can apply to different facets:
<list style="symbols">
  <t>Securing
</t>
      <ul spacing="normal">
        <li>Securing the intent-based system itself.</t>
  <t>Mitigating IBS itself.</li>
        <li>Mitigating the effects of erroneous, harmful harmful, or compromised intents.</t>
  <t>Expressing intent statements.</li>
        <li>Expressing security policies or security-related parameters with intents.</t>
</list></t> intent statements.</li>
      </ul>
      <t>Securing the intent-based system IBS aims at making the intent-based system IBS operationally secure by implementing security mechanisms and applying security best practices. In the context of Intent-based Intent-Based Networking, such mechanisms and practices may consist in of intent verification and validation; validation, operations on intents intent by authenticated and authorized users only; only, and protection against or detection of tampered intents. statements of intent.

Such mechanisms may also include the introduction of multiple levels of intent. For example, intent related to securing the network should occur at a "deeper" level that overrides other levels of intent if necessary, and that is not subject to modification through regular operations but through ones that are specifically secured.  Use of additional mechanisms such as explanation components that describe the security ramifications and trade-off trade-offs should be considered as well.</t>
<t>Mitigating the effects of erroneous or compromised intents statements of intent aims at making
the intent-based system IBS operationally safe by providing checkpoint and
safeguard mechanisms and operating principles.

In the context of Intent-based Intent-Based
Networking, such mechanisms and principles may consist in of the ability to
automatically detect unintended, detrimental detrimental, or abnormal behavior; the
ability to automatically (and gracefully) rollback roll back or fallback fall back to a previous
"safe" state; the ability to prevent or contain error amplification (due to
the combination of a higher degree of automation and the intrinsic higher
degree of freedom, ambiguity, and implicitly implicit information conveyed by intents); intent statements); and dynamic
levels of supervision and reporting to make the user aware of the right information,
information at the right time with the right level of context.  Erroneous or
harmful intents intent statements may inadvertently propagate and compromise security. In
addition, compromised intents, for example, intent statements (for example, forged by an inside attacker,
attacker) may sabotage or harm the network resources and make them vulnerable
to further, larger attacks, e.g., by defeating certain security
mechanisms.</t>

<t>Expressing

      <t>
   Expressing security policies or security-related parameters with intents as intent
   consists of using the intent formalism (a high-level,
   declarative abstraction), abstraction) or part(s) of an intent statement to define
   security-related aspects such as data governance, level(s) as:
      </t>
   <ul>
     <li>data governance; </li>
   <li>level(s) of confidentiality in data exchange, level(s) exchange;</li>
   <li>level(s) of availability of system resources, of protection in
      forwarding paths, and of isolation in processing functions, level(s) functions;</li>
   <li>level(s) of encryption, authorized encryption; and</li>
   <li>authorized entities for given operations, etc.</t> operations.</li>
   </ul>

      <t>The development and introduction of Intent-Based Networking in operational environments will certainly create new security concerns. Such security concerns have to be anticipated at the design and specification time. However, Intent-Based Networking may also be used as an enabler for better security. For instance, security and privacy rules could be expressed in a more human-friendly and generic way and be less technology-specific technology specific and less complex, leading to fewer low-level configuration mistakes. The detection of threats or attacks could also be made more simple and comprehensive thanks to conflict detection at higher-level higher level or at coarser granularity</t> granularity.</t>
      <t>More thorough security analyses should be conducted as our understanding of Intent-Based Networking technology matures.</t>
    </section>
<section title="Acknowledgments">
<t>
We would like to thank the members of the IRTF Network Management Research Group (NMRG) for many valuable discussions and feedback. In particular, we would like to acknowledge the feedback and support from Remi Badonnel, Walter Cerroni,  Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, and Csaba Vulkan.  Of those, we would like to thank the following persons who went one step further and also provided reviews of the document: Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, and Csaba Vulkan.
</t>
</section>

  </middle>
  <back>

	<references title="Informative References">

  	    <?rfc include="reference.RFC.3411"?>
	    <?rfc include="reference.RFC.7575"?>
        <?rfc include="reference.RFC.7950"?>
		<?rfc include="reference.RFC.8174"?>
  		<?rfc include="reference.RFC.8299"?>
	    <?rfc include="reference.RFC.8309"?>
	  	<?rfc include="reference.RFC.8345"?>
        <?rfc include="reference.RFC.8994"?>
        <?rfc include="reference.I-D.ietf-teas-te-service-mapping-yang"?>
	<?rfc include="reference.I-D.ietf-teas-ietf-network-slice-definition"?>

<displayreference target="I-D.ietf-teas-te-service-mapping-yang" to="SERVICE-MAPPING-YANG"/>
<displayreference target="I-D.ietf-teas-ietf-network-slices" to="NETWORK-SLICE"/>

    <references>

      <name>Informative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3411.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8309.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/>

<reference anchor="I-D.ietf-teas-te-service-mapping-yang">
<front>
<title>
Traffic Engineering (TE) and Service Mapping YANG Data Model
</title>
<author initials="Y" surname="Lee" fullname="Young Lee" role="editor">
<organization>Samsung Electronics</organization>
</author>
<author initials="Dhruv" surname="Dhody" fullname="Dhruv Dhody" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author initials="G" surname="Fioccola"  fullname="Giuseppe Fioccola">
<organization>Huawei Technologies</organization>
</author>
<author initials="Q" surname="Wu" fullname="Qin Wu" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author initials="D" surname="Ceccarelli" fullname="Daniele Ceccarelli">
<organization>Ericsson</organization>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft</organization>
</author>
<date month="July" day="11" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-te-service-mapping-yang-11"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-teas-te-service-mapping-yang-11.txt"/>
</reference>

<reference anchor="I-D.ietf-teas-ietf-network-slices">
<front>
<title>Framework for IETF Network Slices</title>
<author initials="A" surname="Farrel" fullname="Adrian Farrel" role="editor">
<organization>Old Dog Consulting</organization>
</author>
<author initials="J" surname="Drake" fullname="John Drake" role="editor">
<organization>Juniper Networks</organization>
</author>
<author  initials="R" surname="Rokui" fullname="Reza Rokui">
<organization>Ciena</organization>
</author>
<author initials="S" surname="Homma" fullname="Shunsuke Homma">
<organization>NTT</organization>
</author>
<author  initials="K" surname="Makhijani" fullname="Kiran Makhijani">
<organization>Futurewei</organization>
</author>
<author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica</organization>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft Inc.</organization>
</author>
<date month="August" day="3" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-14"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-teas-ietf-network-slices-14.txt"/>
</reference>

      <reference anchor="M3010">
        <front>
    <title>M.3010 : Principles
          <title>Principles for a telecommunications management network.</title>
    <author fullname="ITU-T"> network</title>
          <author>
	  <organization>ITU-T</organization>
	  </author>
          <date month="February" year="2000" /> year="2000"/>
        </front>
	<seriesInfo name="ITU-T Recommendation" value="M.3010"/>
      </reference>

      <reference anchor="TR523">
        <front>
          <title>Intent NBI - Definition and Principles. ONF TR-523.</title>
	<author fullname="Open Principles</title>
          <author>
	    <organization>Open Networking Foundation"> Foundation</organization>
	</author>
          <date month="October" year="2016" /> year="2016"/>
        </front>
	<refcontent>ONF TR-523</refcontent>
      </reference>

      <reference anchor="Boutaba07"> anchor="BOUTABA07">
        <front>
          <title>Policy-Based Management: A Historical perspective. Journal of Network and Systems Management (JNSM), Springer, Vol. 15 (4).</title> Perspective</title>
          <author initials="R" surname="Boutaba" fullname="Raouf fullname="R. Boutaba">
	</author>
          <author initials="I" surname="Aib" fullname="Issam fullname="I. Aib">
	</author>
          <date month="December" year="2007" /> month="November" year="2007"/>
        </front>
	<seriesInfo name="DOI" value="10.1007/s10922-007-9083-8"/>
	<refcontent>Journal of Network and Systems Management (JNSM), Vol. 15, Issue 4</refcontent>
      </reference>

      <reference anchor="Clemm20"> anchor="CLEMM20">
        <front>
          <title>Network Management 2030: Operations and Control of Network 2030 Services.  Journal of Network and Systems Management (JNSM), Springer, Vol. 28 (4). </title> Services</title>
          <author initials="A" surname="Clemm" fullname="Alexander fullname="A. Clemm">
    </author>
          <author initials="M" surname="Faten Zhani" fullname="Mohamed Faten fullname="M. F. Zhani">
    </author>
          <author initials="R" surname="Boutaba" fullname="Raouf fullname="R. Boutaba">
    </author>
          <date month="October" year="2020" /> year="2020"/>
        </front>
	<seriesInfo name="DOI" value="10.1007/s10922-020-09517-0"/>
        <refcontent>Journal of Network and Systems Management (JNSM), Vol. 28, Issue 4</refcontent>
      </reference>

      <reference anchor="Lenrow15"> anchor="LENROW15">
        <front>
          <title>Intent As The Common Interface to Network Resources, Intent Based Network Summit 2015 ONF Boulder: IntentNBI</title> Resources</title>
          <author fullname="Dave initials="D" surname="Lenrow" fullname="D. Lenrow">
	</author>
          <date month="February" year="2015" /> year="2015"/>
        </front>
	<refcontent>Intent Based Network Summit 2015 ONF Boulder: IntentNBI</refcontent>
      </reference>

      <reference anchor="Sloman94"> anchor="SLOMAN94">
        <front>
          <title>Policy Driven Management for Distributed Systems. Journal of Network and Systems Management (JNSM), Springer, Vol. 2 (4).</title> Systems</title>
          <author initials="M" surname="Sloman" fullname="Morris fullname="M. Sloman">
	</author>
          <date month="December" year="1994" /> year="1994"/>
        </front>
	<refcontent>Journal of Network and Systems Management (JNSM), Vol. 2, Issue 4, pp. 333-360</refcontent>
      </reference>

      <reference anchor="Strassner03"> anchor="STRASSNER03">
        <front>
          <title>Policy-Based Network Management.  Elsevier.</title> Management</title>
          <author initials="J" surname="Strassner" fullname="John fullname="J. Strassner">
	</author>
          <date year="2003" /> month="August" year="2003"/>
        </front>
      </reference>

      <reference anchor="IEEEXPLORE"> anchor="IEEEXPLORE" target="https://ieeexplore.ieee.org/">
        <front>
    <title> IEEE eXplore, https://ieeexplore.ieee.org/ </title>
    <author fullname="IEEE">
          <title>IEEE Xplore</title>
          <author>
	  <organization>IEEE</organization>
	  </author>
    <date year="2021"/>
        </front>
      </reference>

      <reference anchor="WIN21"> anchor="WIN21" target="https://netsoft2021.ieee-netsoft.org/program/workshops/win-2021/">
        <front>
    <title> 1st IEEE
          <title>1st International Workshop on Intent-Based Networking, https://netsoft2021.ieee-netsoft.org/program/workshops/win-2021/ </title> Networking</title>
          <author initials="L" surname="Ciavaglia" fullname="L. Ciavaglia (co-chair)"> Ciavaglia"> </author>
          <author initials="E" surname="Renault" fullname="E. Renault (co-chair)"> Renault"> </author>
          <date month="June" year="2021"/>
        </front>
	<refcontent>IEEE International Conference on Network Softwarization</refcontent>
      </reference>

      <reference anchor="IEEE-TITS21">
        <front>
    <title>Special
          <title>Guest Editorial Special Issue on Intent-Based Networking for
          5G-Envisioned Internet of Connected Vehicles, in IEEE Transactions on Intelligent Transportation Systems, vol. 22, no. 8, DOI: 10.1109/TITS.2021.3101259</title> Vehicles</title>
<author initials="S" surname="Garg" fullname="S. Garg et al (Editors)"></author> Garg"/>
<author initials="M" surname="Guizani" fullname="M. Guizani"/>
<author initials="Y-C" surname="Liang" fullname="L-C. Liang"/>
<author initials="F" surname="Granelli" fullname="F. Granelli"/>
<author initials="N" surname="Prasad" fullname="N. Prasad"/>
<author initials="R. R. V." surname="Prasad" fullname="R. R. V. Prasad"/>
          <date month="August" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/TITS.2021.3101259"/>
	<refcontent>IEEE Transactions on Intelligent Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017</refcontent>
      </reference>

      <reference anchor="MDPI22">
        <front>
    <title>  Special
          <title>Special Issue "Intent-Based Software-Defined Networks", in Computers (MDPI) (to appear)</title> Networks"</title>
          <author initials="M" surname="Gharbaoui" fullname="Molka Gharbaoui (editor)"></author> fullname="M. Gharbaoui" role="editor"/>
          <date year="2022"/>
        </front>
	<refcontent>Computers (MDPI)</refcontent>
      </reference>

      <reference anchor="Pang20"> anchor="PANG20">
        <front>
          <title>A Survey on Intent-Driven Networks", in IEEE Access Vol 8 pp. 22862-22873,
    DOI: 10:110/ACCESS.2020.2969208 </title> Networks</title>
          <author initials="L" surname="Pang" fullname="L. Pang"> </author>
          <author initials="C" surname="Yang" fullname="C. Yang"> </author>
          <author initials="D" surname="Chen" fullname="D. Chen"> </author>
          <author initials="Y" surname="Song" fullname="Y. Song"> </author>
          <author initials="M" surname="Guizan" fullname="M. Guizan"> </author>
          <date year="2020" /> month="January" year="2020"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/ACCESS.2020.2969208"/>
	<refcontent>IEEE Access, Vol. 8, pp.22862-22873</refcontent>
      </reference>

      <reference anchor="Gharbaoui21"> anchor="GHARBAOUI21">
        <front>
     <title> "Implementation
          <title>Implementation of an Intent Layer for SDN-enabled and QoS-aware Network Slicing", in IEEE 7th Int. Conference on QoS-Aware Network Softwarization (NetSoft), pp 17-23, doi: 10.1109/NetSoft51509.2021.9492643 </title> Slicing</title>
          <author initials="M" surname="Gharbaoui" fullname="M. Gharbaoui"> </author>
          <author initials="B" surname="Martini" fullname="B. Martini"> </author>
          <author initials="P" surname="Castoldi" fullname="P. Castoldi"> </author>
          <date month="June" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/NetSoft51509.2021.9492643"/>
	<refcontent>2021 IEEE 7th International Conference on Network Softwarization (NetSoft), pp. 17-23</refcontent>
      </reference>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
We would like to thank the members of the IRTF Network Management Research Group (NMRG) for many valuable discussions and feedback. In particular, we would like to acknowledge the feedback and support from <contact fullname="Remi Badonnel"/>, <contact fullname="Walter Cerroni"/>,  <contact fullname="Marinos Charalambides"/>, <contact fullname="Luis Contreras"/>, <contact fullname="Jerome Francois"/>, <contact fullname="Molka Gharbaoui"/>, <contact fullname="Olga Havel"/>, <contact fullname="Chen Li"/>, <contact fullname="William Liu"/>, <contact fullname="Barbara Martini"/>, <contact fullname="Stephen Mwanje"/>, <contact fullname="Jeferson Nobre"/>, <contact fullname="Haoyu Song"/>, <contact fullname="Peter Szilagyi"/>, and <contact fullname="Csaba Vulkan"/>.  Of those, we would like to thank the following persons who went one step further and also provided reviews of the document: <contact fullname=" Remi Badonnel"/>, <contact fullname="Walter Cerroni"/>, <contact fullname="Jerome Francois"/>, <contact fullname="Molka Gharbaoui"/>, <contact fullname="Barbara Martini"/>, <contact fullname="Stephen Mwanje"/>, <contact fullname="Peter Szilagyi"/>, and <contact fullname="Csaba Vulkan"/>.
</t>
    </section>

  </back>
</rfc>