draft-nmrg-ibn-concepts-definitions-00.xml

<?xml version="1.0"?>
<!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"?>


<rfc category="info" docName="draft-irtf-nmrg-ibn-concepts-definitions-00" ipr="trust200902">

<front>
<title abbrev="">Intent-Based Networking - Concepts and Definitions</title>


<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>
        </postal>
        <phone></phone>
        <email>ludwig@clemm.org</email>
    </address>
</author>

<author fullname="Laurent Ciavaglia" initials="L"
    surname="Ciavaglia">
    <organization>Nokia</organization>
 	<address>
		<postal>
			<street>Route de Villejust</street>
			<code>91460</code>
			<city>Nozay</city>
			<country>FR</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>
		</postal>
		<email>granville@inf.ufrgs.br</email>
	</address>
</author>

<author fullname="Jeff Tantsura" initials="J"
    surname="Tantsura">
    <organization>Apstra, Inc.</organization>
 	<address>
		<email>jefftant.ietf@gmail.com</email>
	</address>
</author>
<date month="December" year="2019" />

<abstract>
	<t>
		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 and confused with other concepts such as "policy".  
    This document is intended to clarify the concept of "Intent" and provide an overview of functionality that associated with it.  
    The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality which can be used as foundation to guide further definition of associated research and engineering problems and their solutions.
    </t>
</abstract>

</front>


<middle>
<section anchor="intro" title="Introduction">
    <t>
    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 to 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. 
    </t>
    <t>
    There is a sense and reality that in modern network environments managing networks by configuring myriads of "nerd knobs" on a device-by-device basis is no longer sustainable.  
    Big challenges arise with keeping device configurations not only consistent across a network, but consistent with the needs of services and service features they are supposed to enable.
    Adoptability to changes at scale is a fundamental property of a well designed IBN system, that requires abilty to consume and process analytics that are context/intent aware at near real time speeds. 
    At the same time, operations need to be streamlined and automated wherever possible to not only lower operational expenses, but allow for rapid reconfiguration of networks at sub-second time scales and to ensure networks are delivering their functionality as expected.  
    </t>
    <t>
    Accordingly, 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"/> or the introduction of service models used by service orchestration systems and controllers <xref target="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.      
    </t>
    <t>
    This vision has since caught on with the industry in a big way, leading to a significant number 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, 
    as opposed to a set of independent devices (that happen to be interconnected).  Those offerings include IBN systems (offering full lifecycle of intent), SDN controllers (offering a single point of control and administration for a network) as well as network management and Operations Support Systems (OSS).  
    </t>
    <t> 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.  
    </t>
    <t>What has been missing, however, is putting these concepts into a more current context and updating it to account for current technology trends.   This document attempts to clarify the concepts behind intent.  It differentiates it from related concepts.  It also provides an overview of first-order principles of Intent-Based Networking as well as associated functionality.  In addition, a number of research challenges are highlighted.  
    The goal is to contribute to a common and shared understanding that can be used as a foundation to articulate research and engineering problems in the area of Intent-Based Networking.
    </t>
 
   
</section>


 <section title="Key Words">
   <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> 
      when, and only when, they
      appear in all capitals, as shown here.
   </t>
   </section>
	
	<section title="Definitions and Acronyms">

<t>
<list style="empty">
    <t>ACL: Access Control List</t>
    <t>Intent: An abstracted, declarative and vendor agnostic set of rules used to provide full lifecycle (Design/Build/Deploy/Validate) to a network and services it provides.</t>
	<t>Policy: A rule, or set of rules, that governs the choices in behavior of a system.</t>
    <t>SSoT: Single Source of Truth - A functional block in an IBN system that normalizes user' intent and serves as the single source of data for the lower layers.</t>
    <t>IBA: Intent Based Analytics - Analytics that are defined and derived from user' intent and used to validate the intended state.</t>
    <t>IBS: Intent Based System.</t>
    <t>PDP: Policy Decision Point</t>
    <t>PEP: Policy Enforcement Point</t>
    <t>Service Model: A model that represents a service that is provided by a network to a user.</t>
