idnits 2.17.1 draft-clemm-nmrg-dist-intent-00.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 (October 30, 2017) is 2364 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REFERENCES' is mentioned on line 169, but not defined 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 Technologies, Inc. 4 Intended status: Informational L. Ciavaglia 5 Expires: May 3, 2018 Nokia 6 L. Granville 7 Federal University of Rio Grande do Sul (UFRGS) 8 October 30, 2017 10 Distinguishing Intent, Policy, and Service Models 11 draft-clemm-nmrg-dist-intent-00 13 Abstract 15 This document presents existing definitions of the Intent, Policy, 16 and Service Models concepts, analyses their differences and 17 commonalities, and how the concepts relate to one another. The 18 document is intended to clarify the different concepts and converge 19 towards a common and shared understanding, and then use this 20 foundation to guide further definition of valid research and 21 engineering problems and their solutions. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 60 4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 5 61 4.1. Service Models . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Policy and Policy-Based Management . . . . . . . . . . . 6 63 4.3. Intent and Intent-Based Management . . . . . . . . . . . 7 64 5. Distinguishing between Intent, Policy, and Service Models . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Traditionally in the IETF, interest with regard to management and 75 operations has focused on the individual network features and 76 devices. The emphasis has generally been on aspects that needed to 77 be provided by a networking device. A prime example for this is 78 SNMP-based management and the 200+ MIBs that have been defined by the 79 IETF over the years. More recent examples include NETCONF, RESTCONF, 80 and YANG data model definitions including aspects such as interface 81 configuration, ACL configuration, or Syslog configuration. However, 82 recent years have seen an increased interest in addressing also upper 83 layers of management and managing end-to-end concepts. Examples 84 include the definition of YANG models for network topology, or the 85 explanation of service models in the context of service orchestration 86 and controllers. In addition, this interest has been fueled by the 87 discussion about how to manage autonomic networks as discussed in the 88 ANIMA working group. Autonomic networks are driven by the need to 89 lower operational expenses and make management exceptionally easy, 90 putting it at odds with the need to manage the network one device and 91 one feature at a time. 93 It has been recognized for a long time that comprehensive management 94 solutions cannot operate only at the level of individual devices and 95 low-level configurations. ITU-T's TMN model introduced a set of 96 management layers as part of the TMN pyramid, consisting of network 97 element, network, service, and business management. High-level 98 operational objectives would propagate in top-down fashion from upper 99 to lower layers. The associated abstraction hierarchy was key to 100 decompose management complexity into separate areas of concerns. 101 This abstraction hierarchy was accompanied by an information 102 hierarchy that concerned itself at the lowest level with device- 103 specific information, but that would, at higher layers, include, for 104 example, end-to-end service instances. 106 Accordingly, there is generally a recognition that to be able to 107 manage networks efficiently end-to-end, management needs to be 108 applied at higher levels of abstraction than that of low-level device 109 details. Instead, it is required to take a more holistic view, in 110 which device-specific details and data models are low-level artifacts 111 that should ideally be derived from higher-level concepts. This can 112 be achieved, for example, by higher-level systems that break down 113 higher-level concepts (such as an instance of a service) into 114 specific device configurations. Examples of such systems include SDN 115 controllers or service provisioning systems. Potentially, this can 116 be even done by intelligent devices themselves, for example, in case 117 of autonomic nodes in an autonomic network. The goal here is that 118 ultimately nodes are able to understand high-level concepts and 119 automatically coordinate with other nodes to achieve the desired end- 120 to-end behavior, without need for intermediate systems. While 121 autonomic networks are intended to exhibit "self-management" 122 properties, they still require input from an operator or outside 123 system to provide operational guidance and information about the 124 goals, purposes, and service instances that the network is to serve. 126 In the case of autonomic networks, the high-level guidance given to 127 the network is commonly referred to as "Intent" [RFC7575]. The idea 128 behind Intent is that a user provides guidance to the network, for 129 example, communicate expectations regarding service level objectives 130 and service instances or regarding operational goals, such as whether 131 to optimize utilization or service levels in a certain operational 132 context. At the same time, the user should have neither to revert to 133 low-level configurations nor ideally have to learn a specific 134 language of the network. Instead, the user should be able to simply 135 express what the network should accomplish - to convey the user's 136 intent. Ideally, the network would be able to infer the intent using 137 a very high-level, natural language or conversational user interface. 138 The autonomic network would be able to interpret this intent and 139 break it down into low-level configurations as needed, even 140 automatically coordinating between nodes to negotiate and tune 141 behaviors. Intent would be conveyed to the autonomic network as a 142 whole; propagation of intent among devices would occur automatically, 143 as the user should not be concerned with individual nodes nor the 144 instantiation of intent across these nodes. 146 The vision of giving the user the ability to communicate to the 147 network in very simple, high-level terms what the network needs to 148 provide and have the network do the rest seems like the Holy Grail of 149 intuition and ease-of-use for how to interact with a network. 150 Accordingly, the term "intent" has caught on rapidly and spread like 151 wildfire, being rapidly adopted also by SDN controllers and by 152 management solutions, all proclaiming the higher-level abstractions 153 exposed of their own northbound interfaces as "intent". However, 154 somewhat overlooked in all this is the fact that, as mentioned above, 155 the concept of management or control abstraction hierarchies was not 156 invented with Intent. This concept has been known for a long time 157 and variations of this concept incarnated in different forms in the 158 past. Specifically: 160 Policy-based management has the goal of defining high-level 161 policies that are subsequently translated and rendered into lower- 162 level actions and parameter settings at devices. Policies are 163 frequently defined in terms of rules, consisting of events (that 164 trigger a rule), conditions (that are assessed when the rule is 165 triggered), and actions (that are carried out when the condition 166 holds). However, many different categories of policies and ways 167 to define them exist, ranging from ACL-style matching rules to 168 high-level declarative policy languages such as Ponder. 169 [REFERENCES] 171 Service models define end-to-end service instances, which are in 172 turn mapped onto low-level configurations (often expressed via 173 device data models) that are applied across devices and resources 174 in the network. 176 This raises the question in which ways intent, policy, and service 177 models are really different. Terms that are trending can become 178 easily overloaded and may end up being used as synonyms for terms 179 that had already been well-established before, not just for the new 180 and differentiating concept for which they were introduced. In order 181 to avoid this situation, this document aims to provide a clear 182 distinction between these terms and what they represent. 183 Specifically, it aims to answer the question whether "intent" is just 184 a new term for "policy" (or "service model") or whether it represents 185 something genuinely different. 187 2. Key Words 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 3. Definitions and Acronyms 197 ACL: Access Control List 199 Intent: An abstract, high-level policy used to operate a network 200 [RFC7575]. 202 Policy: A rule, or set of rules, that governs the choices in 203 behavior of a system. 205 PDP: Policy Decision Point 207 PEP: Policy Enforcement Point 209 Service Model: A model that represents a service that is provided 210 by a network to a user. 212 4. Introduction of Concepts 214 The following subsections provide an overview of the concepts of 215 service models, of policies respectively policy-based management, and 216 of intent respectively intent-based management. While the 217 descriptions are intentionally kept brief and do not provide detailed 218 tutorials, they should convey the bigger picture of the purpose of 219 each concept and provide a sense where those concepts are similar and 220 where they differ. With this background, the differences between 221 them are summarized in the subsequent section. 223 4.1. Service Models 225 A service model is a model that represents a service that is provided 226 by a network to a user. An example of a service could be a Layer 3 227 VPN service, a Network Slice, or residential Internet access. 228 Service models represent service instances as entities in their own 229 right. Services have their own parameters, actions, and lifecycles. 230 Typically, service instances can be bound to end users, who might be 231 billed for the service. 233 Instantiating a service typically involves multiple aspects: 235 o Resources need to be allocated, such as IP addresses, interfaces, 236 bandwidth, or memory. 238 o How to map services to the resources needs to be defined. 239 Multiple mappings are often possible, which to select may depend 240 on context (such as which type of access is available to connect 241 the end user with the service). 243 o Bindings need to be maintained between upper- and lower-level 244 objects. 246 They involve a system, such as a controller, that provides 247 provisioning logic. Orchestration itself is conducted using a "push" 248 model, in which the controller/manager initiates the operations as 249 required, pushing down the specific configurations to the device. 250 The device itself is typically agnostic to the service or the fact 251 that its resources or configurations are part of a service/concept at 252 a higher layer. 254 Instantiated service models map to instantiated lower-layer models. 255 Examples include instances of paths, or instances of specific port 256 configurations. The service model typically also models dependencies 257 and layering of services over lower-layer networking resources that 258 are used to provide services. This facilitates management by 259 allowing to follow dependencies for troubleshooting activities, to 260 perform impact analysis in which events in the network are assessed 261 regarding their impact on services and customers Services are 262 typically orchestrated or provisioned top-to-bottom, and to keep 263 track of the assignment of network resources. 265 4.2. Policy and Policy-Based Management 267 Policy-based management (PBM) is a management paradigm that separates 268 the rules that govern the behavior of a system from the functionality 269 of the system. It promises to reduce maintenance costs of 270 information and communication systems while improving flexibility and 271 runtime adaptability. It is today present at the heart of a 272 multitude of management architectures and paradigms including SLA- 273 driven, Business-driven, autonomous, adaptive, and self-* management 274 [Boutaba07]. The interested reader is asked to refer to the rich set 275 of existing literature which includes this and many other references. 276 In the following, we an only provide a much-abridged and distilled 277 overview. 279 At the heart of policy-based management is the concept of a policy. 280 Multiple definitions of policy exist: "Policies are rules governing 281 the choices in behavior of a system" [Sloman94]. "Policy is a set of 282 rules that are used to manage and control the changing and/or 283 maintaining of the state of one or more managed objects" 284 [Strassner03]. Common to most definitions is the definition of a 285 policy as a "rule". Typically, rules follow consists of events 286 (whose occurrence triggers a rule), conditions (that get assessed 287 before any actions are actually "fired"), and actions that are 288 carried out when the condition holds. 290 Policy-based management can be considered an imperative management 291 paradigm: Policies specify precisely what needs to be done when. 292 Using policies, management can in effect be defined as a set of 293 simple control loops. This makes policy-based management a suitable 294 technology to implement autonomic behavior that can exhibit self-* 295 management properties including self-configuration, self-healing, 296 self-optimization, and self-protection. In effect, policies define 297 simple control loops typically used to define management as a set of 298 simple control loops. 300 Policies typically involve a certain degree of abstraction in order 301 to cope with heterogeneity of networking devices. Rather than having 302 a device-specific policy that defines events, conditions, and actions 303 in terms of device-specific commands, parameters, and data models, 304 policy is defined at a higher-level of abstraction involving a 305 canonical model of systems and devices to which the policy is to be 306 applied. A policy agent on the device subsequently "renders" the 307 policy, i.e., translates the canonical model into a device-specific 308 representation. This concept allows to apply the same policy across 309 a wide range of devices, which leads to operational scale and allows 310 network operators and authors of policies to think in higher terms of 311 abstraction than device specifics. 313 Policy-based management is typically "push-based": Policies are 314 pushed onto devices where they are rendered and enforced. The push 315 operations are conducted by a manager or controller, which is 316 responsible for deploying policies across the network and monitor 317 their proper operation. That said, other policy architectures are 318 possible. For example, policy-based management can also include a 319 pull-component in which the decision regarding which action to take 320 is delegated to a so-called Policy Decision Point (PDP). This PDP 321 can reside outside the managed device itself and has typically global 322 visibility and context with which to make policy decisions. Whenever 323 a network device observes an event that is associated with a policy, 324 but lacks the full definition of the policy or the ability to reach a 325 conclusion regarding the expected action, it reaches out to the PDP 326 for a decision. Subsequently, the device carries out the decision as 327 returned by the PDP - the device "enforces" the policy and hence acts 328 as a PEP (Policy Enforcement Point). Either way, PBM architectures 329 typically involve a central component from which policies are 330 deployed across the network, and/or policy decisions served. 332 4.3. Intent and Intent-Based Management 334 In the context of Autonomic Networks, Intent is defined in as "an 335 abstract, high-level policy used to operate a network". According to 336 this definition, an intent is a specific type of policy. However, to 337 avoid using "intent" simply as a synonym for "policy, a clearer 338 distinction needs to be introduced that distinguishes intent clearly 339 from other types of policies. 341 Autonomic networks are expected to "self-manage" and operate with 342 minimal outside intervention. However, autonomic networks are not 343 clairvoyant and have no way of automatically knowing particular 344 operational goals nor what instances of networking services to 345 support. In other words, they do not know what the "intent" of the 346 network provider is that gives the network the purpose of its being. 347 This still needs to be communicated by what informally constitutes 348 "intent". 350 More specifically, intent is a declaration of high-level operational 351 goals or services that are to be provided by the network, without 352 specifying how to achieve them. Those goals are defined in a manner 353 that is purely declarative - they specify what to accomplish or what 354 the desired outcome for the network operator is, not how to achieve 355 it or even when to spring into action. In addition, Intent (at least 356 in an Autonomic Network) should be rendered by network devices 357 themselves, i.e., translated into device specific rules and courses 358 of action. It should not be orchestrated or broken down by a higher- 359 level, centralized system. Intent holds for the network as a whole, 360 not individual devices, and is hence automatically disseminated 361 across all devices in the network, which can themselves decide 362 whether they need to act on it. This facilitates management even 363 further, since it obviates the need for a higher-layer system to 364 break down and decompose higher-level intent, and because there is no 365 need to even discover and maintain an inventory of the network to be 366 able to manage it. 368 Intent thus constititutes declarative policy with a network-wide 369 scope. A human operator defines 'what' is expected, and the network 370 computes a solution meeting the requirements. This computation can 371 occur in distributed or even decentralized fashion by auonomic 372 functions that reside on network nodes. 374 Other definitions of intent exist such as [ONF TR 523] and will be 375 investigated in future revisions of this document. Likewise, some 376 definitions of intent allow for the presence of a centralized 377 function that renders the intent into lower-level policies or 378 instructions and orchestrates them across the network. While to the 379 end user the concept of "intent" appears the same regardless of its 380 method of rendering, this interpretation opens a slippery slope of 381 how to clearly distinguish "intent" from other higher-layer 382 abstractions. Again, these notions will be further investigated in 383 future revisions of this document and in collaboration with NMRG. 385 5. Distinguishing between Intent, Policy, and Service Models 387 What Intent, Policy, and Service Models all have in common is the 388 fact that they involve a higher-layer of abstraction of a network 389 that does not involve device-specifics, that generally transcends 390 individual devices, and that makes the network easier to manage for 391 applications and human users compared to having to manage the network 392 one device at a time. Beyond that, differences emerge. Service 393 models have less in common with policy and intent than policy and 394 intent do with each other. 396 Summarized differences: 398 o Service model is a data model with dependencies onto lower models. 399 It requires orchestration by a system; the logic to 400 orchestrate/manage/provide the service model is not included as 401 part of the model itself. 403 o Policy is a set of rules, typically modeled around a variation of 404 events/conditions/actions, used to express simple control loops 405 that can be rendered by devices themselves, without requiring 406 intervention by outside system. 408 o Intent is a higher-level declarative policy that operates at the 409 level of a network, not individual devices. It is used to define 410 operational goals and desired outcomes without the need to 411 enumerate specific events, conditions, and actions. Intent is 412 rendered by the network itself; also the dissemination of intent 413 across the network and any required coordination between nodes is 414 resolved by the network itself without the need for outside 415 systems. 417 6. IANA Considerations 419 Not applicable 421 7. Security Considerations 423 Not applicable 425 8. References 427 8.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, 431 DOI 10.17487/RFC2119, March 1997, 432 . 434 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 435 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 436 Networking: Definitions and Design Goals", RFC 7575, 437 DOI 10.17487/RFC7575, June 2015, 438 . 440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 442 May 2017, . 444 8.2. Informative References 446 [Boutaba07] 447 Boutaba, R. and I. Aib, "Policy-Based Management: A 448 Historical perspective. Journal of Network and Systems 449 Management (JNSM), Springer, Vol. 15 (4).", December 2007. 451 [Sloman94] 452 Sloman, M., "Policy Driven Management for Distributed 453 Systems. Journal of Network and Systems Management (JNSM), 454 Springer, Vol. 2 (4).", December 1994. 456 [Strassner03] 457 Strassner, J., "Policy-Based Network Management. 458 Elsevier.", 2003. 460 Authors' Addresses 462 Alexander Clemm 463 Futurewei Technologies, Inc. 464 2330 Central Expressway 465 Santa Clara, CA 95050 466 USA 468 Email: ludwig@clemm.org 470 Laurent Ciavaglia 471 Nokia 472 Route de Villejust 473 Nozay 91460 474 FR 476 Email: laurent.ciavaglia@nokia.com 477 Lisandro Zambenedetti Granville 478 Federal University of Rio Grande do Sul (UFRGS) 479 Av. Bento Goncalves 480 Porto Alegre 9500 481 BR 483 Email: granville@inf.ufrgs.br