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