</list>
</t>
</section>

<section title="Introduction of Concepts" anchor="Concepts">

<t>The following section provides an overview of the concept of intent respectively intent-based management.  It also provides an overview of the related concepts of service models, and of policies respectively policy-based management, and explains how they relate to intent and intent-based management.   
</t>

<section title="Intent and Intent-Based Management">
<t>
In the context of Autonomic Networks, Intent is defined as "an abstract, high-level policy used to operate a network" <xref target="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.   
</t>
<t>
For one, while Intent-Based Management clearly aims to lead towards networks that are dramatically simpler to manage and operate requiring only minimal outside intervention, the concept of "intent" is not limited to autonomic networks, but applies to any network.  Networks, even when considered "autonomic", are not clairvoyant and have no way of automatically knowing particular operational goals 
nor what instances of networking services to support.  In other words, they do not know what the "intent" of the network provider is that gives the network the purpose of its being.  This still needs to be communicated by what informally constitutes "intent". 
</t>
<t> 
 More specifically, intent is a declaration of operational goals that a network should meet and outcomes that the network is supposed to deliver, without specifying how to achieve them.  Those goals and outcomes are defined in a manner that is purely declarative - they specify what to accomplish, not how to achieve it.  "Intent" thus applies several important concepts simultaneously:
 <list style="symbols">
 <t>It provides data abstraction: Users and operators do not need to be concerned with low-level device configuration and nerd knobs. </t>
 <t>It provides functional abstraction from particular management and control logic: Users and operators do not need to be concerned even with how to achieve a given intent.  What is specified is a desired outcome, with the intent-based system automatically figuring out a course of action (e.g. a set of rules, an algorithm) for how to achieve the outcome. </t>
 </list>
 </t>
 <t>
 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.
 </t>
 <t>
 Tentative definition for intent-based networks
 Networks configuring and adapting autonomously to the user or operator intentions (i.e., a desired state or behavior) without the need to specify every technical detail of the process and operations to achieve it (i.e., the "machines" will figure out on their own how to realize the user goal).
 </t>
<t>Other definitions of intent exist such as <xref target="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.    
  </t>
</section>

<section title="Related Concepts">

<section title="Service Models">
<t>
A service model is a model that represents a service that is provided by a network to a user. Per <xref target="RFC8309"/>, a service model describes a service and its parameters in a
      portable/vendor agnostic way that can be used independent 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 "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"/>, 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.  
</t>
<t>
Instantiating a service typically involves multiple aspects:  
<list style="symbols">
  <t>A user (or northbound system) needs to define and/or request a service to be instantiated.</t>
  <t>Resources need to be allocated, such as IP addresses, AS numbers, VLAN or VxLAN pools, interfaces, bandwidth, or memory.</t>
  <t>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). </t> 
  <t><xref target="I-D.ietf-teas-te-service-mapping-yang"/> is an example of such mapping - a data model to map customer service
   models (e.g., the L3VPM Service Model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks Virtual Network model)</t>
  <t>Bindings need to be maintained between upper and lower-level objects. </t>
  <t>Once instantiated, the service needs to be validated and assured to ensure that the network indeed delivers the service as requested.</t>
