idnits 2.17.1 draft-irtf-nmrg-ibn-concepts-definitions-09.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (March 2022) is 772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8174' is defined on line 1272, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-10 Summary: 0 errors (**), 0 flaws (~~), 4 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: 22 September 2022 Rakuten Mobile 6 L. Z. Granville 7 Federal University of Rio Grande do Sul (UFRGS) 8 J. Tantsura 9 Microsoft 10 March 2022 12 Intent-Based Networking - Concepts and Definitions 13 draft-irtf-nmrg-ibn-concepts-definitions-09 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 research group, 29 having received many detailed and positive reviews by RG 30 participants. It 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 2 September 2022. 49 Copyright Notice 51 Copyright (c) 2022 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 6 67 3. Introduction of Concepts . . . . . . . . . . . . . . . . . . 7 68 3.1. Intent and Intent-Based Management . . . . . . . . . . . 7 69 3.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 11 70 3.2.1. Service Models . . . . . . . . . . . . . . . . . . . 11 71 3.2.2. Policy and Policy-Based Network Management . . . . . 13 72 3.2.3. Distinguishing between Intent, Policy, and Service 73 Models . . . . . . . . . . . . . . . . . . . . . . . 15 74 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5. Intent-Based Networking - Functionality . . . . . . . . . . . 19 76 5.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 19 77 5.1.1. Intent Ingestion and Interaction with Users . . . . . 19 78 5.1.2. Intent Translation . . . . . . . . . . . . . . . . . 20 79 5.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 20 80 5.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 21 81 5.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 21 82 5.2.2. Intent Compliance Assessment . . . . . . . . . . . . 21 83 5.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 21 84 5.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 22 85 6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 7. Additional Considerations . . . . . . . . . . . . . . . . . . 24 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 90 11. Informative References . . . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 This document is a product of the IRTF Network Management Research 96 Group (NMRG). It reflects the consensus of the RG, receiving reviews 97 and explicit support from many participants. It is published for 98 informational purposes. 100 In the past, interest regarding management and operations in the IETF 101 has focused on individual network and device features. 102 Standardization emphasis has generally been put on management 103 instrumentation that needed to be provided to a networking device. A 104 prime example of this is SNMP-based management [RFC3411] and the 200+ 105 MIBs that have been defined by the IETF over the years. More recent 106 examples include YANG data model definitions [RFC7950] for aspects 107 such as interface configuration, ACL configuration, and Syslog 108 configuration. 110 There is a clear sense and reality that managing networks by 111 configuring myriads of "nerd knobs" on a device-by-device basis is no 112 longer an option in modern network environments. Significant 113 challenges arise with keeping device configurations not only 114 consistent across a network but also consistent with the needs of 115 services and service features they are supposed to enable. 116 Additional challenges arise with regard to being able to rapidly 117 adapt the network as needed and to be able to do so at scale. At the 118 same time, operations need to be streamlined and automated wherever 119 possible to not only lower operational expenses but also allow for 120 rapid reconfiguration of networks at sub-second time scales and to 121 ensure that networks are delivering their functionality as expected. 122 Among other things, this requires the ability to consume operational 123 data, perform analytics, and dynamically take actions in a way that 124 is aware of context as well as intended outcomes at near real-time 125 speeds. 127 Accordingly, the IETF has begun to address end-to-end management 128 aspects that go beyond the realm of individual devices in isolation. 129 Examples include the definition of YANG models for network topology 130 [RFC8345] or the introduction of service models used by service 131 orchestration systems and controllers [RFC8309]. Much of the 132 interest has been fueled by the discussion about how to manage 133 autonomic networks, as discussed in the ANIMA working group. 134 Autonomic networks are driven by the desire to lower operational 135 expenses and make the management of the network as a whole more 136 straightforward, putting it at odds with the need to manage the 137 network one device and one feature at a time. However, while 138 autonomic networks are intended to exhibit "self-management" 139 properties, they still require input from an operator or outside 140 system to provide operational guidance and information about the 141 goals, purposes, and service instances that the network is to serve. 143 This input and operational guidance are commonly referred to as 144 "intent," and networks that allow network operators to provide their 145 input using intent as "Intent-Based Networks" (IBN) and the systems 146 that help implement intent as "Intent-Based Systems" (IBS). Those 147 systems can manifest themselves in a number of ways, for example as a 148 controller or managemement system that are implemented as an 149 application that runs on a server or set of servers, or as a set of 150 functions that are distributed across a network and that collectively 151 perform their intent-based functionality. 153 However, intent is about more than just enabling a form of operator 154 interaction with the network that involves higher-layer abstractions. 155 It is also about the ability to let operators focus on what they want 156 their desired outcomes to be while leaving details about how those 157 outcomes would, in fact, be achieved to the IBN (respectively IBS). 158 This, in turn, enables much greater operational efficiency at greater 159 scale, in shorter time scales, with less dependency on human 160 activities (and possibility for mistakes), and an ideal candidate, 161 e.g., for artificial intelligence techniques that can bring about the 162 next level of network automation [Clemm20]. 164 This vision has since caught on with the industry, leading to a 165 significant number of solutions that offer Intent-Based Management 166 that promise network providers to manage networks holistically at a 167 higher level of abstraction and as a system that happens to consist 168 of interconnected components, as opposed to a set of independent 169 devices (that happen to be interconnected). Those offerings include 170 IBN and IBS (offering a full lifecycle of intent), SDN controllers 171 (offering a single point of control and administration for a 172 network), and network management and Operations Support Systems 173 (OSS). 175 It has been recognized for a long time that comprehensive management 176 solutions cannot operate only at the level of individual devices and 177 low-level configurations. In this sense, the vision of intent is not 178 entirely new. In the past, ITU-T's model of a Telecommunications 179 Management Network (TMN) introduced a set of management layers that 180 defined a management hierarchy, consisting of network element, 181 network, service, and business management [M3010]. High-level 182 operational objectives would propagate in a top-down fashion from 183 upper to lower layers. The associated abstraction hierarchy was 184 crucial to decompose management complexity into separate areas of 185 concern. This abstraction hierarchy was accompanied by an 186 information hierarchy that concerned itself at the lowest level with 187 device-specific information, but that would, at higher layers, 188 include, for example, end-to-end service instances. Similarly, the 189 concept of Policy-Based Network Management (PBNM) has, for a long 190 time, touted the ability to allow users to manage networks by 191 specifying high-level management policies, with policy systems 192 automatically "rendering" those policies, i.e., breaking them down 193 into low-level configurations and control logic. (As a note, in the 194 context of this document, "users" generally refers to operators and 195 administrators who are responsible for the management and operation 196 of communication services and networking infrastructures, not to "end 197 users" of communication services.) 199 What has been missing, however, is putting these concepts into a more 200 current context and updating them to account for current technology 201 trends. This document clarifies the concepts behind intent. It 202 differentiates intent from related concepts. It also provides an 203 overview of first-order principles of IBN as well as the associated 204 functionality. The goal is to contribute to a common and shared 205 understanding that can be used as a foundation to articulate research 206 and engineering problems in the area of IBN. 208 It should be noted that the articulation of IBN-related research 209 problems is beyond the scope of this document. However, it should be 210 recognized that IBN has become an important topic in the research 211 community. Per IEEE Xplore [IEEEXPLORE], as of December 2021, in the 212 past decade since 2012, there have been 1138 papers with the index 213 term "intent", of which 411 specifically mention networking. The 214 time period since 2020 alone accounts for 316 papers on intent and 215 153 for intent networking, indicating accelerating interest. In 216 addition, workshops dedicated to this theme are beginning to appear, 217 such as the IEEE International Workshop on Intent-Based Networking 218 [WIN21], as well as various special journal issues [IEEE-TITS21] 219 [MDPI22]. A survey of current intent-driven networking research has 220 been published in [Pang20], listing among the most pressing current 221 research challenges aspects such as intent translation and 222 understanding, intent interfaces, and security. 224 2. Definitions and Acronyms 226 ACL: Access Control List 228 API: Application Programming Interface 230 Intent: A set of operational goals (that a network should meet) 231 and outcomes (that a network is supposed to deliver), defined in a 232 declarative manner without specifying how to achieve or implement 233 them. 235 IBA: Intent-Based Analytics - Analytics that are defined and 236 derived from users' intent and used to validate the intended 237 state. 239 Intent-Based Management - The concept of performing management 240 based on the concept of intent. 242 IBN: Intent-Based Network - A network that can be managed using 243 intent. 245 IBS: Intent-Based System - A system that supports management 246 functions that can be guided using intent. 248 PBNM: Policy-Based Network Management 250 Policy: A set of rules that governs the choices in behavior of a 251 system. 253 PDP: Policy Decision Point 255 PEP: Policy Enforcement Point 257 Service Model: A model that represents a service that is provided 258 by a network to a user. 260 SSoT: Single Source of Truth - A functional block in an IBN system 261 that normalizes users' intent and serves as the single source of 262 data for the lower layers. 264 SVoT: Single Version of Truth 266 User: In the context of this document, an operator and/or 267 administrator responsible for the management and operation of 268 communication services and networking infrastructure (as opposed 269 to an end user of a communication service) 271 3. Introduction of Concepts 273 The following section provides an overview of the concept of intent 274 and Intent-Based Management. It also provides an overview of the 275 related concepts of service models and policies (and Policy-Based 276 Network Management), and explains how they relate to intent and 277 Intent-Based Management. 279 3.1. Intent and Intent-Based Management 281 In this document, intent is defined as a set of operational goals 282 (that a network is supposed to meet) and outcomes (that a network is 283 supposed to deliver), defined in a declarative manner without 284 specifying how to achieve or implement them. 286 The term "intent" was first introduced in the context of Autonomic 287 Networks, where it is defined as "an abstract, high-level policy used 288 to operate a network" [RFC7575]. According to this definition, an 289 intent is a specific type of policy provided by a user to provide 290 guidance to the Autonomic Network that would otherwise operate 291 without human intervention. However, to avoid using intent simply as 292 a synonym for policy, a distinction that differentiates intent 293 clearly from other types of policies needs to be introduced. 295 Intent-Based Management aims to lead towards networks that are 296 fundamentally simpler to manage and operate, requiring only minimal 297 outside intervention. Networks, even when they are autonomic, are 298 not clairvoyant and have no way of automatically knowing particular 299 operational goals nor which instances of networking services to 300 support. In other words, they do not know what the intent of the 301 network provider is that gives the network the purpose of its being. 302 This still needs to be communicated to the network by what informally 303 constitutes intent. That being said, the concept of intent is not 304 limited just to autonomic networks, such as networks that feature an 305 Autonomic Control Plane [RFC8994], but applies to any network. 307 Intent defines goals and outcomes in a manner that is purely 308 declarative, specifying what to accomplish, not how to achieve it. 309 Intent thus applies several important concepts simultaneously: 311 * It provides data abstraction: users do not need to be concerned 312 with low-level device configuration and nerd knobs. 314 * It provides functional abstraction from particular management and 315 control logic: users do not need to be concerned even with how to 316 achieve a given intent. What is specified is the desired outcome, 317 with the IBS automatically figuring out a course of action (e.g., 318 using an algorithm or applying a set of rules derived from the 319 intent) for how to achieve the outcome. 321 The following are some examples of intent, expressed in natural 322 language for the sake of clarity (actual interfaces used to convey 323 intent may differ): 325 * "Steer networking traffic originating from endpoints in one 326 geography away from a second geography, unless the destination 327 lies in that second geography." (States what to achieve, not 328 how.) 330 * "Avoid routing networking traffic originating from a given set of 331 endpoints (or associated with a given customer) through a 332 particular vendor's equipment, even if this occurs at the expense 333 of reduced service levels." (States what to achieve, not how, 334 providing additional guidance for how to trade off between 335 different goals when necessary) 337 * "Maximize network utilization even if it means trading off service 338 levels (such as latency, loss) unless service levels have 339 deteriorated 20% or more from their historical mean." (A desired 340 outcome, with a set of constraints for additional guidance, which 341 does not specify how to achieve this.) 343 * "VPN service must have path protection at all times for all 344 paths." (A desired outcome of which it may not be clear how it 345 can be precisely accommodated.) 347 * "Generate in-situ OAM data and network telemetry for later offline 348 analysis whenever significant fluctuations in latency across a 349 path are observed." (Goes beyond traditional event-condition- 350 action by not being specific about what constitutes "significant" 351 and what specific data to collect) 353 * "Route traffic in a Space Information Network in a way that 354 minimizes dependency on stratospheric balloons unless the intended 355 destination is an aircraft." (Does not specify how to precisely 356 achieve this; extrapolates on scenarios mentioned in [Pang20]) 358 * "For a smart city service, ensure traffic signal control traffic 359 uses dedicated and redundant slices that avoid fate sharing." (A 360 desired outcome with a set of constraints and additional guidance 361 without specifying how to precisely achieve this; extrapolates on 362 scenarios from [Gharbaoui21]). 364 In contrast, the following are examples of what would not constitute 365 intent (again, expressed in natural language for the sake of 366 clarity): 368 * "Configure a given interface with an IP address." This would be 369 considered device configuration and fiddling with configuration 370 knobs, not intent. 372 * "When interface utilization exceeds a specific threshold, emit an 373 alert." This would be a rule that can help support network 374 automation, but a simple rule is not an intent. 376 * "Configure a VPN with a tunnel from A to B over path P." This 377 would be considered as a configuration of a service. 379 * "Deny traffic to prefix P1 unless it is traffic from prefix P2." 380 This would be an example of an access policy or a firewall rule, 381 not intent. 383 In networks, in particular in networks that are deemed autonomic, 384 intent should ideally be rendered by the network itself, i.e., 385 translated into device-specific rules and courses of action. 386 Ideally, intent would not need to be orchestrated or broken down by a 387 higher-level, centralized system but by the network devices 388 themselves using a combination of distributed algorithms and local 389 device abstractions. In this idealized vision, because intent holds 390 for the network as a whole, intent should ideally be automatically 391 disseminated across all devices in the network, which can themselves 392 decide whether they need to act on it. 394 However, such decentralization will not be practical in all cases. 395 Certain functions will need to be at least conceptually centralized. 396 For example, users may require a single conceptual point of 397 interaction with the network. The system providing this points acts 398 as the operational front end for the network through which users can 399 direct requests at the network and from which they can receive 400 updates about the network. It may appear to users as a single 401 system, even if it is implemented in a distributed manner. In turn, 402 it interacts with and manages other systems in the network as needed 403 in order to realize (i.e., to fulfill and to assure) the desired 404 intent. Likewise, the vast majority of network devices may be 405 intent-agnostic and focus only (for example) on the actual forwarding 406 of packets. Many devices may also be constrained in terms of their 407 processing resources. This means that not every device may be able 408 to act on intent on its own. Again, intent in those cases can be 409 achieved by a separate system which performs the required actions. 411 Another reason to provide intent functionality from a conceptually 412 centralized point is in cases where the the realization of a certain 413 type of intent benefits from global knowledge of a network and its 414 state. In many cases, such a global view may be impractical to 415 maintain by individual devices, for example due to the volume of data 416 and time lags that are involved. It may even be impractical for 417 devices to simply access such a view from another remote system if 418 such were available. 420 All of this implies that in many cases, certain intent functionality 421 needs to be provided by functions that are specialized for that 422 purpose and that may be provided by dedicated systems (which in some 423 cases could also co-host other networking functions). For example, 424 the translation of specific types of intent into corresponding 425 courses of action and algorithms to achieve the desired outcomes may 426 need to be provided by such specialized functions. Of course, to 427 avoid single points of failure, the implementation and hosting of 428 such functions may still be distributed, even if conceptually 429 centralized. 431 Regardless of its particular implementation in centralized or 432 decentralized manner, an IBN is a network that can be managed using 433 intent. This means that it is able to recognize and ingest intent of 434 an operator or user and configure and adapt itself according to the 435 user intent, achieving an intended outcome (i.e., a desired state or 436 behavior) without requiring the user to specify the detailed 437 technical steps for how to achieve the outcome. Instead, the IBN 438 will be able to figure out on its own how to achieve the outcome. 439 Similarly, an IBS is a system that allows users to manage a network 440 using intent. Such a system will serve as a point of interaction 441 with users and implement the functionality that is necessary to 442 achieve the intended outcomes, interacting for that purpose with the 443 network as required. 445 Other definitions of intent exist, such as [TR523]. Intent there is 446 simply defined as a declarative interface that is typically provided 447 by a controller. It implies the presence of a centralized function 448 that renders the intent into lower-level policies or instructions and 449 orchestrates them across the network. While this is certainly one 450 way of implementation, the definition that is presented here is more 451 encompassing and ambitious, as it emphasizes the importance of 452 managing the network by specifying desired outcomes without the 453 specific steps to be taken in order to achieve the outcome. A 454 controller API that simply provides a network-level of abstraction is 455 more limited and would not necessarily qualify as intent. Likewise, 456 ingestion and recognition of intent may not necessarily occur via a 457 traditional API but may involve other types of human-machine 458 interactions. 460 3.2. Related Concepts 462 3.2.1. Service Models 464 A service model is a model that represents a service that is provided 465 by a network to a user. Per [RFC8309], a service model describes a 466 service and its parameters in a portable/implementation-agnostic way 467 that can be used independently of the equipment and operating 468 environment on which the service is realized. Two subcategories are 469 distinguished: a "Customer Service Model" describes an instance of a 470 service as provided to a customer, possibly associated with a service 471 order. A "Service Delivery Model" describes how a service is 472 instantiated over existing networking infrastructure. 474 An example of a service could be a Layer 3 VPN service [RFC8299], a 475 Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or 476 residential Internet access. Service models represent service 477 instances as entities in their own right. Services have their own 478 parameters, actions, and lifecycles. Typically, service instances 479 can be bound to end users of communication services, who might be 480 billed for the services provided. 482 Instantiating a service typically involves multiple aspects: 484 * A user (or northbound system) needs to define and/or request a 485 service to be instantiated. 487 * Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, 488 interfaces, bandwidth, or memory need to be allocated. 490 * How to map services to the resources needs to be defined. 491 Multiple mappings are often possible, which to select may depend 492 on context (such as which type of access is available to connect 493 the end user of a communication service with the service). 495 * Bindings between upper and lower-level objects need to be 496 maintained. 498 * Once instantiated, the service operational state needs to be 499 validated and assured to ensure that the network indeed delivers 500 the service as requested. 502 The realization of service models involves a system, such as a 503 controller, that provides provisioning logic. This includes breaking 504 down high-level service abstractions into lower-level device 505 abstractions, identifying and allocating system resources, and 506 orchestrating individual provisioning steps. Orchestration 507 operations are generally conducted using a "push" model in which the 508 controller/manager initiates the operations as required, then pushes 509 down the specific configurations to the device and validates whether 510 the new changes have been accepted and the new operational/derived 511 states are achieved and in sync with the intent/desired state. In 512 addition to instantiating and creating new instances of a service, 513 updating, modifying, and decommissioning services need to be also 514 supported. The device itself typically remains agnostic to the 515 service or the fact that its resources or configurations are part of 516 a service/concept at a higher layer. 518 Instantiated service models map to instantiated lower-layer network 519 and device models. Examples include instances of paths or instances 520 of specific port configurations. The service model typically also 521 models dependencies and layering of services over lower-layer 522 networking resources that are used to provide services. This 523 facilitates management by allowing to follow dependencies for 524 troubleshooting activities, to perform impact analysis in which 525 events in the network are assessed regarding their impact on services 526 and customers. Services are typically orchestrated and provisioned 527 top-to-bottom, which also facilitates keeping track of the assignment 528 of network resources (composition), while troubleshooted bottom-up 529 (decomposition). Service models might also be associated with other 530 data that does not concern the network but provides business context. 531 This includes things such as customer data (such as billing 532 information), service orders and service catalogs, tariffs, service 533 contracts, and Service Level Agreements (SLAs), including contractual 534 agreements regarding remediation actions. 536 [I-D.ietf-teas-te-service-mapping-yang] is an example of a data model 537 that provides a mapping for customer service models (e.g., the L3VPN 538 Service Model) to Traffic Engineering (TE) models (e.g., the TE 539 Tunnel or the Abstraction and Control of Traffic Engineered Networks 540 Virtual Network model) 542 Like intent, service models provide higher layers of abstraction. 543 Service models are often also complemented with mappings that capture 544 dependencies between service and device or network configurations. 545 Unlike intent, service models do not allow to define a desired 546 "outcome" that would be automatically maintained by an IBS. Instead, 547 the management of service models requires the development of 548 sophisticated algorithms and control logic by network providers or 549 system integrators. 551 3.2.2. Policy and Policy-Based Network Management 553 Policy-Based Network Management (PBNM) is a management paradigm that 554 separates the rules that govern the behavior of a system from the 555 functionality of the system. It promises to reduce maintenance costs 556 of information and communication systems while improving flexibility 557 and runtime adaptability. It is present today at the heart of a 558 multitude of management architectures and paradigms, including SLA- 559 driven, Business-driven, autonomous, adaptive, and self-* management 560 [Boutaba07]. The interested reader is asked to refer to the rich set 561 of existing literature, which includes this and many other 562 references. In the following, we will only provide a much-abridged 563 and distilled overview. 565 At the heart of policy-based management is the concept of a policy. 566 Multiple definitions of policy exist: "Policies are rules governing 567 the choices in the behavior of a system" [Sloman94]. "Policy is a 568 set of rules that are used to manage and control the changing and/or 569 maintaining of the state of one or more managed objects" 570 [Strassner03]. Common to most definitions is the definition of a 571 policy as a "rule." Typically, the definition of a rule consists of 572 an event (whose occurrence triggers a rule), a set of conditions 573 (which get assessed and which must be true before any actions are 574 actually "fired"), and, finally, a set of one or more actions that 575 are carried out when the condition holds. 577 Policy-based management can be considered an imperative management 578 paradigm: Policies precisely specified what needs to be done when and 579 in which circumstance. By using policies, management can, in effect, 580 be defined as a set of simple control loops. This makes policy-based 581 management a suitable technology to implement autonomic behavior that 582 can exhibit self-* management properties, including self- 583 configuration, self-healing, self-optimization, and self-protection. 584 This is notwithstanding the fact that policy-based management may 585 make use of the concept of abstractions (such as, "Bob gets gold 586 service") that hide from the user the specifics of how that 587 abstraction is rendered in a particular deployment. 589 Policies typically involve a certain degree of abstraction in order 590 to cope with the heterogeneity of networking devices. Rather than 591 having a device-specific policy that defines events, conditions, and 592 actions in terms of device-specific commands, parameters, and data 593 models, a policy is defined at a higher level of abstraction 594 involving a canonical model of systems and devices to which the 595 policy is to be applied. A policy agent on a controller or the 596 device subsequently "renders" the policy, i.e., translates the 597 canonical model into a device-specific representation. This concept 598 allows applying the same policy across a wide range of devices 599 without needing to define multiple variants. In other words - policy 600 definition is de-coupled from policy instantiation and policy 601 enforcement. This enables operational scale and allows network 602 operators and authors of policies to think in higher terms of 603 abstraction than device specifics and be able to reuse the same, 604 high-level definition across different networking domains, WAN, DC, 605 or public cloud. 607 PBNM is typically "push-based": Policies are pushed onto devices 608 where they are rendered and enforced. The push operations are 609 conducted by a manager or controller, which is responsible for 610 deploying policies across the network and monitoring their proper 611 operation. That being said, other policy architectures are possible. 612 For example, policy-based management can also include a pull- 613 component in which the decision regarding which action to take is 614 delegated to a so-called Policy Decision Point (PDP). This PDP can 615 reside outside the managed device itself and has typically global 616 visibility and context with which to make policy decisions. Whenever 617 a network device observes an event that is associated with a policy 618 but lacks the full definition of the policy or the ability to reach a 619 conclusion regarding the expected action, it reaches out to the PDP 620 for a decision (reached, for example, by deciding on an action based 621 on various conditions). Subsequently, the device carries out the 622 decision as returned by the PDP - the device "enforces" the policy 623 and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM 624 architectures typically involve a central component from which 625 policies are deployed across the network and/or policy decisions 626 served. 628 Like Intent, policies provide a higher layer of abstraction. Policy 629 systems are also able to capture dynamic aspects of the system under 630 management through the specification of rules that allow defining 631 various triggers for specific courses of action. Unlike intent, the 632 definition of those rules (and courses of action) still needs to be 633 articulated by users. Since the intent is unknown, conflict 634 resolution within or between policies requires interactions with a 635 user or some kind of logic that resides outside of PBNM. In that 636 sense, policy constitutes a lower level of abstraction than intent, 637 and it is conceivable for Intent-Based Systems to generate policies 638 that are subsequently deployed by a PBNM system, allowing PBNM to 639 support Intent-Based Networking. 641 3.2.3. Distinguishing between Intent, Policy, and Service Models 643 What Intent, Policy, and Service Models all have in common is the 644 fact that they involve a higher-layer of abstraction of a network 645 that does not involve device-specifics, that generally transcends 646 individual devices, and that makes the network easier to manage for 647 applications and human users compared to having to manage the network 648 one device at a time. Beyond that, differences emerge. 650 Summarized differences: 652 * A service model is a data model that is used to describe instances 653 of services that are provided to customers. A service model has 654 dependencies on lower-level models (device and network models) 655 when describing how the service is mapped onto the underlying 656 network and IT infrastructure. Instantiating a service model 657 requires orchestration by a system; the logic for how to 658 orchestrate/manage/provide the service model and how to map it 659 onto underlying resources is not included as part of the model 660 itself. 662 * Policy is a set of rules, typically modeled around a variation of 663 events/conditions/actions, used to express simple control loops 664 that can be rendered by devices without requiring intervention by 665 the outside system. Policies let users define what to do under 666 what circumstances, but they do not specify the desired outcome. 668 * Intent is a high-level, declarative goal that operates at the 669 level of a network and services it provides, not individual 670 devices. It is used to define outcomes and high-level operational 671 goals, without specifying how those outcomes should be achieved or 672 how goals should specifically be satisfied, and without the need 673 to enumerate specific events, conditions, and actions. Which 674 algorithm or rules to apply can be automatically "learned/derived 675 from intent" by the IBS. In the context of autonomic networking, 676 intent is ideally rendered by the network itself; also, the 677 dissemination of intent across the network and any required 678 coordination between nodes is resolved by the network without the 679 need for external systems. 681 One analogy to capture the difference between policy and Intent-Based 682 Systems is that of Expert Systems and Learning Systems in the field 683 of Artificial Intelligence. Expert Systems operate on knowledge 684 bases with rules that are supplied by users, analogous to policy 685 systems whose policies are supplied by users. They are able to make 686 automatic inferences based on those rules but are not able to "learn" 687 new rules on their own. Learning Systems (popularized by deep 688 learning and neural networks), on the other hand, are able to learn 689 without depending on user programming or articulation of rules. 690 However, they do require a learning or training phase requiring large 691 data sets; explanations of actions that the system actually takes 692 provide a different set of challenges. Analogous to intent-based 693 systems, users focus on what they would like the learning system to 694 accomplish but not how to do it. 696 4. Principles 698 The following main operating principles allow characterizing the 699 intent-based/-driven/-defined nature of a system. 701 1. Single Source of Truth (SSoT) and Single Version/View of Truth 702 (SVoT). The SSoT is an essential component of an intent-based 703 system as it enables several important operations. The set of 704 validated intent expressions is the system's SSoT. SSoT and the 705 records of the operational states enable comparing the intended/ 706 desired state and actual/operational states of the system and 707 determining drift between them. SSoT and the drift information 708 provide the basis for corrective actions. If the IBS is equipped 709 with the means to predict states, it can further develop 710 strategies to anticipate, plan, and pro-actively act on any 711 diverging trends with the aim to minimize their impact. Beyond 712 providing a means for consistent system operation, SSoT also 713 allows for better traceability to validate if/how the initial 714 intent and associated business goals have been properly met, to 715 evaluate the impacts of changes in the intent parameters and 716 impacts and effects of the events occurring in the system. 718 Single Version (or View) of Truth derives from the SSoT and can 719 be used to perform other operations, such as querying, polling, 720 or filtering measured and correlated information in order to 721 create so-called "views." These views can serve the users of the 722 intent-based system. In order to create intents as single 723 sources of truth, the IBS must follow well-specified and well- 724 documented processes and models. In other contexts, SSoT is also 725 referred to as the invariance of the intent [Lenrow15]. 727 2. One-touch but not one-shot. In an ideal intent-based system, the 728 user expresses intent in one form or another, and then the system 729 takes over all subsequent operations (one-touch). A zero-touch 730 approach could also be imagined in the case where the intent- 731 based system has the capabilities or means to recognize 732 intentions in any form of data. However, the zero- or one-touch 733 approach should not distract from the fact that reaching the 734 state of a well-formed and valid intent expression is not a one- 735 shot process. On the contrary, the interfacing between the user 736 and the intent-based system could be designed as an interactive 737 and iterative process. Depending on the level of abstraction, 738 the intent expressions may initially contain more or less 739 implicit parts and unprecise or unknown parameters and 740 constraints. The role of the intent-based system is to parse, 741 understand, and refine the intent expression to reach a well- 742 formed and valid intent expression that can be further used by 743 the system for the fulfillment and assurance operations. An 744 intent refinement process could use a combination of iterative 745 steps involving the user to validate the proposed refined intent 746 and to ask the user for clarifications in case some parameters or 747 variables could not be deduced or learned by means of the system 748 itself. In addition, the Intent-Based System will need to 749 moderate between conflicting intent, helping users to properly 750 choose between intent alternatives that may have different 751 ramifications. 753 3. Autonomy and Supervision. A desirable goal for an intent-based 754 system is to offer a high degree of flexibility and freedom on 755 both the user side and system side, e.g., by giving the user the 756 ability to express intents using the user's own terms, by 757 supporting different forms of expression of intents and being 758 capable of refining the intent expressions to well-formed and 759 exploitable expressions. The dual principle of autonomy and 760 supervision allows operating a system that will have the 761 necessary levels of autonomy to conduct its tasks and operations 762 without requiring the intervention of the user and taking its own 763 decisions (within its areas of concern and span of control) as 764 how to perform and meet the user expectations in terms of 765 performance and quality, while at the same time providing the 766 proper level of supervision to satisfy the user requirements for 767 reporting and escalation of relevant information. 769 4. Learning. An intent-based system is a learning system. In 770 contrast to an imperative-type of system, such as Event- 771 Condition-Action policy rules, where the user defines beforehand 772 the expected behavior of the system to various events and 773 conditions, in an intent-based system, the user only declares 774 what the system is supposed to achieve and not how to achieve 775 these goals. There is thus a transfer of reasoning/rationality 776 from the human (domain knowledge) to the system. This transfer 777 of cognitive capability also implies the availability in the 778 intent-based system of capabilities or means for learning, 779 reasoning, and knowledge representation and management. The 780 learning abilities of an IBS can apply to different tasks such as 781 optimization of the intent rendering or intent refinement 782 processes. The fact that an intent-based system is a 783 continuously evolving system creates the condition for continuous 784 learning and optimization. Other cognitive capabilities such as 785 planning can also be leveraged in an intent-based system to 786 anticipate or forecast future system state and response to 787 changes in intents or network conditions and thus elaboration of 788 plans to accommodate the changes while preserving system 789 stability and efficiency in a trade-off with cost and robustness 790 of operations. 792 5. Capability exposure. Capability exposure consists in the need 793 for expressive network capabilities, requirements, and 794 constraints to be able to compose/decompose intents and map the 795 user's expectations to the system capabilities. 797 6. Abstract and outcome-driven. Users do not need to be concerned 798 with how intent is achieved and are empowered to think in terms 799 of outcomes. In addition, they can refer to concepts at a higher 800 level of abstractions, independent e.g. of vendor-specific 801 renderings. 803 The described principles are perhaps the most prominent, but they are 804 not an exhaustive list. There are additional aspects to consider, 805 such as: 807 * Intent targets are not individual devices but typically 808 aggregations (such as groups of devices adhering to a common 809 criteria, such as devices of a particular role) or abstractions 810 (such as service types, service instances, topologies). 812 * Abstraction and inherent virtualization: agnostic to 813 implementation details. 815 * Human-tailored network interaction: IBN should speak the language 816 of the user as opposed to requiring the user to speak the language 817 of the device/network. 819 * Explainability as an important IBN function, detection and IBN- 820 aided resolution of conflicting intent, reconciliation of what the 821 user wants and what the network can actually do. 823 * Inherent support, verification, and assurance of trust. 825 All of these principles and considerations have implications on the 826 design of intent-based systems and their supporting architecture. 827 Accordingly, they need to be considered when deriving functional and 828 operational requirements. 830 5. Intent-Based Networking - Functionality 832 Intent-Based Networking involves a wide variety of functions that can 833 be roughly divided into two categories: 835 * Intent Fulfillment provides functions and interfaces that allow 836 users to communicate intent to the network and that perform the 837 necessary actions to ensure that intent is achieved. This 838 includes algorithms to determine proper courses of action and 839 functions that learn to optimize outcomes over time. In addition, 840 it also includes more traditional functions such as any required 841 orchestration of coordinated configuration operations across the 842 network and rendering of higher-level abstractions into lower- 843 level parameters and control knobs. 845 * Intent Assurance provides functions and interfaces that allow 846 users to validate and monitor that the network is indeed adhering 847 to and complying with intent. This is necessary to assess the 848 effectiveness of actions taken as part of fulfillment, providing 849 important feedback that allows those functions to be trained or 850 tuned over time to optimize outcomes. In addition, Intent 851 Assurance is necessary to address "intent drift." Intent is not 852 meant to be transactional, i.e. "set and forget", but expected to 853 be remain in effect over time (unless explicitly stated 854 otherwise). Intent drift occurs when a system originally meets 855 the intent, but over time gradually allows its behavior to change 856 or be affected until it no longer does or does so in a less 857 effective manner. 859 The following sections provide a more comprehensive overview of those 860 functions. 862 5.1. Intent Fulfillment 864 Intent fulfillment is concerned with the functions that take intent 865 from its origination by a user (generally, an administrator of the 866 responsible organization) to its realization in the network. 868 5.1.1. Intent Ingestion and Interaction with Users 870 The first set of functions is concerned with "ingesting" intent, 871 i.e., obtaining intent through interactions with users. They provide 872 functions that recognize intent from interaction with the user as 873 well as functions that allow users to refine their intent and 874 articulate it in such ways so that it becomes actionable by an 875 Intent-Based System. Typically, those functions go beyond those 876 provided by a traditional API, although APIs may still be provided 877 (and needed for interactions beyond human users, i.e., with other 878 machines). Many cases would also involve a set of intuitive and 879 easy-to-navigate workflows that guide users through the intent 880 ingestion phase, making sure that all inputs that are necessary for 881 intent modeling and consecutive translation have been gathered. They 882 may support unconventional human-machine interactions, in which a 883 human will not simply give simple commands but which may involve a 884 human-machine dialog to provide clarifications, to explain 885 ramifications and trade-offs, and to facilitate refinements. 887 The goal is ultimately to make IBSs as easy and natural to use and 888 interact with as possible, in particular allowing human users to 889 interact with the IBS in ways that do not involve a steep learning 890 curve that forces the user to learn the "language" of the system. 891 Ideally, it will be the Intent-Based Systems that is increasingly be 892 able to learn how to understand the user as opposed to the other way 893 round. Of course, further research will be required to make this a 894 reality. 896 5.1.2. Intent Translation 898 A second set of functions needs to translate user intent into courses 899 of action and requests to take against the network, which will be 900 meaningful to network configuration and provisioning systems. These 901 functions lie at the core of IBS, bridging the gap between 902 interaction with users on the one hand and the traditional management 903 and operations side that will need to orchestrate provisioning and 904 configuration across the network. 906 Beyond merely breaking down a higher layer of abstraction (intent) 907 into a lower layer of abstraction (policies, device configuration), 908 Intent Translation functions can be complemented with functions and 909 algorithms that perform optimizations and that are able to learn and 910 improve over time in order to result in the best outcomes, 911 specifically in cases where multiple ways of achieving those outcomes 912 are conceivable. For example, satisfying an intent may involve 913 computation of paths and other parameters that will need to be 914 configured across the network. Heuristics and algorithms to do so 915 may evolve over time to optimize outcomes that may depend on a myriad 916 of dynamic network conditions and context. 918 5.1.3. Intent Orchestration 920 A third set of functions deals with the actual configuration and 921 provisioning steps that need to be orchestrated across the network 922 and that were determined by the previous intent translation step. 924 5.2. Intent Assurance 926 Intent assurance is concerned with the functions that are necessary 927 to ensure that the network indeed complies with the desired intent 928 once it has been fulfilled. 930 5.2.1. Monitoring 932 A first set of assurance functions monitors and observes the network 933 and its exhibited behavior. This includes all the usual assurance 934 functions such as monitoring the network for events and performance 935 outliers, performing measurements to assess service levels that are 936 being delivered, generating and collecting telemetry data. 937 Monitoring and observation are required as the basis for the next set 938 of functions that assess whether the observed behavior is in fact in 939 compliance with the behavior that is expected based on the intent. 941 5.2.2. Intent Compliance Assessment 943 At the core of Intent Assurance are functions that compare the actual 944 network behavior that is being monitored and observed with the 945 intended behavior that is expected per the intent and is held by 946 SSoT. These functions continuously assess and validate whether the 947 observation indicates compliance with intent. This includes 948 assessing the effectiveness of intent fulfillment actions, including 949 verifying that the actions had the desired effect and assessing the 950 magnitude of the effect as applicable. It can also include functions 951 that perform analysis and aggregation of raw observation data. The 952 results of the assessment can be fed back to facilitate learning 953 functions that optimize outcomes. 955 Intent compliance assessment also includes assessing whether intent 956 drift occurs over time. Intent drift can be caused by a control 957 plane or lower-level management operations that inadvertently cause 958 behavior changes which conflict with intent that was orchestrated 959 earlier. Intent-Based Systems and Networks need to be able to detect 960 when such drift occurs or is about to occur as well as assess the 961 severity of the drift. 963 5.2.3. Intent Compliance Actions 965 When intent drift occurs or network behavior is inconsistent with 966 desired intent, functions that are able to trigger corrective actions 967 are needed. This includes actions needed to resolve intent drift and 968 bring the network back into compliance. Alternatively, and where 969 necessary, reporting functions need to be triggered that alert 970 operators and provide them with the necessary information and tools 971 to react appropriately, e.g., by helping them articulate 972 modifications to the original intent to moderate between conflicting 973 concerns. 975 5.2.4. Abstraction, Aggregation, Reporting 977 The outcome of Intent Assurance needs to be reported back to the user 978 in ways that allow the user to relate the outcomes to their intent. 979 This requires a set of functions that are able to analyze, aggregate, 980 and abstract the results of the observations accordingly. In many 981 cases, lower-level concepts such as detailed performance statistics 982 and observations related to low-level settings need to be "up- 983 leveled" to concepts the user can relate to and take action on. 985 The required aggregation and analysis functionality needs to be 986 complemented with functions that report intent compliance status and 987 provide adequate summarization and visualization to human users. 989 6. Lifecycle 991 Intent is subject to a lifecycle: it comes into being, may undergo 992 changes over the course of time, and may at some point be retracted. 993 This lifecycle is closely tied to various interconnection functions 994 that are associated with the intent concept. 996 Figure 1 depicts an intent lifecycle and its main functions. The 997 functions were introduced in Section 5 and are divided into two 998 functional (horizontal) planes, reflecting the distinction between 999 fulfillment and assurance. In addition, they are divided into three 1000 (vertical) spaces. 1002 The spaces indicate the different perspectives and interactions with 1003 different roles that are involved in addressing the functions: 1005 * The User Space involves the functions that interface the network 1006 and intent-based system with the human user. It involves the 1007 functions that allow users to articulate and the intent-based 1008 system to recognize that intent. It also involves the functions 1009 that report back the status of the network relative to the intent 1010 and that allow users to assess outcomes and whether their intent 1011 has the desired effect. 1013 * The Translation, or Intent-Based System (IBS) Space involves the 1014 functions that bridge the gap between intent users and the network 1015 operations infrastructure. This includes the functions used to 1016 translate an intent into a course of action as well as the 1017 algorithms that are used to plan and optimize those courses of 1018 action also in consideration of feedback and observations from the 1019 network. It also includes the functions to analyze and aggregate 1020 observations from the network in order to validate compliance with 1021 the intent and to take corrective actions as necessary. In 1022 addition, it includes functions that abstract observations from 1023 the network in ways that relate them to the intent as communicated 1024 by users. This facilitates the reporting functions in the user 1025 space. 1027 * The Network Operations Space, finally, involves the traditional 1028 orchestration, configuration, monitoring, and measurement 1029 functions, which are used to effectuate the rendered intent and 1030 observe its effects on the network. 1032 User Space : Translation / IBS : Network Ops 1033 : Space : Space 1034 : : 1035 +----------+ : +----------+ +-----------+ : +-----------+ 1036 Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| 1037 |generate | | | | plan/ | | provision | 1038 |intent |<--- | refine | | render | : | | 1039 +----^-----+ : +----------+ +-----^-----+ : +-----------+ 1040 | : | : | 1041 .............|................................|................|..... 1042 | : +----+---+ : v 1043 | : |validate| : +----------+ 1044 | : +----^---+ <----| monitor/ | 1045 Assure +---+---+ : +---------+ +-----+---+ : | observe/ | 1046 |report | <---- |abstract |<---| analyze | <----| | 1047 +-------+ : +---------+ |aggregate| : +----------+ 1048 : +---------+ : 1050 Figure 1: Intent Lifecycle 1052 When carefully inspecting the diagram, it becomes apparent that the 1053 intent lifecycle, in fact, involves two cycles, or loops: 1055 * The "inner" intent control loop between IBS and Network Operations 1056 space is completely autonomic and does not involve any human in 1057 the loop. It represents closed-loop automation that involves 1058 automatic analysis and validation of intent based on observations 1059 from the network operations space. Those observations are fed 1060 into the function that plans the rendering of networking intent in 1061 order to make adjustments as needed in the configuration of the 1062 network. The loop addresses and counteracts any intent drift that 1063 may be occuring, using observations to assess the degree of the 1064 network's intent compliance and automatically prompting actions to 1065 address any discrepancies. Likewise, the loop allows to assess 1066 the effectiveness of any actions that are taken in order to 1067 continuously learn and improve how intent needs to be rendered in 1068 order to achieve the desired outcomes. 1070 * The "outer" intent control loop extends to the user space. It 1071 includes the user taking action and adjusting their intent based 1072 on observations and feedback from the IBS. Intent is thus 1073 subjected to a lifecycle: It comes into being, may undergo 1074 refinements, modifications, and changes of time, and may at some 1075 point in time even get retracted. 1077 7. Additional Considerations 1079 Given the popularity of the term "intent," it is tempting to broaden 1080 it use to encompass also other related concepts, resulting in 1081 "intent-washing" that paints those concepts in a new light by simply 1082 applying new intent terminology to them. A common example concerns 1083 referring to the northbound interface of SDN controllers as "intent 1084 interface". However, in some cases, this actually makes sense not 1085 just as a marketing ploy but as a way to better relate previously 1086 existing and new concepts. 1088 In that sense and regards to intent, it makes sense to distinguish 1089 various subcategories of intent as follows: 1091 * Operational Intent: defines intent related to operational goals of 1092 an operator; corresponds to the original "intent" term and the 1093 concepts defined in this document. 1095 * Rule Intent: a synonym for policy rules regarding what to do when 1096 certain events occur. 1098 * Service intent: a synonym for customer service model [RFC8309]. 1100 * Flow Intent: A synonym for a Service Level Objective for a given 1101 flow. 1103 A comprehensive set of classifications of different concepts and 1104 categories of intent will be described in a separate document. 1106 8. IANA Considerations 1108 Not applicable 1110 9. Security Considerations 1112 This document describes concepts and definitions of Intent-Based 1113 Networking. As such, the below security considerations remain high 1114 level, i.e. in the form of principles, guidelines or requirements. 1115 More detailed security considerations will be described in the 1116 documents that specify the architecture and functionality. 1118 Security in Intent-Based Networking can apply to different facets: 1120 * Securing the intent-based system itself. 1122 * Mitigating the effects of erroneous, harmful or compromised 1123 intents. 1125 * Expressing security policies or security-related parameters with 1126 intents. 1128 Securing the intent-based system aims at making the intent-based 1129 system operationally secure by implementing security mechanisms and 1130 applying security best practices. In the context of Intent-based 1131 Networking, such mechanisms and practices may consist in intent 1132 verification and validation; operations on intents by authenticated 1133 and authorized users only; protection against or detection of 1134 tampered intents. Such mechanisms may also include the introduction 1135 of multiple levels of intent. For example, intent related to 1136 securing the network should occur at a "deeper" level that overrides 1137 other levels of intent if necessary, and that is not subject to 1138 modification through regular operations but through ones that are 1139 specifically secured. Use of additional mechanisms such as 1140 explanation components that describe the security ramifications and 1141 trade-off should be considered as well. 1143 Mitigating the effects of erroneous or compromised intents aims at 1144 making the intent-based system operationally safe by providing 1145 checkpoint and safeguard mechanisms and operating principles. In the 1146 context of Intent-based Networking, such mechanisms and principles 1147 may consist in the ability to automatically detect unintended, 1148 detrimental or abnormal behavior; the ability to automatically (and 1149 gracefully) rollback or fallback to a previous "safe" state; the 1150 ability to prevent or contain error amplification (due to the 1151 combination of a higher degree of automation and the intrinsic higher 1152 degree of freedom, ambiguity, and implicitly conveyed by intents); 1153 dynamic levels of supervision and reporting to make the user aware of 1154 the right information, at the right time with the right level of 1155 context. Erroneous or harmful intents may inadvertently propagate 1156 and compromise security. In addition, compromised intents, for 1157 example, intent forged by an inside attacker, may sabotage or harm 1158 the network resources and make them vulnerable to further, larger 1159 attacks, e.g., by defeating certain security mechanisms. 1161 Expressing security policies or security-related parameters with 1162 intents consists of using the intent formalism (a high-level, 1163 declarative abstraction), or part(s) of an intent statement to define 1164 security-related aspects such as data governance, level(s) of 1165 confidentiality in data exchange, level(s) of availability of system 1166 resources, of protection in forwarding paths, of isolation in 1167 processing functions, level(s) of encryption, authorized entities for 1168 given operations, etc. 1170 The development and introduction of Intent-Based Networking in 1171 operational environments will certainly create new security concerns. 1172 Such security concerns have to be anticipated at the design and 1173 specification time. However, Intent-Based Networking may also be 1174 used as an enabler for better security. For instance, security and 1175 privacy rules could be expressed in a more human-friendly and generic 1176 way and be less technology-specific and less complex, leading to 1177 fewer low-level configuration mistakes. The detection of threats or 1178 attacks could also be made more simple and comprehensive thanks to 1179 conflict detection at higher-level or at coarser granularity 1181 More thorough security analyses should be conducted as our 1182 understanding of Intent-Based Networking technology matures. 1184 10. Acknowledgments 1186 We would like to thank the members of the IRTF Network Management 1187 Research Group (NMRG) for many valuable discussions and feedback. In 1188 particular, we would like to acknowledge the feedback and support 1189 from Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis 1190 Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, 1191 William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu 1192 Song, Peter Szilagyi, and Csaba Vulkan. Of those, we would like to 1193 thank the following persons who went one step further and also 1194 provided reviews of the document: Remi Badonnel, Walter Cerroni, 1195 Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, 1196 Peter Szilagyi, and Csaba Vulkan. 1198 11. Informative References 1200 [Boutaba07] 1201 Boutaba, R. and I. Aib, "Policy-Based Management: A 1202 Historical perspective. Journal of Network and Systems 1203 Management (JNSM), Springer, Vol. 15 (4).", December 2007. 1205 [Clemm20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network 1206 Management 2030: Operations and Control of Network 2030 1207 Services. Journal of Network and Systems Management 1208 (JNSM), Springer, Vol. 28 (4).", October 2020. 1210 [Gharbaoui21] 1211 Gharbaoui, M., Martini, B., and P. Castoldi, 1212 ""Implementation of an Intent Layer for SDN-enabled and 1213 QoS-aware Network Slicing", in IEEE 7th Int. Conference on 1214 Network Softwarization (NetSoft), pp 17-23, doi: 10.1109/ 1215 NetSoft51509.2021.9492643", June 2021. 1217 [I-D.ietf-teas-ietf-network-slice-definition] 1218 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 1219 J. Tantsura, "Definition of IETF Network Slices", Work in 1220 Progress, Internet-Draft, draft-ietf-teas-ietf-network- 1221 slice-definition-01, 22 February 2021, 1222 . 1225 [I-D.ietf-teas-te-service-mapping-yang] 1226 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 1227 and J. Tantsura, "Traffic Engineering (TE) and Service 1228 Mapping YANG Model", Work in Progress, Internet-Draft, 1229 draft-ietf-teas-te-service-mapping-yang-10, 7 March 2022, 1230 . 1233 [IEEE-TITS21] 1234 Garg, S., "Special Issue on Intent-Based Networking for 1235 5G-Envisioned Internet of Connected Vehicles, in IEEE 1236 Transactions on Intelligent Transportation Systems, vol. 1237 22, no. 8, DOI: 10.1109/TITS.2021.3101259", August 2021. 1239 [IEEEXPLORE] 1240 IEEE, "IEEE eXplore, https://ieeexplore.ieee.org/", 2021. 1242 [Lenrow15] Lenrow, D., "Intent As The Common Interface to Network 1243 Resources, Intent Based Network Summit 2015 ONF Boulder: 1244 IntentNBI", February 2015. 1246 [M3010] ITU-T, "M.3010 : Principles for a telecommunications 1247 management network.", February 2000. 1249 [MDPI22] Gharbaoui, M., "Special Issue "Intent-Based Software- 1250 Defined Networks", in Computers (MDPI) (to appear)", 2022. 1252 [Pang20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A 1253 Survey on Intent-Driven Networks", in IEEE Access Vol 8 1254 pp. 22862-22873, DOI: 10:110/ACCESS.2020.2969208", 2020. 1256 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1257 Architecture for Describing Simple Network Management 1258 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1259 DOI 10.17487/RFC3411, December 2002, 1260 . 1262 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1263 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1264 Networking: Definitions and Design Goals", RFC 7575, 1265 DOI 10.17487/RFC7575, June 2015, 1266 . 1268 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1269 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1270 . 1272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1274 May 2017, . 1276 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1277 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1278 DOI 10.17487/RFC8299, January 2018, 1279 . 1281 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1282 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1283 . 1285 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1286 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1287 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1288 2018, . 1290 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 1291 Autonomic Control Plane (ACP)", RFC 8994, 1292 DOI 10.17487/RFC8994, May 2021, 1293 . 1295 [Sloman94] Sloman, M., "Policy Driven Management for Distributed 1296 Systems. Journal of Network and Systems Management (JNSM), 1297 Springer, Vol. 2 (4).", December 1994. 1299 [Strassner03] 1300 Strassner, J., "Policy-Based Network Management. 1301 Elsevier.", 2003. 1303 [TR523] Foundation, O. N., "Intent NBI - Definition and 1304 Principles. ONF TR-523.", October 2016. 1306 [WIN21] Ciavaglia, L. and E. Renault, "1st IEEE International 1307 Workshop on Intent-Based Networking, 1308 https://netsoft2021.ieee-netsoft.org/program/workshops/ 1309 win-2021/", June 2021. 1311 Authors' Addresses 1313 Alexander Clemm 1314 Futurewei 1315 2330 Central Expressway 1316 Santa Clara,, CA 95050 1317 United States of America 1318 Email: ludwig@clemm.org 1320 Laurent Ciavaglia 1321 Rakuten Mobile 1322 Email: laurent.ciavaglia@rakuten.com 1324 Lisandro Zambenedetti Granville 1325 Federal University of Rio Grande do Sul (UFRGS) 1326 Av. Bento Gonçalves 1327 Porto Alegre- 1328 9500 1329 Brazil 1330 Email: granville@inf.ufrgs.br 1332 Jeff Tantsura 1333 Microsoft 1334 Email: jefftant.ietf@gmail.com