idnits 2.17.1 draft-clemm-nmrg-dist-intent-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1748 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-01 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: January 9, 2020 Nokia 6 L. Granville 7 Federal University of Rio Grande do Sul (UFRGS) 8 J. Tantsura 9 Apstra, Inc. 10 July 8, 2019 12 Intent-Based Networking - Concepts and Overview 13 draft-clemm-nmrg-dist-intent-02 15 Abstract 17 Intent and Intent-Based Networking are taking the industry by storm. 18 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 is intended to clarify the 21 concept of "Intent" and provide an overview of functionality that 22 associated with it. The goal is to contribute towards a common and 23 shared understanding of terms, concepts, and functionality which can 24 be used as foundation to guide further definition of associated 25 research and 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 January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 6 67 4.2.1. Service Models . . . . . . . . . . . . . . . . . . . 7 68 4.2.2. Policy and Policy-Based Management . . . . . . . . . 8 69 4.2.3. Distinguishing between Intent, Policy, and Service 70 Models . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. Intent-Based Networking - Functionality . . . . . . . . . . . 16 74 7.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 17 75 7.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 17 76 8. Research Challenges . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Intent Interfaces . . . . . . . . . . . . . . . . . . . . 17 78 8.2. Explanation Component . . . . . . . . . . . . . . . . . . 18 79 8.3. IBN Metrics to Guide Desired Outcomes . . . . . . . . . . 18 80 9. Items for Discussion . . . . . . . . . . . . . . . . . . . . 18 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 12.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 Traditionally in the IETF, interest with regard to management and 91 operations has focused on individual network and device features. 92 Standardization emphasis has generally been put on management 93 instrumentation that needed to be provided to a networking device. A 94 prime example for this is SNMP-based management and the 200+ MIBs 95 that have been defined by the IETF over the years. More recent 96 examples include YANG data model definitions for aspects such as 97 interface configuration, ACL configuration, or Syslog configuration. 99 There is a sense and reality that in modern network environments 100 managing networks by configuring myriads of "nerd knobs" on a device- 101 by-device basis is no longer sustainable. Big challenges arise with 102 keeping device configurations not only consistent across a network, 103 but consistent with the needs of services and service features they 104 are supposed to enable. Adoptability to changes at scale is a 105 fundamental property of a well designed IBN system, that requires 106 abilty to consume and process analytics that are context/intent aware 107 at near real time speeds. At the same time, operations need to be 108 streamlined and automated wherever possible to not only lower 109 operational expenses, but allow for rapid reconfiguration of networks 110 at sub-second time scales and to ensure networks are delivering their 111 functionality as expected. 113 Accordingly, IETF has begun to address end-to-end management aspects 114 that go beyond the realm of individual devices in isolation. 115 Examples include the definition of YANG models for network topology 116 [RFC8345] or the introduction of service models used by service 117 orchestration systems and controllers [RFC8309]. In addition, a lot 118 of interest has been fueled by the discussion about how to manage 119 autonomic networks as discussed in the ANIMA working group. 120 Autonomic networks are driven by the desire to lower operational 121 expenses and make management of the network as a whole exceptionally 122 easy, putting it at odds with the need to manage the network one 123 device and one feature at a time. However, while autonomic networks 124 are intended to exhibit "self-management" properties, they still 125 require input from an operator or outside system to provide 126 operational guidance and information about the goals, purposes, and 127 service instances that the network is to serve. 129 This vision has since caught on with the industry in a big way, 130 leading to a significant number solutions that offer "intent-based 131 management" that promise network providers to manage networks 132 holistically at a higher level of abstraction and as a system that 133 happens to consist of interconnected components, as opposed to a set 134 of independent devices (that happen to be interconnected). Those 135 offerings include IBN systems (offering full lifecycle of intent), 136 SDN controllers (offering a single point of control and 137 administration for a network) as well as network management and 138 Operations Support Systems (OSS). 140 However, it has been recognized for a long time that comprehensive 141 management solutions cannot operate only at the level of individual 142 devices and low-level configurations. In this sense, the vision of 143 "intent" is not entirely new. In the past, ITU-T's model of a 144 Telecommunications Management Network, TMN, introduced a set of 145 management layers that defined a management hierarchy, consisting of 146 network element, network, service, and business management. High- 147 level operational objectives would propagate in top-down fashion from 148 upper to lower layers. The associated abstraction hierarchy was key 149 to decompose management complexity into separate areas of concerns. 150 This abstraction hierarchy was accompanied by an information 151 hierarchy that concerned itself at the lowest level with device- 152 specific information, but that would, at higher layers, include, for 153 example, end-to-end service instances. Similarly, the concept of 154 "policy-based management" has for a long time touted the ability to 155 allow users to manage networks by specifying high-level management 156 policies, with policy systems automatically "rendering" those 157 policies, i.e. breaking them down into low-level configurations and 158 control logic. 160 What has been missing, however, is putting these concepts into a more 161 current context and updating it to account for current technology 162 trends. This document attempts to clarify the concepts behind 163 intent. It differentiates it from related concepts. It also 164 provides an overview of first-order principles of Intent-Based 165 Networking as well as associated functionality. In addition, a 166 number of research challenges are highlighted. The goal is to 167 contribute to a common and shared understanding that can be used as a 168 foundation to articulate research and engineering problems in the 169 area of Intent-Based Networking. 171 2. Key Words 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. Definitions and Acronyms 181 ACL: Access Control List 183 Intent: An abstracted, declarative and vendor agnostic set of 184 rules used to provide full lifecycle (Design/Build/Deploy/ 185 Validate) to a network and services it provides. 187 Policy: A rule, or set of rules, that governs the choices in 188 behavior of a system. 190 SSoT: Single Source of Truth - A functional block in an IBN system 191 that normalizes user' intent and serves as the single source of 192 data for the lower layers. 194 IBA: Intent Based Analytics - Analytics that are defined and 195 derived from user' intent and used to validate the intended state. 197 PDP: Policy Decision Point 199 PEP: Policy Enforcement Point 201 Service Model: A model that represents a service that is provided 202 by a network to a user. 204 4. Introduction of Concepts 206 The following section provides an overview of the concept of intent 207 respectively intent-based management. It also provides an overview 208 of the related concepts of service models, and of policies 209 respectively policy-based management, and explains how they relate to 210 intent and intent-based management. 212 4.1. Intent and Intent-Based Management 214 In the context of Autonomic Networks, Intent is defined as "an 215 abstract, high-level policy used to operate a network" [RFC7575]. 216 According to this definition, an intent is a specific type of policy. 217 However, to avoid using "intent" simply as a synonym for "policy, a 218 clearer distinction needs to be introduced that distinguishes intent 219 clearly from other types of policies. 221 For one, while Intent-Based Management clearly aims to lead towards 222 networks that are dramatically simpler to manage and operate 223 requiring only minimal outside intervention, the concept of "intent" 224 is not limited to autonomic networks, but applies to any network. 225 Networks, even when considered "autonomic", are not clairvoyant and 226 have no way of automatically knowing particular operational goals nor 227 what instances of networking services to support. In other words, 228 they do not know what the "intent" of the network provider is that 229 gives the network the purpose of its being. This still needs to be 230 communicated by what informally constitutes "intent". 232 More specifically, intent is a declaration of operational goals that 233 a network should meet and outcomes that the network is supposed to 234 deliver, without specifying how to achieve them. Those goals and 235 outcomes are defined in a manner that is purely declarative - they 236 specify what to accomplish, not how to achieve it. "Intent" thus 237 applies several important concepts simultaneously: 239 o It provides data abstraction: Users and operators do not need to 240 be concerned with low-level device configuration and nerd knobs. 242 o It provides functional abstraction from particular management and 243 control logic: Users and operators do not need to be concerned 244 even with how to achieve a given intent. What is specified is a 245 desired outcome, with the intent-based system automatically 246 figuring out a course of action (e.g. a set of rules, an 247 algorithm) for how to achieve the outcome. 249 In an autonomic network, intent should be rendered by the network 250 itself, i.e. translated into device-specific rules and courses of 251 action. Ideally, it should not even be orchestrated or broken down 252 by a higher-level, centralized system, but by the network devices 253 themselves using a combination of distributed algorithms and local 254 device abstraction. Because intent holds for the network as a whole, 255 not individual devices, it needs to be automatically disseminated 256 across all devices in the network, which can themselves decide 257 whether they need to act on it. This facilitates management even 258 further, since it obviates the need for a higher-layer system to 259 break down and decompose higher-level intent, and because there is no 260 need to even discover and maintain an inventory of the network to be 261 able to manage it. 263 Tentative definition for intent-based networks Networks configuring 264 and adapting autonomously to the user or operator intentions (i.e., a 265 desired state or behavior) without the need to specify every 266 technical detail of the process and operations to achieve it (i.e., 267 the "machines" will figure out on their own how to realize the user 268 goal). 270 Other definitions of intent exist such as [TR523] and will be 271 investigated in future revisions of this document. Likewise, some 272 definitions of intent allow for the presence of a centralized 273 function that renders the intent into lower-level policies or 274 instructions and orchestrates them across the network. While to the 275 end user the concept of "intent" appears the same regardless of its 276 method of rendering, this interpretation opens a slippery slope of 277 how to clearly distinguish "intent" from other higher-layer 278 abstractions. Again, these notions will be further investigated in 279 future revisions of this document and in collaboration with NMRG. 281 4.2. Related Concepts 282 4.2.1. Service Models 284 A service model is a model that represents a service that is provided 285 by a network to a user. Per [RFC8309], a service model describes a 286 service and its parameters in a portable/vendor agnostic way that can 287 be used independent of the equipment and operating environment on 288 which the service is realized. Two subcategories are distinguished: 289 a "Customer Service Model" describes an instance of a service as 290 provided to a customer, possibly associated with a service order. A 291 "Service Delivery Model" describes how a service is instantiated over 292 existing networking infrastructure. 294 An example of a service could be a Layer 3 VPN service [RFC8299], a 295 Network Slice, or residential Internet access. Service models 296 represent service instances as entities in their own right. Services 297 have their own parameters, actions, and lifecycles. Typically, 298 service instances can be bound to end users, who might be billed for 299 the service. 301 Instantiating a service typically involves multiple aspects: 303 o A user (or northbound system) needs to define and/or request a 304 service to be instantiated. 306 o Resources need to be allocated, such as IP addresses, AS numbers, 307 VLAN or VxLAN pools, interfaces, bandwidth, or memory. 309 o How to map services to the resources needs to be defined. 310 Multiple mappings are often possible, which to select may depend 311 on context (such as which type of access is available to connect 312 the end user with the service). 314 o [I-D.ietf-teas-te-service-mapping-yang] is an example of such 315 mapping - a data model to map customer service models (e.g., the 316 L3VPM Service Model) to Traffic Engineering (TE) models (e.g., the 317 TE Tunnel or the Abstraction and Control of Traffic Engineered 318 Networks Virtual Network model) 320 o Bindings need to be maintained between upper and lower-level 321 objects. 323 o Once instantiated, the service needs to be validated and assured 324 to ensure that the network indeed delivers the service as 325 requested. 327 They involve a system, such as a controller, that provides 328 provisioning logic. Orchestration itself is generally conducted 329 using a "push" model, in which the controller/manager initiates the 330 operations as required, pushing down the specific configurations to 331 the device. (In addition to instantiating and creating new instances 332 of a service, updating, modifying, and decommissioning services need 333 to be also supported.) The device itself typically remains agnostic 334 to the service or the fact that its resources or configurations are 335 part of a service/concept at a higher layer. 337 Instantiated service models map to instantiated lower-layer network 338 and device models. Examples include instances of paths, or instances 339 of specific port configurations. The service model typically also 340 models dependencies and layering of services over lower-layer 341 networking resources that are used to provide services. This 342 facilitates management by allowing to follow dependencies for 343 troubleshooting activities, to perform impact analysis in which 344 events in the network are assessed regarding their impact on services 345 and customers. Services are typically orchestrated and provisioned 346 top-to-bottom, which also facilitates keeping track of the assignment 347 of network resources. Service models might also be associated with 348 other data that does not concern the network but provides business 349 context. This includes things such as customer data (such as billing 350 information), service orders and service catalogues, tariffs, service 351 contracts, and Service Level Agreements (SLAs) including contractual 352 agreements regarding remediation actions. 354 Like intent, service models provide higher layers of abstraction. 355 Service models are often also complemented with mappings that capture 356 dependencies between service and device or network configurations. 357 Unlike intent, service models do not allow to define a desired 358 "outcome" that would be automatically maintained by the intent 359 system. Instead, management of service models requires development 360 of sophisticated algorithms and control logic by network providers or 361 system integrators. 363 4.2.2. Policy and Policy-Based Management 365 Policy-based management (PBM) is a management paradigm that separates 366 the rules that govern the behavior of a system from the functionality 367 of the system. It promises to reduce maintenance costs of 368 information and communication systems while improving flexibility and 369 runtime adaptability. It is present today at the heart of a 370 multitude of management architectures and paradigms including SLA- 371 driven, Business-driven, autonomous, adaptive, and self-* management 372 [Boutaba07]. The interested reader is asked to refer to the rich set 373 of existing literature which includes this and many other references. 374 In the following, we will only provide a much-abridged and distilled 375 overview. 377 At the heart of policy-based management is the concept of a policy. 378 Multiple definitions of policy exist: "Policies are rules governing 379 the choices in behavior of a system" [Sloman94]. "Policy is a set of 380 rules that are used to manage and control the changing and/or 381 maintaining of the state of one or more managed objects" 382 [Strassner03]. Common to most definitions is the definition of a 383 policy as a "rule". Typically, the definition of a rule consists of 384 an event (whose occurrence triggers a rule), a set of conditions 385 (that get assessed and that must be true before any actions are 386 actually "fired"), and finally a set of one or more actions that are 387 carried out when the condition holds. 389 Policy-based management can be considered an imperative management 390 paradigm: Policies specify precisely what needs to be done when and 391 in which circumstance. Using policies, management can in effect be 392 defined as a set of simple control loops. This makes policy-based 393 management a suitable technology to implement autonomic behavior that 394 can exhibit self-* management properties including self- 395 configuration, self-healing, self-optimization, and self-protection. 396 In effect, policies define management as a set of simple control 397 loops. 399 Policies typically involve a certain degree of abstraction in order 400 to cope with heterogeneity of networking devices. Rather than having 401 a device-specific policy that defines events, conditions, and actions 402 in terms of device-specific commands, parameters, and data models, 403 policy is defined at a higher-level of abstraction involving a 404 canonical model of systems and devices to which the policy is to be 405 applied. A policy agent on a controller or the device subsequently 406 "renders" the policy, i.e., translates the canonical model into a 407 device-specific representation. This concept allows to apply the 408 same policy across a wide range of devices without needing to define 409 multiple variants. In other words - policy definition is de-coupled 410 from policy instantiation and policy enforcement. This enables 411 operational scale and allows network operators and authors of 412 policies to think in higher terms of abstraction than device 413 specifics and be able to reuse the same, high level definition 414 defintion across different networking domains, WAN, DC or public 415 cloud. 417 Policy-based management is typically "push-based": Policies are 418 pushed onto devices where they are rendered and enforced. The push 419 operations are conducted by a manager or controller, which is 420 responsible for deploying policies across the network and monitor 421 their proper operation. That said, other policy architectures are 422 possible. For example, policy-based management can also include a 423 pull-component in which the decision regarding which action to take 424 is delegated to a so-called Policy Decision Point (PDP). This PDP 425 can reside outside the managed device itself and has typically global 426 visibility and context with which to make policy decisions. Whenever 427 a network device observes an event that is associated with a policy, 428 but lacks the full definition of the policy or the ability to reach a 429 conclusion regarding the expected action, it reaches out to the PDP 430 for a decision (reached, for example, by deciding on an action based 431 on various conditions). Subsequently, the device carries out the 432 decision as returned by the PDP - the device "enforces" the policy 433 and hence acts as a PEP (Policy Enforcement Point). Either way, PBM 434 architectures typically involve a central component from which 435 policies are deployed across the network, and/or policy decisions 436 served. 438 Like Intent, policies provide a higher layer of abstraction. Policy 439 systems are also able to capture dynamic aspects of the system under 440 management through specification of rules that allow to define 441 various triggers for certain courses of actions. Unlike intent, the 442 definition of those rules (and courses of actions) still needs to be 443 articulated by users. Since the intent is unknown, conflict 444 resolution within or between policies requires interactions with a 445 user or some kind of logic that resides outside of PBM. 447 4.2.3. Distinguishing between Intent, Policy, and Service Models 449 What Intent, Policy, and Service Models all have in common is the 450 fact that they involve a higher-layer of abstraction of a network 451 that does not involve device-specifics, that generally transcends 452 individual devices, and that makes the network easier to manage for 453 applications and human users compared to having to manage the network 454 one device at a time. Beyond that, differences emerge. Service 455 models have less in common with policy and intent than policy and 456 intent do with each other. 458 Summarized differences: 460 o A service model is a data model that is used to describe instances 461 of services that are provided to customers. A service model has 462 dependencies on lower level models (device and network models) 463 when describing how the service is mapped onto underlying network 464 and IT infrastructure. Instantiating a service model requires 465 orchestration by a system; the logic for how to 466 orchestrate/manage/provide the service model, and how to map it 467 onto underlying resources, is not included as part of the model 468 itself. 470 o Policy is a set of rules, typically modeled around a variation of 471 events/conditions/actions, used to express simple control loops 472 that can be rendered by devices themselves, without requiring 473 intervention by outside system. Policy lets users define what to 474 do under what circumstances, but it does not specify a desired 475 outcome. 477 o Intent is a higher-level declarative policy that operates at the 478 level of a network and services it provides, not individual 479 devices. It is used to define outcomes and high-level operational 480 goals, without the need to enumerate specific events, conditions, 481 and actions. Which algorithm or rules to apply can be 482 automatically "learned/derived from intent" by the intent system. 483 In the context of autonomic networking, ideally, intent is 484 rendered by the network itself; also the dissemination of intent 485 across the network and any required coordination between nodes is 486 resolved by the network itself without the need for outside 487 systems. 489 One analogy to capture the difference between policy and intent 490 systems is that of Expert Systems and Learning Systems in the field 491 of Artificial Intelligence. Expert Systems operate on knowledge 492 bases with rules that are supplied by users. They are able to make 493 automatic inferences based on those rules, but are not able to 494 "learn" on their own. Learning Systems (popularized by deep learning 495 and neural networks), on the other hand, are able to learn without 496 depending on user programming. However, they do require a learning 497 or training phase and explanations of actions that the system 498 actually takes provide a different set of challenges. 500 5. Principles 502 The following operating principles allow characterizing the intent- 503 based/-driven/-defined nature of a system. 505 1. Single Source of Truth (SSoT) and Single Version/View of Truth 506 (SVoT). The SSoT is an essential component of an intent-based 507 system as it enables several important operations. The set of 508 validated intent expressions is the system's SSoT. SSoT and the 509 records of the operational states enable comparing the intented 510 state and actual state of the system and determining drift 511 between them. SsoT and the drift information provide the basis 512 for corrective actions. If the intent-based is equipped with 513 prediction capabilities or means, it can further develop 514 strategies to anticipate, plan and pro-actively act on the 515 diverging trends with the aim to minimize their impact. Beyond 516 providing a means for consistent system operation, SSoT also 517 allows for better traceability to validate if/how the initial 518 intent and associated business goals have been properly met, to 519 evaluate the impacts of changes in the intent parameters and 520 impacts and effects of the events occurring in the system. 522 Single Version (or View) of Truth derives from the SSoT and can 523 be used to perform other operations such as query, poll or filter 524 the measured and correlated information to create so-called 525 "views". These views can serve the operators and/or the users of 526 the intent-based system. To create intents as single sources of 527 truth, the intent-based system must follow well-specified and 528 well-documented processes and models. In other contexts 529 [Lenrow15], SSoT is also referred to as the invariance of the 530 intent. 532 2. One touch but not one shot. In an ideal intent-based system, the 533 user expresses its intents in one form or another and then the 534 system takes over all subsequent operations (one touch). A zero- 535 touch approach could also be imagined in case where the intent- 536 based system has the capabilities or means to recognize 537 intentions in any form of data. However, the zero- or one-touch 538 approach should not be mistaken the fact that reaching the state 539 of a well-formed and valid intent expression is not a one-shot 540 process. On the contrary, the interfacing between the user and 541 the intent-based system could be designed as an interactive and 542 interactive process. Depending on the level of abstraction, the 543 intent expressions will initially contain more or less implicit 544 parts, and unprecise or unknown parameters and constraints. The 545 role of the intent-based system is to parse, understand and 546 refine the intent expression to reach a well-formed and valid 547 intent expression that can be further used by the system for the 548 fulfillment and assurance operations. An intent refinement 549 process could use a combination of iterative steps involving the 550 user to validate the proposed refined intent and to ask the user 551 for clarifications in case some parameters or variables could not 552 be deduced or learned by the means of the system itself. In 553 addition, the Intent-Based System will need to moderate between 554 conflicting intent, helping users to properly choose between 555 intent alternatives that may have different ramifications. 557 3. Autonomy and Oversight. A desirable goal for an intent-based 558 system is to offer a high degree of flexibility and freedom on 559 both the user side and system side, e.g. by giving the user the 560 ability to express intents using its own terms, by supporting 561 different forms of expression of intents and being capable of 562 refining the intent expressions to well-formed and exploitable 563 expressions. The dual principle of autonomy and oversight allows 564 to operate a system that will have the necessary levels of 565 autonomy to conduct its tasks and operations without requiring 566 intervention of the user and taking its own decisions (within its 567 areas of concern and span of control) as how to perform and meet 568 the user expiations in terms of performance and quality, while at 569 the same time providing the proper level of oversight to satisfy 570 the user requirements for reporting and escalation of relevant 571 information. to be added: description for feedback, reporting, 572 guarantee scope (check points, guard rails, dynamically 573 provisioned, context rich, regular operation vs. exception/ 574 abnormal, information zoom in-out, and link to SVoT. Accountable 575 for decisions and efficiency, late binding (leave it to the 576 system where to place functionality, how to accomplish certain 577 goals). 579 4. Learning. An intent-based system is a learning system. By 580 contrast to imperative type of system, such as Event-Condition- 581 Action policy rules, where the user define beforehand the 582 expected behavior of the system to various event and conditions, 583 in an intent-based system, the user only declare what the system 584 should achieve and not how to achieve these goals. There is thus 585 a transfer of reasoning/rationality from the human (domain 586 knowledge) to the system. This transfer of cognitive capability 587 implies also the availability in the intent-based system of 588 capabilities or means for learning, reasoning and knowledge 589 representation and management. The learning abilities of an 590 intent-based systems can apply to different tasks such as 591 optimization of the intent rendering or intent refinement 592 processes. The fact that an intent-based system is a 593 continuously evolving system creates the condition for continuous 594 learning and optimization. Other cognitive capabilities such as 595 planning can also be leveraged in an intent-based system to 596 anticipate or forecast future system state and response to 597 changes in intents or network conditions and thus elaboration of 598 plans to accommodate the changes while preserving system 599 stability and efficiency in a trade-off with cost and robustness 600 of operations. Cope with unawareness of users (smart 601 recommendations). 603 5. Explainability. Need expressive network capabilities, 604 requirements and constraints to be able to compose/decompose 605 intents, map user's expectation to system capabilities. 606 capability exposure. not just automation of steps that need to 607 be taken, but of bridging the semantic gap between "intent" and 608 actionable levels of instructions Context: multi providers, need 609 discovery and semantic descriptions Explainability: why is a 610 network doing what it is doing 612 6. Abstraction - users do not need to be concerned with how intent 613 is achieved 615 Additional principles will be described in future revision of this 616 document addressing aspects such as: Target groups not individual 617 devices, agnostic to implementation details, user-friendly, user 618 vocabulary vs. language of the device/network, explainability, 619 validation and troubleshooting, how to resolve and point out 620 conflicts (between intents), reconcile the reality of what is 621 possible with the fiction of what the user would want, "moderate", 622 awareness of operating within system boundaries, outcome-driven 623 ((what not how, for the user);(what and how/where, for the 624 operator).not imperative/instruction based.). 626 The above principles will be further used to understand implications 627 on the design of intent-based systems and their supporting 628 architecture, and derive functional and operational requirements. 630 6. Lifecycle 631 user related user data <-----<-+--------+ 632 data + + | | 633 | | | | 634 +----v------+ +-----v-----+ | | 635 | recognize +---+ +-----+ generate | | | 636 user +-----------+ | | +-----------+ | | 637 space | | | | 638 +--------------------------------------------------------------------+ 639 system | | | | 640 space +---v---v---+ +----------+ +-----+-----+ | 641 | translate <-->+ validate <---> recommend | | 642 +-----+-----+ +----------+ +-----------+ | 643 | | 644 +-----v-----+ | 645 | normalize | | 646 +-----+-----+ | 647 | | 648 +-----v-----+ | 649 | decompose | | 650 +-----+-----+ | 651 | | 652 +------v------+ | 653 | communicate | | 654 +------+------+ | 655 preparation | | 656 phase | | 657 +-------------------------------------------------------------------+ 658 operation | | 659 phase +-----v----+ | 660 | fullfill | | 661 +-----+----+ | 662 | | 663 +----v----+ +--------+ | 664 | observe +-----> report +-------------------+ 665 +----+----+ +--------+ 666 | 667 +----v---+ 668 | assure | 669 +--------+ 671 Figure 1: Intent Lifecycle 673 The intent lifecycle is work in progress. Todo: Intent attributes, 674 intent states. Distinguish flow from users to network, and from 675 network to user. 677 Another version is depicted below. Some of the aspects worth 678 highlighting: 680 o There is a distinction between the traditional network operations 681 realm on one hand (providing fulfillment and assurance functions), 682 and the user realm on the other hand (who needs to give direction 683 to the network and be given information and reports regarding how 684 the network is doing. Intent-Based Systems provide the link 685 between those two realms. 687 o There is a genuine distinction between fulfillment operations, 688 used to drive intent into the network, orchestrate configuration 689 operations etc, aand assurance operations intended to gain a sense 690 of whether the network is performing as intended. 692 User Space : Translation / IBS : Network Ops 693 : Space : Space 694 : : 695 +---------+ : +----------+ +-----------+ : +---------+ 696 Fulfill |recognize| ---> |translate/|-->|learn/plan/| ---> | config/ | 697 |intent | <--- | refine | | render | : |provision| 698 +---------+ : +----------+ +-----^-----+ : +---------+ 699 : | : | 700 ..............................................|..................|..... 701 : +----+---+ : v 702 : |validate| : +----------+ 703 : +----^---+ <------| monitor/ | 704 Assure +-------+ : +---------+ +-----+---+ : | observe/ | 705 |report | <---- |abstract |<---| analyze | <------| assure | 706 +-------+ : +---------+ |aggregate| : +----------+ 707 : +---------+ : 709 Figure 2: Intent Lifecycle 2 711 7. Intent-Based Networking - Functionality 713 Intent-Based Networking involves a wide variety of functions which 714 can be roughly divided into two categories: 716 o Intent Fulfillment provides functions and interfaces that allow 717 users to communicate intent to the network, and that orchestrates 718 the intent, i.e. that breaks down intent abstractions into lower- 719 level network and device abstractions and performs or coordinates 720 the configuration operations across the network. 722 o Intent Assurance provides functions and interfaces that allow 723 users to validate and monitor that the network is indeed adhering 724 to and complying with intent. Control plane or lower-level 725 management operations can cause behavior that inadvertently 726 conflicts with intent which was orchestrated earlier. 727 Accordingly, "intent drift" may occur. Network operators need to 728 be able to detect when such drift occurs, or is about to occur, 729 and be provided with the necessary functions to resolve such 730 conflicts. This can occur by either bringing the network back 731 into compliance, or by articulating modifications to the original 732 intent to moderate between conflicting interests. 734 The following sections provide a more comprehensive overview of those 735 functions. 737 7.1. Intent Fulfillment 739 RBD 741 7.2. Intent Assurance 743 Ability to reason about system' state by employing closed-loop 744 validation in the presence of an inevitable change is a fundamental 745 property of an Intent Assurance part of an IBN system. Since service 746 expectations are created during intent consumption and modeling 747 phase, closed-loop intent vaidation should start immidiatelly, with 748 the service instantiation. Telemetry consumed could then be enriched 749 with an additional context and must always be processed in context of 750 the Intent it has been instantiated. Direct relationship between the 751 Intent and telemetry gathered enables correlation between changes in 752 states and the Intent and provides contextual base for reasoning 753 about the changes. 755 8. Research Challenges 757 8.1. Intent Interfaces 759 One goal for intent-based systems is to have the system "infer" the 760 intent of the user, rather than requiring the users to provide a 761 precise and complete set of instructions. Instead of forcing users 762 to speak the language of the system, the system should be able to 763 adapt to the needs of the user. 765 This requires new ways of interacting with users. An intent 766 interface may no longer necessarily involve an interface or API with 767 a clearly defined syntax and set of parameters. Instead, it may 768 apply alternative styles, for example of iterative interrogation- or 769 interview-style interfaces in which the system requests additional 770 information from the user as needed to provide clarification, to 771 select between alternatives, to refine intent. 773 8.2. Explanation Component 775 In an Intent-Based System, some of the actions taken by the network 776 or behavior observed may be difficult to understand, analogous to 777 deep learning systems which may have difficulty explaining their 778 actions. In a networking environment, this can create some problems 779 of its own, such as ensuring that the system is indeed functioning 780 correctly and not compromised, necessary to give network providers 781 the confidence that the Intent-Based Systems can indeed be relied on 782 in business-critical applications. 784 8.3. IBN Metrics to Guide Desired Outcomes 786 As Intent-Based Networks are driven by desired outcomes, how to 787 assess the quality of expected outcomes becomes critical. 788 Corresponding metrics and evaluation functions become the basis by 789 which IBNs can choose between different alternatives, and assess 790 their ability to "learn" and make progress. 792 9. Items for Discussion 794 Arguably, given the popularity of the term intent, its use could be 795 broadened to encompass also known concepts ("intent-washing"). For 796 example, it is conceivable to introduce intent-based terms for 797 various concepts that, although already known, are related to the 798 context of intent. Each of those terms could then designate an 799 intent subcategory, for example: 801 o Operational Intent: defines intent related to operational goals of 802 an operator; corresponds to the original "intent" term. 804 o Rule Intent: a synonym for policy rules regarding what to do when 805 certain events occur. 807 o Service intent: a synonym for customer service model [RFC8309]. 809 o Flow Intent: A synonym for a Service Level Objective for a given 810 flow. 812 Whether to do so is an item for discussion by the Research Group. 814 10. IANA Considerations 816 Not applicable 818 11. Security Considerations 820 Not applicable 822 12. References 824 12.1. Normative References 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 832 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 833 May 2017, . 835 12.2. Informative References 837 [Boutaba07] 838 Boutaba, R. and I. Aib, "Policy-Based Management: A 839 Historical perspective. Journal of Network and Systems 840 Management (JNSM), Springer, Vol. 15 (4).", December 2007. 842 [eTOM] TMForum, "GB 921 Business Process Framework, Release 843 17.0.1.", February 2018. 845 [I-D.ietf-teas-te-service-mapping-yang] 846 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 847 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 848 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 849 yang-01 (work in progress), March 2019. 851 [Lenrow15] 852 Lenrow, D., "Intent As The Common Interface to Network 853 Resources, Intent Based Network Summit 2015 ONF Boulder: 854 IntentNBI", February 2015. 856 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 857 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 858 Networking: Definitions and Design Goals", RFC 7575, 859 DOI 10.17487/RFC7575, June 2015, 860 . 862 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 863 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 864 DOI 10.17487/RFC8299, January 2018, 865 . 867 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 868 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 869 . 871 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 872 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 873 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 874 2018, . 876 [Sloman94] 877 Sloman, M., "Policy Driven Management for Distributed 878 Systems. Journal of Network and Systems Management (JNSM), 879 Springer, Vol. 2 (4).", December 1994. 881 [Strassner03] 882 Strassner, J., "Policy-Based Network Management. 883 Elsevier.", 2003. 885 [TR523] Foundation, O. N., "Intent NBI - Definition and 886 Principles. ONF TR-523.", October 2016. 888 Authors' Addresses 890 Alexander Clemm 891 Futurewei 892 2330 Central Expressway 893 Santa Clara, CA 95050 894 USA 896 Email: ludwig@clemm.org 898 Laurent Ciavaglia 899 Nokia 900 Route de Villejust 901 Nozay 91460 902 FR 904 Email: laurent.ciavaglia@nokia.com 905 Lisandro Zambenedetti Granville 906 Federal University of Rio Grande do Sul (UFRGS) 907 Av. Bento Goncalves 908 Porto Alegre 9500 909 BR 911 Email: granville@inf.ufrgs.br 913 Jeff Tantsura 914 Apstra, Inc. 916 Email: jefftant.ietf@gmail.com