idnits 2.17.1 draft-irtf-nmrg-ibn-concepts-definitions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft Futurewei 4 Intended status: Informational L. Ciavaglia 5 Expires: August 26, 2021 Nokia 6 L. Granville 7 Federal University of Rio Grande do Sul (UFRGS) 8 J. Tantsura 9 Juniper Networks 10 February 22, 2021 12 Intent-Based Networking - Concepts and Definitions 13 draft-irtf-nmrg-ibn-concepts-definitions-03 15 Abstract 17 Intent and Intent-Based Networking (IBN) are taking the industry by 18 storm. At the same time, IBN-related terms are often used loosely 19 and inconsistently, in many cases overlapping and confused with other 20 concepts such as "Policy." This document clarifies the concept of 21 "Intent" and provides an overview of the functionality that is 22 associated with it. The goal is to contribute towards a common and 23 shared understanding of terms, concepts, and functionality that can 24 be used as the foundation to guide further definition of associated 25 research and engineering problems and their solutions. 27 This document is a product of the IRTF Network Management Research 28 Group (NMRG). It reflects the consensus of the RG, receiving reviews 29 from 8 members and explicit support from 14 (beyond the authors). It 30 is published for informational purposes. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 26, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 69 4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 6 70 4.1. Intent and Intent-Based Management . . . . . . . . . . . 6 71 4.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 9 72 4.2.1. Service Models . . . . . . . . . . . . . . . . . . . 9 73 4.2.2. Policy and Policy-Based Network Management . . . . . 11 74 4.2.3. Distinguishing between Intent, Policy, and Service 75 Models . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Intent-Based Networking - Functionality . . . . . . . . . . . 17 78 6.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 17 79 6.1.1. Intent Ingestion and Interaction with Users . . . . . 18 80 6.1.2. Intent Translation . . . . . . . . . . . . . . . . . 18 81 6.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 19 82 6.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 19 83 6.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 19 84 6.2.2. Intent Compliance Assessment . . . . . . . . . . . . 19 85 6.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 20 86 6.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 20 87 7. Life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Additional Considerations . . . . . . . . . . . . . . . . . . 22 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 92 12. Informative References . . . . . . . . . . . . . . . . . . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 95 1. Introduction 97 Traditionally in the IETF, interest regarding management and 98 operations has focused on individual network and device features. 99 Standardization emphasis has generally been put on management 100 instrumentation that needed to be provided to a networking device. A 101 prime example of this is SNMP-based management [RFC3411] and the 200+ 102 MIBs that have been defined by the IETF over the years. More recent 103 examples include YANG data model definitions [RFC7950] for aspects 104 such as interface configuration, ACL configuration, and Syslog 105 configuration. 107 There is a clear sense and reality that managing networks by 108 configuring myriads of "nerd knobs" on a device-by-device basis is no 109 longer an option in modern network environments. Significant 110 challenges arise with keeping device configurations not only 111 consistent across a network but also consistent with the needs of 112 services and service features they are supposed to enable. 113 Additional challenges arise with regards to being able to rapidly 114 adapt the network as needed and to be able to do so at scale. At the 115 same time, operations need to be streamlined and automated wherever 116 possible to not only lower operational expenses but also allow for 117 rapid reconfiguration of networks at sub-second time scales and to 118 ensure that networks are delivering their functionality as expected. 119 Among other things, this requires the ability to consume operational 120 data, perform analytics, and dynamically take actions in a way that 121 is aware of context as well as intended outcomes at near real-time 122 speeds. 124 Accordingly, the IETF has begun to address end-to-end management 125 aspects that go beyond the realm of individual devices in isolation. 126 Examples include the definition of YANG models for network topology 127 [RFC8345] or the introduction of service models used by service 128 orchestration systems and controllers [RFC8309]. Much of the 129 interest has been fueled by the discussion about how to manage 130 autonomic networks, as discussed in the ANIMA working group. 131 Autonomic networks are driven by the desire to lower operational 132 expenses and make the management of the network as a whole more 133 straightforward, putting it at odds with the need to manage the 134 network one device and one feature at a time. However, while 135 autonomic networks are intended to exhibit "self-management" 136 properties, they still require input from an operator or outside 137 system to provide operational guidance and information about the 138 goals, purposes, and service instances that the network is to serve. 140 This input and operational guidance are commonly referred to as 141 "intent," and networks that allow network operators to provide their 142 input using intent as "Intent-Based Networks" (IBN) and the systems 143 that help implement intent as "Intent-Based Systems" (IBS). However, 144 intent is about more than just enabling a form of operator 145 interaction with the network that involves higher-layer abstractions. 146 It is also about the ability to let operators focus on what they want 147 their desired outcomes to be while leaving details about how those 148 outcomes would, in fact, be achieved to the IBN (respectively IBS). 149 This, in turn, enables much greater operational efficiency at greater 150 scale, in shorter time scales, with less dependency on human 151 activities (and possibility for mistakes), and an ideal candidate, 152 e.g., for artificial intelligence techniques that can bring about the 153 next level of network automation [Clemm20]. 155 This vision has since caught on with the industry in a big way, 156 leading to a significant number of solutions that offer Intent-Based 157 Management that promise network providers to manage networks 158 holistically at a higher level of abstraction and as a system that 159 happens to consist of interconnected components, as opposed to a set 160 of independent devices (that happen to be interconnected). Those 161 offerings include IBN and IBS (offering full a life-cycle of intent), 162 SDN controllers (offering a single point of control and 163 administration for a network), and network management and Operations 164 Support Systems (OSS). 166 However, it has been recognized for a long time that comprehensive 167 management solutions cannot operate only at the level of individual 168 devices and low-level configurations. In this sense, the vision of 169 intent is not entirely new. In the past, ITU-T's model of a 170 Telecommunications Management Network (TMN) introduced a set of 171 management layers that defined a management hierarchy, consisting of 172 network element, network, service, and business management [M3010]. 173 High-level operational objectives would propagate in a top-down 174 fashion from upper to lower layers. The associated abstraction 175 hierarchy was crucial to decompose management complexity into 176 separate areas of concern. This abstraction hierarchy was 177 accompanied by an information hierarchy that concerned itself at the 178 lowest level with device-specific information, but that would, at 179 higher layers, include, for example, end-to-end service instances. 180 Similarly, the concept of Policy-Based Network Management (PBNM) has, 181 for a long time, touted the ability to allow users to manage networks 182 by specifying high-level management policies, with policy systems 183 automatically "rendering" those policies, i.e., breaking them down 184 into low-level configurations and control logic. 186 What has been missing, however, is putting these concepts into a more 187 current context and updating them to account for current technology 188 trends. This document clarifies the concepts behind intent. It 189 differentiates intent from related concepts. It also provides an 190 overview of first-order principles of IBN as well as the associated 191 functionality. The goal is to contribute to a common and shared 192 understanding that can be used as a foundation to articulate research 193 and engineering problems in the area of IBN. It should be noted that 194 the articulation of those problems is beyond the scope of this 195 document. 197 2. Key Words 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 3. Definitions and Acronyms 207 ACL: Access Control List 209 API: Application Programming Interface 211 Intent: A set of operational goals (that a network should meet) 212 and outcomes (that a network is supposed to deliver), defined in a 213 declarative manner without specifying how to achieve or implement 214 them. 216 IBA: Intent-Based Analytics - Analytics that are defined and 217 derived from users' intent and used to validate the intended 218 state. 220 Intent-Based Management - The concept of performing management 221 based on the concept of intent. 223 IBN: Intent-Based Network - A network that can be managed using 224 intent. 226 IBS: Intent-Based System - A system that supports management 227 functions that can be guided using intent. 229 PBNM: Policy-Based Network Management 231 Policy: A set of rules that governs the choices in behavior of a 232 system. 234 PDP: Policy Decision Point 236 PEP: Policy Enforcement Point 237 Service Model: A model that represents a service that is provided 238 by a network to a user. 240 SSoT: Single Source of Truth - A functional block in an IBN system 241 that normalizes users' intent and serves as the single source of 242 data for the lower layers. 244 SVoT: Single Version of Truth 246 4. Introduction of Concepts 248 The following section provides an overview of the concept of intent 249 and Intent-Based Management. It also provides an overview of the 250 related concepts of service models and policies (and Policy-Based 251 Network Management), and explains how they relate to intent and 252 Intent-Based Management. 254 4.1. Intent and Intent-Based Management 256 The term "intent" was first introduced in the context of Autonomic 257 Networks, where it is defined as "an abstract, high-level policy used 258 to operate a network" [RFC7575]. According to this definition, an 259 intent is a specific type of policy provided by a user to provide 260 guidance to the Autonomic Network that would otherwise operate 261 without human intervention. However, to avoid using intent simply as 262 a synonym for policy, a distinction that differentiates intent 263 clearly from other types of policies needs to be introduced. 265 Intent-Based Management aims to lead towards networks that are 266 fundamentally simpler to manage and operate, requiring only minimal 267 outside intervention. Networks, even when they are autonomic, are 268 not clairvoyant and have no way of automatically knowing particular 269 operational goals nor which instances of networking services to 270 support. In other words, they do not know what the intent of the 271 network provider is that gives the network the purpose of its being. 272 This still needs to be communicated to the network by what informally 273 constitutes intent. That being said, the concept of intent is not 274 limited just to autonomic networks, such as networks that feature an 275 Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], but 276 applies to any network. 278 More specifically, intent is a declaration of operational goals that 279 a network should meet and outcomes that the network is supposed to 280 deliver, without specifying how to achieve them. Those goals and 281 outcomes are defined in a manner that is purely declarative - they 282 specify what to accomplish, not how to achieve it. Intent thus 283 applies several important concepts simultaneously: 285 o It provides data abstraction: users and operators do not need to 286 be concerned with low-level device configuration and nerd knobs. 288 o It provides functional abstraction from particular management and 289 control logic: users and operators do not need to be concerned 290 even with how to achieve a given intent. What is specified is the 291 desired outcome, with the IBS automatically figuring out a course 292 of action (e.g., using an algorithm or applying a set of rules 293 derived from the intent) for how to achieve the outcome. 295 The following are some examples of intent, expressed in natural 296 language for the sake of clarity (actual interfaces used to convey 297 intent may differ): 299 o "Steer networking traffic originating from endpoints in one 300 geography away from a second geography, unless the destination 301 lies in that second geography." (States what to achieve, not 302 how.) 304 o "Avoid routing networking traffic originating from a given set of 305 endpoints (or associated with a given customer) through a 306 particular vendor's equipment, even if this occurs at the expense 307 of reduced service levels." (States what to achieve, not how, 308 providing additional guidance for how to trade off between 309 different goals when necessary) 311 o "Maximize network utilization even if it means trading off service 312 levels (such as latency, loss) unless service levels have 313 deteriorated 20% or more from their historical mean." (A desired 314 outcome, with a set of constraints for additional guidance, which 315 does not specify how to achieve this.) 317 o "VPN service must have path protection at all times for all 318 paths." (A desired outcome of which it may not be clear how it 319 can be precisely accommodated.) 321 o "Generate in-situ OAM data and network telemetry across for later 322 offline analysis whenever significant fluctuations in latency 323 across a path are observed." (Goes beyond traditional event- 324 condition-action by not being specific about what constitutes 325 "significant" and what specific data to collect) 327 In contrast, the following are examples of what would not constitute 328 intent (again, expressed in natural language for the sake of 329 clarity): 331 o "Configure a given interface with an IP address." This would be 332 considered device configuration and fiddling with configuration 333 knobs, not intent. Pointing to a resourse that could potentially 334 serve as the resource pool for providing IP addresses and/or 335 similar network artifacts that could be used for conifguration 336 would still be a part of intent. 338 o "When interface utilization exceeds a specific threshold, emit an 339 alert." This would be a rule that can help support network 340 automation, but a simple rule is not an intent. 342 o "Configure a VPN with a tunnel from A to B over path P." This 343 would be considered as a configuration of a service. 345 o "Deny traffic to prefix P1 unless it is traffic from prefix P2." 346 This would be an example of an access policy or a firewall rule, 347 not intent. 349 In an autonomic network, intent should be rendered by the network 350 itself, i.e., translated into device-specific rules and courses of 351 action. Ideally, it should not even be orchestrated or broken down 352 by a higher-level, centralized system but by the network devices 353 themselves using a combination of distributed algorithms and local 354 device abstractions. In this idealized vision, because intent holds 355 for the network as a whole, intent should ideally be automatically 356 disseminated across all devices in the network, which can themselves 357 decide whether they need to act on it. 359 However, such decentralization will not be practical in all cases. 360 Certain functions will need to be at least conceptually centralized. 361 For example, users may require a single conceptual point of 362 interaction with the network. Likewise, the vast majority of network 363 devices may be intent-agnostic and focus only (for example) on the 364 actual forwarding of packets. Many devices may also be constrained 365 in their processing resouces and hence their ability to act on 366 intent. Depending on the intent, not every devices needs to be aware 367 of certain intent, for example when it does not affect them and when 368 they play no role in achieving the desired outcome. This implies 369 that certain intent functionality needs to be provided by functions 370 that are specialized for that purpose (which, depending on the 371 scenario, may be hosted on dedicated systems or co-hosted with other 372 networking functions). For example, functionality to translate 373 intent into courses of actions and algorithms to achieve desired 374 outcomes may need to be provided by such specialized functions. Of 375 course, to avoid single points of failure, the implementation and 376 hosting of those functions may still be distributed, even if 377 conceptually centralized. 379 Accordingly, an IBN is a network that can be managed using intent. 380 This means that it is able to recognize and ingest intent of an 381 operator or user and configure and adapt itself according to the user 382 intent, achieving an intended outcome (i.e., a desired state or 383 behavior) without requiring the user to specify the detailed 384 technical steps for how to achieve the outcome. Instead, the IBN 385 will be able to figure out on its own how to achieve the outcome. 386 Similarly, an IBS is a system that allows users to manage a network 387 using intent. Such a system will serve as a point of interaction 388 with users and implement the functionality that is necessary to 389 achieve the intended outcomes, interacting for that purpose with the 390 network as required. 392 Other definitions of intent exist, such as [TR523]. Intent there is 393 simply defined as a declarative interface that is typically provided 394 by a controller. It implies the presence of a centralized function 395 that renders the intent into lower-level policies or instructions and 396 orchestrates them across the network. While this is certainly one 397 way of implementation, the definition presented here is narrower in 398 the sense that it emphasizes the importance of managing the network 399 by specifying desired outcomes without the specific steps to be taken 400 in order to achieve the outcome. A controller API that simply 401 provides a network-level of abstraction would not necessarily qualify 402 as intent. Likewise, ingestion and recognition of intent may not 403 necessarily occur via a traditional API but may involve other types 404 of human-machine interactions. 406 4.2. Related Concepts 408 4.2.1. Service Models 410 A service model is a model that represents a service that is provided 411 by a network to a user. Per [RFC8309], a service model describes a 412 service and its parameters in a portable/implementation-agnostic way 413 that can be used independently of the equipment and operating 414 environment on which the service is realized. Two subcategories are 415 distinguished: a "Customer Service Model" describes an instance of a 416 service as provided to a customer, possibly associated with a service 417 order. A "Service Delivery Model" describes how a service is 418 instantiated over existing networking infrastructure. 420 An example of a service could be a Layer 3 VPN service [RFC8299], a 421 Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or 422 residential Internet access. Service models represent service 423 instances as entities in their own right. Services have their own 424 parameters, actions, and life-cycles. Typically, service instances 425 can be bound to end-users, who might be billed for the services 426 provided. 428 Instantiating a service typically involves multiple aspects: 430 o A user (or northbound system) needs to define and/or request a 431 service to be instantiated. 433 o Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, 434 interfaces, bandwidth, or memory need to be allocated. 436 o How to map services to the resources needs to be defined. 437 Multiple mappings are often possible, which to select may depend 438 on context (such as which type of access is available to connect 439 the end-user with the service). 441 o Bindings between upper and lower-level objects need to be 442 maintained. 444 o Once instantiated, the service operational state needs to be 445 validated and assured to ensure that the network indeed delivers 446 the service as requested. 448 The realization of service models involves a system, such as a 449 controller, that provides provisioning logic. This includes breaking 450 down high-level service abstractions into lower-level device 451 abstractions, identifying and allocating system resources, and 452 orchestrating individual provisioning steps. Orchestration 453 operations are generally conducted using a "push" model in which the 454 controller/manager initiates the operations as required, then pushes 455 down the specific configurations to the device and validates whether 456 the new changes have been accepted and the new operational/derived 457 states are achieved and in sync with the intent/desired state. In 458 addition to instantiating and creating new instances of a service, 459 updating, modifying, and decommissioning services need to be also 460 supported. The device itself typically remains agnostic to the 461 service or the fact that its resources or configurations are part of 462 a service/concept at a higher layer. 464 Instantiated service models map to instantiated lower-layer network 465 and device models. Examples include instances of paths or instances 466 of specific port configurations. The service model typically also 467 models dependencies and layering of services over lower-layer 468 networking resources that are used to provide services. This 469 facilitates management by allowing to follow dependencies for 470 troubleshooting activities, to perform impact analysis in which 471 events in the network are assessed regarding their impact on services 472 and customers. Services are typically orchestrated and provisioned 473 top-to-bottom, which also facilitates keeping track of the assignment 474 of network resources (composition), while troubleshooted bottom-up 475 (decomposition). Service models might also be associated with other 476 data that does not concern the network but provides business context. 477 This includes things such as customer data (such as billing 478 information), service orders and service catalogs, tariffs, service 479 contracts, and Service Level Agreements (SLAs), including contractual 480 agreements regarding remediation actions. 482 [I-D.ietf-teas-te-service-mapping-yang] is an example of a data model 483 that provides a mapping for customer service models (e.g., the L3VPN 484 Service Model) to Traffic Engineering (TE) models (e.g., the TE 485 Tunnel or the Abstraction and Control of Traffic Engineered Networks 486 Virtual Network model) 488 Like intent, service models provide higher layers of abstraction. 489 Service models are often also complemented with mappings that capture 490 dependencies between service and device or network configurations. 491 Unlike intent, service models do not allow to define a desired 492 "outcome" that would be automatically maintained by the intent 493 system. Instead, the management of service models requires the 494 development of sophisticated algorithms and control logic by network 495 providers or system integrators. 497 4.2.2. Policy and Policy-Based Network Management 499 Policy-Based Network Management (PBNM) is a management paradigm that 500 separates the rules that govern the behavior of a system from the 501 functionality of the system. It promises to reduce maintenance costs 502 of information and communication systems while improving flexibility 503 and runtime adaptability. It is present today at the heart of a 504 multitude of management architectures and paradigms, including SLA- 505 driven, Business-driven, autonomous, adaptive, and self-* management 506 [Boutaba07]. The interested reader is asked to refer to the rich set 507 of existing literature, which includes this and many other 508 references. In the following, we will only provide a much-abridged 509 and distilled overview. 511 At the heart of policy-based management is the concept of a policy. 512 Multiple definitions of policy exist: "Policies are rules governing 513 the choices in the behavior of a system" [Sloman94]. "Policy is a 514 set of rules that are used to manage and control the changing and/or 515 maintaining of the state of one or more managed objects" 516 [Strassner03]. Common to most definitions is the definition of a 517 policy as a "rule." Typically, the definition of a rule consists of 518 an event (whose occurrence triggers a rule), a set of conditions 519 (which get assessed and which must be true before any actions are 520 actually "fired"), and, finally, a set of one or more actions that 521 are carried out when the condition holds. 523 Policy-based management can be considered an imperative management 524 paradigm: Policies precisely specified what needs to be done when and 525 in which circumstance. By using policies, management can, in effect, 526 be defined as a set of simple control loops. This makes policy-based 527 management a suitable technology to implement autonomic behavior that 528 can exhibit self-* management properties, including self- 529 configuration, self-healing, self-optimization, and self-protection. 530 In effect, policies define management as a set of simple control 531 loops. 533 Policies typically involve a certain degree of abstraction in order 534 to cope with the heterogeneity of networking devices. Rather than 535 having a device-specific policy that defines events, conditions, and 536 actions in terms of device-specific commands, parameters, and data 537 models, a policy is defined at a higher level of abstraction 538 involving a canonical model of systems and devices to which the 539 policy is to be applied. A policy agent on a controller or the 540 device subsequently "renders" the policy, i.e., translates the 541 canonical model into a device-specific representation. This concept 542 allows applying the same policy across a wide range of devices 543 without needing to define multiple variants. In other words - policy 544 definition is de-coupled from policy instantiation and policy 545 enforcement. This enables operational scale and allows network 546 operators and authors of policies to think in higher terms of 547 abstraction than device specifics and be able to reuse the same, 548 high-level definition across different networking domains, WAN, DC, 549 or public cloud. 551 PBNM is typically "push-based": Policies are pushed onto devices 552 where they are rendered and enforced. The push operations are 553 conducted by a manager or controller, which is responsible for 554 deploying policies across the network and monitor their proper 555 operation. That being said, other policy architectures are possible. 556 For example, policy-based management can also include a pull- 557 component in which the decision regarding which action to take is 558 delegated to a so-called Policy Decision Point (PDP). This PDP can 559 reside outside the managed device itself and has typically global 560 visibility and context with which to make policy decisions. Whenever 561 a network device observes an event that is associated with a policy 562 but lacks the full definition of the policy or the ability to reach a 563 conclusion regarding the expected action, it reaches out to the PDP 564 for a decision (reached, for example, by deciding on an action based 565 on various conditions). Subsequently, the device carries out the 566 decision as returned by the PDP - the device "enforces" the policy 567 and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM 568 architectures typically involve a central component from which 569 policies are deployed across the network and/or policy decisions 570 served. 572 Like Intent, policies provide a higher layer of abstraction. Policy 573 systems are also able to capture dynamic aspects of the system under 574 management through the specification of rules that allow defining 575 various triggers for specific courses of actions. Unlike intent, the 576 definition of those rules (and courses of actions) still needs to be 577 articulated by users. Since the intent is unknown, conflict 578 resolution within or between policies requires interactions with a 579 user or some kind of logic that resides outside of PBM. In that 580 sense, policy constitutes a lower level of abstraction than intent, 581 and it is conceivable for Intent-Based Systems to generate policies 582 that are subsequently deployed by a PBM, allowing PBM to support 583 Intent-Based Networking. 585 4.2.3. Distinguishing between Intent, Policy, and Service Models 587 What Intent, Policy, and Service Models all have in common is the 588 fact that they involve a higher-layer of abstraction of a network 589 that does not involve device-specifics, that generally transcends 590 individual devices, and that makes the network easier to manage for 591 applications and human users compared to having to manage the network 592 one device at a time. Beyond that, differences emerge. Service 593 models have less in common with policy and intent than policy and 594 intent do with each other. 596 Summarized differences: 598 o A service model is a data model that is used to describe instances 599 of services that are provided to customers. A service model has 600 dependencies on lower-level models (device and network models) 601 when describing how the service is mapped onto the underlying 602 network and IT infrastructure. Instantiating a service model 603 requires orchestration by a system; the logic for how to 604 orchestrate/manage/provide the service model and how to map it 605 onto underlying resources is not included as part of the model 606 itself. 608 o Policy is a set of rules, typically modeled around a variation of 609 events/conditions/actions, used to express simple control loops 610 that can be rendered by devices without requiring intervention by 611 the outside system. Policies let users define what to do under 612 what circumstances, but they do not specify the desired outcome. 614 o Intent is a high-level, declarative goal that operates at the 615 level of a network and services it provides, not individual 616 devices. It is used to define outcomes and high-level operational 617 goals, without specifying how those outcomes should be achieved or 618 how goals should specifically be satisfied, and without the need 619 to enumerate specific events, conditions, and actions. Which 620 algorithm or rules to apply can be automatically "learned/derived 621 from intent" by the intent system. In the context of autonomic 622 networking, intent is ideally rendered by the network itself; 623 also, the dissemination of intent across the network and any 624 required coordination between nodes is resolved by the network 625 without the need for external systems. 627 One analogy to capture the difference between policy and intent 628 systems is that of Expert Systems and Learning Systems in the field 629 of Artificial Intelligence. Expert Systems operate on knowledge 630 bases with rules that are supplied by users, analogous to policy 631 systems whose policies are supplied by users. They are able to make 632 automatic inferences based on those rules but are not able to "learn" 633 new rules on their own. Learning Systems (popularized by deep 634 learning and neural networks), on the other hand, are able to learn 635 without depending on user programming or articulation of rules. 636 However, they do require a learning or training phase requiring large 637 data sets; explanations of actions that the system actually takes 638 provide a different set of challenges. Analogous to intent-based 639 systems, users focus on what they would like the learning system to 640 accomplish but not how to do it. 642 5. Principles 644 The following main operating principles allow characterizing the 645 intent-based/-driven/-defined nature of a system. 647 1. Single Source of Truth (SSoT) and Single Version/View of Truth 648 (SVoT). The SSoT is an essential component of an intent-based 649 system as it enables several important operations. The set of 650 validated intent expressions is the system's SSoT. SSoT and the 651 records of the operational states enable comparing the intended/ 652 desired state and actual/operational states of the system and 653 determining drift between them. SSoT and the drift information 654 provide the basis for corrective actions. If the intent-based 655 system is equipped with the means to predict states, it can 656 further develop strategies to anticipate, plan, and pro-actively 657 act on any diverging trends with the aim to minimize their 658 impact. Beyond providing a means for consistent system 659 operation, SSoT also allows for better traceability to validate 660 if/how the initial intent and associated business goals have been 661 properly met, to evaluate the impacts of changes in the intent 662 parameters and impacts and effects of the events occurring in the 663 system. 664 Single Version (or View) of Truth derives from the SSoT and can 665 be used to perform other operations, such as querying, polling, 666 or filtering measured and correlated information in order to 667 create so-called "views." These views can serve the operators 668 and/or the users of the intent-based system. In order to create 669 intents as single sources of truth, the IBS must follow well- 670 specified and well-documented processes and models. In other 671 contexts, SSoT is also referred to as the invariance of the 672 intent [Lenrow15]. 674 2. One-touch but not one-shot. In an ideal intent-based system, the 675 user expresses intent in one form or another, and then the system 676 takes over all subsequent operations (one-touch). A zero-touch 677 approach could also be imagined in the case where the intent- 678 based system has the capabilities or means to recognize 679 intentions in any form of data. However, the zero- or one-touch 680 approach should not distract from the fact that reaching the 681 state of a well-formed and valid intent expression is not a one- 682 shot process. On the contrary, the interfacing between the user 683 and the intent-based system could be designed as an interactive 684 and iterative process. Depending on the level of abstraction, 685 the intent expressions may initially contain more or less 686 implicit parts and unprecise or unknown parameters and 687 constraints. The role of the intent-based system is to parse, 688 understand, and refine the intent expression to reach a well- 689 formed and valid intent expression that can be further used by 690 the system for the fulfillment and assurance operations. An 691 intent refinement process could use a combination of iterative 692 steps involving the user to validate the proposed refined intent 693 and to ask the user for clarifications in case some parameters or 694 variables could not be deduced or learned by means of the system 695 itself. In addition, the Intent-Based System will need to 696 moderate between conflicting intent, helping users to properly 697 choose between intent alternatives that may have different 698 ramifications. 700 3. Autonomy and Supervision. A desirable goal for an intent-based 701 system is to offer a high degree of flexibility and freedom on 702 both the user side and system side, e.g., by giving the user the 703 ability to express intents using the user's own terms, by 704 supporting different forms of expression of intents and being 705 capable of refining the intent expressions to well-formed and 706 exploitable expressions. The dual principle of autonomy and 707 supervision allows operating a system that will have the 708 necessary levels of autonomy to conduct its tasks and operations 709 without requiring the intervention of the user and taking its own 710 decisions (within its areas of concern and span of control) as 711 how to perform and meet the user expectations in terms of 712 performance and quality, while at the same time providing the 713 proper level of supervision to satisfy the user requirements for 714 reporting and escalation of relevant information. 716 4. Learning. An intent-based system is a learning system. By 717 contrast to the imperative type of system, such as Event- 718 Condition-Action policy rules, where the user defines beforehand 719 the expected behavior of the system to various events and 720 conditions, in an intent-based system, the user only declares 721 what the system should achieve and not how to achieve these 722 goals. There is thus a transfer of reasoning/rationality from 723 the human (domain knowledge) to the system. This transfer of 724 cognitive capability also implies the availability in the intent- 725 based system of capabilities or means for learning, reasoning, 726 and knowledge representation and management. The learning 727 abilities of an IBS can apply to different tasks such as 728 optimization of the intent rendering or intent refinement 729 processes. The fact that an intent-based system is a 730 continuously evolving system creates the condition for continuous 731 learning and optimization. Other cognitive capabilities such as 732 planning can also be leveraged in an intent-based system to 733 anticipate or forecast future system state and response to 734 changes in intents or network conditions and thus elaboration of 735 plans to accommodate the changes while preserving system 736 stability and efficiency in a trade-off with cost and robustness 737 of operations. Cope with unawareness of users (smart 738 recommendations). 740 5. Capability exposure. Capability exposure consists in the need 741 for expressive network capabilities, requirements, and 742 constraints to be able to compose/decompose intents and map the 743 user's expectations to the system capabilities. 745 6. Abstract and outcome-driven. Users do not need to be concerned 746 with how intent is achieved and are empowered to think in terms 747 of outcomes. In addition, they can refer to concepts at a higher 748 level of abstractions, independent e.g. of vendor-specific 749 renderings. 751 The described principles are perhaps the most prominent, but they are 752 not an exhaustive list. There are additional aspects to consider, 753 such as: 755 o Intent targets are not individual devices but typically 756 aggregations (such as groups of devices adhering to a common 757 criteria, such as devices of a particular role) or abstractions 758 (such as service types, service instances, topologies). 760 o Abstraction and inherent virtualization: agnostic to 761 implementation details. 763 o Human-tailored network interaction: IBN SHOULD speak the language 764 of the user as opposed to requiring the user to speak the language 765 of the device/network. 767 o Explainability as an important IBN function, detection and IBN- 768 aided resolution of conflicting intent, reconciliation of what the 769 user wants and what the network can actually do. 771 o Inherent support, verification, and assurance of trust. 773 All of these principles and considerations have implications on the 774 design of intent-based systems and their supporting architecture. 775 Accordingly, they need to be considered when deriving functional and 776 operational requirements. 778 6. Intent-Based Networking - Functionality 780 Intent-Based Networking involves a wide variety of functions that can 781 be roughly divided into two categories: 783 o Intent Fulfillment provides functions and interfaces that allow 784 users to communicate intent to the network and that perform the 785 necessary actions to ensure that intent is achieved. This 786 includes algorithms to determine proper courses of action and 787 functions that learn to optimize outcomes over time. In addition, 788 it also includes more traditional functions such as any required 789 orchestration of coordinated configuration operations across the 790 network and rendering of higher-level abstractions into lower- 791 level parameters and control knobs. 793 o Intent Assurance provides functions and interfaces that allow 794 users to validate and monitor that the network is indeed adhering 795 to and complying with intent. This is necessary to assess the 796 effectiveness of actions taken as part of fulfillment, providing 797 important feedback that allows those functions to be trained or 798 tuned over time to optimize outcomes. In addition, Intent 799 Assurance is necessary to address "intent drift." Intent drift 800 occurs when a system originally meets the intent, but over time 801 gradually allows its behavior to change or be affected until it no 802 longer does or does so in a less effective manner. 804 The following sections provide a more comprehensive overview of those 805 functions. 807 6.1. Intent Fulfillment 809 Intent fulfillment is concerned with the functions that take intent 810 from its origination by a user (generally, an administrator of the 811 responsible organization) to its realization in the network. 813 6.1.1. Intent Ingestion and Interaction with Users 815 The first set of functions is concerned with "ingesting" intent, 816 i.e., obtaining intent through interactions with users. They provide 817 functions that recognize intent from interaction with the user as 818 well as functions that allow users to refine their intent and 819 articulate it in such ways so that it becomes actionable by an 820 Intent-Based System. Typically, those functions go beyond those 821 provided by a traditional API, although APIs may still be provided 822 (and needed for interactions beyond human users, i.e., with other 823 machines). Many cases would also invove a set of intuitive and easy- 824 to-navigate workflows that guide users throughout the intent 825 ingestion phase, making sure that all inputs that are nessesary for 826 intent modeling and consecutive translation have been gathered. They 827 may support unconventional human-machine interactions, in which a 828 human will not simply give simple commands but which may involve a 829 human-machine dialog to provide clarifications, to explain 830 ramifications and trade-offs, and to facilitate refinements. 832 The goal is ultimately to make Intent-Based Systems as easy and 833 natural to use and interact with as possible, in particular allowing 834 human users to interact with the IBS in ways that do not involve a 835 steep learning curve that forces the user to learn the "language" of 836 the system. Ideally, it will be the Intent-Based Systems that should 837 increasingly be able to learn how to understand the user as opposed 838 to the other way round. Of course, further research will be required 839 to make this a reality. 841 6.1.2. Intent Translation 843 A second set of functions needs to translate user intent into courses 844 of actions and requests to take against the network, which will be 845 meaningful to network configuration and provisioning systems. These 846 functions lie at the core of IBS, bridging the gap between 847 interaction with users on the one hand and the traditional management 848 and operations side that will need to orchestrate provisioning and 849 configuration across the network. 851 Beyond merely breaking down a higher layer of abstraction (intent) 852 into a lower layer of abstraction (policies, device configuration), 853 Intent Translation functions can be complemented with functions and 854 algorithms that perform optimizations and that are able to learn and 855 improve over time in order to result in the best outcomes, 856 specifically in cases where multiple ways of achieving those outcomes 857 are conceivable. For example, satisfying an intent may involve 858 computation of paths and other parameters that need will need to be 859 configured across the network. Heuristics and algorithms to do so 860 may evolve over time to optimize outcomes that may depend on a myriad 861 of dynamic network conditions and context. 863 6.1.3. Intent Orchestration 865 A third set of functions deals with the actual configuration and 866 provisioning steps that need to be orchestrated across the network 867 and that were determined by the previous intent translation step. 869 6.2. Intent Assurance 871 Intent assurance is concerned with the functions that are necessary 872 to ensure that the network indeed complies with the desired intent 873 once it has been fulfilled. 875 6.2.1. Monitoring 877 A first set of assurance functions monitors and observes the network 878 and its exhibited behavior. This includes all the usual assurance 879 functions such as monitoring the network for events and performance 880 outliers, performing measurements to assess service levels that are 881 being delivered, generating and collecting telemetry data. 882 Monitoring and observation are required as the basis for the next set 883 of functions that assess whether the observed behavior is in fact in 884 compliance with the behavior that is expected based on the intent. 886 6.2.2. Intent Compliance Assessment 888 At the core of Intent Assurance are functions that compare the actual 889 network behavior that is being monitored and observed with the 890 intended behavior that is expected per the intent and is held by 891 SSoT. These functions continuously assess and validate whether the 892 observation indicates compliance with intent. This includes 893 assessing the effectiveness of intent fulfillment actions, including 894 verifying that the actions had the desired effect and assessing the 895 magnitude of the effect as applicable. It can also include functions 896 that perform analysis and aggregation of raw observation data. The 897 results of the assessment can be fed back to facilitate learning 898 functions that optimize outcomes. 900 Intent compliance assessment also includes assessing whether intent 901 drift occurs over time. Intent drift can be caused by a control 902 plane or lower-level management operations that inadvertently cause 903 behavior changes which conflict with intent that was orchestrated 904 earlier. Intent-Based Systems and Networks need to be able to detect 905 when such drift occurs or is about to occur as well as assess the 906 severity of the drift. 908 6.2.3. Intent Compliance Actions 910 When intent drift occurs or network behavior is inconsistent with 911 desired intent, functions that are able to trigger corrective actions 912 are needed. This includes actions needed to resolve intent drift and 913 bring the network back into compliance. Alternatively, and where 914 necessary, reporting functions need to be triggered that alert 915 operators and provide them with the necessary information and tools 916 to react appropriately, e.g., by helping them articulate 917 modifications to the original intent to moderate between conflicting 918 concerns. 920 6.2.4. Abstraction, Aggregation, Reporting 922 The outcome of Intent Assurance needs to be reported back to the user 923 in ways that allow the user to relate the outcomes to their intent. 924 This requires a set of functions that are able to analyze, aggregate, 925 and abstract the results of the observations accordingly. In many 926 cases, lower-level concepts such as detailed performance statistics 927 and observations related to low-level settings need to be "up- 928 leveled" to concepts the user can relate to and take action on. 930 The required aggregation and analysis functionality needs to be 931 complemented with functions that report intent compliance status and 932 provide adequate summarization and visualization to human users. 934 7. Life-cycle 936 Intent is subject to a life-cycle: it comes into being, may undergo 937 changes over the course of time, and may at some point be retracted. 938 This life-cycle is closely tied to various interconnection functions 939 that are associated with the intent concept. 941 Figure 1 depicts an intent life-cycle and its main functions. The 942 functions were introduced in Section 6 and are divided into two 943 functional (horizontal) planes, reflecting the distinction between 944 fulfillment and assurance. In addition, they are divided into three 945 (vertical) spaces. 947 The spaces indicate the different perspectives and interactions with 948 different roles that are involved in addressing the functions: 950 o The User Space involves the functions that interface the network 951 and intent-based system with the human user. It involves the 952 functions that allow users to articulate and the intent-based 953 system to recognize that intent. It also involves the functions 954 that report back the status of the network relative to the intent 955 and that allow users to assess outcomes and whether their intent 956 has the desired effect. 958 o The Translation, or Intent-Based System (IBS) Space involves the 959 functions that bridge the gap between intent users and network 960 operations. This includes the functions used to translate an 961 intent into a course of action as well as the algorithms that are 962 used to plan and optimize those courses of action also in 963 consideration of feedback and observations from the network. It 964 also includes the functions to analyze and aggregate observations 965 from the network in order to validate compliance with the intent 966 and to take corrective actions as necessary. In addition, it 967 includes functions that abstract observations from the network in 968 ways that relate them to the intent as communicated by users. 969 This facilitates the reporting functions in the userspace. 971 o The Network Operations Space, finally, involves the traditional 972 orchestration, configuration, monitoring, and measurement 973 functions, which are used to effectuate the rendered intent and 974 observe its effects on the network. 976 User Space : Translation / IBS : Network Ops 977 : Space : Space 978 : : 979 +----------+ : +----------+ +-----------+ : +-----------+ 980 Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| 981 |generate | | | | plan/ | | provision | 982 |intent |<--- | refine | | render | : | | 983 +----^-----+ : +----------+ +-----^-----+ : +-----------+ 984 | : | : | 985 .............|................................|................|..... 986 | : +----+---+ : v 987 | : |validate| : +----------+ 988 | : +----^---+ <----| monitor/ | 989 Assure +---+---+ : +---------+ +-----+---+ : | observe/ | 990 |report | <---- |abstract |<---| analyze | <----| | 991 +-------+ : +---------+ |aggregate| : +----------+ 992 : +---------+ : 994 Figure 1: Intent Life-cycle 996 When carefully inspecting the diagram, it becomes apparent that the 997 intent life-cycle, in fact, involves two cycles, or loops: 999 o The "inner" intent control loop between IBS and Network Operations 1000 space is completely autonomic and does not involve any human in 1001 the loop. It involves automatic analysis and validation of intent 1002 based on observations from the network operations space. Those 1003 observations are fed into the function that plans the rendering of 1004 networking intent in order to make adjustments as needed in the 1005 configuration of the network. The loop addresses and counteracts 1006 any intent drift that may be occuring, using observations to 1007 assess the degree of the network's intent compliance and 1008 automatically prompting actions to address any discrepancies. 1009 Likewise, the loop allows to assess the effectiveness of any 1010 actions that are taken in order to continuously learn and improve 1011 how intent needs to be rendered in order to achieve the desired 1012 outcomes. 1014 o The "outer" intent control loop extends to the user space. It 1015 includes the user taking action and adjusting their intent based 1016 on observations and feedback from the IBS. Intent is thus 1017 subjected to a lifecycle: It comes into being, may undergo 1018 refinements, modifications, and changes of time, and may at some 1019 point in time even get retracted. 1021 8. Additional Considerations 1023 Given the popularity of the term "intent," it is tempting to broaden 1024 it use to encompass also other related concepts, resulting in 1025 "intent-washing" that paints those concepts in a new light by simply 1026 applying new intent terminology to them. A common example concerns 1027 referring to the northbound interface of SDN controllers as "intent 1028 interface". However, in some cases, this actually makes sense not 1029 just as a marketing ploy but as a way to better relate previously 1030 existing and new concepts. 1032 In that sense and regards to intent, it make sense to distinguish 1033 various subcategories of intent as follows: 1035 o Operational Intent: defines intent related to operational goals of 1036 an operator; corresponds to the original "intent" term and the 1037 concepts defined in this document. 1039 o Rule Intent: a synonym for policy rules regarding what to do when 1040 certain events occur. 1042 o Service intent: a synonym for customer service model [RFC8309]. 1044 o Flow Intent: A synonym for a Service Level Objective for a given 1045 flow. 1047 A comprehensive set of classifications of different concepts and 1048 categories of intent will be described in a separate document. 1050 9. IANA Considerations 1052 Not applicable 1054 10. Security Considerations 1056 This document describes concepts and definitions of Intent-Based 1057 Networking. As such, the below security considerations remain high 1058 level, i.e. in the form of principles, guidelines or requirements. 1059 More detailed security considerations will be described in the 1060 documents that specify the architecture and functionality. 1062 Security in Intent-Based Networking can apply to different facets: 1064 o Securing the intent-based system itself. 1066 o Mitigating the effects of erroneous, harmful or compromised 1067 intents. 1069 o Expressing security policies or security-related parameters with 1070 intents. 1072 Securing the intent-based system aims at making the intent-based 1073 system operationally secure by implementing security mechanisms and 1074 applying security best practices. In the context of Intent-based 1075 Networking, such mechanisms and practices may consist in intent 1076 verification and validation; operations on intents by authenticated 1077 and authorized users only; protection against or detection of 1078 tampered intents. Such mechanisms may also include the introduction 1079 of multiple levels of intent. For example, intent related to 1080 securing the network should occur at a "deeper" level that overrides 1081 other levels of intent if necessary, and that is not subject to 1082 modification through regular operations but through ones that are 1083 specifically secured. Use of additional mechanisms such as 1084 explanation components that describe the security ramifications and 1085 trade-off should be considered as well. 1087 Mitigating the effects of erroneous or compromised intents aims at 1088 making the intent-based system operationally safe by providing 1089 checkpoint and safeguard mechanisms and operating principles. In the 1090 context of Intent-based Networking, such mechanisms and principles 1091 may consist in the ability to automatically detect unintended, 1092 detrimental or abnormal behavior; the ability to automatically (and 1093 gracefully) rollback or fallback to a previous "safe" state; the 1094 ability to prevent or contain error amplification (due to the 1095 combination of a higher degree of automation and the intrinsic higher 1096 degree of freedom, ambiguity, and implicitly conveyed by intents); 1097 dynamic levels of supervision and reporting to make the user aware of 1098 the right information, at the right time with the right level of 1099 context. Erroneous or harmful intents may inadvertently propagate 1100 and compromise security. In addition, compromised intents, for 1101 example, intent forged by an inside attacker, may sabotage or harm 1102 the network resources and make them vulnerable to further, larger 1103 attacks, e.g., by defeating certain security mechanisms. 1105 Expressing security policies or security-related parameters with 1106 intents consists of using the intent formalism (a high-level, 1107 declarative abstraction), or part(s) of an intent statement to define 1108 security-related aspects such as data governance, level(s) of 1109 confidentiality in data exchange, level(s) of availability of system 1110 resources, of protection in forwarding paths, of isolation in 1111 processing functions, level(s) of encryption, authorized entities for 1112 given operations, etc. 1114 The development and introduction of Intent-Based Networking in 1115 operational environments will certainly create new security concerns. 1116 Such security concerns have to be anticipated at the design and 1117 specification time. However, Intent-Based Networking may also be 1118 used as an enabler for better security. For instance, security and 1119 privacy rules could be expressed in a more human-friendly and generic 1120 way and be less technology-specific and less complex, leading to 1121 fewer low-level configuration mistakes. The detection of threats or 1122 attacks could also be made more simple and comprehensive thanks to 1123 conflict detection at higher-level or at coarser granularity 1125 More thorough security analyses should be conducted as our 1126 understanding of Intent-Based Networking technology matures. 1128 11. Acknowledgments 1130 We would like to thank the members of the IRTF Network Management 1131 Research Group (NMRG) for many valuable discussions and feedback. In 1132 particular, we would like to acknowledge the feedback and support 1133 from Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis 1134 Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, 1135 William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu 1136 Song, Peter Szilagyi, and Csaba Vulkan. Of those, we would like to 1137 thank the following persons who went one step further and also 1138 provided reviews of the document: Remi Badonnel, Walter Cerroni, 1139 Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, 1140 Peter Szilagyi, and Csaba Vulkan. 1142 12. Informative References 1144 [Boutaba07] 1145 Boutaba, R. and I. Aib, "Policy-Based Management: A 1146 Historical perspective. Journal of Network and Systems 1147 Management (JNSM), Springer, Vol. 15 (4).", December 2007. 1149 [Clemm20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network 1150 Management 2030: Operations and Control of Network 2030 1151 Services. Journal of Network and Systems Management 1152 (JNSM), Springer, Vol. 28 (4).", October 2020. 1154 [I-D.ietf-anima-autonomic-control-plane] 1155 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1156 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1157 plane-30 (work in progress), October 2020. 1159 [I-D.ietf-teas-ietf-network-slice-definition] 1160 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1161 Tantsura, "Definition of IETF Network Slices", draft-ietf- 1162 teas-ietf-network-slice-definition-00 (work in progress), 1163 January 2021. 1165 [I-D.ietf-teas-te-service-mapping-yang] 1166 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 1167 and J. Tantsura, "Traffic Engineering (TE) and Service 1168 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1169 yang-05 (work in progress), November 2020. 1171 [Lenrow15] 1172 Lenrow, D., "Intent As The Common Interface to Network 1173 Resources, Intent Based Network Summit 2015 ONF Boulder: 1174 IntentNBI", February 2015. 1176 [M3010] ITU-T, "M.3010 : Principles for a telecommunications 1177 management network.", February 2000. 1179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1180 Requirement Levels", BCP 14, RFC 2119, 1181 DOI 10.17487/RFC2119, March 1997, 1182 . 1184 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1185 Architecture for Describing Simple Network Management 1186 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1187 DOI 10.17487/RFC3411, December 2002, 1188 . 1190 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1191 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1192 Networking: Definitions and Design Goals", RFC 7575, 1193 DOI 10.17487/RFC7575, June 2015, 1194 . 1196 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1197 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1198 . 1200 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1201 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1202 May 2017, . 1204 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1205 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1206 DOI 10.17487/RFC8299, January 2018, 1207 . 1209 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1210 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1211 . 1213 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1214 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1215 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1216 2018, . 1218 [Sloman94] 1219 Sloman, M., "Policy Driven Management for Distributed 1220 Systems. Journal of Network and Systems Management (JNSM), 1221 Springer, Vol. 2 (4).", December 1994. 1223 [Strassner03] 1224 Strassner, J., "Policy-Based Network Management. 1225 Elsevier.", 2003. 1227 [TR523] Foundation, O. N., "Intent NBI - Definition and 1228 Principles. ONF TR-523.", October 2016. 1230 Authors' Addresses 1231 Alexander Clemm 1232 Futurewei 1233 2330 Central Expressway 1234 Santa Clara, CA 95050 1235 USA 1237 Email: ludwig@clemm.org 1239 Laurent Ciavaglia 1240 Nokia 1241 Route de Villejust 1242 Nozay 91460 1243 FR 1245 Email: laurent.ciavaglia@nokia.com 1247 Lisandro Zambenedetti Granville 1248 Federal University of Rio Grande do Sul (UFRGS) 1249 Av. Bento Goncalves 1250 Porto Alegre 9500 1251 BR 1253 Email: granville@inf.ufrgs.br 1255 Jeff Tantsura 1256 Juniper Networks 1258 Email: jefftant.ietf@gmail.com