idnits 2.17.1 draft-draft-li-intent-classification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-draft-li-intent-classification-01', but the file name used is 'draft-draft-li-intent-classification-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ONOS' is defined on line 492, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Li 2 Internet Draft China Telecom 3 Intended status: Informational Y. Cheng 4 China Unicom 5 J. Strassner 6 O.Havel 7 W.Xu 8 Huawei Technologies 9 October 22, 2018 10 Expires: April 2019 12 Intent Classification 13 draft-draft-li-intent-classification-01 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, except to publish it 28 as an RFC and to translate it into languages other than English. 30 This document may contain material from IETF Documents or IETF 31 Contributions published or made publicly available before November 32 10, 2008. The person(s) controlling the copyright in some of this 33 material may not have granted the IETF Trust the right to allow 34 modifications of such material outside the IETF Standards Process. 35 Without obtaining an adequate license from the person(s) controlling 36 the copyright in such materials, this document may not be modified 37 outside the IETF Standards Process, and derivative works of it may 38 not be created outside the IETF Standards Process, except to format 39 it for publication as an RFC or to translate it into languages other 40 than English. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on April 22, 2009. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. Code Components extracted from this 71 document must include Simplified BSD License text as described in 72 Section 4.e of the Trust Legal Provisions and are provided without 73 warranty as described in the Simplified BSD License. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with 80 respect to this document. 82 Abstract 84 RFC 7575 [RFC7575] defines Intent as an abstract high-level policy 85 used to operate the network. Intent management system includes an 86 interface for users to input requests and an engine to translate the 87 intents into the network configuration and manage their lifecycle. 88 Up to now, there is no commonly agreed definition, interface or 89 model of intent. 91 This document discusses what intent means to different stakeholders, 92 describes different ways to classify intent, and an associated 93 taxonomy of this classification. 95 Table of Contents 97 1. Introduction ................................................ 3 98 2. Requirements Language ........................................ 4 99 3. Acronyms .................................................... 4 100 4. Abstract intent requirements ................................. 4 101 4.1. What is Intent ......................................... 4 102 4.2. Intent Solutions & Intent Users ......................... 5 103 4.3. Current Problems & Requirements ......................... 5 104 4.4. Intent Types that need to be supported .................. 7 105 5. The Policy Continuum......................................... 7 106 6. Functional Characteristics and Behavior ...................... 8 107 6.1. Persistence ............................................ 8 108 6.2. Granularity ............................................ 8 109 6.3. Abstracting Intent Operation ............................ 9 110 6.4. Policy Subjects and Policy Targets ...................... 9 111 6.5. Policy Scope ........................................... 9 112 7. IANA Considerations ........................................ 11 113 8. Security Considerations ..................................... 11 114 9. IANA Considerations ........................................ 11 115 10. References ................................................ 11 116 10.1. Normative References .................................. 11 117 10.2. Informative References ................................ 11 118 11. Acknowledgments ........................................... 12 120 1. Introduction 122 Different SDOs (such as [ANIMA][ONF]) have proposed intent as a 123 declarative interface for defining a set of network operations to 124 execute. 126 Although there is no common definition or model of intent which are 127 agreed by all SDOs, there are several shared principles: 129 o intent should be declarative, using and depending on as few 130 deployment details as possible and focusing on what and not how 132 o intent should provide an easy-to-use interface, and use 133 terminology and concepts familiar to its target audience 135 o intent should be vendor-independent and portable across platforms 137 o the intent framework should be able to detect and resolve 138 conflicts between multiple intents 140 SDOs have different perspectives on what intent is, what set of 141 actors it is intended to serve, and how it should be used. This 142 document provides several dimensions to classify intents. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 147 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 148 in this document are to be interpreted as described in RFC 2119 149 [RFC2119]. 151 3. Acronyms 153 CLI: Command Line Interface 155 SDO: Standards Development Organisation 157 SUPA: Simplified Use of Policy Abstractions 159 VPN: Virtual Private Network 161 4. Abstract intent requirements 163 In order to understand the different intent requirements that would 164 drive intent classification, we first need to understand what intent 165 means for different intent users. 167 4.1. What is Intent 169 The term Intent has become very widely used in the industry for 170 different purposes, sometimes it is not even in agreement with SDO 171 shared principles mentioned in the Introduction. Different 172 stakeholders consider an intent to be an ECA policy, a GBP policy, a 173 business policy, a network service, a customer service, a network 174 configuration, application / application group policy, any 175 operator/administrator task, network troubleshooting / diagnostics / 176 test, a new app, a marketing term for existing 177 management/orchestration capabilities, etc. Their intent is 178 sometimes technical, non-technical, abstract or technology specific. 179 For some stakeholders, intent is a subset of these and for other 180 stakeholders intent is all of these. It has in some cases become a 181 term to replace a very generic 'service' or 'policy' terminology. 183 While it is easier for those familiar with different standards to 184 understand what service, CFS, RFS, resource, policy continuum, ECA 185 policy, declarative policy, abstract policy or intent policy is, it 186 may be more difficult for the wider audience. Intent is very often 187 just a synonym for policy. Those familiar with policies understand 188 the difference between a business, intent, declarative, imperative 189 and ECA policy. But maybe the wider audience does not understand the 190 difference and sometimes equates the policy to an ECA policy. 192 Therefore, it is important to start a discussion in the industry 193 about what intent is for different solutions and intent users. It is 194 also imperative to try to propose some intent categories / 195 classifications that could be understood by a wider audience. This 196 would help us define intent interfaces, DSLs and models. 198 4.2. Intent Solutions & Intent Users 200 Different Solutions and Actors have different requirements, 201 expectations and priorities for intent driven networking. They 202 require different intent types and have different use cases. Some 203 users are more technical and require intents that expose more 204 technical information. Other users do not understand networks and 205 require intents that shield them from different networking concepts 206 and technologies. 208 4.3. Current Problems & Requirements 210 Network APIs and CLIs are too complex due to the fact that they 211 expose technologies & topologies. App developers and end-users do 212 not want to set IP Addresses, VLANs, subnets, ports, etc. Operators 213 and administrators would also benefit from the simpler interfaces, 214 like: 216 o Allow Customer Site A to be connected to Internet via Network B 218 o Allow User A to access all internal resources, except the Server 219 B 221 o Allow User B to access Internet via Corporate Network A 223 o Move all Users from Corporate Network A to the Corporate Network 224 B 226 o Request Gold VPN service between my sites A, B and C 228 o Provide CE Redundancy for all Customer Sites 230 o Add Access Rules to my Service 232 Networks are complex, with many different protocols and 233 encapsulations. Some basic questions are not easy to answer: 235 o Can User A talk to User B? 237 o Can Host A talk to Host B? 239 o Are there any loops in my network? 241 o Are Network A and Network B connected? 243 o Can User A listen to communications between Users B & C? 245 Operators and Administrators manually troubleshoot and fix their 246 networks and services. They instead want: 248 o a reliable network that is self-configured and self-assured based 249 on the intent 251 o to be notified about the problem before the user is aware 253 o automation of network/service recovery based on intent (self- 254 healing, self-optimization) 256 o to get suggestions about correction/optimization steps based on 257 experience (historical data & behaviour) 259 Therefore, Operators and Administrators want to: 261 o simplify and automate network operations 263 o simplify definitions of network services 265 o provide simple customer APIs for Value Added Services (operators) 267 o be informed if the network or service is not behaving as 268 requested 270 o enable automatic optimization and correction for selected 271 scenarios 273 o have systems that learn from historic information and behaviour 275 End-Users cannot build their own services and policies without 276 becoming technical experts and they must perform manual maintenance 277 actions. Application developers and end-users/subscribers want to be 278 able to: 280 o build their own network services with their own policies via 281 simple interfaces, without becoming networking experts 283 o have their network services up and running based on intent and 284 automation only, without any manual actions or maintenance 286 4.4. Intent Types that need to be supported 288 The following intent types need to be supported, in order to address 289 the requirements from different solutions and intent users: 291 o Customer network service intent 293 o Network resource management 295 o Cloud and cloud resource management 297 o Network Policy intent 299 o Task based intents 301 o System policies intents 303 5. The Policy Continuum 305 The Policy Continuum defines the set of actors that will create, 306 read, use, and manage policy. Each set of actors has their own 307 terminology and concepts that they are familiar with. This captures 308 the fact that business people do not want to use CLI, and network 309 operations center personnel do not want to use non-technical 310 languages. 312 6. Functional Characteristics and Behavior 314 Intent can be used to operate immediately on a target (much like 315 issuing a command), or whenever it is appropriate (e.g., in response 316 to an event). In either case, intent has a number of behaviors that 317 serve to further organize its purpose, as described by the following 318 subsections. 320 6.1. Persistence 322 Intents can be classified into transient/persistent intents. 324 If intent is transient, it has no lifecycle management. As soon as 325 the specified operation is successfully carried out, the intent is 326 finished, and can no longer affect the target object. 328 If the intent is persistent, it has lifecycle management. Once the 329 intent is successfully activated and deployed, the system will keep 330 all relevant intents active until they are deactivated or removed. 332 6.2. Granularity 334 Intents can have different granularities: high granularity, low 335 granularity and anything in between. 337 High granularity intents are more complex to design but are the most 338 valuable. Intent translation, intent conflict resolution and intent 339 verification are very complex and require advanced algorithms. 340 Examples: e2e network service, like customer network service over 341 physical & virtual network, over access, metro, dc and wan with all 342 related QoS, security and application policies. 344 Low granularity intents, like some path checks (can A talk to B) or 345 individual network service/network/application/user policies, are 346 the least complex. Their intent translation, intent conflict 347 resolution and intent verification are much simpler than for high 348 granularity intents. 350 6.3. Abstracting Intent Operation 352 The modeling of Policies can be abstracting using the following 353 three-tuple: 355 {Context, Capabilities, Constraints} 357 Context grounds the policy, and determines if it is relevant or not 358 for the current situation. Capabilities describe the functionality 359 that the policy can perform. Capabilities take different forms, 360 depending on the expressivity of the policy as well as the 361 programming paradigm(s) used. Constraints define any restrictions 362 on the capabilities to be used for that particular context. Metadata 363 can be optionally attached to each of the elements of the three- 364 tuple, and may be used to describe how the policy should be used and 365 how it operates, as well as prescribe any operational dependencies 366 that must be taken into account. 368 Put another way: 370 o Context selects policies based on applicability 372 o Capabilities describe the functionality provided by the policy 374 o Constraints restrict the capabilities offered and/or the behavior 375 of the policy 377 Hence, the difference between imperative, declarative, and other 378 types of policies lies in how the elements of this three-tuple are 379 used according to that particular programming paradigm. This is how 380 [SUPA] was designed: a Policy is a container that aggregates a set 381 of statements. 383 6.4. Policy Subjects and Policy Targets 385 Policy subject is the actor that performs the action specified in 386 the policy. It can be the intent management system which executes 387 the policy. Policy target is a set of managed objects which may be 388 affected in the policy enforcement. 390 6.5. Policy Scope 392 Policies used to manage the behavior of objects that they are 393 applied to (e.g., the target of the policy). 395 It is useful to differentiate between the following categories of 396 targets: 398 o Policies defined for the Customer or End-User 400 o Policies defined for the management system to act on objects in 401 the domain that the management system controls 403 o Policies defined for the management system to act on objects in 404 one or more domains that the management system does not directly 405 control 407 The different origins and views of these three categories of actors 408 lead to the following important differences: 410 o Network Knowledge. This area is explored using three exemplary 411 actors that have different knowledge of the network. 413 Customers and end-users do not necessarily know the functional and 414 operational details of the network that they are using. 415 Furthermore, most of the actors in this category lack skills to 416 understand such details; in fact, such knowledge is typically not 417 relevant to their job. In addition, the network may not expose 418 these details to its users. This class of actor focuses on the 419 applications that they run, and uses services offered by the 420 network. Hence, they want to specify policies that provide 421 consistent behavior according to their business needs. They do not 422 have to worry about how the policies are deployed onto the 423 underlying network, and especially, whether the policies need to be 424 translated to different forms to enable network elements to 425 understand them. 427 Application developers work in a set of abstractions defined by 428 their application and programming environment(s). For example, many 429 application developers think in terms of objects (for example, a 430 VPN). While this makes sense to the application developer, most 431 network devices do not have a VPN object per se; rather, the VPN is 432 formed through a set of configuration statements for that device in 433 concert with configuration statements for the other devices that 434 together make up the VPN. Hence, the view of application developers 435 matches the services provided by the network, but may not directly 436 correspond to other views of other actors. 438 Management personnel, such as network Administrators, have complete 439 knowledge of the underlying network. However, they may not 440 understand the details of the applications and services of Customers 441 and End-Users. 443 o Automation. In theory, intents from both end-user and management 444 system can be automated. In practice, most intents from end-user 445 are created manually according to business request. End-users do 446 not create or alter intents unless there is change in business. 447 Intents from management systems can be created or altered to 448 reflect with network policy change. For example, end-users 449 create intents to set up paths between hosts, while the 450 management system creates an intent to set a global link 451 utilization limit. 453 7. IANA Considerations 455 This document includes no request to IANA. 457 8. Security Considerations 459 This document does not have any Security Considerations. 461 9. IANA Considerations 463 This document includes no request to IANA. 465 10. References 467 10.1. Normative References 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 473 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 474 Networking: Definitions and Design Goals", RFC 7575, 475 DOI 10.17487/RFC7575, June 2015 477 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions", 478 2017, . 481 10.2. Informative References 483 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017, 484 . 487 [ONF] ONF, "Intent Definition Principles", 2017, 488 . 492 [ONOS] ONOS, "ONOS Intent Framework", 2017, 493 . 496 11. Acknowledgments 498 The authors would like to thank Will (Shucheng) Liu and Xiaolin Song 499 for their comments to this document. 501 Authors' Addresses 503 Chen Li 504 China Telecom 505 No.118 Xizhimennei street, Xicheng District 506 Beijing 100035 507 P.R. China 508 Email: lichen.bri@chinatelecom.cn 510 Ying Cheng 511 China Unicom 512 No.21 Financial Street, XiCheng District 513 Beijing 100033 514 P.R. China 515 Email: chengying10@chinaunicom.cn 517 John Strassner 518 Huawei Technologies 519 2330 Central Expressway 520 Santa Clara 95138 521 Email: john.sc.strassner@huawei.com 523 Olga Havel 524 Huawei Technologies 525 Email: olga.havel@huawei.com 527 Weiping Xu 528 Huawei Technologies 529 Bantian, Longgang District 530 shenzhen 518129 531 P.R. China 533 Email: xuweiping@huawei.com