idnits 2.17.00 (12 Aug 2021) /tmp/idnits44229/draft-irtf-nmrg-ibn-intent-classification-06.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 document date (February 22, 2022) is 81 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Bezahaf19' is mentioned on line 139, but not defined == Missing Reference: 'IBN-POC' is mentioned on line 165, but not defined == Unused Reference: 'RFC2119' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: 'RFC8328' is defined on line 1744, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 1749, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 1757, but no explicit reference was found in the text == Unused Reference: 'ANIMA' is defined on line 1761, but no explicit reference was found in the text == Unused Reference: 'SUPA' is defined on line 1765, but no explicit reference was found in the text == Unused Reference: 'ANIMA-Prefix' is defined on line 1769, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-05 == Outdated reference: draft-ietf-anima-prefix-management has been published as RFC 8992 Summary: 0 errors (**), 0 flaws (~~), 13 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: August 2022 A. Olariu 5 Huawei Technologies 6 P. Martinez-Julia 7 NICT 8 J. Nobre 9 UFRGS 10 D. Lopez 11 Telefonica, I+D 12 February 22, 2022 14 Intent Classification 15 draft-irtf-nmrg-ibn-intent-classification-06 17 Abstract 19 Intent is an abstract, high-level policy used to operate the network. 20 Intent-based management system includes an interface for users to 21 input requests and an engine to translate the intents into the 22 network configuration and manage their life-cycle. 24 This document discusses mostly the concept of network intents, but 25 other types of intents are also being considered. Specifically, it 26 highlights stakeholder perspectives of intent, methods to classify 27 and encode intent, the associated intent taxonomy, and defines 28 relevant intent terms where necessary. This document provides a 29 foundation for intent related research and facilitates solution 30 development. 32 This document is a product of the IRTF Network Management Research 33 Group (NMRG and is not issued by the IETF and is not an IETF 34 standard. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 22, 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction...................................................4 71 1.1. Research activities..........................................4 72 1.2. Standards and open source activities.........................5 73 1.3. Scope........................................................6 74 2. Acronyms.......................................................7 75 3. Definitions....................................................8 76 4. Abstract Intent Requirements...................................8 77 4.1. What is Intent?..............................................8 78 4.2. Intent Solutions and Intent Users............................9 79 4.3. Benefits of Intents for Different Stakeholders..............11 80 4.4. Intent Types that need to be supported......................12 81 5. Functional Characteristics and Behaviour......................13 82 5.1. Abstracting Intent Operation................................13 83 5.2. Intent User Types...........................................14 84 5.3. Intent Scope................................................15 85 5.4. Intent Network Scope........................................15 86 5.5. Intent Abstraction..........................................16 87 5.6. Intent Life-cycle...........................................16 88 5.7. Autonomous Driving Levels...................................16 89 6. Intent Classification.........................................17 90 6.1. Intent Classification Methodology...........................18 91 6.2. Intent Taxonomy.............................................21 92 6.3. Intent Classification for Carrier Solution..................23 93 6.3.1. Intent Users and Intent Types.............................23 94 6.3.2. Intent Categories.........................................27 95 6.3.3. Intent Classification Example.............................27 96 6.4. Intent Classification for Data Center Network Solutions.....31 97 6.4.1. Intent Users and Intent Types.............................31 98 6.4.2. Intent Categories.........................................35 99 6.4.3. Intent Classification Example.............................35 100 6.5. Intent Classification for Enterprise Solution...............39 101 6.5.1. Intent Users and Intent Types.............................39 102 6.5.2. Intent Categories.........................................41 103 7. Conclusions...................................................43 104 8. Security Considerations.......................................43 105 9. IANA Considerations...........................................43 106 10. Contributors.................................................44 107 11. Acknowledgments..............................................44 108 12. Informative References.......................................44 110 1. Introduction 112 The vision of intent-based networks has attracted a lot of attention, 113 as it promises to simplify the management of networks by human 114 operators. This is done by simply specifying what should happen on 115 the network, without giving any instructions on how to do it. This 116 promise led many researcher-led activities and telecom companies to 117 start researching this new vision, and many Standards Development 118 Organization (SDOs) to propose different intent frameworks. 120 This draft proposes an intent classification methodology and an 121 intent taxonomy. The scope of these proposals is to ensure a common 122 understanding in the research community in terms of what are the 123 intent users, intent types, or intent solutions, etc. for specific 124 scenarios that are being considered. 126 The document represents the consensus of the RG. During the 127 document's lifecycle it received many positive expressions of support 128 and detailed reviews beyond the authors. Only in the last call period 129 it received more than 12 positive expressions of support and more 130 than 5 detailed reviews. It is published for informational purposes. 132 1.1. Research activities 134 Intent-based networking is an active research topic which spans 135 across different areas that could benefit from an intent 136 classification and taxonomy. 138 One such area is intent expression and recognition ([Bezahaf21], 139 [Bezahaf19]), NILE [Jacobs18]). The use of a common classification 140 can provide consistency in the understanding of the various forms of 141 intent expressions being proposed and investigated. 143 Another area where this intent classification could contribute is the 144 orchestration of cognitive autonomous RANs [Banerjee21] where intents 145 are classified based on their content. 147 The work carried in intent network verification [Tian19] where the 148 authors are proposing new intent language is another candidate where 149 intent classification could be used advantageously. 151 Furthermore, this draft is proving itself already extremely relevant 152 to the research community as it has been used as the basis for 153 proposing self-generated Intent-based systems [Bezhaf19], for 154 advancing IBN-based VNF placement solutions that rely on defining 155 user intent profiles corresponding to abstract network services 156 [Leivadeas21], for improving existing solutions in provisioning 157 intent-based networks, and proposing new approaches to service 158 management [Davoli21], or even for defining grammars for users to 159 specify the high-level requirements for blockchain selection in the 160 form of intent [Padovan20]. As well, the draft has been mentioned in 161 surveys addressing the topic of intelligent intent-based autonomous 162 networks [Mehmood21], [Szilagyi21]. 164 This document describes as well an example on how this proposal has 165 been successfully applied in an academic environment [IBN-POC] by 166 researchers in the area of SDN/NFV for defining the scope of their 167 project. The specific problem addressed by researches is how to 168 apply intent concepts at different levels that correspond to 169 different stakeholders. 171 IEEE Communications Society Technical Committee on Network Operation 172 and Management (IEEE-CNOM), IRTF-NMRG and IFIP WG6.6 have developed a 173 taxonomy for network and service management [IFIP-NSM] that is used 174 by the research community in network management and operations to 175 structure the research area through a well-defined set of keywords 176 and to improve quality of reviews in submissions to journals, 177 conferences and workshops. The proposed intent taxonomy may be 178 contributed as an extension to this taxonomy for intent driven 179 management. 181 1.2. Standards and open source activities 183 Several SDOs and open source projects, such as Internet Research Task 184 Force (IRTF)/ Network Management Research Group (NMRG), Open 185 Networking Foundation (ONF) [ONF] /Open Network Operating System 186 (ONOS) [ONOS], European Telecommunications Standards Institute 187 (ETSI)/Experiential Networked Intelligence (ENI), TMF with its 188 Autonomous Networks, have proposed intents for defining a set of 189 network operations to execute in a declarative manner. 191 More recently, the IRTF NMRG is working on the Intent-based 192 Networking - Concepts and Definitions document, [CLEMM]. This 193 document clarifies the concept of "Intent" and provides an overview 194 of the functionality that is associated with it. The goal is to 195 contribute towards a common and shared understanding of terms, 196 concepts, and functionality that can be used as the foundation to 197 guide further definition of associated research and engineering 198 problems and their solutions. 200 The present document, together with [CLEMM], aims to become the 201 foundation for future intent-related topic discussions regarding the 202 NMRG. 204 The SDOs usually came up with their own way of specifying an intent, 205 and with their own understanding of what an intent is. Besides that, 206 each SDO defines a set of terms and level of abstraction, its 207 intended intent users, and the applications and usage scenarios. 209 However, most intent approaches proposed by SDOs share the same 210 following features: 212 o It must be declarative in nature, meaning that an intent user 213 specifies the goal on the network without specifying how to achieve 214 that goal. 216 o It must be vendor agnostic, in the sense that it abstracts the 217 network capabilities, or the network infrastructure from the intent 218 user, and it can be ported across different platforms. 220 o It must provide an easy-to-use interface, which simplifies the 221 intent users' interaction with the intent system through the usage 222 of familiar terminology or concepts. 224 It should be able to detect and resolve intent conflicts, which 225 include, for example, static (compile-time) conflicts and dynamic 226 (run-time) conflicts. 228 1.3. Scope 230 This document mostly addresses intents in the context of network 231 intents, however other types of intents are not excluded, as 232 presented in section 4.4. and section 6.2. . 234 It is impossible to fully differentiate intents only by the common 235 characteristics followed by concepts, terms and intentions. This 236 document clarifies what an intent represents for different 237 stakeholders through a classification on various dimensions, such as 238 solutions, intent users, and intent types. This classification 239 ensures common understanding among all participants and is used to 240 determine the scope and priority of individual projects, proof-of- 241 concept (PoCs), research initiatives, or open source projects. 243 The scope of intent classification in this document includes 244 solutions, intent users and intent types, and the initial 245 classification table is made according to this scope. The 246 methodology presented can be used to update the classification 247 tables by adding or removing different solutions, intent users, or 248 intent types to cater for future scenarios, applications or domains. 250 2. Acronyms 252 AI: Artificial Intelligence 254 CE: Customer Equipment 256 CFS: Customer Facing Service 258 CLI: Command Line Interface 260 DB: Database 262 DC: Data Center 264 ECA: Event-Condition-Action 266 GBP: Group-Based Policy 268 GPU: Graphics Processing Unit 270 IBN: Intent Based Network 272 NFV: Network Function Virtualization 274 O&M: Operations & Maintenance 276 ONF: Open Networking Foundation 278 ONOS: Open Network Operating System 280 PNF: Physical Network Function 282 QoE: Quality of Experience 284 RFS: Resource Facing Service 286 SDO: Standards Development Organization 288 SD-WAN: Software-Defined Wide-Area Network 289 SLA: Service Level Agreement 291 SUPA: Simplified Use of Policy Abstractions 293 VM: Virtual Machine 295 VNF: Virtual Network Function 297 3. Definitions 299 A common and shared understanding of terms and definitions related 300 to IBN is provided in [CLEMM], as follows: 302 o Intent: A set of operational goals (that a network should meet) 303 and outcomes (that a network is supposed to deliver), defined 304 in a declarative manner without specifying how to achieve or 305 implement them. 307 o Intent-Based Network: A network that can be managed using 308 intent. 310 o Policy: A set of rules that governs the choices in behaviour of 311 a system. 313 o Intent User: A user that defines and issues the intent request 314 to the intent-based management system. 316 Other definitions relevant to this draft, such as intent scope, 317 intent network scope, intent abstraction, intent abstraction, and 318 intent lifecycle are available in section 5. 320 4. Abstract Intent Requirements 322 In order to understand the different intent requirements that would 323 drive intent classification, we first need to understand what intent 324 means for different intent users. 326 4.1. What is Intent? 328 The term Intent has become very widely used in the industry for 329 different purposes, sometimes it is not even in agreement with SDO 330 shared principles mentioned in the Introduction section.[CLEMM] draft 331 brings clarification with relation to what an intent is and how it 332 differentiates from policies and services. 334 Different stakeholders have different perspective of the network and 335 therefore have different intent requirements. Their intent is 336 sometimes technical, non-technical, abstract or technology specific. 337 Therefore, it is important to start a discussion in the industry and 338 academia communities about what intent is for different solutions and 339 intent users. It is also imperative to try to propose some intent 340 categories/ classifications that could be understood by a wider 341 audience. This would help us define intent interfaces, domain- 342 specific languages, and models. 344 4.2. Intent Solutions and Intent Users 346 Intent types are defined by all aspects that are required to profile 347 different requirements to easily distinguish among them. However, in 348 order to facilitate a clustered classification, we can focus on two 349 aspects, the solution and intent user. They can be considered as the 350 main keys to classify intents, as we can easily group requirements by 351 solution and intent user. 353 On the one hand, different solutions and intent users have different 354 requirements, expectations and priorities for intent-based 355 networking. Therefore, intent users require different intent types, 356 depending on their context, since they participate in different use 357 cases. For instance, some intent users are more technical and require 358 intents that expose more technical information. Other intent users do 359 not have knowledge of the network infrastructure and require intents 360 that shield them from different networking concepts and technologies. 362 The following are the solutions and intent users that intent-based 363 networking needs to support: 365 +--------------------+------------------------------------+ 366 | Solutions | Intent Users | 367 +--------------------+------------------------------------+ 368 | Carrier Networks | Network Operator | 369 | | Service Designers/App Developer | 370 | | Service Operators | 371 | | Customers/Subscribers | 372 +--------------------+------------------------------------+ 373 | DC Networks | Cloud Administrator | 374 | | Underlay Network Administrator | 375 | | Application Developers | 376 | | Customer/Tenants | 377 +--------------------+------------------------------------+ 378 | Enterprise Networks| Enterprise Administrator | 379 | | Application Developers | 380 | | End-Users | 381 +--------------------+------------------------------------+ 382 Table 1 - Intent Solutions and Intent Users 384 These intent solutions and intent users represent a starting point 385 for the classification and are expendable through the methodology 386 presented in section 6.1. . 388 o For carrier networks scenario, for example, if a 389 customer/subscriber wants to watch high-definition video, then the 390 intent is to convert the video image to 1080p rate. 392 o For DC networks scenario, administrators have their own clear 393 network intent such as load balancing. For all traffic flows that 394 need NFV service chaining, restrict the maximum load of any VNF 395 node/container below 50% and the maximum load of any network link 396 below 70%. 398 o For enterprise networks scenario, when hosting a video conference 399 multiple remote accesses are required. An example of the intent 400 from the network administrator is: for any end-user of this 401 application, the arrival time of hologram objects of all the 402 remote tele-presenters should be synchronised within 50ms to reach 403 the destination viewer for each conversation session. 405 4.3. Benefits of Intents for Different Stakeholders 407 Current network APIs and CLIs are too complex because they are highly 408 integrated with the low level concepts exposed by networks. 409 Customers, application developers and end-users must not be required 410 to set IP addresses, VLANs, subnets, ports, while operators may still 411 want to have more technical and network visibility. All stakeholders 412 would benefit from the simpler interfaces, like: 414 o Request gold VPN service between my sites A, B and C 416 o Provide CE redundancy for the customer sites 418 o Add access rules to the network service 420 Operators and administrators manually troubleshoot and fix their 421 networks and services. They instead want to: 423 o simplify and automate network operations 425 o simplify definitions of network services 427 o provide simple customer APIs for value added services (operators) 429 o be informed if the network or service is not behaving as requested 431 o enable automatic optimization and correction for selected 432 scenarios 434 o have systems that learn from historic information and behaviour 436 Currently, intent users cannot build their own services and policies 437 without becoming technical experts and performing manual maintenance 438 actions. They instead want to be able to: 440 o build their own network services with their own policies via 441 simple interfaces, without becoming networking experts 443 o have their network services up and running based on intent and 444 automation only, without any manual actions or maintenance 446 4.4. Intent Types that need to be supported 448 Next to the intent solutions and intent users, another way to 449 categorize the intent is through the intent types. The following 450 intent types and subtypes need to be supported, in order to address 451 the requirements from different solutions and intent users: 453 o Customer service intent 455 o for customer self-service with SLA 457 o for service operator orders 459 o Network and underlay network service intent 461 o for service operator orders 463 o for intent driven network configuration, verification, 464 correction and optimization 466 o for intent created and provided by the underlay network 467 administrator 469 o Network and underlay network intent 471 o for network configuration 473 o for automated lifecycle management of network configurations 475 o for network resources (switches, routers, routing, policies, 476 underlay) 478 o Cloud management intent 480 o for DC configuration, VMs, DB servers, APP servers 482 o for communication between VMs 484 o Cloud resource management intent 486 o for cloud resource life-cycle management (policy driven self- 487 configuration and auto-scaling and recovery/optimization) 489 o Strategy intent 491 o for security, QoS, application policies, traffic steering, etc. 493 o for configuring and monitoring policies, alarms generation for 494 non-compliance, auto-recovery 496 o for design models and policies for network and network service 497 design 499 o for design workflows, models and policies for operational task 500 intents 502 o Operational task intents 504 o for network migration 506 o for device replacements 508 o for network software upgrades 510 o for automating any other tasks that operators/administrator 511 often perform 513 It is important to mention there all of the previously mentioned 514 types and subtypes may affect other intents. For example, operational 515 task intent can modify many other intents. The task itself is short- 516 lived, but the modification of other intents has an impact on their 517 life-cycle, so those changes must continue to be continuously 518 monitored and self-corrected/self-optimized. 520 5. Functional Characteristics and Behaviour 522 Intent can be used to operate immediately on a target (much like 523 issuing a command), or whenever it is appropriate (e.g., in response 524 to an event). In either case, intent has a number of behaviours that 525 serve to further organize its purpose, as described by the following 526 subsections. 528 5.1. Abstracting Intent Operation 530 The modelling of intents can be abstracted using the following 531 three-tuple: 533 {Context, Capabilities, Constraints} 535 o Context grounds the intent, and determines if it is relevant or 536 not for the current situation. Thus, context selects intents based 537 on applicability. 539 o Capabilities describe the functionality that the intent can 540 perform. Capabilities take different forms, depending on the 541 expressivity of the intent as well as the programming paradigm(s) 542 used. 544 o Constraints define any restrictions on the capabilities to be used 545 for that particular context. 547 Metadata can be attached via strategy templates to each of the 548 elements of the three-tuple, and may be used to describe how the 549 intent should be used and how it operates, as well as prescribe any 550 operational dependencies that must be taken into account. 552 Although different intent categories share the same abstracted intent 553 model, each category will have its own specific context, capabilities 554 and constraints. 556 5.2. Intent User Types 558 Expanding on the introduction in section 4.2. , intent user types 559 represent the intent users that define and issue the intent request. 560 Depending on the intent solutions, there are specific intent users. 561 Examples of intent users are customers, network operators, service 562 operators, enterprise administrators, cloud administrators, and 563 underlay network administrators, or application developers. 565 o Customers and end-users do not necessarily know the functional and 566 operational details of the network that they are using. 567 Furthermore, they lack skills to understand such details; in fact, 568 such knowledge is typically not relevant to their job. In 569 addition, the network may not expose these details to its intent 570 users. This class of intent users focuses on the applications that 571 they run, and uses services offered by the network. Hence, they 572 want to specify policies that provide consistent behaviour 573 according to their business needs. They do not have to worry about 574 how the intents are deployed onto the underlying network, and 575 especially, whether the intents need to be translated to different 576 forms to enable network elements to understand them. 578 o Application developers work in a set of abstractions defined by 579 their application and programming environment(s). For example, 580 many application developers think in terms of objects (e.g., a 581 VPN). While this makes sense to the application developer, most 582 network devices do not have a VPN object per se; rather, the VPN 583 is formed through a set of configuration statements for that 584 device in concert with configuration statements for the other 585 devices that together make up the VPN. Hence, the view of 586 application developers matches the services provided by the 587 network, but may not directly correspond to other views of other 588 intent users. 590 o Network operators may have the knowledge of the underlying 591 network. However, they may not understand the details of the 592 applications and services of customers. 594 5.3. Intent Scope 596 Intents are used to manage the behaviour of the networks they are 597 applied to and all intents are applied within a specific scope, such 598 as: 600 o Connectivity scope, if the intent creates or modifies a 601 connection. 602 o Security/privacy scope, if the intent specifies the security 603 characteristics of the network, customers, or end-users. 604 o Application scope, when the intent specifies the applications to 605 be affected by the intent request. 606 o QoS scope, when the intent specifies the QoS characteristics of 607 the network. 609 These intent scopes are expendable through the methodology presented 610 in section 6.1. . 612 5.4. Intent Network Scope 614 Regardless on the intent user type, their intent request is affecting 615 the network, or network components, which are representing the intent 616 targets. 618 Thus, intent network scope, or policy target as known in the area of 619 declarative policy, can represent VNFs or PNFs, physical network 620 elements, campus networks, SD-WAN networks, radio access networks, 621 cloud edge, cloud core, branch, etc. 623 5.5. Intent Abstraction 625 Intent can be classified by whether it is necessary to feedback 626 technical network information or non-technical information to the 627 intent user after the intent is executed. As well, intent abstraction 628 covers the level of technical details in the intent itself. 630 o For non-technical intent users, they do not care how the intent is 631 executed, or the details of the network. As a result, they do not 632 need to know the configuration information of the underlying 633 network. They only focus on whether the intent execution result 634 achieves the goal, and the execution effect such as the quality of 635 completion and the length of execution. In this scenario, we refer 636 to an abstraction without technical feedback. 638 o For administrators, such as network administrators, they perform 639 intents, such as allocating network resources, selecting 640 transmission paths, handling network failures, etc. They require 641 multiple feedback indicators for network resource conditions, 642 congestion conditions, fault conditions, etc. after execution. In 643 this case, we refer to an abstraction with technical feedback. 645 As per intent definition provided in [CLEMM], lower-level intents are 646 not considered to qualify as intents. However, we kept this 647 classification to identify any PoCs/Demos/Use Cases that still either 648 require or implement lower level of abstraction for intents. 650 5.6. Intent Life-cycle 652 Intents can be classified into transient and persistent intents: 654 o If the intent is transient, it has no life-cycle management. As 655 soon as the specified operation is successfully carried out, the 656 intent is finished, and can no longer affect the target object. 658 o If the intent is persistent, it has life-cycle management. Once 659 the intent is successfully activated and deployed, the system will 660 keep all relevant intents active until they are deactivated or 661 removed. 663 5.7. Autonomous Driving Levels 665 In different phases of the autonomous driving network [TMF-auto], the 666 intents are different. Depending on the Autonomous Network Level of 667 the overall solution, we may have different intent requirements and 668 types. For example, at lower level the customer intent is 669 automatically converted to configuration policies only, while at the 670 higher levels the customer intent is covering the full life cycle, it 671 is converted to both configuration and monitoring policies and is 672 self-assured using AI. 674 A typical example of autonomous driving network level 0 to 5 are 675 listed as below. 677 o Level 0 - Traditional manual network: O&M personnel manually 678 control the network and obtain network alarms and logs. - No 679 intent 681 o Level 1 - Partially automated network: Automated scripts are used 682 to automate service provisioning, network deployment, and 683 maintenance. Shallow perception of network status and decision 684 making suggestions of machine; - No intent 686 o Level 2 - Automated network: Automation of most service 687 provisioning, network deployment, and maintenance of a 688 comprehensive perception of network status and local machine 689 decision making; - simple intent on service provisioning 691 o Level 3 - Self-optimization network: Deep awareness of network 692 status and automatic network control, meeting requirements of 693 intent users of the network. - Intent based on network status 694 cognition 696 o Level 4 - Partial autonomous network: In a limited environment, 697 people do not need to participate in decision-making and networks 698 can adjust itself. - Intent based on limited AI 700 o Level 5 - Autonomous network: In different network environments 701 and network conditions, the network can automatically adapt to and 702 adjust to meet people's intentions. - Intent based on AI 704 6. Intent Classification 706 This section proposes an intent classification approach that may help 707 to classify mainstream intent related demos/tools. 709 The three classifications in this document have been proposed from 710 scratch, following the methodology presented, through three 711 iterations: one for carrier network intent solution, one for DC 712 intent solution, and one for enterprise intent solution. For each 713 intent solution, we identified the specific intent users and intent 714 types. Then, we further identified intent scope, network scope, 715 abstractions, and life-cycle requirements. 717 These classifications and the generated tables can be easily 718 extended. For example, for the DC intent solution, a new category is 719 identified, i.e. resource scope, and the classification table has 720 been extended accordingly. 722 In the future, as new scenarios, applications, and domains are 723 emerging, new classifications and taxonomies can be identified, 724 following the proposed methodology. 726 The intent classifications have been documented to the best of our 727 knowledge at this point in time. Additional classifications will most 728 probably see the light in the future. 730 The output of the intent classification is the intent taxonomy 731 introduced in the next sections. 733 Thus, this section first introduces the proposed intent 734 classification methodology, followed by consolidated intent taxonomy 735 for three intent solutions, and then by concrete examples of intent 736 classifications for three different intent solutions (e.g. carrier 737 network, data center, and enterprise) that were derived using the 738 proposed methodology and then can be filled in for PoCs, demos, 739 research projects or future drafts. 741 6.1. Intent Classification Methodology 743 This section describes the methodology used to derive the initial 744 classification proposed in the draft. The proposed methodology can be 745 used to create new intent classifications from scratch, by analysing 746 the solution knowledge. As well, the methodology can be used to 747 update existing classification tables by adding or removing different 748 solutions, intent users or intent types in order to cater for future 749 scenarios, applications or domains. 751 +------------------------------------------+ 752 |Solution Knowledge (requirements, | 753 |use cases, technologies, network, intent | 754 |users, intent requirements) | 755 +----------------+-------------------------+ 756 | Input Rx=Read 757 | Ux=Update (Add/Remove) 758 +--------V--------+ 759 |1.Identify Intent| 760 | Solution +------------+ 761 | | | 762 +---------^-+-----+ | 763 R1 | | U1 | 764 +---------------+ U8 | | R2 +--v----------------+ 765 |8.Identify New +---------+ | | +-----------> 2.Identify | 766 | Categories | R8 | | | | U2 | Intent | 767 | <-------- | | | | +---------+ User Types | 768 +--------^------+ | | | | | | +-------|-----------+ 769 | | | | | | | | 770 | ++-+-v-v---+-v-+ | 771 +--------+------+ U7 | | R3 +------v------------+ 772 |7.Identify +------> Intent +--------> 3.Identify | 773 | Life-cycle | R7 |Classification| U3 | Type | 774 | Requirements <------+ <--------+ of Intent | 775 +--------^------+ +^--^-+--^-+---+ +------|------------+ 776 | || | | | | | 777 | || | | | | | 778 +--------+-----+ || | | | | R4 +-------v-----------+ 779 |6.Identify | U6 || | | | +-----------> 4.Identify | 780 | Abstractions+---------| | | | U4 | Intent | 781 | <---------+ | | +-------------+ Scope | 782 +-------^------+ R6 | | +-------+-----------+ 783 | | | | 784 | U5 | |R5 | 785 | +-------+-v--------+ | 786 | |5.Identify Network| | 787 +----------+ Scope <---------------+ 788 +------------------+ 789 Figure 1 - Intent Classification Methodology 791 The intent classification workflow starts from the solution 792 knowledge, which can provide information on requirements, use cases, 793 technologies used, network properties, intent users that define and 794 issue the intent request, and requirements. The following, defines 795 the steps to classify an intent: 797 1. The information provided in the solution knowledge is given as 798 input for identifying the intent solution (e.g. carrier, enterprise, 799 and data center). Intent solutions are reviewed against the existing 800 classification and they can either be used if present or added if not 801 there or removed if not needed, from the classification. (R1-U1). 803 2. Identify the intent user types (e.g. customer, network operators, 804 service operators, etc.), review existing intent classification and 805 use the intent user type if present, add if it is not there or remove 806 it if not needed (R2-U2). 808 3. Identify the types of intent (e.g. network intent, customer 809 service intent) and then review existing classification and 810 use/add/remove the intent type (R3-U3). 812 4. Identify the intent scopes (e.g. connectivity, application) based 813 on the solution knowledge and then review existing classification and 814 use/add/remove the identified intent scope (R4-U4). 816 5. Identify the network scopes (e.g. campus, radio access) and then 817 review existing classification and either use it or add/remove the 818 identified network scope (R5-U5). 820 6. Identify the abstractions (e.g. technical, non-technical) and 821 then review existing classification and use/add/remove the 822 abstractions (R6-U6). 824 7. Identify the life-cycle requirements (e.g. persistent, transient) 825 and then review existing classification and use/add/remove the life- 826 cycle requirements (R7-U7). 828 8. Identify any new categories and use/add the newly identified 829 categories. New categories can be identified as new domains or 830 applications are emerging, or new areas of concern (e.g. privacy, 831 compliance) might arise, which are not listed in the current 832 methodology. 834 6.2. Intent Taxonomy 836 The following taxonomy describes the various intent solutions, intent 837 user types, intent types, intent scopes, network scopes, abstractions 838 and life-cycle and represents the output of the intent classification 839 tables for each of the solutions addressed (i.e. carrier, data 840 center, and enterprise solutions). 842 The intent scope categories in Figure 2 are shared among the carrier, 843 DC, and enterprise solutions. The abbreviations (Cx) in sections 844 6.3.2. 6.4.2. are introduced with the scope of fitting as column 845 title in the following tables. 847 +--------------------------------+ 848 +-->|Carrier Enterprise Data Center| 849 | +--------------------------------+ 850 | +--------------------------------+ 851 | |Customer/Subscriber/End-User | 852 +----------+ | |Network or Service Operator | 853 +>+Solutions +--+ |Application Developer | 854 | +----------+ +->|Enterprise Administrator | 855 | | |Cloud Administrator | 856 | +----------+ | |Underlay Network Administrator | 857 +>+Intent +---+ +--------------------------------+ 858 | |User | +--------------------------------+ 859 | |Types | |Customer Service Intent | 860 | +----------+ |Strategy Intent | 861 | +----------+ |Network Service Intent | 862 +>+Intent +----->|Underlay Network Service Intent | 863 +------+ | |Type | |Network Intent | 864 |Intent+-+ +----------+ |Underlay Network Intent | 865 +------+ | |Operational Task Intent | 866 | +----------+ |Cloud Management Intent | 867 +>+Intent +---+ |Cloud Resource Management Intent| 868 | |Scope | | +--------------------------------+ 869 | +----------+ | +--------------------------------+ 870 | +->|Connectivity Application QoS | 871 | +----------+ |Security/Privacy Storage Compute| 872 +>+Network +---+ +--------------------------------+ 873 | |Scope | | +--------------------------------+ 874 | +----------+ | |Radio Access Branch | 875 | +->|Transport Access SD-WAN | 876 | +----------+ |Transport Aggr. VNF PNF | 877 +>+Abstrac +----+ |Transport Core Physical | 878 | |tion | | |Cloud Edge Logical | 879 | +----------+ | |Cloud Core Campus | 880 | +----------+ | +--------------------------------+ 881 +>+Life | | +--------------------------------+ 882 |cycle +--+ +>|Technical Non-Technical | 883 +----------+ | +--------------------------------+ 884 | +--------------------------------+ 885 +-->|Persistent Transient | 886 +--------------------------------+ 887 Figure 2 - Intent Taxonomy 889 6.3. Intent Classification for Carrier Solution 891 6.3.1. Intent Users and Intent Types 893 This section addresses step 1, 2, and 3 from Figure 1 and the 894 following table describes the intent users in carrier solutions and 895 intent types with their descriptions for different intent users. 897 +-------------+-------------+---------------------------------------+ 898 | Intent User | Intent Type | Intent Type Description | 899 +-------------------------------------------------------------------+ 900 | Customer/ |Customer |Customer self-service with SLA and | 901 | Subscriber |Service |value added service | 902 | |Intent |Example: Always maintain high quality | 903 | | |of service and high bandwidth for gold | 904 | | |level subscribers. | 905 | | |Operational statement: Measure the | 906 | | |network congestion status, give | 907 | | |different adaptive parameters to | 908 | | |stations of different priority, thus in| 909 | | |heavy load situation, make the | 910 | | |bandwidth of the high-priority | 911 | | |customers guaranteed. | 912 | | |At the same time ensure the overall | 913 | | |utilization of system, improve | 914 | | |the overall throughput of the system. | 915 | +-----------------------------------------------------+ 916 | |Strategy |Customer designs models and policy | 917 | |Intent |intents to be used by customer service | 918 | | |intents. | 919 | | |Example: Request reliable service | 920 | | |during peak traffic periods for apps | 921 | | |of type video. | 922 +-------------------------------------------------------------------+ 923 |Network |Network |Service provided by network service | 924 |Operator |Service |operator to the customer | 925 | |Intent |(e.g. the service operator) | 926 | | |Example: Request network service with | 927 | | |delay guarantee for access customer A. | 928 | +-------------+---------------------------------------+ 929 | |Network |Network operator requests network-wide | 930 | |Intent |(service underlay or other network-wide| 931 | | |configuration) or network resource | 932 | | |configurations (switches, routers, | 933 | | |routing, policies). Includes | 934 | | |connectivity, routing, QoS, security, | 935 | | |application policies, traffic steering | 936 | | |policies, configuration policies, | 937 | | |monitoring policies, alarm generation | 938 | | |for non-compliance, auto-recovery, etc.| 939 | | |Example: Request high priority queueing| 940 | | |for traffic of class A. | 941 | +-----------------------------------------------------+ 942 | |Operational |Network operator requests execution of | 943 | |Task |any automated task other than network | 944 | |Intent |service intent and network intent | 945 | | |(e.g. network migration, server | 946 | | |replacements, device replacements, | 947 | | |network software upgrades). | 948 | | |Example: Request migration of all | 949 | | |services in network N to backup path P.| 950 | +-----------------------------------------------------+ 951 | |Strategy |Network operator designs models, policy| 952 | |Intent |intents and workflows to be used by | 953 | | |network service Intents, network | 954 | | |intents and operational task intents. | 955 | | |Workflows can automate any tasks that | 956 | | |network operator often performed in | 957 | | |addition to network service intents and| 958 | | |network intents | 959 | | |Example: Ensure the load on any link in| 960 | | |the network is not higher than 50%. | 961 +-------------+-------------+---------------------------------------+ 962 +-------------+-------------+---------------------------------------+ 963 | Service | Customer | Service operator's customer orders, | 964 | Operator | Service | customer service / SLA | 965 | | Intent | Example: Provide service S with | 966 | | | guaranteed bandwidth for customer A. | 967 | +-----------------------------------------------------+ 968 | | Network | Service operator's network orders / | 969 | | Service | network SLA | 970 | | Intent | Example: Provide network guarantees in| 971 | | | terms of security, low latency and | 972 | | | high bandwidth | 973 | +-----------------------------------------------------+ 974 | | Operational | Service operator requests execution of| 975 | | Task | any automated task other than | 976 | | Intent | customer service intent and network | 977 | | | service intent | 978 | | | Example: Update service operator | 979 | | | portal platforms and their software | 980 | | | regularly. Move services from network | 981 | | | operator 1 to network operator 2. | 982 | +-----------------------------------------------------+ 983 | | Strategy | Service operator designs models, | 984 | | Intent | policy intents and workflows to be | 985 | | | used by customer service intents, | 986 | | | network service intents and | 987 | | | operational task intents. Workflows | 988 | | | can automate any tasks that service | 989 | | | operator often performed in addition | 990 | | | to network service intents and network| 991 | | | intents. | 992 | | | Example: Request network service | 993 | | | guarantee to avoid network congestion | 994 | | | during special periods | 995 | | | such as black Friday, and Christmas. | 996 +-------------+-------------+---------------------------------------+ 997 | Application | Customer | Customer service intent API provided | 998 | Developer | Service | to the application developers | 999 | | Intent | Example: API to request network to | 1000 | | | watch HD video 4K/8K. | 1001 | +-----------------------------------------------------+ 1002 | | Network | Network service intent API provided to| 1003 | | Service | the application developers | 1004 | | Intent | Example:API to request network service| 1005 | | | , monitoring and traffic grooming. | 1006 | +-----------------------------------------------------+ 1007 | | Network | Network intent API provided to the | 1008 | | Intent | application developers | 1009 | | | Example: API to request network | 1010 | | | resources configuration. | 1011 | +-----------------------------------------------------+ 1012 | | Operational | Operational task intent API provided | 1013 | | Task | to the application developers. This is| 1014 | | Intent | for the trusted internal operator / | 1015 | | | service providers / customer DevOps | 1016 | | | Example: API to request server | 1017 | | | migrations. | 1018 | +-----------------------------------------------------+ 1019 | | Strategy | Application developer designs models, | 1020 | | Intent | policy and workflows to be used by | 1021 | | | customer service intents, network | 1022 | | | service intents and operational | 1023 | | | task intents. This is for the trusted | 1024 | | | internal operator/service provider/ | 1025 | | | customer DevOps | 1026 | | | Example: API to design network load | 1027 | | | balancing strategies during peak times| 1028 +-------------+-------------+---------------------------------------+ 1030 Table 2 - Intent Classification for Carrier Solution 1032 6.3.2. Intent Categories 1034 This subsection addresses step 4 to 7 from Figure 1, and the 1035 following are the proposed categories: 1037 o Intent Scope: C1=Connectivity, C2=Security/Privacy, 1038 C3=Application, C4=QoS 1039 o Network Scope: 1040 o Network Domain: C1=Radio Access, C2=Transport Access, 1041 C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge, 1042 C6=Cloud Core) 1043 o Network Function (NF) Scope: C1=VNFs, C2=PNFs 1044 o Abstraction (ABS): C1=Technical (with technical feedback), 1045 C2=Non-technical (without technical feedback) see section 5.2. . 1046 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient 1047 (short lived) 1049 6.3.3. Intent Classification Example 1051 This section depicts an example on how the methodology described in 1052 section 6.1. can be used in order to classify intents introduced in 1053 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. This 1054 PoC is led by academics carrying research in the area of SDN/NFV and 1055 the specific problem they are addressing is to apply the intent 1056 concept at different levels that correspond to different 1057 stakeholders. For this research work, they considered two types of 1058 intents: slice intents and service chain intents. 1060 In this PoC [POC-IBN], a slice intent expresses a request for a 1061 network slice with two types of components: a set of top layer 1062 virtual functions, and a set of virtual switches and/or routers of 1063 L2/L3 VNFs. A service chain intent expressed a request for a service 1064 operated through a chain of service components running in L4-L7 1065 virtual functions. 1067 Following the intent classification methodology described step-by- 1068 step in section 6.1. , the following can be derived: 1070 1. The intent solution for both intents is carrier network. 1072 2. The intent user type is network operator for the slice intent, and 1073 service operator for the service chain intent. 1075 3. The type of intent, is a network service intent for the slice 1076 intent, and a customer service intent for the service chain intent. 1078 4. The intent scopes are connectivity and application. 1080 5. The network scope is VNF, cloud edge, and cloud core. 1082 6. The abstractions are with technical feedback for the slice intent, 1083 and without technical feedback for the service chain intent 1085 7. The life-cycle is persistent. 1087 The following table shows how to represent this information in a 1088 tabular form. The 'X' in the table refers to the slice intent, and 1089 the 'Y' in the table refers to the service chain intent. 1091 +---------+---------+-----------+-----+-----------------+-----+-----+ 1092 | Intent | Intent | Intent | NF | Network | ABS |L-C | 1093 | User | Type | Scope |Scope| Scope | | | 1094 | | +-----------+-----+-----------------+-----+-----+ 1095 | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| 1096 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1097 |Customer |Customer | | | | | | | | | | | | | | | | | 1098 |/ Sub- |Service | | | | | | | | | | | | | | | | | 1099 | scriber |Intent | | | | | | | | | | | | | | | | | 1100 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1101 | |Strategy | | | | | | | | | | | | | | | | | 1102 | |Intent | | | | | | | | | | | | | | | | | 1103 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1104 |Network |Network |X | |X | |X | | | | | |X | |X | |X | | 1105 |Operator |Service | | | | | | | | | | | | | | | | | 1106 | |Intent | | | | | | | | | | | | | | | | | 1107 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1108 | |Network | | | | | | | | | | | | | | | | | 1109 | |Intent | | | | | | | | | | | | | | | | | 1110 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1111 | |Operatio-| | | | | | | | | | | | | | | | | 1112 | |nal Task | | | | | | | | | | | | | | | | | 1113 | |Intent | | | | | | | | | | | | | | | | | 1114 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1115 | |Strategy | | | | | | | | | | | | | | | | | 1116 | |Intent | | | | | | | | | | | | | | | | | 1117 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1118 |Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | | 1119 |Operator |Service | | | | | | | | | | | | | | | | | 1120 | |Intent | | | | | | | | | | | | | | | | | 1121 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1122 | |Network | | | | | | | | | | | | | | | | | 1123 | |Service | | | | | | | | | | | | | | | | | 1124 | |Intent | | | | | | | | | | | | | | | | | 1125 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1126 | |Op Task | | | | | | | | | | | | | | | | | 1127 | |Intent | | | | | | | | | | | | | | | | | 1128 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1129 | |Strategy | | | | | | | | | | | | | | | | | 1130 | |Intent | | | | | | | | | | | | | | | | | 1131 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1132 |App |Customer | | | | | | | | | | | | | | | | | 1133 |Developer|Intent | | | | | | | | | | | | | | | | | 1134 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1135 | |Network | | | | | | | | | | | | | | | | | 1136 | |Service | | | | | | | | | | | | | | | | | 1137 | |Intent | | | | | | | | | | | | | | | | | 1138 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1139 | |Network | | | | | | | | | | | | | | | | | 1140 | |Intent | | | | | | | | | | | | | | | | | 1141 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1142 | |Op Task | | | | | | | | | | | | | | | | | 1143 | |Intent | | | | | | | | | | | | | | | | | 1144 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1145 | |Strategy | | | | | | | | | | | | | | | | | 1146 | |Intent | | | | | | | | | | | | | | | | | 1147 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1149 Table 3 - Intent Classification Example for Carrier Solution 1151 6.4. Intent Classification for Data Center Network Solutions 1153 6.4.1. Intent Users and Intent Types 1155 The following table describes the intent users in DC network 1156 solutions and intent types with their descriptions for different 1157 intent users. 1159 +---------------+-------------+-------------------------------------+ 1160 | Intent User | Intent Type | Intent Type Description | 1161 +-------------------------------------------------------------------+ 1162 | Customer / | Customer | Customer self-service via tenant | 1163 | Tenants | Service | portal. | 1164 | | | Example: Request GPU computing and | 1165 | | | storage resources to meet 10k video | 1166 | | | surveillance services. | 1167 | +---------------------------------------------------+ 1168 | | Strategy | This includes models and policy | 1169 | | Intent | intents designed by customers/ | 1170 | | | tenants to be reused later during | 1171 | | | instantiation. | 1172 | | | Example: Request dynamic computing | 1173 | | | and storage resources of the service| 1174 | | | in special and daily times. | 1175 | | | | 1176 +-------------------------------------------------------------------+ 1177 | | Cloud | Configuration of VMs, DB Servers, | 1178 | Cloud | Management | app servers, connectivity, | 1179 | Administrator | Intent | communication between VMs. | 1180 | | | Example: Request connectivity | 1181 | | | between VMs A,B,and C in network N1.| 1182 | +---------------------------------------------------+ 1183 | | Cloud | Policy-driven self-configuration and| 1184 | | Resource | and recovery / optimization | 1185 | | Management | Example: Request automatic life | 1186 | | Intent |-cycle management of VM cloud | 1187 | | | resources. | 1188 | +---------------------------------------------------+ 1189 | | Operational | Cloud administrator requests | 1190 | | Task Intent | execution of any automated task | 1191 | | | other than cloud management | 1192 | | | intents and cloud resource | 1193 | | | management intents. | 1194 | | | Example: Request upgrade operating | 1195 | | | system to version X on all VMs | 1196 | | | in network N1. | 1197 | | |Operational statement: an intent to | 1198 | | |update a system might reconfigure the| 1199 | | |system topology (connect to a service| 1200 | | |and to peers), exchange data (update | 1201 | | |the content), and uphold a certain | 1202 | | |QoE level (allocate sufficient | 1203 | | |network resources). The network, | 1204 | | |thus, carries out the necessary | 1205 | | |configuration to best serve such an | 1206 | | |intent; e.g. setting up direct | 1207 | | |connections between terminals, and | 1208 | | |allocating fair shares of router | 1209 | | |queues considering other network | 1210 | | |services. 1211 | +---------------------------------------------------+ 1212 | | Strategy | Cloud administrator designs models, | 1213 | | Intent | policy intents and workflows to be | 1214 | | | used by other intents. Automate any | 1215 | | | tasks that administrator often | 1216 | | | performs, in addition to life-cycle | 1217 | | | of cloud management intents and | 1218 | | | cloud management resource intents. | 1219 | | | Example: In case of emergency, | 1220 | | | automatically migrate all cloud | 1221 | | | resources to DC2. | 1222 +---------------+---------------------------------------------------+ 1223 | Underlay | Underlay | Service created and provided by | 1224 | Network | Network | the underlay network administrator. | 1225 | Administrator | Service | Example: Request underlay service | 1226 | | Intent | between DC1 and DC2 with | 1227 | | | bandwidth B. | 1228 | +---------------------------------------------------+ 1229 | | Underlay | Underlay network administrator | 1230 | | Network | requests some DCN-wide underlay | 1231 | | Intent | network configuration or network | 1232 | | | resource configurations. | 1233 | | | Example: Establish and allocate | 1234 | | | DHCP address pool. | 1235 | +---------------------------------------------------+ 1236 | | Operational | Underlay network administrator | 1237 | | Task Intent | requests execution of the any | 1238 | | | automated task other than underlay | 1239 | | | network service and resource | 1240 | | | intent. | 1241 | | | Example: Request automatic rapid | 1242 | | | detection of device failures and | 1243 | | | pre-alarm correlation. | 1244 | +---------------------------------------------------+ 1245 | | Strategy | Underlay network administrator | 1246 | | Intent | designs models, policy intents & | 1247 | | | workflows to be used by other | 1248 | | | intents. Automate any tasks that | 1249 | | | administrator often performs. | 1250 | | | Example: For all traffic flows | 1251 | | | that need NFV service chaining, | 1252 | | | restrict the maximum load of any | 1253 | | | VNF node/container below 50% and | 1254 | | | the maximum load of any network | 1255 | | | link below 70%. | 1256 +-------------------------------------------------------------------+ 1257 | | Cloud | Cloud management intent API | 1258 | | Management | provided to the application | 1259 | | Intent | developers. | 1260 | | | Example: API to request | 1261 | | | configuration of VMs, or DB Servers.| 1262 | Application +---------------------------------------------------+ 1263 | Developer | Cloud | Cloud resource management intent | 1264 | | Resource | API provided to the application | 1265 | | Management | developers. | 1266 | | Intent | Example: API to request automatic | 1267 | | | life-cycle management of cloud | 1268 | | | resources. | 1269 | +---------------------------------------------------+ 1270 | | Underlay | Underlay network service API | 1271 | | Network | provided to the application | 1272 | | Service | developers. | 1273 | | Intent | Example: API to request real-time | 1274 | | | monitoring of device condition. | 1275 | +---------------------------------------------------+ 1276 | | Underlay | Underlay network resource API | 1277 | | Network | provided to the application | 1278 | | Intent | developers. | 1279 | | | Example: API to request dynamic | 1280 | | | management of IPv4 address pool | 1281 | | | resources. | 1282 | | | | 1283 | +---------------------------------------------------+ 1284 | | Operational | Operational task intent API | 1285 | | Task Intent | provided to the trusted | 1286 | | | application developer (internal | 1287 | | | DevOps). | 1288 | | | Example: API to request automatic | 1289 | | | rapid detection of device failures | 1290 | | | and pre-alarm correlation | 1291 | | | | 1292 | +---------------------------------------------------+ 1293 | | Strategy | Application developer designs | 1294 | | Intent | models, policy intents and | 1295 | | | building blocks to be used by | 1296 | | | other intents. This is for the | 1297 | | | trusted internal DCN DevOps. | 1298 | | | Example: API to request load | 1299 | | | balancing thresholds. | 1300 +---------------+-------------+-------------------------------------+ 1302 Table 4 - Intent Classification for Data Center Network Solutions 1304 6.4.2. Intent Categories 1306 The following are the proposed categories: 1307 o Intent Scope: C1=Connectivity, C2=Security/Privacy, 1308 C3=Application, C4=QoS C5=Storage C6=Compute 1309 o Network Scope 1310 o Network Domain: DC Network 1311 o DCN Network (DCN Net) Scope: C1=Logical, C2=Physical 1312 o DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical 1313 o Abstraction (ABS): C1=Technical (with technical feedback), 1314 C2=Non-technical (without technical feedback), see section 5.2. 1315 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient 1316 (short lived) 1318 6.4.3. Intent Classification Example 1320 This section depicts an example on how the methodology described in 1321 section 6.1. can be used by the research community to classify 1322 intents. As mentioned in 6.3.3. a successful use of the 1323 classification proposed in this draft is introduced in the 'A Multi- 1324 Level Approach to IBN' PoC demonstration [POC-IBN]. The PoC is led by 1325 academics carrying research in the area of SDN/NFV and the specific 1326 problem they are addressing is to apply the intent concept at 1327 different levels that correspond to different stakeholders. 1329 For their research work, they considered two types of intents: slice 1330 intents and service chain intents. For the data center solution, only 1331 the slice intent is relevant. 1333 As already mentioned in section 6.3.3. , a slice intent expresses a 1334 request for a network slice with two types of components: a set of 1335 top layer virtual functions, and a set of virtual switches and/or 1336 routers of L2/L3 VNFs. 1338 Following the intent classification methodology described step-by- 1339 step in section 6.1. , we identify the following: 1341 1. The intent solution is for the data center. 1343 2. The intent user type is the cloud administrator for the slice 1344 intent and service chain intent. 1346 3. The type of intent, is a cloud management intent, for the slice 1347 intent. 1349 4. The intent scopes are connectivity and application. 1351 5. The network scope is logical, and the resource scope is virtual. 1353 6. The abstractions are with technical feedback for the slice intent. 1355 7. The life-cycle is persistent. 1357 The following table shows how to represent this information in a 1358 tabular form, where the 'X' in the table refers to the slice intent. 1360 +---------+-------------+-----------------+-----+-----+-----+-----+ 1361 |Intent | Intent | Intent | DCN | DCN | ABS | L-C | 1362 |User | Type | Scope | Res | Net | | | 1363 | | +-----------------+-----+-----+-----+-----+ 1364 | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| 1365 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1366 |Customer | Customer | | | | | | | | | | | | | | | 1367 |/Tenants | Service | | | | | | | | | | | | | | | 1368 | | Intent | | | | | | | | | | | | | | | 1369 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1370 | | Strategy | | | | | | | | | | | | | | | 1371 | | Intent | | | | | | | | | | | | | | | 1372 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1373 | Cloud | Cloud | | | | | | | | | | | | | | | 1374 | Admin | Management |X | |X | | | |X | |X | |X | |X | | 1375 | | Intent | | | | | | | | | | | | | | | 1376 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1377 | | Cloud | | | | | | | | | | | | | | | 1378 | | Resource | | | | | | | | | | | | | | | 1379 | | Management | | | | | | | | | | | | | | | 1380 | | Intent | | | | | | | | | | | | | | | 1381 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1382 | | Operational | | | | | | | | | | | | | | | 1383 | | Task Intent | | | | | | | | | | | | | | | 1384 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1385 | | Strategy | | | | | | | | | | | | | | | 1386 | | Intent | | | | | | | | | | | | | | | 1387 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1388 |Underlay | Underlay | | | | | | | | | | | | | | | 1389 |Network | Network | | | | | | | | | | | | | | | 1390 |Admin | Intent | | | | | | | | | | | | | | | 1391 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1392 | | Underlay | | | | | | | | | | | | | | | 1393 | | Network | | | | | | | | | | | | | | | 1394 | | Resource | | | | | | | | | | | | | | | 1395 | | Intent | | | | | | | | | | | | | | | 1396 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1397 | | Operational | | | | | | | | | | | | | | | 1398 | | Task Intent | | | | | | | | | | | | | | | 1399 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1400 | | Strategy | | | | | | | | | | | | | | | 1401 | | Intent | | | | | | | | | | | | | | | 1402 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1403 |App | Cloud | | | | | | | | | | | | | | | 1404 |Developer| Management | | | | | | | | | | | | | | | 1405 | | Intent | | | | | | | | | | | | | | | 1406 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1407 | | Cloud | | | | | | | | | | | | | | | 1408 | | Resource | | | | | | | | | | | | | | | 1409 | | Management | | | | | | | | | | | | | | | 1410 | | Intent | | | | | | | | | | | | | | | 1411 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1412 | | Underlay | | | | | | | | | | | | | | | 1413 | | Network | | | | | | | | | | | | | | | 1414 | | Intent | | | | | | | | | | | | | | | 1415 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1416 | | Underlay | | | | | | | | | | | | | | | 1417 | | Network | | | | | | | | | | | | | | | 1418 | | Resource | | | | | | | | | | | | | | | 1419 | | Intent | | | | | | | | | | | | | | | 1420 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1421 | | Operational | | | | | | | | | | | | | | | 1422 | | Task Intent | | | | | | | | | | | | | | | 1423 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1424 | | Strategy | | | | | | | | | | | | | | | 1425 | | Intent | | | | | | | | | | | | | | | 1426 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1428 Table 5 - Intent Classification Example for Data Center Network 1429 Solutions 1431 6.5. Intent Classification for Enterprise Solution 1433 6.5.1. Intent Users and Intent Types 1435 The following table describes the intent users in enterprise 1436 solutions and their intent types. 1438 +--------------+-------------+-------------------------------------+ 1439 | Intent User | Intent Type | Intent Type Description | 1440 +--------------+---------------------------------------------------+ 1441 | End-User | Customer | Enterprise end-user self-service or | 1442 | | Service | applications, enterprise may have | 1443 | | Intent | multiple types of end-users. | 1444 | | | Example: Request access to VPN | 1445 | | | service. | 1446 | | | Request video conference between | 1447 | | | end-user A and B. | 1448 | +---------------------------------------------------+ 1449 | | Strategy | This includes models and policy | 1450 | | Intent | intents designed by end-users to be | 1451 | | | used by end-user intents and their | 1452 | | | applications. | 1453 | | | Example: Create a video conference | 1454 | | | type for a weekly meeting. | 1455 +------------------------------------------------------------------+ 1456 |Enterprise | Network | Service provided by the | 1457 |Administrator | Service | administrator to the end-users | 1458 |(internal or | Intent | and their applications. | 1459 | MSP) | | Example: For any end-user of | 1460 | | | application X, the arrival of | 1461 | | | hologram objects of all the remote | 1462 | | | tele-presenters should be | 1463 | | | synchronised within 50ms to reach | 1464 | | | the destination viewer for each | 1465 | | | conversation session. | 1466 | | | Create management VPN connectivity | 1467 | | | for type of service A. | 1468 | | | Operational statement: The job of | 1469 | | | the network layer is to ensure that | 1470 | | | the delay is between 50-70ms through| 1471 | | | the routing algorithm. At the same | 1472 | | | time,the node resources need to meet| 1473 | | | the bandwidth requirements of 4K | 1474 | | | video conferences. | 1475 +------------------------------------------------------------------+ 1476 | | Network | Administrator requires network wide | 1477 | | Intent | configuration (e.g. underlay, | 1478 | | | campus) or resource configuration | 1479 | | | (switches, routers, policies). | 1480 | | | Example: Configure switches in | 1481 | | | campus network 1 to prioritise | 1482 | | | traffic of type A. | 1483 | | | Configure YouTube as business | 1484 | | | non-relevant. | 1485 | +---------------------------------------------------+ 1486 | | Operational | Administrator requests execution of | 1487 | | Task Intent | any automated task other than | 1488 | | | network service intents and network | 1489 | | | intents. | 1490 | | | Example: Request network security | 1491 | | | automated tasks such as web | 1492 | | | filtering and DDOS cloud protection.| 1493 | +---------------------------------------------------+ 1494 | | Strategy | Administrator designs models, policy| 1495 | | Intent | intents and workflows to be used by | 1496 | | | other intents. Automate any tasks | 1497 | | | that administrator often performs. | 1498 | | | Example: In case of emergency, | 1499 | | | automatically shift all traffic of | 1500 | | | type A through network N. | 1501 | | | | 1502 +--------------+-------------+-------------------------------------+ 1503 | Application | End-User | End-user service / application | 1504 | Developer | Intent | intent API provided to the | 1505 | | | application developers. | 1506 | | | Example: API for request to open a | 1507 | | | VPN service. | 1508 | +---------------------------------------------------+ 1509 | | Network | Network service API provided to | 1510 | | Service | application developers. | 1511 | | Intent | Example: API for request network | 1512 | | | bandwidth and latency for | 1513 | | | hosting video conference. | 1514 | +---------------------------------------------------+ 1515 | | Network | Network API provided to application | 1516 | | Intent | developers. | 1517 | | | Example: API for request of network | 1518 | | | devices configuration. | 1519 | +---------------------------------------------------+ 1520 | | Operational | Operational task intent API provided| 1521 | | Task Intent | to the trusted application developer| 1522 | | | (internal DevOps). | 1523 | | | Example: API for requesting | 1524 | | | automatic monitoring and | 1525 | | | interception for network security | 1526 | +---------------------------------------------------+ 1527 | | Strategy | Application developer designs | 1528 | | Intent | models, policy intents and building | 1529 | | | blocks to be used by other intents. | 1530 | | | This is for the trusted internal | 1531 | | | DevOps. | 1532 | | | Example: API for strategy intent in | 1533 | | | case of emergencies. | 1534 | | | | 1535 +--------------+-------------+-------------------------------------+ 1536 Table 6 - Intent Classification for Enterprise Solution 1538 6.5.2. Intent Categories 1540 The following are the proposed categories: 1541 o Intent Scope: C1=Connectivity, C2=Security/Privacy, 1542 C3=Application, C4=QoS 1543 o Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN 1544 o Abstraction (ABS): C1=Technical (with technical feedback), 1545 C2=Non-technical (without technical feedback), see section 5.2. 1546 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient 1547 (short lived) 1549 The following is the intent classification table example for 1550 enterprise solutions. 1552 +---------------+-------------+-----------+--------+-----+-----+ 1553 | Intent User | Intent Type | Intent | Net | ABS | L-C | 1554 | | | Scope | | | | 1555 | | +-----------+--------+-----+-----+ 1556 | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| 1557 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1558 | End-User | Customer | | | | | | | | | | | | 1559 | | Service | | | | | | | | | | | | 1560 | | Intent | | | | | | | | | | | | 1561 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1562 | | Strategy | | | | | | | | | | | | 1563 | | Intent | | | | | | | | | | | | 1564 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1565 | Enterprise | Network | | | | | | | | | | | | 1566 | Administrator | Service | | | | | | | | | | | | 1567 | | Intent | | | | | | | | | | | | 1568 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1569 | | Network | | | | | | | | | | | | 1570 | | Intent | | | | | | | | | | | | 1571 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1572 | | Operational | | | | | | | | | | | | 1573 | | Task | | | | | | | | | | | | 1574 | | Intent | | | | | | | | | | | | 1575 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1576 | | Strategy | | | | | | | | | | | | 1577 | | Intent | | | | | | | | | | | | 1578 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1579 | Application | End-User | | | | | | | | | | | | 1580 | Developer | Intent | | | | | | | | | | | | 1581 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1582 | | Network | | | | | | | | | | | | 1583 | | Service | | | | | | | | | | | | 1584 | | Intent | | | | | | | | | | | | 1585 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1586 | | Network | | | | | | | | | | | | 1587 | | Intent | | | | | | | | | | | | 1588 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1589 | | Operational | | | | | | | | | | | | 1590 | | Task | | | | | | | | | | | | 1591 | | Intent | | | | | | | | | | | | 1592 | +-------------+--+--+--+--+--+--+--+--+--+--+--+ 1593 | | Strategy | | | | | | | | | | | | 1594 | | Intent | | | | | | | | | | | | 1595 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ 1596 Table 7 - Intent Categories for Enterprise Solution 1598 7. Conclusions 1600 This document is aligned with the RG objectives and supports 1601 investigations into intent-based networking by proposing an intent 1602 categorization methodology and taxonomy. It brings clarification on 1603 what an intent represents for different stakeholders through the 1604 proposal of an Intent Classification approach, ensuring that a 1605 common understanding among all the participants exists. This, 1606 together with the proposed intent taxonomy provides a solid 1607 foundation for future intent-related topic discussions within NMRG. 1609 The benefits of this intent classification draft in the research 1610 community have been demonstrated through a PoC implementation [POC- 1611 IBN] in which the draft's concepts at different levels corresponding 1612 to different stakeholders have been applied to. 1614 8. Security Considerations 1616 This document identifies the security and privacy as categories of 1617 the intent scope. The intents could be solely security intents and 1618 privacy intents or security can be embedded in the intents that 1619 include also connectivity, application, and QoS scope. 1621 Security and privacy scope, is when the intent specifies the security 1622 characteristics of the network, customers, or end-users, and privacy 1623 for customers and end-users. 1625 More details of these security intents would be described in future 1626 documents that specify architecture, functionality, user intents and 1627 models. As well, an analysis of the security considerations of the 1628 overall intent-based system is provided in section 10 of [CLEMM]. 1630 9. IANA Considerations 1632 This document has no actions for IANA. 1634 10. Contributors 1636 The following people all contributed to creating this document: 1638 Xueyuan Sun, China Telecom 1639 Will (Shucheng) Liu, Huawei 1640 Ying Chen, China Unicom 1641 John Strassner, Huawei 1642 Weiping Xu, Huawei 1643 Richard Meade, Huawei 1645 11. Acknowledgments 1647 Special thanks to Xueyuan Sun from China Telecom for significant 1648 contributions to this document, and to Will (Shucheng) Liu from 1649 Huawei for contributions and guidance. 1651 This document has benefited from reviews, suggestions, comments and 1652 proposed text provided by the following members, listed in 1653 alphabetical order: Mehdi Bezahaf, Brian E Carpenter, Laurent 1654 Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome 1655 Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav 1656 Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff 1657 Tantsura. 1659 We thank to Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide 1660 Borsatti, for contributing with their 'A multi-level approach to 1661 IBN' PoC demonstration a first attempt to adopt the intent 1662 classification methodology. 1664 12. Informative References 1666 [Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C. and Race, N., "To All 1667 Intents and Purposes: Towards Flexible Intent Expression," 1668 2021 IEEE 7th International Conference on Network 1669 Softwarization (NetSoft), 2021. 1671 [Bezhaf19] Bezahaf, M., Hernandez, MP, Bardwell, L., Davies, E., 1672 Broadbent, M.,King, D. and Hutchison, D. , "Self-Generated 1673 Intent-Based System," 2019 10th International Conference on 1674 Networks of the Future (NoF), 2019. 1676 [Jacobs18] Jacobs, A.S., Pfitscher,R.J., Ferreira, R.A., and 1677 Granville, L.Z., "Refining Network Intents for Self-Driving 1678 Networks", Proceedings of the Afternoon Workshop on Self- 1679 Driving Networks (SelfDN 2018), 2018. 1681 [Banerjee21] Banerjee,A., Mwanje. S. and Carle, G., "Contradiction 1682 Management in Intent-driven Cognitive Autonomous RAN", 1683 2021. 1685 [Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H. H., Ye, Q., Wang, C., 1686 and Zhao, B. Y., "Safely and automatically updating in- 1687 network ACL configurations with intent language", SIGCOMM 1688 '19, 2019. 1690 [Leivadeas21] Leivadeas, A. and Falkner, M., "VNF Placement Problem: 1691 A Multi-Tenant Intent-Based Networking Approach," 24th 1692 Conference on Innovation in Clouds, Internet and Networks 1693 and Workshops (ICIN), 2021. 1695 [Davoli21] Davoli, G., "Programmability and Management of Software- 1696 defined Network Infrastructures", 2021. 1698 [Padovan20] Padovan, S., "Design and Implementation of a Blockchain 1699 Intent Management System", 2020. 1701 [Mehmood21] Mehmood, K., Kralevska, K., and Palma, D., "Intent-driven 1702 Autonomous Network and Service Management in Future 1703 Networks: A Structured Literature Review", 2021. 1705 [Szilagyi21] Szilagyi, P., "I2BN: Intelligent Intent Based Networks", 1706 Journal of ICT Standardization, 2021. 1708 [POC-IBN] Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide 1709 Borsatti, "A multi-level approach to IBN", July 2020, 1710 https://www.ietf.org/proceedings/108/slides/slides-108- 1711 nmrg-ietf-108-hackathon-report-a-multi-level-approach-to- 1712 ibn-02 1714 [IFIP-NSM] IFIP - Network and Service Management Taxonomy, 1715 https://www.simpleweb.org/ifip/taxonomy.html 1717 [ONF] ONF, "Intent Definition Principles", 2017, 1718 . 1722 [ONOS] ONOS, "ONOS Intent Framework", 2017, 1723 . 1726 [CLEMM] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent- 1727 Based Networking - Concepts and Overview", Work in 1728 Progress, draft-irtf-nmrg-ibn-concepts-definitions-05, 1729 February 2021, https://tools.ietf.org/html/draft-irtf-nmrg- 1730 ibn-concepts-definitions-05 1732 [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of 1733 Autonomous Networks: Empowering Digital Transformation For 1734 the Telecoms Industry, inform.tmforum.org, 15 May, 2019. 1736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1737 Requirement Levels", BCP 14, RFC 2119, March 1997. 1739 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1740 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1741 Networking: Definitions and Design Goals", RFC 7575, June 1742 2015. 1744 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1745 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1746 Management Framework for the Simplified Use of Policy 1747 Abstractions (SUPA)", March 2018. 1749 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 1750 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, 1751 M., Perry, J., Waldbusser, S., "Terminology for Intent- 1752 driven Management", RFC 3198, November 2001. 1754 [RFC6020] Bjorlund, M., "YANG - A Data Modelling Language for Network 1755 Configuration Protocol (NETCONF)", RFC 6020, October 2010. 1757 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 1758 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 1759 Optimization (ALTO) Protocol", September 2014. 1761 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017, 1762 . 1765 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions", 1766 2017, . 1769 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun, 1770 "Autonomic IPv6 Edge Prefix Management in Large-scale 1771 Networks", draft-ietf-anima-prefix-management-07 (work in 1772 progress), December 2017. 1774 Authors' Addresses 1776 Chen Li 1777 China Telecom 1778 No.118 Xizhimennei street, Xicheng District 1779 Beijing 100035 1780 P.R. China 1781 Email: lichen.bri@chinatelecom.cn 1783 Olga Havel 1784 Huawei Technologies 1785 Ireland 1786 Email: olga.havel@huawei.com 1788 Adriana Olariu 1789 Huawei Technologies 1790 Ireland 1791 Email: adriana.olariu@huawei.com 1793 Pedro Martinez-Julia 1794 NICT 1795 Japan 1796 Email: pedro@nict.go.jp 1798 Jeferson Campos Nobre 1799 Federal University of Rio Grande do Sul 1800 Porto Alegre 1801 Brazil 1802 Email: jcnobre@inf.ufrgs.br 1804 Diego R. Lopez 1805 Telefonica I+D 1806 Don Ramon de la Cruz, 82 1807 Madrid 28006 1808 Spain 1809 Email: diego.r.lopez@telefonica.com