idnits 2.17.1 draft-clemm-nmrg-dist-intent-01.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 18, 2018) is 2109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 Huawei 4 Intended status: Informational L. Ciavaglia 5 Expires: January 19, 2019 Nokia 6 L. Granville 7 Federal University of Rio Grande do Sul (UFRGS) 8 July 18, 2018 10 Clarifying the Concepts of Intent and Policy 11 draft-clemm-nmrg-dist-intent-01 13 Abstract 15 Intent and Intent-Based Networking are taking the industry by storm. 16 At the same time, those terms are used loosely and often 17 inconsistently, in many cases overlapping with other concepts such as 18 "policy". This document is therefore intended to clarify the concept 19 of "Intent" and how it relates to other concepts. The goal is to 20 contribute towards a common and shared understanding of terms and 21 concepts which can then be used as foundation to guide further 22 definition of valid research and engineering problems and their 23 solutions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 19, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 62 4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 4 63 4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Policy and Policy-Based Management . . . . . . . . . . . 6 65 4.3. Intent and Intent-Based Management . . . . . . . . . . . 7 66 5. Distinguishing between Intent, Policy, and Service Models . . 8 67 6. Items for Discussion . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Traditionally in the IETF, interest with regard to management and 78 operations has focused on individual network and device features. 79 Standardization emphasis has generally been put on management 80 instrumentation that needed to be provided by a networking device. A 81 prime example for this is SNMP-based management and the 200+ MIBs 82 that have been defined by the IETF over the years. More recent 83 examples include YANG data model definitions for aspects such as 84 interface configuration, ACL configuration, or Syslog configuration. 86 There is a sense that managing networks by configuring myriads of 87 "nerd knobs" on a device-by-device basis is no longer sustainable in 88 modern network environments. Big challenges arise with keeping 89 device configurations not only consistent across a network, but 90 consistent with the needs of services they are supposed to enable. 91 At the same time, operations need to be streamlined and automated 92 wherever possible to not only lower operational expenses, but allow 93 for rapid reconfiguration of networks at sub-second time scales. 95 Accordingly, IETF has begun to address end-to-end management aspects 96 that go beyond the realm of individual devices in isolation. 98 Examples include the definition of YANG models for network topology 99 [RFC8345] or the introduction of service models used by service 100 orchestration systems and controllers [RFC8309]. In addition, a lot 101 of interest has been fueled by the discussion about how to manage 102 autonomic networks as discussed in the ANIMA working group. 103 Autonomic networks are driven by the desire to lower operational 104 expenses and make management of the network as a whole exceptionally 105 easy, putting it at odds with the need to manage the network one 106 device and one feature at a time. However, while autonomic networks 107 are intended to exhibit "self-management" properties, they still 108 require input from an operator or outside system to provide 109 operational guidance and information about the goals, purposes, and 110 service instances that the network is to serve. It is in this 111 context that the term "intent" was coined for the first time. 113 This vision has since caught on with the industry in a big way, 114 leading to countless offerings that tout "intent-based management" 115 that promise network providers to manage networks holistically at a 116 higher level of abstraction and as a system that happens to consist 117 of interconnected components, as opposed to a set of independent 118 devices (that happen to be interconnected). Those offerings include 119 SDN controllers (offering a single point of control and 120 administration for a network) as well as network management and 121 Operations Support Systems (OSS). 123 However, it has been recognized for a long time that comprehensive 124 management solutions cannot operate only at the level of individual 125 devices and low-level configurations. In this sense, the vision of 126 "intent" is not entirely new. In the past, ITU-T's model of a 127 Telecommunications Management Network, TMN, introduced a set of 128 management layers that defined a management hierarchy, consisting of 129 network element, network, service, and business management. High- 130 level operational objectives would propagate in top-down fashion from 131 upper to lower layers. The associated abstraction hierarchy was key 132 to decompose management complexity into separate areas of concerns. 133 This abstraction hierarchy was accompanied by an information 134 hierarchy that concerned itself at the lowest level with device- 135 specific information, but that would, at higher layers, include, for 136 example, end-to-end service instances. Similarly, the concept of 137 "policy-based management" has for a long time touted the ability to 138 allow users to manage networks by specifying high-level management 139 policies, with policy systems automatically "rendering" those 140 policies, i.e. breaking them down into low-level configurations and 141 control logic. 143 What is missing, however, is putting these concepts into a more 144 current context and defining a reference model that goes beyond a 145 TMN. This document attempts to clarify terminology and explain how 146 intent relates to other, similar concepts, in hope that a common and 147 shared understanding of terms and concepts can be used as a 148 foundation to articulate research and engineering problems and their 149 solutions. 151 2. Key Words 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Definitions and Acronyms 161 ACL: Access Control List 163 Intent: An abstract, high-level policy used to operate a network 164 [RFC7575]. 166 Policy: A rule, or set of rules, that governs the choices in 167 behavior of a system. 169 PDP: Policy Decision Point 171 PEP: Policy Enforcement Point 173 Service Model: A model that represents a service that is provided 174 by a network to a user. 176 4. Introduction of Concepts 178 The following subsections provide an overview of the concepts of 179 service models, of policies respectively policy-based management, and 180 of intent respectively intent-based management. While the 181 descriptions are intentionally kept brief and do not provide detailed 182 tutorials, they should convey the bigger picture of the purpose of 183 each concept and provide a sense where those concepts are similar and 184 where they differ. With this background, the differences between 185 them are subsequently summarized in in another section. 187 4.1. Service Models 189 A service model is a model that represents a service that is provided 190 by a network to a user. Per [RFC8309], a service model describes a 191 service and its parameters in a portable way that can be used 192 independent of the equipment and operating environment on which the 193 service is realized. Two subcategories are distinguished: a 194 "Customer Service Model" describes an instance of a service as 195 provided to a customer, possibly associated with a service order. A 196 "Service Delivery Model" describes how a service is instantiated over 197 existing networking infrastructure. 199 An example of a service could be a Layer 3 VPN service [RFC8299], a 200 Network Slice, or residential Internet access. Service models 201 represent service instances as entities in their own right. Services 202 have their own parameters, actions, and lifecycles. Typically, 203 service instances can be bound to end users, who might be billed for 204 the service. 206 Instantiating a service typically involves multiple aspects: 208 o Resources need to be allocated, such as IP addresses, interfaces, 209 bandwidth, or memory. 211 o How to map services to the resources needs to be defined. 212 Multiple mappings are often possible, which to select may depend 213 on context (such as which type of access is available to connect 214 the end user with the service). 216 o Bindings need to be maintained between upper- and lower-level 217 objects. 219 They involve a system, such as a controller, that provides 220 provisioning logic. Orchestration itself is generally conducted 221 using a "push" model, in which the controller/manager initiates the 222 operations as required, pushing down the specific configurations to 223 the device. The device itself typically remains agnostic to the 224 service or the fact that its resources or configurations are part of 225 a service/concept at a higher layer. 227 Instantiated service models map to instantiated lower-layer network 228 and device models. Examples include instances of paths, or instances 229 of specific port configurations. The service model typically also 230 models dependencies and layering of services over lower-layer 231 networking resources that are used to provide services. This 232 facilitates management by allowing to follow dependencies for 233 troubleshooting activities, to perform impact analysis in which 234 events in the network are assessed regarding their impact on services 235 and customers Services are typically orchestrated and provisioned 236 top-to-bottom, which also facilitates keeping track of the assignment 237 of network resources. 239 Service models also associate with other data that does not concern 240 the network but provides business context. This includes things such 241 as customer data (such as billing information), service orders and 242 service catalogues, tariffs, service contracts, and Service Level 243 Agreements (SLAs) including contractual agreements regarding 244 remediation actions. 246 4.2. Policy and Policy-Based Management 248 Policy-based management (PBM) is a management paradigm that separates 249 the rules that govern the behavior of a system from the functionality 250 of the system. It promises to reduce maintenance costs of 251 information and communication systems while improving flexibility and 252 runtime adaptability. It is today present at the heart of a 253 multitude of management architectures and paradigms including SLA- 254 driven, Business-driven, autonomous, adaptive, and self-* management 255 [Boutaba07]. The interested reader is asked to refer to the rich set 256 of existing literature which includes this and many other references. 257 In the following, we an only provide a much-abridged and distilled 258 overview. 260 At the heart of policy-based management is the concept of a policy. 261 Multiple definitions of policy exist: "Policies are rules governing 262 the choices in behavior of a system" [Sloman94]. "Policy is a set of 263 rules that are used to manage and control the changing and/or 264 maintaining of the state of one or more managed objects" 265 [Strassner03]. Common to most definitions is the definition of a 266 policy as a "rule". Typically, the definition of a rule consists of 267 an event (whose occurrence triggers a rule), a set of conditions 268 (that get assessed and that must be true before any actions are 269 actually "fired"), and finally a set of one or more actions that are 270 carried out when the condition holds. 272 Policy-based management can be considered an imperative management 273 paradigm: Policies specify precisely what needs to be done when. 274 Using policies, management can in effect be defined as a set of 275 simple control loops. This makes policy-based management a suitable 276 technology to implement autonomic behavior that can exhibit self-* 277 management properties including self-configuration, self-healing, 278 self-optimization, and self-protection. In effect, policies define 279 simple control loops typically used to define management as a set of 280 simple control loops. 282 Policies typically involve a certain degree of abstraction in order 283 to cope with heterogeneity of networking devices. Rather than having 284 a device-specific policy that defines events, conditions, and actions 285 in terms of device-specific commands, parameters, and data models, 286 policy is defined at a higher-level of abstraction involving a 287 canonical model of systems and devices to which the policy is to be 288 applied. A policy agent on the device subsequently "renders" the 289 policy, i.e., translates the canonical model into a device-specific 290 representation. This concept allows to apply the same policy across 291 a wide range of devices without needing to define multiple variants. 292 This enables operational scale and allows network operators and 293 authors of policies to think in higher terms of abstraction than 294 device specifics. 296 Policy-based management is typically "push-based": Policies are 297 pushed onto devices where they are rendered and enforced. The push 298 operations are conducted by a manager or controller, which is 299 responsible for deploying policies across the network and monitor 300 their proper operation. That said, other policy architectures are 301 possible. For example, policy-based management can also include a 302 pull-component in which the decision regarding which action to take 303 is delegated to a so-called Policy Decision Point (PDP). This PDP 304 can reside outside the managed device itself and has typically global 305 visibility and context with which to make policy decisions. Whenever 306 a network device observes an event that is associated with a policy, 307 but lacks the full definition of the policy or the ability to reach a 308 conclusion regarding the expected action, it reaches out to the PDP 309 for a decision (reached, for example, by deciding on an action based 310 on various conditions). Subsequently, the device carries out the 311 decision as returned by the PDP - the device "enforces" the policy 312 and hence acts as a PEP (Policy Enforcement Point). Either way, PBM 313 architectures typically involve a central component from which 314 policies are deployed across the network, and/or policy decisions 315 served. 317 4.3. Intent and Intent-Based Management 319 In the context of Autonomic Networks, Intent is defined as "an 320 abstract, high-level policy used to operate a network" [RFC7575]. 321 According to this definition, an intent is a specific type of policy. 322 However, to avoid using "intent" simply as a synonym for "policy, a 323 clearer distinction needs to be introduced that distinguishes intent 324 clearly from other types of policies. 326 Autonomic networks are expected to "self-manage" and operate with 327 minimal outside intervention. However, autonomic networks are not 328 clairvoyant and have no way of automatically knowing particular 329 operational goals nor what instances of networking services to 330 support. In other words, they do not know what the "intent" of the 331 network provider is that gives the network the purpose of its being. 332 This still needs to be communicated by what informally constitutes 333 "intent". 335 More specifically, intent is a declaration of high-level operational 336 goals that a network should meet, without specifying how to achieve 337 them. Those goals are defined in a manner that is purely declarative 338 - they specify what to accomplish or what the desired outcome for the 339 network operator is, not how to achieve it. This encompasses 340 abstraction from low-level device configurations, as well as 341 abstraction from particular management and control logic such as when 342 to spring into action. 344 In an autonomic network, intent should be rendered by the network 345 itself, i.e. translated into device specific rules and courses of 346 action. Ideally, it should not even be orchestrated or broken down 347 by a higher-level, centralized system, but by the network devices 348 themselves using a combination of distributed algorithms and local 349 device abstraction. Because intent holds for the network as a whole, 350 not individual devices, it needs to be automatically disseminated 351 across all devices in the network, which can themselves decide 352 whether they need to act on it. This facilitates management even 353 further, since it obviates the need for a higher-layer system to 354 break down and decompose higher-level intent, and because there is no 355 need to even discover and maintain an inventory of the network to be 356 able to manage it. Intent thus constitutes declarative policy with a 357 network-wide scope. A human operator defines 'what' is expected, and 358 the network computes a solution meeting the requirements. This 359 computation can occur in distributed or even decentralized fashion by 360 auonomic functions that reside on network nodes. 362 Other definitions of intent exist such as [TR523] and will be 363 investigated in future revisions of this document. Likewise, some 364 definitions of intent allow for the presence of a centralized 365 function that renders the intent into lower-level policies or 366 instructions and orchestrates them across the network. While to the 367 end user the concept of "intent" appears the same regardless of its 368 method of rendering, this interpretation opens a slippery slope of 369 how to clearly distinguish "intent" from other higher-layer 370 abstractions. Again, these notions will be further investigated in 371 future revisions of this document and in collaboration with NMRG. 373 5. Distinguishing between Intent, Policy, and Service Models 375 What Intent, Policy, and Service Models all have in common is the 376 fact that they involve a higher-layer of abstraction of a network 377 that does not involve device-specifics, that generally transcends 378 individual devices, and that makes the network easier to manage for 379 applications and human users compared to having to manage the network 380 one device at a time. Beyond that, differences emerge. Service 381 models have less in common with policy and intent than policy and 382 intent do with each other. 384 Summarized differences: 386 o A service model is a data model that is used to describe instances 387 of services that are provided to customers. A service model has 388 dependencies on lower models (device and network models) when 389 describing how the service is mapped onto underlying network and 390 IT infrastructure. Instantiating a service model requires 391 orchestration by a system; the logic for how to 392 orchestrate/manage/provide the service model and how to map it 393 onto underlying resources is not included as part of the model 394 itself. 396 o Policy is a set of rules, typically modeled around a variation of 397 events/conditions/actions, used to express simple control loops 398 that can be rendered by devices themselves, without requiring 399 intervention by outside system. Policy is used to define what to 400 do under what circumstances, but it does not specify a desired 401 outcome. 403 o Intent is a higher-level declarative policy that operates at the 404 level of a network, not individual devices. It is used to define 405 outcomes and high-level operational goals, without the need to 406 enumerate specific events, conditions, and actions. Ideally, 407 intent is rendered by the network itself; also the dissemination 408 of intent across the network and any required coordination between 409 nodes is resolved by the network itself without the need for 410 outside systems. 412 The TM Forum's Business Process Framework for network service 413 providers [eTOM] categorizes network operations broadly into three 414 categories: Fulfillment, Assurance, and Billing. Intent is generally 415 tied to fulfillment, broadly defined as all activities and processes 416 having to do with configuration of the network to fulfill a given 417 purpose. It is not tied to assurance, broadly defined as all 418 activities and processes having to do with keeping the network and 419 services running (including monitoring, measuring, reporting, 420 assessing compliance of service levels with service level objectives, 421 diagnostics, etc). Policy, on the other hand, aligns more closely 422 with assurance. 424 6. Items for Discussion 426 Arguably, given the popularity of the term intent, its use could be 427 broadened to encompass also known concepts ("intent-washing"). For 428 example, it is conceivable to introduce intent-based terms for 429 various concepts that, although already known, are related to the 430 context of intent. Each of those terms could then designate an 431 intent subcategory, for example: 433 o Operational Intent: defines intent related to operational goals of 434 an operator; corresponds to the original "intent" term. 436 o Rule Intent: a synonym for policy rules regarding what to do when 437 certain events occur. 439 o Service intent: a synonym for customer service model [RFC8309]. 441 o Flow Intent: A synonym for a Service Level Objective for a given 442 flow. 444 Whether to do so is an item for discussion by the Research Group. 446 7. IANA Considerations 448 Not applicable 450 8. Security Considerations 452 Not applicable 454 9. References 456 9.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 464 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 465 May 2017, . 467 9.2. Informative References 469 [Boutaba07] 470 Boutaba, R. and I. Aib, "Policy-Based Management: A 471 Historical perspective. Journal of Network and Systems 472 Management (JNSM), Springer, Vol. 15 (4).", December 2007. 474 [eTOM] "GB 921 Business Process Framework, Release 17.0.1.", 475 February 2018. 477 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 478 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 479 Networking: Definitions and Design Goals", RFC 7575, 480 DOI 10.17487/RFC7575, June 2015, 481 . 483 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 484 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 485 DOI 10.17487/RFC8299, January 2018, 486 . 488 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 489 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 490 . 492 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 493 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 494 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 495 2018, . 497 [Sloman94] 498 Sloman, M., "Policy Driven Management for Distributed 499 Systems. Journal of Network and Systems Management (JNSM), 500 Springer, Vol. 2 (4).", December 1994. 502 [Strassner03] 503 Strassner, J., "Policy-Based Network Management. 504 Elsevier.", 2003. 506 [TR523] "Intent NBI - Definition and Principles. ONF TR-523.", 507 October 2016. 509 Authors' Addresses 511 Alexander Clemm 512 Huawei 513 2330 Central Expressway 514 Santa Clara, CA 95050 515 USA 517 Email: ludwig@clemm.org 518 Laurent Ciavaglia 519 Nokia 520 Route de Villejust 521 Nozay 91460 522 FR 524 Email: laurent.ciavaglia@nokia.com 526 Lisandro Zambenedetti Granville 527 Federal University of Rio Grande do Sul (UFRGS) 528 Av. Bento Goncalves 529 Porto Alegre 9500 530 BR 532 Email: granville@inf.ufrgs.br