idnits 2.17.1 draft-li-nmrg-intent-classification-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 == Line 504 has weird spacing: '...e, many appl...' == Line 508 has weird spacing: '...vice in conce...' == Line 511 has weird spacing: '...elopers matc...' == Line 512 has weird spacing: '...irectly corr...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7575' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC8328' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'ANIMA-Prefix' is defined on line 646, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Li 2 Internet Draft China Telecom 3 Intended status: Informational Y. Cheng 4 Expires: January 2020 China Unicom 5 J. Strassner 6 O. Havel 7 W. Liu 8 Huawei Technologies 9 P. Martinez-Julia 10 NICT 11 J. Nobre 12 UFRGS 13 D. Lopez 14 Telefonica I+D 15 July 9, 2019 17 Intent Classification 18 draft-li-nmrg-intent-classification-01 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 34 http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 8, 2009. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Abstract 60 RFC7575 defines Intent as an abstract high-level policy used to 61 operate the network. Intent management system includes an interface 62 for users to input requests and an engine to translate the intents 63 into the network configuration and manage their lifecycle. Up to 64 now, there is no commonly agreed definition, interface or model of 65 intent. 67 This document discusses what intent means to different stakeholders, 68 describes different ways to classify intent, and an associated 69 taxonomy of this classification. This is a foundation for discussion 70 intent related topics. 72 Table of Contents 74 1. Introduction ................................................ 3 75 2. Acronyms .................................................... 3 76 3. Abstract intent requirements ................................. 4 77 3.1. What is Intent? ......................................... 4 78 3.2. Intent Solutions & Intent Users ......................... 4 79 3.3. Current Problems & Requirements ......................... 5 80 3.4. Intent Types that need to be supported .................. 7 81 4. Functional Characteristics and Behavior ...................... 8 82 4.1. Persistence ............................................ 8 83 4.2. Granularity ............................................ 9 84 4.3. Hierarchy .............................................. 9 85 4.4. Abstracting Intent Operation ........................... 10 86 4.5. Policy Subjects and Policy Targets ..................... 11 87 4.6. Policy Scope .......................................... 11 88 5. The Policy Continuum ........................................ 12 89 6. Involvement of intent in the application of AI to Network Manage 90 ment .......................................................... 12 91 7. Security Considerations ..................................... 13 92 8. IANA Considerations ......................................... 13 93 9. Contributors ................................................ 13 94 10. Acknowledgments ............................................ 13 95 11. References ................................................. 14 96 11.1. Normative References ................................. 14 97 11.2. Informative References ................................ 14 99 1. Introduction 101 Different SDOs (such as [ANIMA][ONF][ONOS]) have proposed intent as 102 a declarative interface for defining a set of network operations to 103 execute. 105 Although there is no common definition or model of intent which are 106 agreed by all SDOs, there are several shared principles: 108 o intent should be declarative, using and depending on as few 109 deployment details as possible and focusing on what and not how 111 o intent should provide an easy-to-use interface, and use 112 terminology and concepts familiar to its target audience 114 o intent should be vendor-independent and portable across 115 platforms 117 o the intent framework should be able to detect and resolve 118 conflicts between multiple intents. 120 SDOs have different perspectives on what intent is, what set of 121 actors it is intended to serve, and how it should be used. This 122 document provides several dimensions to classify intents. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Acronyms 130 CLI: Command Line Interface 132 SDO: Standards Development Organization 134 SUPA: Simplified Use of Policy Abstractions 135 VPN: Virtual Private Network 137 DC: Data Center 139 3. Abstract intent requirements 141 In order to understand the different intent requirements that would 142 drive intent classification, we first need to understand what intent 143 means for different intent users. 145 3.1. What is Intent? 147 The term Intent has become very widely used in the industry for 148 different purposes, sometimes it is not even in agreement with SDO 149 shared principles mentioned in the Introduction. Different 150 stakeholders consider an intent to be an ECA policy, a GBP policy, a 151 business policy, a network service, a customer service, a network 152 configuration, application / application group policy, any 153 operator/administrator task, network troubleshooting / diagnostics / 154 test, a new app, a marketing term for existing 155 management/orchestration capabilities, etc. Their intent is 156 sometimes technical, non-technical, abstract or technology specific. 157 For some stakeholders, intent is a subset of these and for other 158 stakeholders intent is all of these. It has in some cases become a 159 term to replace a very generic 'service' or 'policy' terminology. 161 While it is easier for those familiar with different standards to 162 understand what service, CFS, RFS, resource, policy continuum, ECA 163 policy, declarative policy, abstract policy or intent policy is, it 164 may be more difficult for the wider audience. Intent is very often 165 just a synonym for policy. Those familiar with policies understand 166 the difference between a business, intent, declarative, imperative 167 and ECA policy. But maybe the wider audience does not understand the 168 difference and sometimes equates the policy to an ECA policy. 170 Therefore, it is important to start a discussion in the industry 171 about what intent is for different solutions and intent users. It is 172 also imperative to try to propose some intent categories / 173 classifications that could be understood by a wider audience. This 174 would help us define intent interfaces, DSLs and models. 176 3.2. Intent Solutions & Intent Users 178 Different Solutions and Actors have different requirements, 179 expectations and priorities for intent driven networking. They 180 require different intent types and have different use cases. Some 181 users are more technical and require intents that expose more 182 technical information. Other users do not understand networks and 183 require intents that shield them from different networking concepts 184 and technologies. The following are the solutions and intent users 185 that intent driven networking needs to support: 187 +--------------------+------------------------------------+ 188 | Solutions | Intent Users | 189 +--------------------+------------------------------------+ 190 | Carrier Networks | Network Operator | 191 | | Service Designers | 192 | | Service Operators | 193 | | Customers/Subscribers | 194 +--------------------+------------------------------------+ 195 | DC Networks | Cloud Administrator | 196 | | Underlay Network Administrator | 197 | | App Developers | 198 | | End Users | 199 +--------------------+------------------------------------+ 200 | Enterprise Networks| Enterprise Administrator | 201 | | App Developers | 202 | | Enterprise Administrator | 203 +--------------------+------------------------------------+ 205 3.3. Current Problems & Requirements 207 Network APIs and CLIs are too complex due to the fact that they 208 expose technologies & topologies. App developers and end-users do 209 not want to set IP Addresses, VLANs, subnets, ports, etc. Operators 210 and administrators would also benefit from the simpler interfaces, 211 like: 213 o Allow Customer Site A to be connected to Internet via Network B 215 o Allow User A to access all internal resources, except the Server 216 B 218 o Allow User B to access Internet via Corporate Network A 220 o Move all Users from Corporate Network A to the Corporate Network 221 B 223 o Request Gold VPN service between my sites A, B and C 225 o Provide CE Redundancy for all Customer Sites 226 o Add Access Rules to my Service 228 Networks are complex, with many different protocols and 229 encapsulations. Some basic questions are not easy to answer: 231 o Can User A talk to User B? 233 o Can Host A talk to Host B? 235 o Are there any loops in my network? 237 o Are Network A and Network B connected? 239 o Can User A listen to communications between Users B & C? 241 Operators and Administrators manually troubleshoot and fix their 242 networks and services. They instead want: 244 o a reliable network that is self-configured and self-assured based 245 on the intent 247 o to be notified about the problem before the user is aware 249 o automation of network/service recovery based on intent (self- 250 healing, self-optimization) 252 o to get suggestions about correction/optimization steps based on 253 experience (historical data & behaviour) 255 Therefore, Operators and Administrators want to: 257 o simplify and automate network operations 259 o simplify definitions of network services 261 o provide simple customer APIs for Value Added Services (operators) 263 o be informed if the network or service is not behaving as 264 requested 266 o enable automatic optimization and correction for selected 267 scenarios 269 o have systems that learn from historic information and behaviour 271 End-Users cannot build their own services and policies without 272 becoming technical experts and they must perform manual maintenance 273 actions. Application developers and end-users/subscribers want to be 274 able to: 276 o build their own network services with their own policies via 277 simple interfaces, without becoming networking experts 279 o have their network services up and running based on intent and 280 automation only, without any manual actions or maintenance 282 3.4. Intent Types that need to be supported 284 The following intent types need to be supported, in order to address 285 the requirements from different solutions and intent users: 287 o Customer network service intent 289 o for customer self-service 291 o for service operator orders 293 o for intent driven network configuration, verification, 294 correction and optimization 296 o Network resource management 298 o For network configuration 300 o For automated lifecycle management of network configurations 302 o For network resources (switches, routers, routing, policies, 303 underlay) 305 o Cloud and cloud resource management 307 o For DC configuration, VMs, DB Servers, APP Servers 309 o For communication between VMs 311 o For cloud resource lifecycle management (policy driven self- 312 configuration & auto-scaling & recovery/optimization) 314 o Network Policy intent 316 o For security, QoS, application policies, traffic steering, etc 318 o For configuring & monitoring policies, alarms generation for 319 non-compliance, auto-recovery 321 o Task based intents 323 o For network migration 325 o For server replacements 327 o For device replacements 329 o For network software upgrades 331 o To automate any tasks that operators/administrator often 332 perform 334 o System policies intents 336 o For intent management system policies 338 o For design models and policies for network service design 340 o For design models and policies for network design 342 o For design workflows, models and policies for task based 343 intents 345 o Intents that affect other intents 347 o It may be task based intent that modifies many other intents. 349 o The task itself is short-lived, but the modification of other 350 intents has an impact on their lifecycle, so those changes 351 must continue to be continuously monitored and self- 352 corrected/self-optimized. 354 4. Functional Characteristics and Behavior 356 Intent can be used to operate immediately on a target (much like 357 issuing a command), or whenever it is appropriate (e.g., in response 358 to an event). In either case, intent has a number of behaviors that 359 serve to further organize its purpose, as described by the following 360 subsections. 362 4.1. Persistence 364 Intents can be classified into transient/persistent intents: 366 o If intent is transient, it has no lifecycle management. As soon 367 as the specified operation is successfully carried out, the 368 intent is finished, and can no longer affect the target object. 370 o If the intent is persistent, it has lifecycle management. Once 371 the intent is successfully activated and deployed, the system 372 will keep all relevant intents active until they are deactivated 373 or removed. 375 4.2. Granularity 377 Intents can have different granularities: high granularity, low 378 granularity and anything in between. 380 High granularity intents are more complex to design but are the most 381 valuable. Intent translation, intent conflict resolution and intent 382 verification are very complex and require advanced algorithms. 383 Examples: e2e network service, like customer network service over 384 physical & virtual network, over access, metro, dc and wan with all 385 related QoS, security and application policies. 387 Low granularity intents, like some path checks (can A talk to B) or 388 individual network service/network/application/user policies, are 389 the least complex. Their intent translation, intent conflict 390 resolution and intent verification are much simpler than for high 391 granularity intents. 393 Granularity requirements of intents for different users - from the 394 high granularity e2e network service (e.g. customer network service 395 over physical/virtual network infrastructure, AN and WAN with all 396 the QoS/Security/App Policies) to some low granularity path checks. 398 4.3. Hierarchy 400 In different phases of the autonomous driving network, the intents 401 are different. A typical example of autonomous driving network Level 402 0 to 5 are listed as below. 404 o Level 0 - Traditional manual network: O&M personnel manually 405 control the network and obtain network alarms and logs. 407 o Level 1- Partially automated network: Automated scripts are used 408 to automate service provisioning, network deployment, and 409 maintenance. Shallow perception of network status and decision 410 making suggestions of machine; 412 o Level 2- Automated network: Automation of most service 413 provisioning, network deployment, and maintenance Comprehensive 414 perception of network status and local machine decision making; 416 o Level 3- Self-optimization network: Deep awareness of network 417 status and automatic network control, meeting users' network 418 intentions 420 o Level 4- Partial autonomous network: In a limited environment, 421 people do not need to participate in decision-making and adjust 422 themselves. 424 o Level 5- Autonomous network: In different network environments 425 and network conditions, the network can automatically adapt to 426 and adjust to meet people's intentions. 428 4.4. Abstracting Intent Operation 430 The modeling of Policies can be abstracting using the following 431 three-tuple: 433 {Context, Capabilities, Constraints} 435 Context grounds the policy, and determines if it is relevant or not 436 for the current situation. Capabilities describe the functionality 437 that the policy can perform. Capabilities take different forms, 438 depending on the expressivity of the policy as well as the 439 programming paradigm(s) used. Constraints define any restictions on 440 the capabilities to be used for that particular context. Metadata 441 can be optionally attached to each of the elements of the three- 442 tuple, and may be used to describe how the policy should be used and 443 how it operates, as well as prescribe any operational dependencies 444 that must be taken into account. Put another way: 446 o Context selects policies based on applicability 448 o Capabilities describe the functionality provided by the policy 450 o Constraints restrict the capabilities offered and/or the behavior 451 of the policy 453 Hence, the difference between imperative, declarative, and other 454 types of policies lies in how the elements of this three-tuple are 455 used according to that particular programming paradigm. This is how 456 [SUPA] was designed: a Policy is a container that aggregates a set 457 of tatements. 459 4.5. Policy Subjects and Policy Targets 461 Policy subject is the actor that performs the action specified in 462 the policy. It can be the intent management system which executes 463 the policy. Policy target is a set of managed objects which may be 464 affected in the policy enforcement. 466 4.6. Policy Scope 468 Policies used to manage the behavior of objects that they are 469 applied to (e.g., the target of the policy). It is useful to 470 differentiate between the following categories of targets: 472 o Policies defined for the Customer or End-User 474 o Policies defined for the management system to act on objects in 475 the domain that the management system controls 477 o Policies defined for the management system to act on objects in 478 one or more domains that the management system does not directly 479 control 481 The different origins and views of these three categories of actors 482 lead to the following important differences: 484 o Network Knowledge. This area is explored using three exemplary 485 actors that have different knowledge of the network: 487 o Customers and end-users do not necessarily know the functional 488 and operational details of the network that they are using. 489 Furthermore, most of the actors in this category lack skills 490 to understand such details; in fact, such knowledge is 491 typically not relevant to their job. In addition, the network 492 may not expose these details to its users. This class of 493 actor focuses on the applications that they run, and uses 494 services offered by the network. Hence, they want to specify 495 policies that provide consistent behavior according to their 496 business needs. They do not have to worry about how the 497 policies are deployed onto the underlying network, and 498 especially, whether the policies need to be translated to 499 different forms to enable network elements to understand 500 them. 502 o Application developers work in a set of abstractions defined 503 by their application and programming environment(s). For 504 example, many application developers think in terms of 505 objects (e.g., a VPN). While this makes sense to the 506 application developer, most network devices do not have a VPN 507 object per se; rather, the VPN is formed through a set of 508 configuration statements for that device in concert with 509 configuration statements for the other devices that 510 together make up the VPN. Hence, the view of application 511 developers matches the services provided by the network, 512 but may not directly correspond to other views of other 513 actors. 515 o Management personnel, such as network Administrators, may have 516 the knowledge of the underlying network. However, they may 517 not understand the details of the applications and services 518 of Customers and End-Users. 520 o Automation. Theoricaly, intents from both end-user and management 521 system can be automated. In practice, most intents from end-user 522 are created manually according to business request. End-users do 523 not create or alter intents unless there is change in business. 524 Intents from management systems can be created or altered to 525 reflect with network policy change. For example, end-users create 526 intents to set up paths between hosts, while the management 527 system creates an intent to set a global link utilization limit. 529 5. The Policy Continuum 531 The Policy Continuum defines the set of actors that will create, 532 read, use, and manage policy. Each set of actors has their own 533 terminology and concepts that they are familiar with. This captures 534 the fact that business people do not want to use CLI, and network 535 operations center personnel do not want to use non-technical 536 languages. 538 6. Involvement of intent in the application of AI to Network Manage 539 ment 541 In the application of AI to NM, an intent is expected to be, on the 542 one hand, a formal definitions of a goal or policy instructed to the 543 decision system and, on the other hand, a formal definition of the 544 specific actions that some network controller must perform. Goal 545 intents and policy intents have different meanings. The former will 546 establish an objective for the automated management system to 547 accomplish, such as "avoiding latency to be higher than 10 ms". 548 Meanwhile, policy intents set the overall regulations and possible 549 actions that the AI system can use to achieve those goals. Both goal 550 and policy intents are expected to be provided by humans, although 551 they must be in some very formal language that can be easily 552 understood by computers. All those relations make the degree of 553 formality an important dimension to classify intents so that users, 554 which here are AI-based agents, can be able to choose the proper 555 solution to consume them. 557 To enforce the resulting actions determined by AI-based control 558 modules, action intents will have a format that avoids 559 misconceptions as much as possible. This means that they will be 560 closer to machine language structures than natural (human) language 561 structures. This can sacrificing some degree of human 562 understandability, so it forms another dimension in the 563 classification of intents. This dimension allows automated systems 564 to discern which format of intent to use in relation to the 565 possibility and degree of humans to be involved in their exchanges. 567 Finally, as intents can use different words and languages to refer 568 to the same concepts, all intents related to AI will be required to 569 follow a specific ontology. This way, input intents will be easily 570 semantically translated to formal structures. Output intents will 571 also be composed by following the ontology, so receivers of those 572 intents will be able to easily understand them. 574 7. Security Considerations 576 This document does not have any Security Considerations. 578 8. IANA Considerations 580 This document has no actions for IANA. 582 9. Contributors 584 The following people all contributed to creating this document, 585 listed in alphabetical order: 587 Richard Meade, Huawei 588 Weiping Xu, Huawei 590 10. Acknowledgments 592 This document has benefited from reviews, suggestions, comments and 593 proposed text provided by the following members, listed in 594 alphabetical order: Brian E Carpenter, Juergen Schoenwaelder, 595 Laurent Ciavaglia, Xiaolin Song. 597 11. References 599 11.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 605 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 606 Networking: Definitions and Design Goals", RFC 7575, June 607 2015. 609 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 610 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 611 Management Framework for the Simplified Use of Policy 612 Abstractions (SUPA)", March 2018. 614 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 615 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, 616 M., Perry, J., Waldbusser, S., "Terminology for Intent- 617 driven Management", RFC 3198, November 2001. 619 11.2. Informative References 621 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 622 Network Configuration Protocol (NETCONF)", RFC 6020, 623 October 2010. 625 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 626 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 627 Optimization (ALTO) Protocol", September 2014. 629 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017, 630 . 633 [ONF] ONF, "Intent Definition Principles", 2017, 634 . 638 [ONOS] ONOS, "ONOS Intent Framework", 2017, 639 . 642 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions", 643 2017, . 646 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun, 647 "Autonomic IPv6 Edge Prefix Management in Large-scale 648 Networks", draft-ietf-anima-prefix-management-07 (work in 649 progress), December 2017. 651 Authors' Addresses 653 Chen Li 654 China Telecom 655 No.118 Xizhimennei street, Xicheng District 656 Beijing 100035 657 P.R. China 658 Email: lichen.bri@chinatelecom.cn 660 Ying Cheng 661 China Unicom 662 No.21 Financial Street, XiCheng District 663 Beijing 100033 664 P.R. China 665 Email: chengying10@chinaunicom.cn 667 John Strassner 668 Huawei Technologies 669 2330 Central Expressway 670 Santa Clara, CA 95138 671 United States of America 672 Email: john.sc.strassner@huawei.com 674 Olga Havel 675 Huawei Technologies 676 Email: olga.havel@huawei.com 678 Will(Shucheng) Liu 679 Huawei Technologies 680 Bantian, Longgang District 681 Shenzhen 518129 682 P.R. China 683 Email: liushucheng@huawei.com 685 Pedro Martinez-Julia 686 NICT 687 Japan 688 Email: pedro@nict.go.jp 690 Jeferson Campos Nobre 691 University of Vale do Rio dos Sinos 692 Porto Alegre 693 Brazil 694 Email: jcnobre@inf.ufrgs.br 696 Diego R. Lopez 697 Telefonica I+D 698 Don Ramon de la Cruz, 82 699 Madrid 28006 700 Spain 701 Email: diego.r.lopez@telefonica.com