idnits 2.17.1 draft-irtf-nmrg-ibn-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1263 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7575' is defined on line 1562, but no explicit reference was found in the text == Unused Reference: 'RFC8328' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 1572, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 1579, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'SUPA' is defined on line 1600, but no explicit reference was found in the text == Unused Reference: 'ANIMA-Prefix' is defined on line 1604, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-clemm-nmrg-dist-intent-02 Summary: 0 errors (**), 0 flaws (~~), 10 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 O. Havel 4 Expires: May 2021 W. Liu 5 A. Olariu 6 Huawei Technologies 7 P. Martinez-Julia 8 NICT 9 J. Nobre 10 UFRGS 11 D. Lopez 12 Telefonica, I+D 13 November 2, 2020 15 Intent Classification 16 draft-irtf-nmrg-ibn-intent-classification-01 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 32 http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 2, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Abstract 58 RFC7575 defines Intent as an abstract high-level policy used to 59 operate the network. Intent management system includes an interface 60 for users to input requests and an engine to translate the intents 61 into the network configuration and manage their life-cycle. Up to 62 now, there is no commonly agreed definition, interface or model of 63 intent. 65 This document discusses mostly the concept of network intents, but 66 other types of intents are also being considered. Specifically, it 67 highlights stakeholder perspectives of intent, methods to classify 68 and encode intent, the associated intent taxonomy, and defines 69 relevant intent terms where necessary. This document provides a 70 foundation for intent related research and facilitate solution 71 development. 73 Table of Contents 75 1. Introduction ................................................ 3 76 2. Key Words ................................................... 5 77 3. Acronyms .................................................... 5 78 4. Abstract Intent Requirements................................. 7 79 4.1. What is Intent?......................................... 7 80 4.2. Intent Solutions and Intent Users ....................... 8 81 4.3. Current Problems and Requirements ....................... 9 82 4.4. Intent Types that need to be supported ................. 10 83 5. Functional Characteristics and Behaviour .................... 12 84 5.1. Abstracting Intent Operation ........................... 12 85 5.2. Intent User Types ...................................... 13 86 5.3. Intent Scope ........................................... 14 87 5.4. Intent Network Scope ................................... 14 88 5.5. Intent Abstraction ..................................... 14 89 5.6. Intent Life-cycle ...................................... 15 90 5.7. Hierarchy .............................................. 15 91 6. Intent Classification ....................................... 16 92 6.1. Intent Classification Methodology ...................... 17 93 6.2. Intent Taxonomy ........................................ 20 94 6.3. Intent Classification for Carrier Solution ............. 22 95 6.3.1. Intent Users and Intent Types ..................... 22 96 6.3.2. Intent Categories ................................. 26 97 6.3.3. Intent Classification Example ..................... 26 98 6.4. Intent Classification for Data Center Solutions......... 30 99 6.4.1. Intent Users and Intent Types ..................... 30 100 6.4.2. Intent Categories ................................. 34 101 6.4.3. Intent Classification Example ..................... 34 102 6.5. Intent Classification for Enterprise Solution .......... 38 103 6.5.1. Intent Users and Intent Types ..................... 38 104 6.5.2. Intent Categories ................................. 40 105 7. Security Considerations ..................................... 42 106 8. IANA Considerations ......................................... 42 107 9. Contributors ................................................ 42 108 10. Acknowledgments ............................................ 42 109 11. References ................................................. 42 110 11.1. Normative References .................................. 42 111 11.2. Informative References ................................ 43 113 1. Introduction 115 The vision of intent-driven networks has attracted a lot of 116 attention, as it promises to simplify the management of networks by 117 human operators. This is done by simply specifying what should happen 118 on the network, without giving any instructions on how to do it. This 119 promise led many telecom companies to begin adopting this new vision, 120 and many Standards Development Organization (SDOs) to propose 121 different intent framework. 123 Several SDOs and open source projects, such as Internet Engineering 124 Task Force (IETF) (by the Autonomic Networking Integrated Model and 125 Approach Working Group [ANIMA]), Open Networking Foundation (ONF) 126 [ONF], Open Network Operating System (ONOS) [ONOS], have proposed 127 intents for defining a set of network operations to execute in a 128 declarative manner. 130 IETF [ANIMA] defines intent as a declarative policy, but still lacks 131 a more complete definition, a tentative format, and a life-cycle. 132 Within ONOS [ONOS], intent is represented as a list of Command-Line 133 Interface (CLI) commands that allows users to bypass low-level 134 details on the network, such as flows or host addresses. ONF through 135 its Boulder and Aspen projects focuses on Northbound Interface (NBI) 136 semantics and intent models. 138 The SDOs usually came up with their own way of specifying an intent, 139 and with their own understanding of what an intent is. Besides that, 140 each SDO defines a set of terms and level of abstraction, its 141 intended users, and the applications and usage scenarios. 143 However, most intent approaches proposed by SDOs share the same 144 following features: 146 o It must be declarative in nature, meaning that a user specifies the 147 goal on the network without specifying how to achieve that goal. 149 o It must be vendor agnostic, in the sense that it abstracts the 150 network capabilities, or the network infrastructure from the user, 151 and it can be ported across different platforms. 153 o It must provide an easy-to-use interface, which simplifies the 154 users' interaction with the intent system through the usage of 155 familiar terminology or concepts. 157 o It should be able to detect and resolve intent conflicts, which 158 include, for example, static (compile-time) conflicts and dynamic 159 (run-time) conflicts. 161 Currently, work is underway on unifying a common understanding of 162 intent concepts and terminology. Concerning NMRG, [CLEMM] is a 163 document to present a definition for intent as higher-level 164 declarative policy that operates at the level of network and services 165 it provides. In addition, this document captures the differences 166 between intent, policy and service. 168 However, even with proposed intent concepts and terminology, as well 169 as agreement on common intent characteristics, an intent may still be 170 viewed in different ways by different stakeholders for different use 171 cases and solutions. This document mostly addresses intents in the 172 context of network intents, however other types of intents are not 173 excluded, as presented in Section 4.4. and Section 6.2. . 175 The goal of this document is to clarify what an intent represents for 176 different stakeholders through a classification on various 177 dimensions, such as solutions, users, and intent types. This 178 classification can ensure a common understanding across all 179 participants and be used to identify the scope and priorities of 180 individual projects, Proof of Concepts (PoCs), research initiatives, 181 or open-source projects. This goal is achieved by proposing the 182 methodology and initial classification tables. This methodology can 183 be used to update the tables by adding or removing different 184 solutions, users or intent types in order to cater for future 185 scenarios, applications or domains. 187 The present document, together with [CLEMM], aims to become the 188 foundation for future intent-related topic discussions regarding the 189 NMRG. 191 2. Key Words 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 3. Acronyms 199 AI: Artificial Intelligence 201 API: Application Programming Interface 203 CE: Customer Equipment 205 CFS: Customer Facing Service 206 CLI: Command Line Interface 208 DB: Data Base 210 DC: Data Center 212 ECA: Event-Condition-Action 214 GBP: Group-Based Policy 216 IETF: Internet Engineering Task Force 218 IP: Internet Protocol 220 O&M: Operations & Maintenance 222 ONF: Open Networking Foundation 224 ONOS: Open Network Operating System 226 PNF: Physical Network Function 228 QoS: Quality of Service 230 RFS: Resource Facing Service 232 SDO: Standards Development Organization 234 SD-WAN: Software-Defined Wide-Area Network 236 SLA: Service-Level Agreement 238 SUPA: Simplified Use of Policy Abstractions 240 VLAN: Virtual Local Area Network 242 VM: Virtual Machine 244 VPN: Virtual Private Network 246 4. Abstract Intent Requirements 248 In order to understand the different intent requirements that would 249 drive intent classification, we first need to understand what intent 250 means for different intent users. 252 4.1. What is Intent? 254 The term Intent has become very widely used in the industry for 255 different purposes, sometimes it is not even in agreement with SDO 256 shared principles mentioned in the Introduction. 258 Different stakeholders consider an intent to be an ECA policy, a GBP 259 policy, a business policy, a network service, a customer service, a 260 network configuration, application/application group policy, any 261 operator/administrator task, network troubleshooting/diagnostics/ 262 test, a new app, a marketing term for existing 263 management/orchestration capabilities, etc. Their intent is sometimes 264 technical, non-technical, abstract or technology specific. For some 265 stakeholders, intent is a subset of these and for other stakeholders 266 intent is all of these. It has in some cases become a term to replace 267 a very generic 'service' or 'policy' terminology. 269 Concerning this, [CLEMM] draft brings clarification with relation to 270 what an intent is and how it differentiates from policies and 271 services. Future versions of this draft will be kept aligned with 272 [CLEMM]. 274 While it is easier for those familiar with different standards to 275 understand what service, CFS, RFS, resource, policy continuum, ECA 276 policy, declarative policy, abstract policy or intent policy is, it 277 may be more difficult for the wider audience. 279 An intent is mistaken by many to be just a synonym for policy. While 280 it is easier for those familiar with different standards to 281 understand what service, CFS, RFS, resource, policy continuum, ECA 282 policy, declarative policy, abstract policy or intent policy is, it 283 may be more difficult for the wider audience. Furthermore, those 284 familiar with policies understand the difference between a business, 285 intent, declarative, imperative, and ECA policy. 287 Therefore, it is important to start a discussion in the industry 288 about what intent is for different solutions and intent users. It is 289 also imperative to try to propose some intent categories/ 290 classifications that could be understood by a wider audience. This 291 would help us define intent interfaces, DSLs and models. 293 4.2. Intent Solutions and Intent Users 295 Different Solutions and Actors have different requirements, 296 expectations and priorities for intent-driven networking. They 297 require different intent types and have different use cases. Some 298 users are more technical and require intents that expose more 299 technical information. Other users do not understand networks and 300 require intents that shield them from different networking concepts 301 and technologies. The following are the solutions and intent users 302 that intent-driven networking needs to support: 304 +--------------------+------------------------------------+ 305 | Solutions | Intent Users | 306 +--------------------+------------------------------------+ 307 | Carrier Networks | Network Operator | 308 | | Service Designers | 309 | | Service Operators | 310 | | Customers/Subscribers | 311 +--------------------+------------------------------------+ 312 | DC Networks | Cloud Administrator | 313 | | Underlay Network Administrator | 314 | | App Developers | 315 | | End-Users | 316 +--------------------+------------------------------------+ 317 | Enterprise Networks| Enterprise Administrator | 318 | | App Developers | 319 | | End-Users | 320 +--------------------+------------------------------------+ 322 These intent solutions and intent users represent a starting point 323 for the classification and are expendable through the methodology 324 presented in Section 6.1. . 326 o For carrier networks scenario, for example, if the end-users wants 327 to watch high-definition video, then the intent is to convert the 328 video image to 1080p rate for the users. 330 o For DC networks scenario, administrators have their own clear 331 network intent such as load balancing. For all traffic flows that 332 need NFV service chaining, restrict the maximum load of any VNF 333 node/container below 50% and the maximum load of any network link 334 below 70%. 336 o For Enterprise Networks scenario, enterprise administrators 337 express their intent from an external client (application service 338 provider). For example, when hosting a video conference, multiple 339 remote accesses are required. An example of the intent expressed 340 to the network operator is: For any user of this application, the 341 arrival time of hologram objects of all the remote tele-presenters 342 should be synchronised within 50ms to reach the destination viewer 343 for each conversation session. 345 4.3. Current Problems and Requirements 347 Network APIs and CLIs are too complex due to the fact that they 348 expose technologies and topologies. App developers and end-users do 349 not want to set IP Addresses, VLANs, subnets, ports, etc. Operators 350 and administrators would also benefit from the simpler interfaces, 351 like: 353 o Allow Customer Site A to be connected to Internet via Network B 355 o Allow User A to access all internal resources, except the Server B 357 o Allow User B to access Internet via Corporate Network A 359 o Move all Users from Corporate Network A to the Corporate Network B 361 o Request Gold VPN service between my sites A, B and C 363 o Provide CE Redundancy for all Customer Sites 365 o Add Access Rules to my Service 367 Networks are complex, with many different protocols and 368 encapsulations. Some basic questions are not easy to answer: 370 o Can User A talk to User B? 372 o Can Host A talk to Host B? 374 o Are there any loops in my network? 376 o Are Network A and Network B connected? 378 o Can User A listen to communications between Users B and C? 380 Operators and Administrators manually troubleshoot and fix their 381 networks and services. They instead want: 383 o a reliable network that is self-configured and self-assured based on 384 the intent 386 o to be notified about the problem before the user is aware 388 o automation of network/service recovery based on intent (self-healing, 389 self-optimization) 391 o to get suggestions about correction/optimization steps based on 392 experience (historical data and behaviour) 394 Therefore, Operators and Administrators want to: 396 o simplify and automate network operations 398 o simplify definitions of network services 400 o provide simple customer APIs for Value Added Services (operators) 402 o be informed if the network or service is not behaving as requested 404 o enable automatic optimization and correction for selected scenarios 406 o have systems that learn from historic information and behaviour 408 End-users cannot build their own services and policies without 409 becoming technical experts and they must perform manual maintenance 410 actions. Application developers and end-users/subscribers want to be 411 able to: 413 o build their own network services with their own policies via simple 414 interfaces, without becoming networking experts 416 o have their network services up and running based on intent and 417 automation only, without any manual actions or maintenance 419 4.4. Intent Types that need to be supported 421 The following intent types need to be supported, in order to address 422 the requirements from different solutions and intent users: 424 o Customer service intent 426 o for customer self-service with SLA or add a service 428 o for service operator orders 430 o Network and Underlay Network service intent 432 o for service operator orders 434 o for intent driven network configuration, verification, 435 correction and optimization 437 o for intent created and provided by the underlay network 438 administrator 440 o Network and Underlay Network intent 442 o For network configuration 444 o For automated lifecycle management of network configurations 446 o For network resources (switches, routers, routing, policies, 447 underlay) 449 o Cloud management intent 451 o For DC configuration, VMs, DB Servers, APP Servers 453 o For communication between VMs 455 o Cloud resource management intent 457 o For cloud resource life-cycle management (policy driven self- 458 configuration and auto-scaling and recovery/optimization) 460 o Strategy intent 462 o For security, QoS, application policies, traffic steering, etc. 464 o For configuring and monitoring policies, alarms generation for 465 non-compliance, auto-recovery 467 o For design models and policies for network and network service 468 design 470 o For design workflows, models and policies for operational task 471 intents 473 o Operational task intents 475 o For network migration 476 o For server replacements 478 o For device replacements 480 o For network software upgrades 482 o To automate any tasks that operators/administrator often 483 perform 485 o Intents that affect other intents 487 o It may be task-based intent that modifies many other intents. 489 o The task itself is short-lived, but the modification of other 490 intents has an impact on their life-cycle, so those changes 491 must continue to be continuously monitored and self- 492 corrected/self-optimized. 494 5. Functional Characteristics and Behaviour 496 Intent can be used to operate immediately on a target (much like 497 issuing a command), or whenever it is appropriate (e.g., in response 498 to an event). In either case, intent has a number of behaviours that 499 serve to further organize its purpose, as described by the following 500 subsections. 502 5.1. Abstracting Intent Operation 504 The modelling of Intents can be abstracted using the following 505 three-tuple: 507 {Context, Capabilities, Constraints} 509 o Context grounds the intent, and determines if it is relevant or 510 not for the current situation. Thus, context selects intents based 511 on applicability. 513 o Capabilities describe the functionality that the intent can 514 perform. Capabilities take different forms, depending on the 515 expressivity of the intent as well as the programming paradigm(s) 516 used. 518 o Constraints define any restrictions on the capabilities to be used 519 for that particular context. 521 Metadata can be attached via strategy templates to each of the 522 elements of the three-tuple, and may be used to describe how the 523 intent should be used and how it operates, as well as prescribe any 524 operational dependencies that must be taken into account. 526 5.2. Intent User Types 528 Intent user types, or intent actors as they are known in the area of 529 declarative policy, represent the users that define and issue the 530 intent request. Depending on the Intent Solutions, there are specific 531 intent actors. Examples of intent actors are customers, network 532 operators, service operators, enterprise administrators, cloud 533 administrators, and underlay network administrators, or application 534 developers. 536 o Customers and end-users do not necessarily know the functional and 537 operational details of the network that they are using. 538 Furthermore, they lack skills to understand such details; in fact, 539 such knowledge is typically not relevant to their job. In 540 addition, the network may not expose these details to its users. 541 This class of actor focuses on the applications that they run, and 542 uses services offered by the network. Hence, they want to specify 543 policies that provide consistent behaviour according to their 544 business needs. They do not have to worry about how the intents 545 are deployed onto the underlying network, and especially, whether 546 the intents need to be translated to different forms to enable 547 network elements to understand them. 549 o Application developers work in a set of abstractions defined by 550 their application and programming environment(s). For example, 551 many application developers think in terms of objects (e.g., a 552 VPN). While this makes sense to the application developer, most 553 network devices do not have a VPN object per se; rather, the VPN 554 is formed through a set of configuration statements for that 555 device in concert with configuration statements for the other 556 devices that together make up the VPN. Hence, the view of 557 application developers matches the services provided by the 558 network, but may not directly correspond to other views of other 559 actors. 561 o Management personnel, such as network operators, may have the 562 knowledge of the underlying network. However, they may not 563 understand the details of the applications and services of 564 Customers and End-Users. 566 5.3. Intent Scope 568 Intent are used to manage the behaviour of the networks they are 569 applied to and all intents are applied within a specific scope, such 570 as: 572 o Connectivity scope, if the intent creates or modifies a 573 connection. 574 o Security scope, if the intent specifies the security 575 characteristics of the network or users. 576 o Application scope, when the intent specifies the applications to 577 be affected by the intent request. 578 o QoS Scope, when the intent specifies the QoS characteristics of 579 the network. 581 These intent scopes are expendable through the methodology presented 582 in Section 6.1. . 584 5.4. Intent Network Scope 586 Regardless on the intent user type, their intent request is affecting 587 the network, or network components, which are representing the intent 588 targets. 590 Thus, intent network scope, or policy target as known in the area of 591 declarative policy, can represent VNFs or PNFs, Physical Network 592 Elements, Campus networks, SD-WAN networks, radio access networks, 593 cloud edge, cloud core, branch, etc. 595 5.5. Intent Abstraction 597 Intent can be classified by whether it is necessary to feedback 598 technical network information or non-technical information to the 599 intended proponent after the intent is executed. As well, intent 600 abstraction covers the level of technical details in the intent 601 itself. 603 o For ordinary users, they do not care how the intent is executed, 604 or the details of the network. As a result, they do not need to 605 know the configuration information of the underlying network. They 606 only focus on whether the intent execution result achieves the 607 goal, and the execution effect such as the quality of completion 608 and the length of execution. In this scenario, we refer to an 609 abstraction without technical feedback. 611 o For administrators, such as network administrators, they perform 612 intents, such as allocating network resources, selecting 613 transmission paths, handling network failures, etc. They require 614 multiple feedback indicators for network resource conditions, 615 congestion conditions, fault conditions, etc. after execution. In 616 this case, we refer to an abstraction with technical feedback. 618 As per intent definition provided in [CLEMM], lower-level intents are 619 not considered to qualify as intents. However, we kept this 620 classification to identify any PoCs/Demos/Use Cases that still either 621 require or implement lower level of abstraction for intents. 623 5.6. Intent Life-cycle 625 Intents can be classified into transient and persistent intents: 627 o If intent is transient, it has no life-cycle management. As soon 628 as the specified operation is successfully carried out, the intent 629 is finished, and can no longer affect the target object. 631 o If the intent is persistent, it has life-cycle management. Once 632 the intent is successfully activated and deployed, the system will 633 keep all relevant intents active until they are deactivated or 634 removed. 636 5.7. Hierarchy 638 In different phases of the autonomous driving network [TMF-auto], the 639 intents are different. A typical example of autonomous driving 640 network Level 0 to 5 are listed as below. 642 o Level 0 - Traditional manual network: O&M personnel manually 643 control the network and obtain network alarms and logs. - No 644 intent 646 o Level 1 - Partially automated network: Automated scripts are used 647 to automate service provisioning, network deployment, and 648 maintenance. Shallow perception of network status and decision 649 making suggestions of machine; - No intent 651 o Level 2 - Automated network: Automation of most service 652 provisioning, network deployment, and maintenance comprehensive 653 perception of network status and local machine decision making; - 654 simple intent on service provisioning 656 o Level 3 - Self-optimization network: Deep awareness of network 657 status and automatic network control, meeting users' network 658 intentions. - Intent based on network status cognition 660 o Level 4 - Partial autonomous network: In a limited environment, 661 people do not need to participate in decision-making and adjust 662 themselves. - Intent based on limited AI 664 o Level 5 - Autonomous network: In different network environments 665 and network conditions, the network can automatically adapt to and 666 adjust to meet people's intentions. - Intent based on AI 668 6. Intent Classification 670 This chapter proposes an intent classification approach that may help 671 to classify mainstream intent related demos/tools. 673 The three classifications in this draft have been proposed from 674 scratch, following the methodology presented, through three 675 iterations: one for carrier Intent Solution, one for DC Intent 676 Solution, and one for enterprise Intent Solution. For each Intent 677 solution, we identified the specific Intent Users and Intent Types. 678 Then, we further identified the Intent Scope, Network Scope, 679 Abstractions, and Life-cycle requirements. 681 These classifications and the generated tables can be easily 682 extended. For example, for the DC Intent Solution, a new category is 683 identified, i.e. Resource Scope, and the classification table has 684 been extended accordingly. 686 In the future, as new scenarios, applications, and domains are 687 emerging, new classifications and taxonomies can be identified, 688 following the proposed methodology. 690 The output of the intent classification is the intent taxonomy 691 introduced in the next sections. 693 Thus, this section first introduces the proposed intent 694 classification methodology, followed by consolidated intent taxonomy 695 for three intent solutions, and then by concrete examples of intent 696 classifications for three different intent solutions (e.g. Carrier 697 Network, Data Center, and Enterprise) that were derived using the 698 proposed methodology and then can be filled in for PoCs, demos, 699 research projects or future drafts. 701 6.1. Intent Classification Methodology 703 This section describes the methodology used to derive the initial 704 classification proposed in the draft. The proposed methodology can be 705 used to create new intent classifications from scratch, by analysing 706 the solution knowledge. As well, the methodology can be used to 707 update existing classification tables by adding or removing different 708 solutions, users or intent types in order to cater for future 709 scenarios, applications or domains. 711 The intent classification workflow starts from the Solution 712 Knowledge, which can provide information on requirements, use cases, 713 technologies used, network properties, actors that define and issue 714 the intent request, and requirements. The following, defines the 715 steps to classify an intent: 717 1. The information provided in the solution knowledge is provided as 718 input to identifying the intent solution (e.g. Carrier, Enterprise, 719 and Data Center). This intent solution is reviewed against the 720 existing classification and it can either be used or add/remove the 721 intent solution identified from the solution knowledge (R1-U1). 723 2. The next step is identifying the intent user types (e.g. customer, 724 network operators, service operators, etc.) and then review existing 725 classification and use it or add/remove the intent user type 726 identified from the solution knowledge (R2-U2). 728 3. The next phase is to identify the type of intent (e.g. Network 729 Intent, Customer Service Intent) and then review existing 730 classification and use/add/remove the intent type (R3-U3). 732 4. The forth step is identifying the intent scope (e.g. Connectivity, 733 Application) based on the Solution Knowledge and then review existing 734 classification and use/add/remove the identified intent scope (R4- 735 U4). 737 5. The next step is to identify the network scope (e.g. Campus, Radio 738 Access) and then then review existing classification and either use 739 it or add/remove the identified network scope (R5-U5). 741 6. The next phase is to identify the abstractions (e.g. technical, 742 non-technical) and then review existing classification and 743 use/add/remove the abstractions (R6-U6). 745 7. The seventh step is to identify the life-cycle requirements (e.g. 746 persistent, transient) and then review existing classification and 747 use/add/remove the life-cycle requirements (R7-U7). 749 8. The last step is to identify any new categories and use/add the 750 newly identified categories. New categories can be identified as new 751 domains or applications are emerging, or new areas of concern (e.g. 752 privacy, compliance) might arise, which are not listed in the 753 current methodology. 755 +------------------------------------------+ 756 |Solution Knowledge (requirements, | 757 |use cases, technologies, network, actors, | 758 |intent requirements) | 759 +----------------+-------------------------+ 760 | 761 | Input 762 v 763 +--------+--------+ 764 |1.Identify Intent| 765 | Solution +------------+ 766 | | | 767 +---------^-+-----+ | 768 R1 | | U1 | 769 | | | 770 +---------------+ U8 | | R2 +--v----------------+ 771 |8.Identify New +---------+ | | +-----------> 2.Identify | 772 | Categories | R8 | | | | U2 | Intent | 773 | <-------- | | | | +---------+ User Types | 774 +--------^------+ | | | | | | +-------|-----------+ 775 | | | | | | | | 776 | ++-+-v-v---+-v-+ | 777 +--------+------+ U7 | | R3 +------v------------+ 778 |7.Identify +------> Intent +--------> 3.Identify | 779 | Life-cycle | R7 |Classification| U3 | Type | 780 | Requirements <------+ <--------+ of Intent | 781 +--------^------+ +^--^-+--^-+---+ +------|------------+ 782 | || | | | | | 783 | || | | | | | 784 +--------+-----+ || | | | | R4 +-------v-----------+ 785 |6.Identify | U6 || | | | +-----------> 4.Identify | 786 | Abstractions+---------| | | | U4 | Intent | 787 | <---------+ | | +-------------+ Scope | 788 +-------^------+ R6 | | +-------+-----------+ 789 | | | | 790 | U5 | |R5 | 791 | +-------+-v--------+ | 792 | |5.Identify Network| | 793 +----------+ Scope <---------------+ 794 +------------------+ 796 6.2. Intent Taxonomy 798 The following taxonomy describes the various intent solutions, intent 799 user types, intent types, intent scopes, network scopes, abstractions 800 and life-cycle and represents the output of the intent classification 801 tables for each of the solutions addressed (i.e. Carrier Solution, 802 Data Center, and Enterprise). 804 +--------------------------------+ 805 |Carrier Enterprise | 806 +-->|Data Center | 807 | +--------------------------------+ 808 | +--------------------------------+ 809 | |Customer | 810 +----------+ | |Network or Service Operator | 811 +>+Solutions +--+ |Application Developer | 812 | +----------+ +->|Enterprise Administrator | 813 | | |Cloud Administrator | 814 | +----------+ | |Underlay Network Administrator | 815 +>+Intent +---+ +--------------------------------+ 816 | |User | +--------------------------------+ 817 | |Types | |Customer Service Intent | 818 | +----------+ |Strategy Intent | 819 | +----------+ |Network Service Intent | 820 +>+Intent +----->|Underlay Network Service Intent | 821 +------+ | |Type | |Network Intent | 822 |Intent+-+ +----------+ |Underlay Network Intent | 823 +------+ | |Operational Task Intent | 824 | +----------+ |Cloud Management Intent | 825 +>+Intent +---+ |Cloud Resource Management Intent| 826 | |Scope | | +--------------------------------+ 827 | +----------+ | +--------------------------------+ 828 | +->|Connectivity Application | 829 | +----------+ |Security QoS | 830 +>+Network +---+ +--------------------------------+ 831 | |Scope | | +--------------------------------+ 832 | +----------+ | |Radio Access Branch | 833 | +->|Transport Access SD-WAN | 834 | +----------+ |Transport Aggr. VNF PNF | 835 +>+Abstrac +----+ |Transport Core Physical | 836 | |tion | | |Cloud Edge Logical | 837 | +----------+ | |Cloud Core Campus | 838 | +----------+ | +--------------------------------+ 839 +>+Life | | +--------------------------------+ 840 |cycle +--+ +>|Technical Non-Technical | 841 +----------+ | +--------------------------------+ 842 | +--------------------------------+ 843 +-->|Persistent Transient | 844 +--------------------------------+ 846 6.3. Intent Classification for Carrier Solution 848 Users and Intent Types 850 The following table describes the Intent Users in Carrier Solutions 851 and Intent Types with their descriptions for different intent users. 853 +-------------+-------------+---------------------------------------+ 854 | Intent User | Intent Type | Intent Type Description | 855 +-------------------------------------------------------------------+ 856 | Customer/ |Customer |Customer Self-Service with SLA and | 857 | Subscriber |Service |Value Added Service | 858 | |Intent |Example: Always maintain high quality | 859 | | |of service and high bandwidth for gold | 860 | | |level users. | 861 | | |Operational statement: Measure the | 862 | | |network congestion status, give | 863 | | |different adaptive parameters to | 864 | | |stations of different priority, thus in| 865 | | |heavy load situation, makes the | 866 | | |bandwidth of the high-priority users | 867 | | |guaranteed. At the same time ensure the| 868 | | |overall utilization of system, improve | 869 | | |the overall throughput of the system. | 870 | +-----------------------------------------------------+ 871 | |Strategy |Customer designs models and policy | 872 | |Intent |intents to be used by Customer Service | 873 | | |Intents. | 874 | | |Example: Request reliable service | 875 | | |during peak traffic periods for apps | 876 | | |of type video. | 877 +-------------------------------------------------------------------+ 878 |Network |Network |Service provided by Network Service | 879 |Operator |Service |Operator to the Customer | 880 | |Intent |(e.g. the Service Operator) | 881 | | |Example: Request network service with | 882 | | |delay guarantee for access customer A. | 883 | +-------------+---------------------------------------+ 884 | |Network |Network Operator requests network-wide | 885 | |Intent |(service underlay or other network-wide| 886 | | |configuration) or network resource | 887 | | |configurations (switches, routers, | 888 | | |routing, policies). Includes | 889 | | |Connectivity, Routing, QoS, Security, | 890 | | |Application Policies, Traffic Steering | 891 | | |Policies, Configuration policies, | 892 | | |Monitoring policies, alarm generation | 893 | | |for non-compliance, auto-recovery, etc.| 894 | | |Example: Request high priority queueing| 895 | | |for traffic of class A. | 896 | +-----------------------------------------------------+ 897 | |Operational |Network Operator requests execution of | 898 | |Task |any automated task other than Network | 899 | |Intent |Service Intent and Network Intent | 900 | | |(e.g. Network Migration, Server | 901 | | |Replacements, Device Replacements, | 902 | | |Network Software Upgrades). | 903 | | |Example: Request migration of all | 904 | | |services in Network N to backup path P.| 905 | +-----------------------------------------------------+ 906 | |Strategy |Network Operator designs models, policy| 907 | |Intent |intents and workflows to be used by | 908 | | |Network Service Intents, Network | 909 | | |Intents and Operational Task Intents. | 910 | | |Workflows can automate any tasks that | 911 | | |Network Operator often performed in | 912 | | |addition to Network Service Intents and| 913 | | |Network Intents | 914 | | |Example: Ensure the load on any link in| 915 | | |the network is not higher than 50%. | 916 +-------------+-------------+---------------------------------------+ 917 +-------------+-------------+---------------------------------------+ 918 | Service | Customer | Service Operator's Customer Orders, | 919 | Operator | Service | Customer Service / SLA | 920 | | Intent | Example: Provide service S with | 921 | | | guaranteed bandwidth for customer A. | 922 | +-----------------------------------------------------+ 923 | | Network | Service Operator's Network Orders / | 924 | | Service | Network SLA | 925 | | | Example: Provide network guarantees in| 926 | | Intent | terms of security, low latency and | 927 | | | high bandwidth | 928 | +-----------------------------------------------------+ 929 | | Operational | Service Operator requests execution of| 930 | | Task | any automated task other than | 931 | | Intent | Customer Service Intent and Network | 932 | | | Service Intent | 933 | | | Example: Update service operator | 934 | | | portal platforms and their software | 935 | | | regularly. Move services from Network | 936 | | | Operator 1 to Network Operator 2. | 937 | +-----------------------------------------------------+ 938 | | Strategy | Service Operator designs models, | 939 | | Intent | policy intents and workflows to be | 940 | | | used by Customer Service Intents, | 941 | | | Network Service Intents and | 942 | | | Operational Task Intents. Workflows | 943 | | | can automate any tasks that Service | 944 | | | Operator often performed in addition | 945 | | | to Network Service Intents and Network| 946 | | | Intents. | 947 | | | Example: Request network service | 948 | | | guarantee to avoid network congestion | 949 | | | during special periods | 950 | | | such as Black Friday, and Christmas. | 951 +-------------+-------------+---------------------------------------+ 952 | Application | Customer | Customer Service Intent API provided | 953 | Developer | Service | to the Application Developers | 954 | | Intent | Example: API to request network to | 955 | | | watch HD video 4K/8K. | 956 | +-----------------------------------------------------+ 957 | | Network | Network Service Intent API provided to| 958 | | Service | the Application Developers | 959 | | Intent | Example: API to request network and | 960 | | | monitoring and traffic grooming. | 961 | +-----------------------------------------------------+ 962 | | Network | Network Intent API provided to the | 963 | | Intent | Application Developers | 964 | | | Example: API to request network | 965 | | | resources configuration. | 966 | +-----------------------------------------------------+ 967 | | Operational | Operational Task Intent API provided | 968 | | Task | to the Application Developers. This is| 969 | | Intent | for the trusted internal Operator / | 970 | | | Service Providers / Customer DevOps | 971 | | | Example: API to request server | 972 | | | migrations. | 973 | +-----------------------------------------------------+ 974 | | Strategy | Application Developer designs models, | 975 | | Intent | policy and workflows to be used by | 976 | | | Customer Service Intents, Network | 977 | | | Service Intents and Operational | 978 | | | Task Intents. This is for the trusted | 979 | | | internal Operator/Service Provider/ | 980 | | | Customer DevOps | 981 | | | Example: API to design network load | 982 | | | balancing strategies during peak times| 983 +-------------+-------------+---------------------------------------+ 985 Categories 987 The following are the proposed categories: 988 Intent Scope: C1=Connectivity, C2=Security, C3=Application, 989 C4=QoS 990 Network Scope: 991 o Network Domain: C1=Radio Access, C2=Transport Access, 992 C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge, 993 C6=Cloud Core) 994 o Network Function (NF) Scope: C1=VNFs, C2=PNFs 995 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non- 996 technical (without technical feedback) see Section 5.2. . 997 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient 998 (Short Lived) 1000 Classification Example 1002 This section depicts an example on how the methodology described in 1003 Section 6.1. can be used in order to classify intents introduced in 1004 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. The 1005 PoC considered two intents: slice intents and service chain intents. 1007 In this PoC [POC-IBN], a slice intent expresses a request for a 1008 network slice with two types of components: a set of top layer 1009 virtual functions, and a set of virtual switches and/or routers of 1010 L2/L3 VNFs. A service chain intent expressed a request for a service 1011 operated through a chain of service components running in L4-L7 1012 virtual functions. 1014 Following the intent classification methodology described step-by- 1015 step in Section 6.1. , we identify the following: 1017 1. The Intent Solution is for the Carrier. 1019 2. The Intent User Type is the Network Operator for the slice intent, 1020 and the Service Operator for the service chain intent 1022 3. The Type of Intent, is a Network Service Intent for the slice 1023 intent, and a Customer Service Intent for the service chain 1024 intent. 1026 4. The Intent Scopes are connectivity and application. 1028 5. The Network Scope is a logical one. 1030 6. The Abstractions are with technical feedback for the slice intent, 1031 and without technical feedback for the service chain intent 1033 7. The life-cycle is persistent. 1035 The following table shows how to represent this information in a 1036 tabular form. The 'X' in the table refers to the slice intent, and 1037 the 'Y' in the table refers to the service chain intent. 1039 +---------+---------+-----------+-----+-----------------+-----+-----+ 1040 | Intent | Intent | Intent | NF | Network | ABS |L-C | 1041 | User | Type | Scope |Scope| Scope | | | 1042 | | +-----------+-----+-----------------+-----+-----+ 1043 | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| 1044 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1045 |Customer |Customer | | | | | | | | | | | | | | | | | 1046 |/ Sub- |Service | | | | | | | | | | | | | | | | | 1047 | scriber |Intent | | | | | | | | | | | | | | | | | 1048 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1049 | |Strategy | | | | | | | | | | | | | | | | | 1050 | |Intent | | | | | | | | | | | | | | | | | 1051 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1052 |Network |Network |X | |X | |X | | | | | |X |X |X | |X | | 1053 |Operator |Service | | | | | | | | | | | | | | | | | 1054 | |Intent | | | | | | | | | | | | | | | | | 1055 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1056 | |Network | | | | | | | | | | | | | | | | | 1057 | |Intent | | | | | | | | | | | | | | | | | 1058 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1059 | |Operatio-| | | | | | | | | | | | | | | | | 1060 | | nal Task| | | | | | | | | | | | | | | | | 1061 | |Intent | | | | | | | | | | | | | | | | | 1062 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1063 | |Strategy | | | | | | | | | | | | | | | | | 1064 | |Intent | | | | | | | | | | | | | | | | | 1065 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1066 |Service |Customer |Y | |Y | |Y | | | | | | |Y |Y |Y |Y | | 1067 |Operator |Service | | | | | | | | | | | | | | | | | 1068 | |Intent | | | | | | | | | | | | | | | | | 1069 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1070 | |Network | | | | | | | | | | | | | | | | | 1071 | |Service | | | | | | | | | | | | | | | | | 1072 | |Intent | | | | | | | | | | | | | | | | | 1073 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1074 | |Op Task | | | | | | | | | | | | | | | | | 1075 | |Intent | | | | | | | | | | | | | | | | | 1076 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1077 | |Strategy | | | | | | | | | | | | | | | | | 1078 | |Intent | | | | | | | | | | | | | | | | | 1079 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1080 |App |Customer | | | | | | | | | | | | | | | | | 1081 |Developer|Intent | | | | | | | | | | | | | | | | | 1082 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1083 | |Network | | | | | | | | | | | | | | | | | 1084 | |Service | | | | | | | | | | | | | | | | | 1085 | |Intent | | | | | | | | | | | | | | | | | 1086 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1087 | |Network | | | | | | | | | | | | | | | | | 1088 | |Intent | | | | | | | | | | | | | | | | | 1089 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1090 | |Op Task | | | | | | | | | | | | | | | | | 1091 | |Intent | | | | | | | | | | | | | | | | | 1092 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1093 | |Strategy | | | | | | | | | | | | | | | | | 1094 | |Intent | | | | | | | | | | | | | | | | | 1095 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1096 6.4. Intent Classification for Data Center Solutions 1098 Users and Intent Types 1100 The following table describes the Intent Users in DCN Solutions and 1101 Intent Types with their descriptions for different intent users. 1103 +---------------+-------------+-------------------------------------+ 1104 | Intent User | Intent Type | Intent Type Description | 1105 +-------------------------------------------------------------------+ 1106 | Customer / | Customer | Customer Self-Service via Tenant | 1107 | Tenants | Service | Portal, Customers may have multiple | 1108 | | Intent | type of end-users. | 1109 | | | Example: Request GPU computing and | 1110 | | | storage resources to meet 10k video | 1111 | | | surveillance services. | 1112 | +---------------------------------------------------+ 1113 | | Strategy | This includes models and policy | 1114 | | Intent | intents designed by Customers/ | 1115 | | | Tenants to be used by Customer and | 1116 | | | End-User Intents. | 1117 | | | Example: Request dynamic computing | 1118 | | | and storage resources of the service| 1119 | | | in special and daily times. | 1120 | | | | 1121 +-------------------------------------------------------------------+ 1122 | | Cloud | Configuration of VMs, DB Servers, | 1123 | Cloud | Management | App Servers, Connectivity, | 1124 | Administrator | Intent | Communication between VMs. | 1125 | | | Example: Request connectivity | 1126 | | | between VMs A,B,and C in Network N1.| 1127 | +---------------------------------------------------+ 1128 | | Cloud | Policy-driven self-configuration and| 1129 | | Resource | and recovery / optimization | 1130 | | Management | Example: Request automatic life | 1131 | | Intent |-cycle management of VM cloud | 1132 | | | resources. | 1133 | +---------------------------------------------------+ 1134 | | Operational | Cloud Administrator requests | 1135 | | Task Intent | execution of any automated task | 1136 | | | other than Cloud Management | 1137 | | | Intents and Cloud Resource | 1138 | | | Management Intents. | 1139 | | | Example: Request upgrade operating | 1140 | | | system to version X on all VMs | 1141 | | | in Network N1. | 1142 | | |Operational statement: an intent to | 1143 | | |update a system might reconfigure the| 1144 | | |system topology (connect to a service| 1145 | | |and to peers), exchange data (update | 1146 | | |the content), and uphold a certain | 1147 | | |QoE level (allocate sufficient | 1148 | | |network resources). The network,thus,| 1149 | | |carries out the necessary | 1150 | | |configuration to best serve such an | 1151 | | |intent; e.g. setting up direct | 1152 | | |connections between terminals, and | 1153 | | |allocating fair shares of router | 1154 | | |queues considering other network | 1155 | | |services. 1156 | +---------------------------------------------------+ 1157 | | Strategy | Cloud Administrator designs models, | 1158 | | Intent | policy intents and workflows to be | 1159 | | | used by other intents. Automate any | 1160 | | | tasks that Administrator often | 1161 | | | performs, in addition to life-cycle | 1162 | | | of Cloud Management Intents and | 1163 | | | Cloud Management Resource Intents. | 1164 | | | Example: In case of emergency, | 1165 | | | automatically migrate all cloud | 1166 | | | resources to DC2. | 1167 +---------------+---------------------------------------------------+ 1168 | Underlay | Underlay | Service created and provided by | 1169 | Network | Network | the Underlay Network Administrator. | 1170 | Administrator | Service | Example: Request underlay service | 1171 | | Intent | between DC1 and DC2 with | 1172 | | | bandwidth B. | 1173 | +---------------------------------------------------+ 1174 | | Underlay | Underlay Network Administrator | 1175 | | Network | requests some DCN-wide underlay | 1176 | | Intent | network configuration or network | 1177 | | | resource configurations. | 1178 | | | Example: Establish and allocate | 1179 | | | DHCP address pool. | 1180 | +---------------------------------------------------+ 1181 | | Operational | Underlay Network Administrator | 1182 | | Task Intent | requests execution of the any | 1183 | | | automated task other than Underlay | 1184 | | | Network Service and Resource | 1185 | | | Intent. | 1186 | | | Example: Request automatic rapid | 1187 | | | detection of device failures and | 1188 | | | pre-alarm correlation. | 1189 | +---------------------------------------------------+ 1190 | | Strategy | Underlay Network Administrator | 1191 | | Intent | designs models, policy intents & | 1192 | | | workflows to be used by other | 1193 | | | intents. Automate any tasks that | 1194 | | | Administrator often performs | 1195 | | | Example: For all traffic flows | 1196 | | | that need NFV service chaining, | 1197 | | | restrict the maximum load of any | 1198 | | | VNF node/container below 50% and | 1199 | | | the maximum load of any network | 1200 | | | link below 70%. | 1201 +-------------------------------------------------------------------+ 1202 | | Cloud | Cloud Management Intent API | 1203 | | Management | provided to the Application | 1204 | | Intent | Developers. | 1205 | | | Example: API to request | 1206 | | | configuration of VMs,or DB Servers | 1207 | Application +---------------------------------------------------+ 1208 | Developer | Cloud | Cloud Resource Management Intent | 1209 | | Resource | API provided to the Application | 1210 | | Management | Developers. | 1211 | | Intent | Example: API to request automatic | 1212 | | | life-cycle management of cloud | 1213 | | | resources. | 1214 | +---------------------------------------------------+ 1215 | | Underlay | Underlay Network Service API | 1216 | | Network | provided to the Application | 1217 | | Service | Developers. | 1218 | | Intent | Example: API to request real-time | 1219 | | | monitoring of device condition. | 1220 | +---------------------------------------------------+ 1221 | | Underlay | Underlay Network Resource API | 1222 | | Network | provided to the Application | 1223 | | Intent | Developers. | 1224 | | | Example: API to request dynamic | 1225 | | | management of IPv4 address pool | 1226 | | | resources. | 1227 | | | | 1228 | +---------------------------------------------------+ 1229 | | Operational | Operational Task Intent API | 1230 | | Task Intent | provided to the trusted | 1231 | | | Application Developer (internal | 1232 | | | DevOps). | 1233 | | | Example: API to request automatic | 1234 | | | rapid detection of device failures | 1235 | | | and pre-alarm correlation | 1236 | | | | 1237 | +---------------------------------------------------+ 1238 | | Strategy | Application Developer designs | 1239 | | Intent | models, policy intents and | 1240 | | | building blocks to be used by | 1241 | | | other intents. This is for the | 1242 | | | trusted internal DCN DevOps. | 1243 | | | Example: API to request load | 1244 | | | balancing thresholds. | 1245 +---------------+-------------+-------------------------------------+ 1247 Categories 1249 The following are the proposed categories: 1250 Intent Scope: C1=Connectivity, C2=Security, C3=Application, 1251 C4=QoS C5=Storage C6=Compute 1252 Network Scope 1253 o Network Domain: DC Network 1254 o DCN Network (DCN Net) Scope: C1=Logical, C2=Physical 1255 o DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical 1256 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non- 1257 technical (without technical feedback), see Section 5.2. 1258 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient 1259 (Short Lived) 1261 Classification Example 1263 This section depicts an example on how the methodology described in 1264 Section 6.1. can be used in order to classify intents introduced in 1265 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. The 1266 PoC considered two intents: slice intents and service chain intents. 1268 In this PoC [POC-IBN], a slice intent expresses a request for a 1269 network slice with two types of components: a set of top layer 1270 virtual functions, and a set of virtual switches and/or routers of 1271 L2/L3 VNFs. A service chain intent expressed a request for a service 1272 operated through a chain of service components running in L4-L7 1273 virtual functions. 1275 Following the intent classification methodology described step-by- 1276 step in Section 6.1. , we identify the following: 1278 1. The Intent Solution is for the Data Center. 1280 2. The Intent User Type is the Cloud Administrator for the slice 1281 intent and service chain intent. 1283 3. The Type of Intent, is a Cloud Management intent, for the slice 1284 and service chain intent. 1286 4. The Intent Scopes are connectivity and application. 1288 5. The Network Scope is a logical, and the resource scope is virtual. 1290 6. The Abstractions are with technical feedback for the slice intent, 1291 and without technical feedback for the service chain intent 1293 7. The life-cycle is persistent. 1295 The following table shows how to represent this information in a 1296 tabular form, where the 'X' in the table refers to the slice and 1297 service chain intent. 1299 +---------+-------------+-----------------+-----+-----+-----+-----+ 1300 |Intent | Intent | Intent | DCN | DCN | ABS | L-C | 1301 |User | Type | Scope | Res | Net | | | 1302 | | +-----------------+-----+-----+-----+-----+ 1303 | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| 1304 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1305 |Customer | Customer | | | | | | | | | | | | | | | 1306 |/Tenants | Intent | | | | | | | | | | | | | | | 1307 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1308 | | Strategy | | | | | | | | | | | | | | | 1309 | | Intent | | | | | | | | | | | | | | | 1310 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1311 | Cloud | Cloud | | | | | | | | | | | | | | | 1312 | Admin | Management |X | |X | | | |X | |X | |X |X |X | | 1313 | | Intent | | | | | | | | | | | | | | | 1314 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1315 | | Cloud | | | | | | | | | | | | | | | 1316 | | Resource | | | | | | | | | | | | | | | 1317 | | Management | | | | | | | | | | | | | | | 1318 | | Intent | | | | | | | | | | | | | | | 1319 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1320 | | Operational | | | | | | | | | | | | | | | 1321 | | Task Intent | | | | | | | | | | | | | | | 1322 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1323 | | Strategy | | | | | | | | | | | | | | | 1324 | | Intent | | | | | | | | | | | | | | | 1325 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1326 |Underlay | Underlay | | | | | | | | | | | | | | | 1327 |Network | Network | | | | | | | | | | | | | | | 1328 |Admin | Service | | | | | | | | | | | | | | | 1329 | | Intent | | | | | | | | | | | | | | | 1330 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1331 | | Underlay | | | | | | | | | | | | | | | 1332 | | Network | | | | | | | | | | | | | | | 1333 | | Resource | | | | | | | | | | | | | | | 1334 | | Intent | | | | | | | | | | | | | | | 1335 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1336 | | Operational | | | | | | | | | | | | | | | 1337 | | Task Intent | | | | | | | | | | | | | | | 1338 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1339 | | Strategy | | | | | | | | | | | | | | | 1340 | | Intent | | | | | | | | | | | | | | | 1341 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1342 |App | Cloud | | | | | | | | | | | | | | | 1343 |Developer| Management | | | | | | | | | | | | | | | 1344 | | Intent | | | | | | | | | | | | | | | 1345 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1346 | | Cloud | | | | | | | | | | | | | | | 1347 | | Resource | | | | | | | | | | | | | | | 1348 | | Management | | | | | | | | | | | | | | | 1349 | | Intent | | | | | | | | | | | | | | | 1350 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1351 | | Underlay | | | | | | | | | | | | | | | 1352 | | Network | | | | | | | | | | | | | | | 1353 | | Service | | | | | | | | | | | | | | | 1354 | | Intent | | | | | | | | | | | | | | | 1355 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1356 | | Underlay | | | | | | | | | | | | | | | 1357 | | Network | | | | | | | | | | | | | | | 1358 | | Resource | | | | | | | | | | | | | | | 1359 | | Intent | | | | | | | | | | | | | | | 1360 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1361 | | Operational | | | | | | | | | | | | | | | 1362 | | Task Intent | | | | | | | | | | | | | | | 1363 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1364 | | Strategy | | | | | | | | | | | | | | | 1365 | | Intent | | | | | | | | | | | | | | | 1366 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1368 6.5. Intent Classification for Enterprise Solution 1370 Users and Intent Types 1372 The following table describes the Intent Users in Enterprise 1373 Solutions and their Intent Types. 1375 +--------------+-------------+-------------------------------------+ 1376 | Intent User | Intent Type | Intent Type Description | 1377 +--------------+---------------------------------------------------+ 1378 | End-User | Customer | Enterprise End-User Self-Service or | 1379 | | Service | Applications, Enterprise may have | 1380 | | Intent | multiple types of End-Users. | 1381 | | | Example: Request access to VPN | 1382 | | | service. | 1383 | | | Request video conference between | 1384 | | | user A and B. | 1385 | +---------------------------------------------------+ 1386 | | Strategy | This includes models and policy | 1387 | | Intent | intents designed by End-Users to be | 1388 | | | used by End-User Intents and their | 1389 | | | Applications. | 1390 | | | Example: Create a video conference | 1391 | | | type for a weekly meeting. | 1392 +------------------------------------------------------------------+ 1393 |Administrator | Network | Service provided by the | 1394 | (internal or | Service | Administrator to the End-Users | 1395 | MSP) | Intent | and their Applications. | 1396 | | | Example: For any user of application| 1397 | | | X, the arrival time of hologram | 1398 | | | objects of all the remote tele- | 1399 | | | presenters should be synchronised | 1400 | | | within 50ms to reach the destination| 1401 | | | viewer for each conversation session| 1402 | | | Create management VPN connectivity | 1403 | | | for type of service A. | 1404 | | | Operational statement: The job of | 1405 | | | the network layer is to ensure that | 1406 | | | the delay is between 50-70ms through| 1407 | | | the routing algorithm. At the same | 1408 | | | time,the node resources need to meet| 1409 | | | the bandwidth requirements of 4K | 1410 | | | video conferences. | 1411 +------------------------------------------------------------------+ 1412 | | Network | Administrator requires network wide | 1413 | | Intent | configuration (e.g. underlay, | 1414 | | | campus) or resource configuration | 1415 | | | (switches, routers, policies). | 1416 | | | Example: Configure switches in | 1417 | | | campus network 1 to prioritise | 1418 | | | traffic of type A. | 1419 | | | Configure Youtube as business | 1420 | | | non-relevant. | 1421 | +---------------------------------------------------+ 1422 | | Operational | Administrator requests execution of | 1423 | | Task Intent | any automated task other than | 1424 | | | Network Service Intents and Network | 1425 | | | Intents. | 1426 | | | Example: Request network security | 1427 | | | automated tasks such as Web | 1428 | | | filtering and DDOS cloud protection.| 1429 | +---------------------------------------------------+ 1430 | | Strategy | Administrator designs models, policy| 1431 | | Intent | intents and workflows to be used by | 1432 | | | other intents. Automate any tasks | 1433 | | | that Administrator often performs. | 1434 | | | Example: In case of emergency, | 1435 | | | automatically shift all traffic of | 1436 | | | type A through network N. | 1437 | | | | 1438 +--------------+-------------+-------------------------------------+ 1439 | Application | End-User | End-User Service / Application | 1440 | Developer | Intent | Intent API provided to the | 1441 | | | Application Developers. | 1442 | | | Example: API for request to open a | 1443 | | | VPN service. | 1444 | +---------------------------------------------------+ 1445 | | Network | Network Service API Provided to | 1446 | | Service | Application Developers. | 1447 | | Intent | Example: API for request network | 1448 | | | bandwidth and latency for | 1449 | | | hosting video conference. | 1450 | +---------------------------------------------------+ 1451 | | Network | Network API Provided to Application | 1452 | | Intent | Developers. | 1453 | | | Example: API for request of network | 1454 | | | devices configuration. | 1455 | +---------------------------------------------------+ 1456 | | Operational | Operational Task Intent API provided| 1457 | | Task Intent | to the trusted Application Developer| 1458 | | | (internal DevOps). | 1459 | | | Example: API for requesting | 1460 | | | automatic monitoring and | 1461 | | | interception for network security | 1462 | +---------------------------------------------------+ 1463 | | Strategy | Application Developer designs | 1464 | | Intent | models, policy intents and building | 1465 | | | blocks to be used by other intents. | 1466 | | | This is for the trusted internal | 1467 | | | DevOps. | 1468 | | | Example: API for strategy intent in | 1469 | | | case of emergencies. | 1470 | | | | 1471 +--------------+-------------+-------------------------------------+ 1473 Categories 1475 The following are the proposed categories: 1476 Intent Scope: C1=Connectivity, C2=Security, C3=Application, 1477 C4=QoS 1478 Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN 1479 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non- 1480 technical (without technical feedback), see Section 5.2. 1481 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient 1482 (Short Lived) 1484 The following is the Intent Classification Table Example for 1485 Enterprise Solutions. 1487 +---------------+-------------+-----------+--------+-----+-----+ 1488 | Intent User | Intent Type | Intent | Net | ABS | L-C | 1489 | | | Scope | | | | 1490 | | +-----------+--------+-----+-----+ 1491 | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| 1492 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1493 | End-User | End-User | | | | | | | | | | | | 1494 | | Intent | | | | | | | | | | | | 1495 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1496 | | Strategy | | | | | | | | | | | | 1497 | | Intent | | | | | | | | | | | | 1498 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1499 | Enterprise | Network | | | | | | | | | | | | 1500 | Administrator | Intent | | | | | | | | | | | | 1501 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1502 | | Strategy | | | | | | | | | | | | 1503 | | Intent | | | | | | | | | | | | 1504 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1505 | Application | End-User | | | | | | | | | | | | 1506 | Developer | Intent | | | | | | | | | | | | 1507 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1508 | | Network | | | | | | | | | | | | 1509 | | Service | | | | | | | | | | | | 1510 | | Intent | | | | | | | | | | | | 1511 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1512 | | Network | | | | | | | | | | | | 1513 | | Intent | | | | | | | | | | | | 1514 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1515 | | Operational | | | | | | | | | | | | 1516 | | Task | | | | | | | | | | | | 1517 | | Intent | | | | | | | | | | | | 1518 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1519 | | Strategy | | | | | | | | | | | | 1520 | | Intent | | | | | | | | | | | | 1521 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1523 7. Security Considerations 1525 This document does not have any Security Considerations. 1527 8. IANA Considerations 1529 This document has no actions for IANA. 1531 9. Contributors 1533 The following people all contributed to creating this document, 1534 listed in alphabetical order: 1536 Ying Chen, China Unicom 1537 Richard Meade, Huawei 1538 John Strassner, Huawei 1539 Xueyuan Sun, China Telecom 1540 Weiping Xu, Huawei 1542 10. Acknowledgments 1544 This document has benefited from reviews, suggestions, comments and 1545 proposed text provided by the following members, listed in 1546 alphabetical order: Brian E Carpenter, Juergen Schoenwaelder, Laurent 1547 Ciavaglia, Xiaolin Song, Alexander Clemm, Daniel King, Mehdi Bezahaf, 1548 Yehia Elkhatib, Pedro Andres Aranda Gutierrez. 1550 We thank to Walter Cerroni, Barbara Martini, Molka Gharbaoui for 1551 contributing with their 'A multi-level approach to IBN ' PoC 1552 demonstration a first attempt to adopt the intent classification 1553 methodology. 1555 11. References 1557 11.1. Normative References 1559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1560 Requirement Levels", BCP 14, RFC 2119, March 1997. 1562 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1563 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1564 Networking: Definitions and Design Goals", RFC 7575, June 1565 2015. 1567 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1568 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1569 Management Framework for the Simplified Use of Policy 1570 Abstractions (SUPA)", March 2018. 1572 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 1573 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, 1574 M., Perry, J., Waldbusser, S., "Terminology for Intent- 1575 driven Management", RFC 3198, November 2001. 1577 11.2. Informative References 1579 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1580 Network Configuration Protocol (NETCONF)", RFC 6020, 1581 October 2010. 1583 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 1584 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 1585 Optimization (ALTO) Protocol", September 2014. 1587 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017, 1588 . 1591 [ONF] ONF, "Intent Definition Principles", 2017, 1592 . 1596 [ONOS] ONOS, "ONOS Intent Framework", 2017, 1597 . 1600 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions", 1601 2017, . 1604 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun, 1605 "Autonomic IPv6 Edge Prefix Management in Large-scale 1606 Networks", draft-ietf-anima-prefix-management-07 (work in 1607 progress), December 2017. 1609 [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of 1610 Autonomous Networks: Empowering Digital Transformation For 1611 the Telecoms Industry, inform.tmforum.org, 15 May, 2019. 1613 [CLEMM] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent- 1614 Based Networking - Concepts and Overview", Work in 1615 Progress, draft-clemm-nmrg-dist-intent-03, June 2020, 1616 https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts- 1617 definitions-02 1619 [POC-IBN] Walter Cerroni, Molka Gharbaoui, Barbara Martini, Davide 1620 Borsatti, "A multi-level approach to IBN", July 2020, 1621 https://www.ietf.org/proceedings/108/slides/slides-108- 1622 nmrg-ietf-108-hackathon-report-a-multi-level-approach-to- 1623 ibn-02 1625 Authors' Addresses 1627 Chen Li 1628 China Telecom 1629 No.118 Xizhimennei street, Xicheng District 1630 Beijing 100035 1631 P.R. China 1632 Email: lichen.bri@chinatelecom.cn 1634 Olga Havel 1635 Huawei Technologies 1636 Ireland 1637 Email: olga.havel@huawei.com 1639 Adriana Olariu 1640 Huawei Technologies 1641 Ireland 1642 Email: adriana.olariu@huawei.com 1644 Will(Shucheng) Liu 1645 Huawei Technologies 1646 P.R. China 1647 Email: liushucheng@huawei.com 1649 Pedro Martinez-Julia 1650 NICT 1651 Japan 1652 Email: pedro@nict.go.jp 1654 Jeferson Campos Nobre 1655 Federal University of Rio Grande do Sul 1656 Porto Alegre 1657 Brazil 1658 Email: jcnobre@inf.ufrgs.br 1660 Diego R. Lopez 1661 Telefonica I+D 1662 Don Ramon de la Cruz, 82 1663 Madrid 28006 1664 Spain 1665 Email: diego.r.lopez@telefonica.com