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