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