diff options
Diffstat (limited to 'doc/rfc/rfc9315.txt')
| -rw-r--r-- | doc/rfc/rfc9315.txt | 1367 |
1 files changed, 1367 insertions, 0 deletions
diff --git a/doc/rfc/rfc9315.txt b/doc/rfc/rfc9315.txt new file mode 100644 index 0000000..86fc258 --- /dev/null +++ b/doc/rfc/rfc9315.txt @@ -0,0 +1,1367 @@ + + + + +Internet Research Task Force (IRTF) A. Clemm +Request for Comments: 9315 Futurewei +Category: Informational L. Ciavaglia +ISSN: 2070-1721 Nokia + L. Z. Granville + Federal University of Rio Grande do Sul (UFRGS) + J. Tantsura + Microsoft + October 2022 + + + Intent-Based Networking - Concepts and Definitions + +Abstract + + Intent and Intent-Based Networking are taking the industry by storm. + At the same time, terms related to Intent-Based Networking are often + used loosely and inconsistently, in many cases overlapping and + confused with other concepts such as "policy." This document + clarifies the concept of "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. + + 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 research group + participants. It is published for informational purposes. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Network + Management Research Group of the Internet Research Task Force (IRTF). + Documents approved for publication by the IRSG are not candidates for + any level of Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9315. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Definitions and Acronyms + 3. Introduction of Concepts + 3.1. Intent and Intent-Based Management + 3.2. Related Concepts + 3.2.1. Service Models + 3.2.2. Policy and Policy-Based Network Management + 3.2.3. Distinguishing between Intent, Policy, and Service + Models + 4. Principles + 5. Intent-Based Networking - Functionality + 5.1. Intent Fulfillment + 5.1.1. Intent Ingestion and Interaction with Users + 5.1.2. Intent Translation + 5.1.3. Intent Orchestration + 5.2. Intent Assurance + 5.2.1. Monitoring + 5.2.2. Intent Compliance Assessment + 5.2.3. Intent Compliance Actions + 5.2.4. Abstraction, Aggregation, Reporting + 6. Life Cycle + 7. Additional Considerations + 8. IANA Considerations + 9. Security Considerations + 10. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + 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. + + 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 [RFC3411] and the 200+ + MIBs that have been defined by the IETF over the years. More recent + examples include YANG data model definitions [RFC7950] for aspects + such as interface configuration, Access Control List (ACL) + configuration, and Syslog configuration. + + 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. + + 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 + [RFC8345] or the introduction of service models used by service + orchestration systems and controllers [RFC8309]. Much of the + 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 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. + + This input and operational guidance are commonly referred to as + "intent," and a network that allows network operators to provide + their input using intent is referred to as an "Intent-Based Network" + (IBN), while a system that helps implement intent is referred to as + an "Intent-Based System" (IBS). Those systems can manifest + themselves in a number of ways -- for example, as a controller or + management system that 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. + + 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 be achieved. + Focusing on the 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). This also makes Intent-Based Networking an ideal + candidate for artificial intelligence techniques that can bring about + the next level of network automation [CLEMM20]. + + 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 as opposed to a set of independent + devices (that happen to be interconnected). Those offerings include + IBNs and IBSs (offering a full life cycle of intent), Software- + Defined Network (SDN) controllers (offering a single point of control + and administration for a network), and network management and + Operations Support Systems (OSSs). + + 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 [M3010]. 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 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. + + 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 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 Intent- + Based Networking. + + 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 Intent-Based Networking has become an important topic + in the research community. Per IEEE Xplore [IEEEXPLORE], 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 [WIN21], as well as various + special journal issues [IEEE-TITS21]. A survey of current intent- + driven networking research has been published in [PANG20], listing + among the most pressing current research challenges aspects such as + intent translation and understanding, intent interfaces, and + security. + +2. Definitions and Acronyms + + ACL: Access Control List + + API: Application Programming Interface + + IBA: Intent-Based Analytics. Analytics that are defined and derived + from users' intent and used to validate the intended state. + + IBN: Intent-Based Network. A network that can be managed using + intent. + + IBS: Intent-Based System. A system that supports management + functions that can be guided using intent. + + Intent: A set of operational goals (that a network should meet) and + outcomes (that a network is supposed to deliver) defined in a + declarative manner without specifying how to achieve or implement + them. + + Intent-Based Management: The concept of performing management based + on the concept of intent. + + PBNM: Policy-Based Network Management + + PDP: Policy Decision Point + + PEP: Policy Enforcement Point + + Policy: A set of rules that governs the choices in behavior of a + system. + + Service Model: A model that represents a service that is provided by + a network to a user. + + SSoT: Single Source of Truth. A functional block in an IBN system + that normalizes users' intent and serves as the single source of + data for the lower layers. + + Statement of Intent: A specification of one particular aspect or + component of intent, also referred to as an intent statement. + + SVoT: Single Version of Truth + + User: 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). + +3. Introduction of Concepts + + 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. + +3.1. Intent and Intent-Based Management + + 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) defined in a declarative manner without + specifying how to achieve or implement them. + + 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 the network" [RFC7575]. 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. + + | 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. + + 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 [RFC8994], but applies to any network. + + 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: + + * It provides data abstraction: Users do not need to be concerned + with low-level device configuration and nerd knobs. + + * It provides functional abstraction from particular management and + control logic: Users do not need to be concerned even with how to + achieve a given intent. What is specified is the desired 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. + + The following are some examples of intent, expressed in natural + language for the sake of clarity (actual interfaces used to convey + intent may differ): + + * "Steer networking traffic originating from endpoints in one + geography away from a second geography, unless the destination + lies in that second geography." (states what to achieve, not how.) + + * "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 what to achieve, not how, + providing additional guidance for how to trade off between + different goals when necessary.) + + * "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 desired + outcome, with a set of constraints for additional guidance, that + does not specify how to achieve this.) + + * "Ensure VPN services have path protection at all times for all + paths." (a desired outcome of which it may not be clear how it can + be precisely accommodated.) + + * "Generate 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 beyond event-condition-action by not being + specific about what constitutes "significant" and what specific + data to collect.) + + * "Route traffic in a Space Information Network in a way that + minimizes dependency on stratospheric balloons unless the intended + destination is an aircraft." (does not specify how to precisely + achieve this; extrapolates on scenarios mentioned in [PANG20].) + + * "For a smart city service, ensure traffic signal control traffic + uses dedicated and redundant slices that avoid fate sharing." (a + desired outcome with a set of constraints and additional guidance + without specifying how to precisely achieve this; extrapolates on + scenarios from [GHARBAOUI21].) + + In contrast, the following are examples of what would not constitute + intent (again, expressed in natural language for the sake of + clarity): + + * "Configure a given interface with an IP address." (This would be + considered device configuration and fiddling with configuration + knobs, not intent.) + + * "When interface utilization exceeds a specific threshold, emit an + alert." (This would be a rule that can help support network + automation, but a simple rule is not an intent.) + + * "Configure a VPN with a tunnel from A to B over path P." (This + would be considered as a configuration of a service.) + + * "Deny traffic to prefix P1 unless it is traffic from prefix P2." + (This would be an example of an access policy or a firewall rule, + not intent.) + + 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. + + 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 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 that performs the required actions. + + Another reason to provide intent functionality from a conceptually + centralized point is in cases where 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. + + 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 even if conceptually + centralized. + + 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. + + Other definitions of intent exist, such as [TR523]. 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 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 an API based on function invocations and simple request- + response interactions but may involve other types of human-machine + interactions such as dialogs to provide clarifications and + refinements to requests. + +3.2. Related Concepts + +3.2.1. Service Models + + A service model is a model that represents a service that is provided + by a network to a user. Per [RFC8309], a service model describes a + service and its parameters in a portable 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, and a "Service Delivery Model" describes how a service is + instantiated over existing networking infrastructure. + + An example of a service could be a Layer 3 VPN service [RFC8299], a + Network Slice [NETWORK-SLICE], or residential Internet access. + Service models represent service instances as entities in their own + right. Services have their own parameters, actions, and life cycles. + Typically, service instances can be bound to end users of + communication services who might be billed for the services provided. + + Instantiating a service typically involves multiple aspects: + + * A user (or northbound system) needs to define and/or request a + service to be instantiated. + + * Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, + interfaces, bandwidth, or memory need to be allocated. + + * 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). + + * Bindings between upper- and lower-level objects need to be + maintained. + + * Once instantiated, the service operational state needs to be + validated and assured to ensure that the network indeed delivers + the service as requested. + + 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 + 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. + + 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 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, which also facilitates keeping track of the assignment + of network resources (composition), while troubleshooted 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. + + [SERVICE-MAPPING-YANG] 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). + + 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. + +3.2.2. Policy and Policy-Based Network Management + + 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, autonomous, adaptive, and self-* management + [BOUTABA07]. The interested reader is asked to refer to the rich set + of existing literature, which includes this and many other + references. In the following, we will only provide a much-abridged + and distilled overview. + + At the heart of policy-based management is the concept of a policy. + Multiple definitions of policy exist: "Policies are rules governing + the choices in the behavior of a system" [SLOMAN94]. "Policy is a + set of rules that are used to manage and control the changing and/or + maintaining of the state of one or more managed objects" + [STRASSNER03]. Common to most definitions is the definition of a + policy as a "rule." Typically, the definition of a rule consists of + an event (whose occurrence triggers a rule), a set of conditions + (which get assessed and which must be true before any actions are + actually "fired"), and finally, a set of one or more actions that are + carried out when the condition holds. + + Policy-based management can be considered an imperative management + paradigm: Policies precisely 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. + + 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, policy + definition is 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, data + center (DC), or public cloud. + + 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 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 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, PBNM + architectures typically involve a central component from which + policies are deployed across the network and/or policy decisions + served. + + Like 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 IBSs to generate policies that are + subsequently deployed by a PBNM system, allowing PBNM to support + Intent-Based Networking. + +3.2.3. Distinguishing between Intent, Policy, and Service Models + + What intent, policy, and service models all have in common is the + fact that they involve a higher layer of abstraction of a network + that does not involve device specifics, generally transcends + individual devices, and 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. + + Summarized differences: + + * 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. + + * 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. + + * 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. + + One analogy to capture the difference between policy-based systems + and 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 IBSs, users + focus on what they would like the learning system to accomplish but + not how to do it. + +4. Principles + + The following main operating principles allow characterizing the + intent-based/-driven/-defined nature of a system. + + 1. Single Source of Truth (SSoT) and Single Version of Truth (SVoT). + The SSoT is an essential component of an 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 in order to evaluate the + impacts of changes in the intent parameters and impacts and + effects of the events occurring in the system. + + Single Version (or View) of Truth derives from the SSoT and can + be used to perform other 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 IBS. + In order to create 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 [LENROW15]. + + 2. One touch but not one shot. In an ideal IBS, the user expresses + intent 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 the case where the 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 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 imprecise or unknown parameters and + constraints. The role of the 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 IBS will need to moderate between conflicting + intent, helping users to properly choose between intent + alternatives that may have different ramifications. + + 3. Autonomy and Supervision. A desirable goal for an 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 intent using the user's own terms, by supporting + different forms of expression for individual statements of 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. + + 4. Learning. An IBS is a learning system. In contrast to an + 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 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 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 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 IBS to anticipate or forecast future + system state and response to changes in 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. + + 5. Capability exposure. Capability exposure consists in the need + for expressive network capabilities, requirements, and + constraints to be able to compose/decompose intent and map the + user's expectations to the system capabilities. + + 6. 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., of vendor-specific + renderings. + + The described principles are perhaps the most prominent, but they are + not an exhaustive list. There are additional aspects to consider, + such as: + + * 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). + + * Abstraction and inherent virtualization: agnostic to + implementation details. + + * 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. + + * 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. + + * Inherent support, verification, and assurance of trust. + + All of these principles and considerations have implications on the + design of IBSs and their supporting architecture. Accordingly, they + need to be considered when deriving functional and operational + requirements. + +5. Intent-Based Networking - Functionality + + Intent-Based Networking involves a wide variety of functions that can + be roughly divided into two categories: + + * 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 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. + + * 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., "set and forget", but is expected + to 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. + + The following sections provide a more comprehensive overview of those + functions. + +5.1. Intent Fulfillment + + 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. + +5.1.1. Intent Ingestion and Interaction with Users + + 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 IBS. + Typically, those functions go beyond those provided by a 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 commands but instead a human-machine + dialog is used to provide clarifications, to explain ramifications + and trade-offs, and to facilitate refinements. + + 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 IBSs that are increasingly able to learn how + to understand the user, as opposed to the other way around. Of + course, further research will be required to make this a reality. + +5.1.2. Intent Translation + + 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 management and + operations side that will need to orchestrate provisioning and + configuration across the network. + + Beyond merely breaking down a higher layer of abstraction (intent) + into a lower layer of abstraction (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. + +5.1.3. Intent Orchestration + + 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. + +5.2. Intent Assurance + + Intent 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. + +5.2.1. Monitoring + + 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. + +5.2.2. Intent Compliance Assessment + + 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. + + 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 that conflict with intent that was orchestrated + earlier. 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. + +5.2.3. Intent Compliance Actions + + 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. + +5.2.4. Abstraction, Aggregation, Reporting + + 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. + + 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. + +6. Life Cycle + + Intent is subject to a life cycle: it comes into being, may undergo + changes over the course of time, and may at some point be retracted. + This life cycle is closely tied to various interconnection functions + that are associated with the intent concept. + + Figure 1 depicts an intent life cycle and its main functions. The + functions were introduced in Section 5 and are divided into two + functional (horizontal) planes reflecting the distinction between + fulfillment and assurance. In addition, they are divided into three + (vertical) spaces. + + The spaces indicate the different perspectives and interactions with + different roles that are involved in addressing the functions: + + * The User Space involves the functions that interface the network + and IBS with the human user. It involves the functions that allow + users to articulate and the 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. + + * 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. + + * The Network Operations Space, finally, involves orchestration, + configuration, monitoring, and measurement functions, which are + used to effectuate the rendered intent and observe its effects on + the network. + + 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| : +----------+ + : +---------+ : + + Figure 1: Intent Life Cycle + + When carefully inspecting the diagram, it becomes apparent that the + intent life cycle, in fact, involves two cycles, or loops: + + * 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 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. + + * 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 life cycle: It comes into being, may undergo + refinements, modifications, and changes of time, and may at some + point in time even get retracted. + +7. Additional Considerations + + Given the popularity of the term "intent," it is tempting to broaden + its use to encompass 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." + 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. + + In that sense and with regards to intent, it makes sense to + distinguish various subcategories of intent as follows: + + Operational Intent: defines intent related to operational goals of + an operator; it corresponds to the original "intent" term and the + concepts defined in this document. + + Rule Intent: a synonym for policy rules regarding what to do when + certain events occur. + + Service Intent: a synonym for customer service model [RFC8309]. + + Flow Intent: a synonym for a Service Level Objective for a given + flow. + + A comprehensive set of classifications of different concepts and + categories of intent will be described in a separate document. + +8. IANA Considerations + + This document has no IANA actions. + +9. Security Considerations + + This document describes concepts and definitions of Intent-Based + Networking. As such, the below security considerations remain high + level, i.e., in the form of principles, guidelines, or requirements. + More detailed security considerations will be described in the + documents that specify the architecture and functionality. + + Security in Intent-Based Networking can apply to different facets: + + * Securing the IBS itself. + + * Mitigating the effects of erroneous, harmful, or compromised + intent statements. + + * Expressing security policies or security-related parameters with + intent statements. + + Securing the IBS aims at making the IBS operationally secure by + implementing security mechanisms and applying security best + practices. In the context of Intent-Based Networking, such + mechanisms and practices may consist of intent verification and + validation, operations on intent by authenticated and authorized + users only, and protection against or detection of tampered + 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-offs should be considered as well. + + Mitigating the effects of erroneous or compromised statements of + intent aims at making the IBS operationally safe by providing + checkpoint and safeguard mechanisms and operating principles. In the + context of Intent-Based Networking, such mechanisms and principles + may consist of the ability to automatically detect unintended, + detrimental, or abnormal behavior; the ability to automatically (and + gracefully) roll back or 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 implicit information conveyed by + intent statements); and dynamic levels of supervision and reporting + to make the user aware of the right information at the right time + with the right level of context. Erroneous or harmful intent + statements may inadvertently propagate and compromise security. In + addition, compromised intent statements (for example, forged by an + inside attacker) may sabotage or harm the network resources and make + them vulnerable to further, larger attacks, e.g., by defeating + certain security mechanisms. + + Expressing security policies or security-related parameters as intent + consists of using the intent formalism (a high-level, declarative + abstraction) or part(s) of an intent statement to define security- + related aspects such as: + + * data governance; + + * level(s) of confidentiality in data exchange; + + * level(s) of availability of system resources, of protection in + forwarding paths, and of isolation in processing functions; + + * level(s) of encryption; and + + * authorized entities for given operations. + + 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 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 or at coarser granularity. + + More thorough security analyses should be conducted as our + understanding of Intent-Based Networking technology matures. + +10. Informative References + + [BOUTABA07] + Boutaba, R. and I. Aib, "Policy-Based Management: A + Historical Perspective", Journal of Network and Systems + Management (JNSM), Vol. 15, Issue 4, + DOI 10.1007/s10922-007-9083-8, November 2007, + <https://doi.org/10.1007/s10922-007-9083-8>. + + [CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network + Management 2030: Operations and Control of Network 2030 + Services", Journal of Network and Systems Management + (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0, + October 2020, + <https://doi.org/10.1007/s10922-020-09517-0>. + + [GHARBAOUI21] + Gharbaoui, M., Martini, B., and P. Castoldi, + "Implementation of an Intent Layer for SDN-enabled and + QoS-Aware Network Slicing", 2021 IEEE 7th International + Conference on Network Softwarization (NetSoft), pp. 17-23, + DOI 10.1109/NetSoft51509.2021.9492643, June 2021, + <https://doi.org/10.1109/NetSoft51509.2021.9492643>. + + [IEEE-TITS21] + Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad, + N., and R. R. V. Prasad, "Guest Editorial Special Issue on + Intent-Based Networking for 5G-Envisioned Internet of + Connected Vehicles", IEEE Transactions on Intelligent + Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017, + DOI 10.1109/TITS.2021.3101259, August 2021, + <https://doi.org/10.1109/TITS.2021.3101259>. + + [IEEEXPLORE] + IEEE, "IEEE Xplore", <https://ieeexplore.ieee.org/>. + + [LENROW15] Lenrow, D., "Intent As The Common Interface to Network + Resources", Intent Based Network Summit 2015 ONF Boulder: + IntentNBI, February 2015. + + [M3010] ITU-T, "Principles for a telecommunications management + network", ITU-T Recommendation M.3010, February 2000. + + [NETWORK-SLICE] + Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., + Makhijani, K., Contreras, L. M., and J. Tantsura, + "Framework for IETF Network Slices", Work in Progress, + Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 + August 2022, <https://datatracker.ietf.org/doc/html/draft- + ietf-teas-ietf-network-slices-14>. + + [PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A + Survey on Intent-Driven Networks", IEEE Access, Vol. 8, + pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January + 2020, <https://doi.org/10.1109/ACCESS.2020.2969208>. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, + DOI 10.17487/RFC3411, December 2002, + <https://www.rfc-editor.org/info/rfc3411>. + + [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., + Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic + Networking: Definitions and Design Goals", RFC 7575, + DOI 10.17487/RFC7575, June 2015, + <https://www.rfc-editor.org/info/rfc7575>. + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + <https://www.rfc-editor.org/info/rfc7950>. + + [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, + "YANG Data Model for L3VPN Service Delivery", RFC 8299, + DOI 10.17487/RFC8299, January 2018, + <https://www.rfc-editor.org/info/rfc8299>. + + [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models + Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, + <https://www.rfc-editor.org/info/rfc8309>. + + [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., + Ananthakrishnan, H., and X. Liu, "A YANG Data Model for + Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March + 2018, <https://www.rfc-editor.org/info/rfc8345>. + + [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An + Autonomic Control Plane (ACP)", RFC 8994, + DOI 10.17487/RFC8994, May 2021, + <https://www.rfc-editor.org/info/rfc8994>. + + [SERVICE-MAPPING-YANG] + Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q., + Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering + (TE) and Service Mapping YANG Data Model", Work in + Progress, Internet-Draft, draft-ietf-teas-te-service- + mapping-yang-11, 11 July 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te- + service-mapping-yang-11>. + + [SLOMAN94] Sloman, M., "Policy Driven Management for Distributed + Systems", Journal of Network and Systems Management + (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994. + + [STRASSNER03] + Strassner, J., "Policy-Based Network Management", August + 2003. + + [TR523] Open Networking Foundation, "Intent NBI - Definition and + Principles", ONF TR-523, October 2016. + + [WIN21] Ciavaglia, L. and E. Renault, "1st International Workshop + on Intent-Based Networking", IEEE International Conference + on Network Softwarization, June 2021, + <https://netsoft2021.ieee-netsoft.org/program/workshops/ + win-2021/>. + +Acknowledgments + + 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. + +Authors' Addresses + + Alexander Clemm + Futurewei + 2330 Central Expressway + Santa Clara, CA 95050 + United States of America + Email: ludwig@clemm.org + + + Laurent Ciavaglia + Nokia + Route de Villejust + 91620 Nozay + France + Email: laurent.ciavaglia@nokia.com + + + Lisandro Zambenedetti Granville + Federal University of Rio Grande do Sul (UFRGS) + Av. Bento Gonçalves + Porto Alegre-RS + 9500 + Brazil + Email: granville@inf.ufrgs.br + + + Jeff Tantsura + Microsoft + Email: jefftant.ietf@gmail.com |