</list> 
</t>
<t> 
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. (In addition to instantiating and creating new instances of a service, updating, modifying, and decommissioning services 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, 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 might also be associated with other data that does not concern the network but provides business context.  
This includes things such as customer data (such as billing information), service orders and service catalogues, tariffs, service contracts, and Service Level Agreements (SLAs) including contractual agreements regarding remediation actions. 
</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 the intent system.  
Instead, management of service models requires development of sophisticated algorithms and control logic by network providers or system integrators.  
</t>
</section>

<section title="Policy and Policy-Based Management">
<t>
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  present today at the heart of a multitude of management architectures and paradigms including SLA-driven, Business-driven, autonomous, adaptive, and self-* management <xref target="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 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 behavior of a system" <xref target="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" <xref target="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.
</t>
<t>
Policy-based management can be considered an imperative management paradigm: Policies specify precisely what needs to be done when and in which circumstance.  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 management as a set of simple control loops.   
</t>
<t>
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 a controller or the device subsequently "renders" the policy, i.e., translates the canonical model into a device-specific representation.  
This concept allows to apply the same policy across a wide range of devices without needing to define multiple variants.  In other words - policy definition is de-coupled 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 defintion across different networking domains, WAN, DC or public cloud.
</t>
<t>
 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.    
</t>
<t>
Like Intent, policies provide a higher layer of abstraction.  Policy systems are also able to capture dynamic aspects of the system under management through specification of rules that allow to define various triggers for certain courses of actions.  
Unlike intent, the definition of those rules (and courses of actions) 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 PBM.
</t>
</section>

<section title="Distinguishing between Intent, Policy, and Service Models">
<t>
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.  
</t>
<t>
Summarized differences: 
<list style="symbols">
<t>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 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> 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 lets users define what to do under what circumstances, but it does not specify a desired outcome.  
</t>
<t>Intent is a higher-level declarative policy 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 the need to enumerate specific events, conditions, and actions.  
Which algorithm or rules to apply can be automatically "learned/derived from intent" by the intent system.  
    In the context of autonomic networking,  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.
</t>
</list>
</t>
<t> One analogy to capture the difference between policy and intent systems 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.  
They are able to make automatic inferences based on those rules, but are not able to "learn" 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.  
However, they do require a learning or training phase and explanations of actions that the system actually takes provide a different set of challenges.  
</t>

</section>
</section>
</section>

<section title="Principles">
<t>
The following operating principles allow characterizing the intent-based/-driven/-defined nature of a system. 
</t>
<t><list style="numbers">
<t> Single Source of Truth (SSoT) and Single Version/View of Truth (SVoT). 
The SSoT is an essential component of an intent-based system as it enables several important operations. The set of validated intent expressions is the system's SSoT. 
SSoT and the records of the operational states enable comparing the intented state and actual state of the system and determining drift between them.
SsoT and the drift information provide the basis for corrective actions. If the intent-based is equipped with prediction capabilities or means, it can further develop strategies to anticipate, plan and pro-actively act on the diverging trends with the aim to minimize their impact.
Beyond providing a means for consistent system operation, SSoT also allows for better traceability to validate if/how the initial intent and associated business goals have been properly met, to evaluate the impacts of changes in the intent parameters and impacts and effects of the events occurring in the system. 
<vspace/>
Single Version (or View) of Truth derives from the SSoT and can be used to perform other operations such as query, poll or filter the measured and correlated information to create so-called "views". These views can serve the operators and/or the users of the intent-based system. 
To create intents as single sources of truth, the intent-based system must follow well-specified and well-documented processes and models.
In other contexts <xref target="Lenrow15"/>, SSoT is also referred to as the invariance of the intent.
</t>
<t> One touch but not one shot.
In an ideal intent-based system, the user expresses its intents in one form or another and then the system takes over all subsequent operations (one touch). A zero-touch approach could also be imagined in case where the intent-based system has the capabilities or means to recognize intentions in any form of data.
However, the zero- or one-touch approach should not be mistaken the fact that reaching the state of a well-formed and valid intent expression is not a one-shot process. On the contrary, the interfacing between the user and the intent-based system could be designed as an interactive and interactive process.
Depending on the level of abstraction, the intent expressions will initially contain more or less implicit parts, and unprecise or unknown parameters and constraints. The role of the intent-based system is to parse, understand and refine the intent expression to reach a well-formed and valid intent expression that can be further used by the system for the fulfillment and assurance operations.
An intent refinement process could use a combination of iterative steps involving the user to validate the proposed refined intent and to ask the user for clarifications in case some parameters or variables could not be deduced or learned by the means of the system itself.
In addition, the Intent-Based System will need to moderate between conflicting intent, helping users to properly choose between intent alternatives that may have different ramifications.  
</t>

<t> Autonomy and Oversight.
A desirable goal for an intent-based system is to offer a high degree of flexibility and freedom on both the user side and system side, e.g. by giving the user the ability to express intents using its own terms, by supporting different forms of expression of intents and being capable of refining the intent expressions to well-formed and exploitable expressions.
The dual principle of autonomy and oversight allows to operate a system that will have the necessary levels of autonomy to conduct its tasks and operations without requiring intervention of the user and taking its own decisions (within its areas of concern and span of control) as how to perform and meet the user expiations in terms of performance and quality, 
while at the same time providing the proper level of oversight to satisfy the user requirements for reporting and escalation of relevant information.
to be added: description for feedback, reporting, guarantee scope (check points, guard rails, dynamically provisioned, context rich, regular operation vs. exception/abnormal, information zoom in-out, and link to SVoT. Accountable for decisions and efficiency, late binding (leave it to the system where to place functionality, how to accomplish certain goals). 
</t>

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

<t> Explainability.
Need expressive network capabilities, requirements and constraints to be able to compose/decompose intents, map user’s expectation to system capabilities. capability exposure.
not just automation of steps that need to be taken, but of bridging the semantic gap between "intent" and actionable levels of instructions
Context: multi providers, need discovery and semantic descriptions
Explainability: why is a network doing what it is doing
</t>
<t>Abstraction - users do not need to be concerned with how intent is achieved</t>
</list></t>
<t> Additional principles will be described in future revision of this document addressing aspects such as: Target groups not individual devices, agnostic to implementation details, user-friendly, user vocabulary vs. language of the device/network, 
explainability, validation and troubleshooting, how to resolve and point out conflicts (between intents), reconcile the reality of what is possible with the fiction of what the user would want, "moderate", awareness of operating within system boundaries, 
outcome-driven ((what not how, for the user);(what and how/where, for the operator).not imperative/instruction based.).
</t>
<t>The above principles will be further used to understand implications on the design of intent-based systems and their supporting architecture, and derive functional and operational requirements. </t>

</section>

<section title="Lifecycle">

<t>
Intent is subject to a lifecycle: it comes into being, may undergo changes over the course of time, and may at some point be retracted.  This lifecycle is closely tied to various interconnection functions that are associated with the intent concept.
</t>

<t><xref target="Fig_Lifecycle"/> depicts an intent lifecycle and its main functions.  The functions are divided into two functional (horizontal) planes and into three (vertical) spaces.
</t>

<t>The functional planes provide structure for the main funcional concerns that are associated with intent: how to fulfill intent, and how to assure it.

<list style="symbols">
<t>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.  This includes: 
<list style="symbols">
<t>Functions that recognize intent from interaction with the user and functions that allow users to refine their intent and articulate it in such ways so that it becomes actionable by an Intent-Based System.  
Those functions can involve unconventional human-machine interactions, in which a human will not simply give simple commands, but which may involve a human-machine dialog to provide clarifications, to explain ramifications and tradeoffs, and to facilitate refinements. </t>

<t>Functions that translate user intent into courses of actions and requests to take against the network, which will be meaningful to network configuration and provisioning systems.  
Possibly, this includes learning functions and algorithms that optimize the courses of actions to take in order to result in the best outcomes, specifically in cases where multiple ways of achieving those outcomes are conceivable.  </t>

<t>Functions that perform and orchestrate the configuration and provisioning steps that were determined by the previous intent translation step. </t>
</list>
</t>

<t>Assurance is concerned with the functions that are necessary ensure that the network indeed complies with the desired intent once it has been fulfilled.  This includes:
<list style="symbols">
<t>Functions that monitor and observe the network and its exhibited behavior. </t>
<t>Functions that assess and validate whether the observation indicate compliance with intent.  This can include functions that perform analysis and aggregation of raw observation data. </t>
<t>Functions that trigger corrective action as needed. </t>  
<t>Functions that abstract the observations and analysis results in a way that makes it possible for users to relate them to intent.  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>Functions that report intent compliance status and that provide adequate summarization and visualization to the user.</t>
</list>
</t>
</list>
</t>
<t>The spaces indicate the different perspectives and interactions with different roles that are involved to address the functions:
<list style="symbols">
<t>
The user space involves the functions that interface the network and intent-based system with the human user.  It involves the functions that allow users to articulate and the intent-based system 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 whether their intent is having the desired effect.</t>
<t>
The translation or Intent-Based System (IBS) space involves the functions that bridge the gap between intent users and network operations.  This includes the functions used to translate an intent into a course of action, the algorithms used to plan and optimize those courses of actions also in consideration of feedback, the functions to analyze and abstract observations to validate compliance with intent and take corrective actions as necessary.</t>
<t>
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>
<figure anchor="Fig_Lifecycle" title="Intent Lifecycle">
<artwork>
<![CDATA[

         User Space   :       Translation / IBS        :   Network Ops
                      :            Space               :       Space
                      :                                :
        +---------+   :  +----------+   +-----------+  :   +---------+
Fulfill |recognize| ---> |translate/|-->|learn/plan/| ---> | config/ |
        |intent   | <--- |  refine  |   |  render   |  :   |provision|
        +----^----+   :  +----------+   +-----^-----+  :   +---------+
             |        :                       |        :         |
.............|................................|..................|.....
             |        :                  +----+---+    :         v
             |        :                  |validate|    :   +----------+
             |        :                  +----^---+ <------| monitor/ |
Assure   +---+---+    :  +---------+    +-----+---+    :   | observe/ |
         |report | <---- |abstract |<---| analyze | <------|  assure  |
         +-------+    :  +---------+    |aggregate|    :   +----------+
                      :                 +---------+    :
]]>
</artwork>
</figure>
</t>
<t>
When inspecting the diagram carefully, it become apparent that the intent lifecycle in fact involves two cycles, or loops:
<list style="symbols">
<t>The "inner" intent control loop between IBS and Network Operations space is completely automated and does not involve any human in the loop.  It involves automatic analysis and validation of intent based on observations from the network operations space, and feeding those observations into the function that plans the rendering of networking intent in order to make adjustments as needed in the configuration of the network.  
</t>
<t>The "outer" intent control loop involves also the user space and includes the user taking action and adjusting their intent based on feedback from the IBS.</t>
</list>
</t>
<t>Slight alternatives in intent lifecycles and the functions involved are conceivable.  <xref target="Fig2_Lifecycle"/> depicts one such alternative with an emphasis in intent fulfilment. (Todo: Intent attributes, intent states. Distinguish flow from users to network, and from network to user.)</t> 
<t>
<figure anchor="Fig2_Lifecycle" title="Intent Lifecycle (alt.)">
<artwork>
<![CDATA[


        user related                    user data <-----<-+--------+
        data  +                          +                |        |
              |                          |                |        |
         +----v------+             +-----v-----+          |        |
         | recognize +---+   +-----+ generate  |          |        |
   user  +-----------+   |   |     +-----------+          |        |
   space                 |   |                            |        |
+--------------------------------------------------------------------+
   system                |   |                            |        |
   space             +---v---v---+   +----------+   +-----+-----+  |
                     | translate <-->+ validate <---> recommend |  |
                     +-----+-----+   +----------+   +-----------+  |
                           |                                       |
                     +-----v-----+                                 |
                     | normalize |                                 |
                     +-----+-----+                                 |
                           |                                       |
                     +-----v-----+                                 |
                     | decompose |                                 |
                     +-----+-----+                                 |
                           |                                       |
                    +------v------+                                |
                    | communicate |                                |
                    +------+------+                                |
    preparation            |                                       |
    phase                  |                                       |
 +-------------------------------------------------------------------+
    operation              |                                       |
    phase            +-----v----+                                  |
                     | fullfill |                                  |
                     +-----+----+                                  |
                           |                                       |
                      +----v----+     +--------+                   |
                      | observe +-----> report +-------------------+
                      +----+----+     +--------+
                           |
                      +----v---+
                      | assure |
                      +--------+


]]>
</artwork>
</figure>
</t> 

</section>


<section title="Intent-Based Networking - Functionality">
<t>
Intent-Based Networking involves a wide variety of functions which can be roughly divided into two categories:
<list style="symbols">
<t>Intent Fulfillment provides functions and interfaces that allow users to communicate intent to the network, and that orchestrates the intent, i.e. that breaks down intent abstractions into lower-level network and device abstractions and performs or coordinates the configuration operations across the network.  
</t>
<t>Intent Assurance provides functions and interfaces that allow users to validate and monitor that the network is indeed adhering to and complying with intent.  Control plane or lower-level management operations can cause behavior that inadvertently conflicts with intent which was orchestrated earlier.  Accordingly, "intent drift" may occur.  
Network operators need to be able to detect when such drift occurs, or is about to occur, and be provided with the necessary functions to resolve such conflicts.  This can occur by either bringing the network back into compliance, or by articulating modifications to the original intent to moderate between conflicting interests.  
</t>
</list>
</t>
<t>
The following sections provide a more comprehensive overview of those functions.  
</t>
<section title="Intent Fulfillment">
<t>RBD  
</t>
</section>

<section title="Intent Assurance">
<t>Ability to reason about system' state by employing closed-loop validation in the presence of an inevitable change is a fundamental property of an Intent Assurance part of an IBN system. Since service expectations are created during intent consumption and modeling phase, closed-loop intent vaidation should start immidiatelly, with the service instantiation.
Telemetry consumed could then be enriched with an additional context and must always be processed in context of the Intent it has been instantiated. Direct relationship between the Intent and telemetry gathered enables correlation between changes in states and the Intent and provides contextual base for reasoning about the changes.
</t>
</section>
</section>

<section title="Items for Discussion">
<t>
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:  
<list style="symbols">
  <t>Operational Intent: defines intent related to operational goals of an operator; corresponds to the original "intent" term. 
  </t>
  <t>Rule Intent: a synonym for policy rules regarding what to do when certain events occur.  
  </t>
  <t>Service intent: a synonym for customer service model <xref target="RFC8309"/>.   
  </t>
  <t>Flow Intent: A synonym for a Service Level Objective for a given flow.    
  </t>
</list>
Whether to do so is an item for discussion by the Research Group.  
</t>
</section>

<section title="IANA Considerations">
<t>
Not applicable
</t>
</section>
	

<section title="Security Considerations">
 
<t>
Not applicable
</t>
</section>

</middle>

<back>

	<references title="Normative References">

		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.8174"?>

</references>
        
        <references title="Informative References">
	    <?rfc include="reference.RFC.7575"?>
  		<?rfc include="reference.RFC.8299"?>
	    <?rfc include="reference.RFC.8309"?>
	  	<?rfc include="reference.RFC.8345"?>		
      <?rfc include="reference.I-D.ietf-teas-te-service-mapping-yang"?>
        
  <reference anchor="Sloman94"> 
	<front>		
	<title>Policy Driven Management for Distributed Systems. Journal of Network and Systems Management (JNSM), Springer, Vol. 2 (4).</title>
	<author initials="M" surname="Sloman" fullname="Morris Sloman">
	</author>
	<date month="December" year="1994" />
	</front>
  </reference> 
        
  <reference anchor="Strassner03"> 
	<front>		
	<title>Policy-Based Network Management.  Elsevier.</title>
	<author initials="J" surname="Strassner" fullname="John Strassner">
	</author>
	<date year="2003" />
	</front>
  </reference> 
        
  
  <reference anchor="Boutaba07"> 
	<front>		
	<title>Policy-Based Management: A Historical perspective. Journal of Network and Systems Management (JNSM), Springer, Vol. 15 (4).</title>
	<author initials="R" surname="Boutaba" fullname="Raouf Boutaba">
	</author>
	<author initials="I" surname="Aib" fullname="Issam Aib">
	</author>
	<date month="December" year="2007" />
	</front>
  </reference>     

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

  <reference anchor="eTOM"> 
	<front>		
	<title>GB 921 Business Process Framework, Release 17.0.1.</title>
	<author fullname="TMForum">
	</author>

	<date month="February" year="2018" />
	</front>
  </reference> 

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

</back>
	
</rfc>