rfc9316.original		rfc9316.txt
	Network Working Group C. Li
	Internet Draft China Telecom
	Intended status: Informational O. Havel
	Expires: November 2022 A. Olariu
	Huawei Technologies
	P. Martinez-Julia
	NICT
	J. Nobre
	UFRGS
	D. Lopez
	Telefonica, I+D
	May 18, 2022
	Intent Classification		Internet Research Task Force (IRTF) C. Li
	draft-irtf-nmrg-ibn-intent-classification-08		Request for Comments: 9316 China Telecom
			Category: Informational O. Havel
			ISSN: 2070-1721 A. Olariu
			Huawei Technologies
			P. Martinez-Julia
			NICT
			J. Nobre
			UFRGS
			D. Lopez
			Telefonica, I+D
			October 2022
			Intent Classification
	Abstract		Abstract
	Intent is an abstract, high-level policy used to operate the network.		Intent is an abstract, high-level policy used to operate a network.
	Intent-based management system includes an interface for users to		An intent-based management system includes an interface for users to
	input requests and an engine to translate the intents into the		input requests and an engine to translate the intents into the
	network configuration and manage their life-cycle.		network configuration and manage their life cycle.
	This document discusses mostly the concept of network intents, but		This document mostly discusses the concept of network intents, but
	other types of intents are also being considered. Specifically, it		other types of intents are also considered. Specifically, this
	highlights stakeholder perspectives of intent, methods to classify		document highlights stakeholder perspectives of intent, methods to
	and encode intent, the associated intent taxonomy, and defines		classify and encode intent, and the associated intent taxonomy; it
	relevant intent terms where necessary. This document provides a		also defines relevant intent terms where necessary, provides a
	foundation for intent related research and facilitates solution		foundation for intent-related research, and facilitates solution
	development.		development.
	This document is a product of the IRTF Network Management Research		This document is a product of the IRTF Network Management Research
	Group (NMRG).		Group (NMRG).
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Research Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IRTF). The IRTF publishes the results of Internet-related research
	time. It is inappropriate to use Internet-Drafts as reference		and development activities. These results might not be suitable for
	material or to cite them other than as "work in progress."		deployment. This RFC represents the consensus of the Network
			Management Research Group of the Internet Research Task Force (IRTF).
			Documents approved for publication by the IRSG are not candidates for
			any level of Internet Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on November 18, 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9316.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document.
	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................4		1. Introduction
	1.1. Research activities..........................................4		1.1. Research Activities
	1.2. Standards and open source activities.........................5		1.2. Standards and Open-Source Activities
	1.3. Scope........................................................6		1.3. Scope
	2. Acronyms.......................................................7		2. Abbreviations
	3. Definitions....................................................8		3. Definitions
	4. Abstract Intent Requirements...................................8		4. Abstract Intent Requirements
	4.1. What is Intent?..............................................8		4.1. What is intent?
	4.2. Intent Solutions and Intent Users............................9		4.2. Intent Solutions and Intent Users
	4.3. Benefits of Intents for Different Stakeholders..............11		4.3. Benefits of Intents for Different Stakeholders
	4.4. Intent Types that need to be supported......................12		4.4. Intent Types That Need to Be Supported
	5. Functional Characteristics and Behaviour......................13		5. Functional Characteristics and Behavior
	5.1. Abstracting Intent Operation................................13		5.1. Abstracting Intent Operation
	5.2. Intent User Types...........................................14		5.2. Intent User Types
	5.3. Intent Scope................................................15		5.3. Intent Scope
	5.4. Intent Network Scope........................................15		5.4. Intent Network Scope
	5.5. Intent Abstraction..........................................16		5.5. Intent Abstraction
	5.6. Intent Life-cycle...........................................16		5.6. Intent Life Cycle
	5.7. Autonomous Driving Levels...................................16		5.7. Autonomous Driving Levels
	6. Intent Classification.........................................17		6. Intent Classification
	6.1. Intent Classification Methodology...........................18		6.1. Intent Classification Methodology
	6.2. Intent Taxonomy.............................................21		6.2. Intent Taxonomy
	6.3. Intent Classification for Carrier Solution..................23		6.3. Intent Classification for Carrier Solution
	6.3.1. Intent Users and Intent Types.............................23		6.3.1. Intent Users and Intent Types
	6.3.2. Intent Categories.........................................27		6.3.2. Intent Categories
	6.3.3. Intent Classification Example.............................27		6.3.3. Intent Classification Example
	6.4. Intent Classification for Data Center Network Solutions.....31		6.4. Intent Classification for Data Center Network Solutions
	6.4.1. Intent Users and Intent Types.............................31		6.4.1. Intent Users and Intent Types
	6.4.2. Intent Categories.........................................35		6.4.2. Intent Categories
	6.4.3. Intent Classification Example.............................35		6.4.3. Intent Classification Example
	6.5. Intent Classification for Enterprise Solution...............39		6.5. Intent Classification for Enterprise Solution
	6.5.1. Intent Users and Intent Types.............................39		6.5.1. Intent Users and Intent Types
	6.5.2. Intent Categories.........................................41		6.5.2. Intent Categories
	7. Conclusions...................................................43		7. Conclusions
	8. Security Considerations.......................................43		8. Security Considerations
	9. IANA Considerations...........................................43		9. IANA Considerations
	10. Contributors.................................................44		10. Informative References
	11. Acknowledgments..............................................44		Acknowledgments
	12. Informative References.......................................44		Contributors
			Authors' Addresses
	1. Introduction		1. Introduction
	The vision of intent-based networks has attracted a lot of attention,		The vision of intent-based networks has attracted a lot of attention
	as it promises to simplify the management of networks by human		because it promises to simplify the management of networks by human
	operators. This is done by simply specifying what should happen on		operators. This is done by simply specifying what should happen on
	the network, without giving any instructions on how to do it. This		the network without giving any instructions on how to do it. This
	promise led many researcher-led activities and telecom companies to		promise caused many researcher-led activities and telecom companies
	start researching this new vision, and many Standards Development		to start researching this new vision and many Standards Development
	Organization (SDOs) to propose different intent frameworks.		Organizations (SDOs) to propose different intent frameworks.
	This draft proposes an intent classification methodology and an		This document proposes an intent classification methodology and an
	intent taxonomy. The scope of these proposals is to ensure a common		intent taxonomy. The scope of these proposals is to ensure a common
	understanding in the research community in terms of what are the		understanding in the research community in terms of what the intent
	intent users, intent types, or intent solutions, etc. for specific		users, intent types, or intent solutions, etc., are for specific
	scenarios that are being considered.		scenarios that are being considered.
	The document represents the consensus of the Network Management		The document represents the consensus of the Network Management
	Research Group (NMRG). It has been reviewed extensively by the		Research Group (NMRG). It has been reviewed extensively by the
	Research Group (RG) members who are actively involved in the research		Research Group (RG) members who are actively involved in the research
	and development of the technology covered by this document. It is not		and development of the technology covered by this document. It is
	an IETF product and is not a standard.		not an IETF product and is not a standard.
	1.1. Research activities		1.1. Research Activities
	Intent-based networking is an active research topic which spans		Intent-based networking is an active research topic spanning across
	across different areas that could benefit from an intent		different areas that could benefit from an intent classification and
	classification and taxonomy.		taxonomy.
	One such area is intent expression and recognition ([Bezahaf21],		Some examples include:
	[Bezahaf19]), NILE [Jacobs18]). The use of a common classification
	can provide consistency in the understanding of the various forms of
	intent expressions being proposed and investigated.
	Another area where this intent classification could contribute is the		* intent expression and recognition ([Bezahaf21], [Bezahaf19],
	orchestration of cognitive autonomous RANs [Banerjee21] where intents		[Jacobs18]). The use of a common classification could provide
	are classified based on their content.		consistency in the understanding of the various forms of intent
			expressions being proposed and investigated.
	The work carried in intent network verification [Tian19] where the		* the orchestration of cognitive autonomous radio access networks
	authors are proposing new intent language is another candidate where		(RANs) [Banerjee21] where intents are classified based on their
	intent classification could be used advantageously.		content.
	Furthermore, this draft is proving itself already extremely relevant		* intent network verification [Tian19], where the authors are
	to the research community as it has been used as the basis for		working to propose new intent language.
	proposing self-generated Intent-based systems [Bezhaf19], for
	advancing IBN-based VNF placement solutions that rely on defining		Furthermore, this document is already proving to be extremely
	user intent profiles corresponding to abstract network services		relevant to the research community as it has been used as the basis
	[Leivadeas21], for improving existing solutions in provisioning		for proposing self-generated Intent-based systems [Bezahaf19], for
	intent-based networks, and proposing new approaches to service		advancing Virtual Network Function (VNF) placement solutions based on
	management [Davoli21], or even for defining grammars for users to		Internet-Based Networks (IBNs) that rely on defining user intent
	specify the high-level requirements for blockchain selection in the		profiles corresponding to abstract network services [Leivadeas21],
	form of intent [Padovan20]. As well, the draft has been mentioned in		for improving existing solutions in provisioning intent-based
			networks, for proposing new approaches to service management
			[Davoli21], and even for defining grammars for users to specify the
			high-level requirements for blockchain selection in the form of
			intent [Padovan20]. As well, the document has been mentioned in
	surveys addressing the topic of intelligent intent-based autonomous		surveys addressing the topic of intelligent intent-based autonomous
	networks [Mehmood21], [Szilagyi21].		networks [Mehmood21] [Szilagyi21].
	This document describes as well an example on how this proposal has		This document also describes an example on how this proposal has been
	been successfully applied in an academic environment [IBN-POC] by		successfully applied in an academic environment [POC-IBN] by
	researchers in the area of SDN/NFV for defining the scope of their		researchers in the area of Software-Defined Networking / Network
	project. The specific problem addressed by researches is how to		Function Virtualization (SDN/NFV) for defining the scope of their
			project. The specific problem addressed by researchers is how to
	apply intent concepts at different levels that correspond to		apply intent concepts at different levels that correspond to
	different stakeholders.		different stakeholders.
	IEEE Communications Society Technical Committee on Network Operation		The IEEE Communications Society Technical Committee on Network
	and Management (IEEE-CNOM), IRTF-NMRG and IFIP WG6.6 have developed a		Operation and Management (IEEE-CNOM), IRTF Network Management
	taxonomy for network and service management [IFIP-NSM] that is used		Research Group, and IFIP WG6.6 have developed a taxonomy for network
	by the research community in network management and operations to		and service management [IFIP-NSM] that is used by the research
	structure the research area through a well-defined set of keywords		community in network management and operations to structure the
	and to improve quality of reviews in submissions to journals,		research area through a well-defined set of keywords and to improve
	conferences and workshops. The proposed intent taxonomy may be		quality of reviews in submissions to journals, conferences, and
	contributed as an extension to this taxonomy for intent driven		workshops. The proposed intent taxonomy may be contributed as an
	management.		extension to this taxonomy for intent-driven management.
	1.2. Standards and open source activities		1.2. Standards and Open-Source Activities
	Several SDOs and open source projects, such as Internet Research Task		Several SDOs and open-source projects, such as the IRTF NMRG, Open
	Force (IRTF)/ Network Management Research Group (NMRG), Open
	Networking Foundation (ONF) [ONF] / Open Network Operating System		Networking Foundation (ONF) [ONF] / Open Network Operating System
	(ONOS) [ONOS], European Telecommunications Standards Institute		(ONOS) [ONOS], European Telecommunications Standards Institute (ETSI)
	(ETSI)/Experiential Networked Intelligence (ENI), TMF with its		/ Experiential Networked Intelligence (ENI), and TMF with its
	Autonomous Networks, have proposed intents for defining a set of		autonomous networks, have proposed intents for defining a set of
	network operations to execute in a declarative manner.		network operations to execute in a declarative manner.
	More recently, the IRTF NMRG is working on the Intent-based		More recently, the IRTF NMRG is working on "Intent-Based Networking -
	Networking - Concepts and Definitions document, [CLEMM]. This		Concepts and Definitions" [RFC9315]. This document clarifies the
	document clarifies the concept of "Intent" and provides an overview		concept of "Intent" and provides an overview of the functionality
	of the functionality that is associated with it. The goal is to		that is associated with it. The goal is to contribute towards a
	contribute towards a common and shared understanding of terms,		common and shared understanding of terms, concepts, and functionality
	concepts, and functionality that can be used as the foundation to		that can be used as the foundation to guide further definition of
	guide further definition of associated research and engineering		associated research and engineering problems and their solutions.
	problems and their solutions.
	The present document, together with [CLEMM], aims to become the		The present document, together with [RFC9315], aims to become the
	foundation for future intent-related topic discussions regarding the		foundation for future intent-related topic discussions regarding the
	NMRG.		NMRG.
	The SDOs usually came up with their own way of specifying an intent,		The SDOs usually come up with their own way of specifying an intent
	and with their own understanding of what an intent is. Besides that,		and their own understanding of what an intent is. Additionally, each
	each SDO defines a set of terms and level of abstraction, its		SDO defines a set of terms and level of abstraction, its intent
	intended intent users, and the applications and usage scenarios.		users, and the applications and usage scenarios.
	However, most intent approaches proposed by SDOs share the same		However, most intent approaches proposed by SDOs share the same
	following features:		features:
	o It must be declarative in nature, meaning that an intent user		* It must be declarative in nature, meaning that an intent user
	specifies the goal on the network without specifying how to achieve		specifies the goal on the network without specifying how to
	that goal.		achieve that goal.
	o It must be vendor agnostic, in the sense that it abstracts the		* It must be vendor agnostic in the sense that it abstracts the
	network capabilities, or the network infrastructure from the intent		network capabilities or the network infrastructure from the intent
	user, and it can be ported across different platforms.		user, and it can be ported across different platforms.
	o It must provide an easy-to-use interface, which simplifies the		* It must provide an easy-to-use interface, which simplifies the
	intent users' interaction with the intent system through the usage		interaction of the intent users with the intent system through the
	of familiar terminology or concepts.		usage of familiar terminology or concepts.
	It should be able to detect and resolve intent conflicts, which		* It should be able to detect and resolve intent conflicts, which
	include, for example, static (compile-time) conflicts and dynamic		include, for example, static (compile-time) conflicts and dynamic
	(run-time) conflicts.		(run-time) conflicts.
	1.3. Scope		1.3. Scope
	The focus of this document is on the definition of criteria enabling		The focus of this document is on the definition of criteria enabling
	to categorize intents from the stakeholders' viewpoint. Concepts and		the categorization of intents from viewpoint of the stakeholders.
	definitions related to IBN are provided in [CLEMM].		Concepts and definitions related to IBN are provided in [RFC9315].
	This document mostly addresses intents in the context of network		This document mostly addresses intents in the context of network
	intents, however other types of intents are not excluded, as		intents; however, other types of intents are not excluded, as
	presented in section 4.4. and section 6.2. .		presented in Sections 4.4 and 6.2.
	It is impossible to fully differentiate intents only by the common		It is impossible to fully differentiate intents only by the common
	characteristics followed by concepts, terms and intentions. This		characteristics followed by concepts, terms, and intentions. This
	document clarifies what an intent represents for different		document clarifies what an intent represents for different
	stakeholders through a classification on various dimensions, such as		stakeholders through a classification on various dimensions, such as
	solutions, intent users, and intent types. This classification		solutions, intent users, and intent types. This classification
	ensures common understanding among all participants and is used to		ensures common understanding among all participants and is used to
	determine the scope and priority of individual projects, proof-of-		determine the scope and priority of individual projects, proof of
	concept (PoCs), research initiatives, or open source projects.		concepts (PoCs), research initiatives, or open-source projects.
	The scope of intent classification in this document includes		The scope of intent classification in this document includes
	solutions, intent users and intent types, and the initial		solutions, intent users, and intent types; the initial classification
	classification table is made according to this scope. The		table is made according to this scope. The methodology presented can
	methodology presented can be used to update the classification		be used to update the classification tables by adding or removing
	tables by adding or removing different solutions, intent users, or		different solutions, intent users, or intent types to cater to future
	intent types to cater for future scenarios, applications or domains.		scenarios, applications, or domains.
	2. Acronyms		2. Abbreviations
	AI: Artificial Intelligence		AI: Artificial Intelligence
	CE: Customer Equipment		CE: Customer Equipment
	CFS: Customer Facing Service		CFS: Customer Facing Service
	CLI: Command Line Interface		CLI: Command-Line Interface
	DB: Database		DB: Database
	DC: Data Center		DC: Data Center
	ECA: Event-Condition-Action		ECA: Event Condition Action
	GBP: Group-Based Policy		GBP: Group-Based Policy
	GPU: Graphics Processing Unit		GPU: Graphics Processing Unit
	IBN: Intent Based Network		IBN: Intent-Based Network
	NFV: Network Function Virtualization		NFV: Network Function Virtualization
	O&M: Operations & Maintenance		O&M: OAM & Maintenance
	ONF: Open Networking Foundation		ONF: Open Networking Foundation
	ONOS: Open Network Operating System		ONOS: Open Network Operating System
	PNF: Physical Network Function		PNF: Physical Network Function
	QoE: Quality of Experience		QoE: Quality of Experience
	RFS: Resource Facing Service		RFS: Resource Facing Service
	SDO: Standards Development Organization
	SD-WAN: Software-Defined Wide-Area Network		SDO: Standards Development Organization
	SLA: Service Level Agreement		SD-WAN: Software-Defined Wide-Area Network
	SUPA: Simplified Use of Policy Abstractions		SLA: Service Level Agreement
	VM: Virtual Machine		SUPA: Simplified Use of Policy Abstractions
	VNF: Virtual Network Function		VM: Virtual Machine
	3. Definitions		VNF: Virtual Network Function
	A common and shared understanding of terms and definitions related		3. Definitions
	to IBN is provided in [CLEMM], as follows:
	o Intent: A set of operational goals (that a network should meet)		A common and shared understanding of terms and definitions related to
	and outcomes (that a network is supposed to deliver), defined		IBN is provided in [RFC9315] as follows:
	in a declarative manner without specifying how to achieve or
	implement them.
	o Intent-Based Network: A network that can be managed using		Intent: A set of operational goals (that a network should meet) and
	intent.		outcomes (that a network is supposed to deliver) defined in a
			declarative manner without specifying how to achieve or implement
			them.
	o Policy: A set of rules that governs the choices in behaviour of		Intent-Based Network: A network that can be managed using intent.
	a system.
	o Intent User: A user that defines and issues the intent request		Policy: A set of rules that governs the choices in behavior of a
	to the intent-based management system.		system.
	Other definitions relevant to this draft, such as intent scope,		Intent User: A user that defines and issues the intent request to
			the intent-based management system.
			Other definitions relevant to this document, such as intent scope,
	intent network scope, intent abstraction, intent abstraction, and		intent network scope, intent abstraction, intent abstraction, and
	intent lifecycle are available in section 5.		intent life cycle are available in Section 5.
	4. Abstract Intent Requirements		4. Abstract Intent Requirements
	In order to understand the different intent requirements that would		In order to understand the different intent requirements that would
	drive intent classification, we first need to understand what intent		drive intent classification, we first need to understand what intent
	means for different intent users.		means for different intent users.
	4.1. What is Intent?		4.1. What is intent?
	The term Intent has become very widely used in the industry for		The term "Intent" has become very widely used in the industry for
	different purposes, sometimes it is not even in agreement with SDO		different purposes; sometimes its use is not even in agreement with
	shared principles mentioned in the Introduction section.[CLEMM] draft		SDO-shared principles mentioned in Section 1. [RFC9315] brings
	brings clarification with relation to what an intent is and how it		clarification with relation to what an intent is and how it
	differentiates from policies and services.		differentiates from policies and services.
	Different stakeholders have different perspective of the network and		Different stakeholders have different perspectives of the network;
	therefore have different intent requirements. Their intent is		therefore, they have different intent requirements. Their intent is
	sometimes technical, non-technical, abstract or technology specific.		sometimes technical, non-technical, abstract, or technology specific.
	Therefore, it is important to start a discussion in the industry and		Therefore, it is important to start a discussion in the industry and
	academia communities about what intent is for different solutions and		academic communities about what intent is for different solutions and
	intent users. It is also imperative to try to propose some intent		intent users. It is also imperative to try to propose some intent
	categories/ classifications that could be understood by a wider		categories/classifications that could be understood by a wider
	audience. This would help us define intent interfaces, domain-		audience. This would help us define intent interfaces, domain-
	specific languages, and models.		specific languages, and models.
	4.2. Intent Solutions and Intent Users		4.2. Intent Solutions and Intent Users
	Intent types are defined by all aspects that are required to profile		Intent types are defined by all aspects that are required to profile
	different requirements to easily distinguish among them. However, in		different requirements to easily distinguish between them. However,
	order to facilitate a clustered classification, we can focus on two		in order to facilitate a clustered classification, we can focus on
	aspects, the solution and intent user. They can be considered as the		two aspects: the solution and intent user. They can be considered to
	main keys to classify intents, as we can easily group requirements by		be the main keys to classify intents, as we can easily group
	solution and intent user.		requirements by solution and intent user.
	On the one hand, different solutions and intent users have different		On the one hand, different solutions and intent users have different
	requirements, expectations and priorities for intent-based		requirements, expectations, and priorities for intent-based
	networking. Therefore, intent users require different intent types,		networking. Therefore, intent users require different intent types,
	depending on their context, since they participate in different use		depending on their context, since they participate in different use
	cases. For instance, some intent users are more technical and require		cases. For instance, some intent users are more technical and
	intents that expose more technical information. Other intent users do		require intents that expose more technical information. Other intent
	not have knowledge of the network infrastructure and require intents		users do not have knowledge of the network infrastructure and require
	that shield them from different networking concepts and technologies.		intents that shield them from different networking concepts and
			technologies.
	The following are the solutions and intent users that intent-based		The following are the solutions and intent users that intent-based
	networking needs to support:		networking needs to support:
	+--------------------+------------------------------------+		+============+=====================================+
	| Solutions | Intent Users |		| Solutions | Intent Users |
	+--------------------+------------------------------------+		+============+=====================================+
	| Carrier Networks | Network Operator |		| Carrier | Network Operators, Service |
	| | Service Designers/App Developer |		| Networks | Designers / App Developers, Service |
	| | Service Operators |		| | Operators, Customers / Subscribers |
	| | Customers/Subscribers |		+------------+-------------------------------------+
	+--------------------+------------------------------------+		| DC | Cloud Administrators, Underlay |
	| DC Networks | Cloud Administrator |		| Networks | Network Administrators, Application |
	| | Underlay Network Administrator |		| | Developers, Customers / Tenants |
	| | Application Developers |		+------------+-------------------------------------+
	| | Customer/Tenants |		| Enterprise | Enterprise Administrators, |
	+--------------------+------------------------------------+		| Networks | Application Developers, End Users |
	| Enterprise Networks| Enterprise Administrator |		+------------+-------------------------------------+
	| | Application Developers |
	| | End-Users |
	+--------------------+------------------------------------+
	Table 1 - Intent Solutions and Intent Users
	These intent solutions and intent users represent a starting point		Table 1: Intent Solutions and Intent Users
	for the classification and are expendable through the methodology
	presented in section 6.1. .
	o For carrier networks scenario, for example, if a		These intent solutions and intent users represent a starting point
	customer/subscriber wants to watch high-definition video, then the		for the classification and are expendable through the methodology
	intent is to convert the video image to 1080p rate.		presented in Section 6.1.
	o For DC networks scenario, administrators have their own clear		* For carrier network scenarios, for example, if a customer/
	network intent such as load balancing. For all traffic flows that		subscriber wants to watch high-definition video, then the intent
	need NFV service chaining, restrict the maximum load of any VNF		is to convert the video image to 1080p.
	node/container below 50% and the maximum load of any network link
	below 70%.
	o For enterprise networks scenario, when hosting a video conference		* For DC network scenarios, administrators have their own clear
	multiple remote accesses are required. An example of the intent		network intent such as load balancing. For all traffic flows that
	from the network administrator is: for any end-user of this		need NFV service chaining, they can restrict the maximum load of
	application, the arrival time of hologram objects of all the		any VNF node / container below 50% and the maximum load of any
	remote tele-presenters should be synchronised within 50ms to reach		network link below 70%.
	the destination viewer for each conversation session.
	o		* For enterprise network scenarios, when hosting a video conference,
			multiple remote accesses are required. An example of the intent
			from the network administrator is as follows: for any end user of
			this application, the arrival time of hologram objects of all the
			remote tele-presenters should be synchronized within 50 ms to
			reach the destination viewer for each conversation session.
	4.3. Benefits of Intents for Different Stakeholders		4.3. Benefits of Intents for Different Stakeholders
	Current network APIs and CLIs are too complex because they are highly		Current network APIs and CLIs are too complex because they are highly
	integrated with the low level concepts exposed by networks.		integrated with the low-level concepts exposed by networks.
	Customers, application developers and end-users must not be required		Customers, application developers, and end users must not be required
	to set IP addresses, VLANs, subnets, ports, while operators may still		to set IP addresses, VLANs, subnets, or ports, whereas operators may
	want to have more technical and network visibility. All stakeholders		still want to have both more technical and network visibility. All
	would benefit from the simpler interfaces, like:		stakeholders would benefit from simpler interfaces, such as:
	o Request gold VPN service between my sites A, B and C		* request gold VPN service between sites A, B, and C
	o Provide CE redundancy for the customer sites		* provide CE redundancy for the customer sites
	o Add access rules to the network service		* add access rules to the network service
	Operators and administrators manually troubleshoot and fix their		Operators and administrators manually troubleshoot and fix their
	networks and services. They instead want to:		networks and services. They instead want to:
	o simplify and automate network operations		* simplify and automate network operations
	o simplify definitions of network services		* simplify definitions of network services
	o provide simple customer APIs for value added services (operators)		* provide simple customer APIs for value-added services (operators)
	o be informed if the network or service is not behaving as requested		* be informed if the network or service is not behaving as requested
	o enable automatic optimization and correction for selected		* enable automatic optimization and correction for selected
	scenarios		scenarios
	o have systems that learn from historic information and behaviour		* have systems that learn from historic information and behavior
	Currently, intent users cannot build their own services and policies		Currently, intent users cannot build their own services and policies
	without becoming technical experts and performing manual maintenance		without becoming technical experts and performing manual maintenance
	actions. They instead want to be able to:		actions. They instead want to be able to:
	o build their own network services with their own policies via		* build their own network services with their own policies via
	simple interfaces, without becoming networking experts		simple interfaces, without becoming networking experts
	o have their network services up and running based on intent and		* have their network services up and running based on intent and
	automation only, without any manual actions or maintenance		automation only, without any manual actions or maintenance
	o		4.4. Intent Types That Need to Be Supported
	4.4. Intent Types that need to be supported
	Next to the intent solutions and intent users, another way to		Next to the intent solutions and intent users, another way to
	categorize the intent is through the intent types. The following		categorize the intent is through the intent types. The following
	intent types and subtypes need to be supported, in order to address		intent types and subtypes need to be supported in order to address
	the requirements from different solutions and intent users:		the requirements from different solutions and intent users.
	o Customer service intent		* Customer service intent
	o for customer self-service with SLA		- for customer self service with SLA
	o for service operator orders		- for service operator orders
	o Network and underlay network service intent		* Network and underlay network service intent
	o for service operator orders		- for service operator orders
	o for intent driven network configuration, verification,		- for intent-driven network configuration, verification,
	correction and optimization		correction, and optimization
	o for intent created and provided by the underlay network		- for intent created and provided by the underlay network
	administrator		administrator
	o Network and underlay network intent		* Network and underlay network intent
	o for network configuration		- for network configuration
	o for automated lifecycle management of network configurations		- for automated life-cycle management of network configurations
	o for network resources (switches, routers, routing, policies,		- for network resources (switches, routers, routing, policies,
	underlay)		and underlay)
	o Cloud management intent		* Cloud management intent
	o for DC configuration, VMs, DB servers, APP servers		- for DC configuration, VMs, DB servers, and Application servers
	o for communication between VMs		- for communication between VMs
	o Cloud resource management intent		* Cloud resource management intent
	o for cloud resource life-cycle management (policy driven self-		- for cloud resource life-cycle management (policy-driven self-
	configuration and auto-scaling and recovery/optimization)		configuration and auto-scaling and recovery/optimization)
	o Strategy intent		* Strategy intent
	o for security, QoS, application policies, traffic steering, etc.		- for security, QoS, application policies, traffic steering, etc.
	o for configuring and monitoring policies, alarms generation for		- for configuring and monitoring policies, alarm generation for
	non-compliance, auto-recovery		non-compliance, and auto-recovery
	o for design models and policies for network and network service		- for design models and policies for network and network service
	design		design
	o for design workflows, models and policies for operational task		- for design workflows, models, and policies for operational task
	intents		intents
	o Operational task intents		* Operational task intents
	o for network migration		- for network migration
	o for device replacements		- for device replacements
	o for network software upgrades		- for network software upgrades
	o for automating any other tasks that operators/administrator		- for automating any other tasks that operators/administrator
	often perform		often perform
	It is important to mention there all of the previously mentioned		It is important to mention all of the previously mentioned types and
	types and subtypes may affect other intents. For example, operational		subtypes may affect other intents. For example, operational task
	task intent can modify many other intents. The task itself is short-		intent can modify many other intents. The task itself is short
	lived, but the modification of other intents has an impact on their		lived, but the modification of other intents has an impact on their
	life-cycle, so those changes must continue to be continuously		life cycle, so those changes must continue to be continuously
	monitored and self-corrected/self-optimized.		monitored and self corrected/optimized.
	5. Functional Characteristics and Behaviour		5. Functional Characteristics and Behavior
	Intent can be used to operate immediately on a target (much like		Intent can be used to operate immediately on a target (much like
	issuing a command), or whenever it is appropriate (e.g., in response		issuing a command) or whenever it is appropriate (e.g., in response
	to an event). In either case, intent has a number of behaviours that		to an event). In either case, intent has a number of behaviors that
	serve to further organize its purpose, as described by the following		serve to further organize its purpose, as described by the following
	subsections.		subsections.
	5.1. Abstracting Intent Operation		5.1. Abstracting Intent Operation
	The modelling of intents can be abstracted using the following		The modeling of intents can be abstracted using the following three-
	three-tuple:		tuple:
	{Context, Capabilities, Constraints}		{Context, Capabilities, Constraints}
	o Context grounds the intent, and determines if it is relevant or		* Context grounds the intent and determines if it is relevant or not
	not for the current situation. Thus, context selects intents based		for the current situation. Thus, context selects intents based on
	on applicability.		applicability.
	o Capabilities describe the functionality that the intent can		* Capabilities describe the functionality that the intent can
	perform. Capabilities take different forms, depending on the		perform. Capabilities take different forms depending on the
	expressivity of the intent as well as the programming paradigm(s)		expressivity of the intent as well as the programming paradigm(s)
	used.		used.
	o Constraints define any restrictions on the capabilities to be used		* Constraints define any restrictions on the capabilities to be used
	for that particular context.		for that particular context.
	Metadata can be attached via strategy templates to each of the		Metadata can be attached via strategy templates to each of the
	elements of the three-tuple, and may be used to describe how the		elements of the three-tuple and may be used to describe how the
	intent should be used and how it operates, as well as prescribe any		intent should be used and how it operates as well as prescribe any
	operational dependencies that must be taken into account.		operational dependencies that must be taken into account.
	Although different intent categories share the same abstracted intent		Although different intent categories share the same abstracted intent
	model, each category will have its own specific context, capabilities		model, each category will have its own specific context,
	and constraints.		capabilities, and constraints.
	5.2. Intent User Types		5.2. Intent User Types
	Expanding on the introduction in section 4.2. , intent user types		Expanding on the introduction in Section 4.2, intent user types
	represent the intent users that define and issue the intent request.		represent the intent users that define and issue the intent request.
	Depending on the intent solutions, there are specific intent users.		Depending on the intent solutions, there are specific intent users.
	Examples of intent users are customers, network operators, service		Examples of intent users are customers, network operators, service
	operators, enterprise administrators, cloud administrators, and		operators, enterprise administrators, cloud administrators, underlay
	underlay network administrators, or application developers.		network administrators, or application developers.
	o Customers and end-users do not necessarily know the functional and		* Customers and end users do not necessarily know the functional and
	operational details of the network that they are using.		operational details of the network that they are using.
	Furthermore, they lack skills to understand such details; in fact,		Furthermore, they lack skills to understand such details; in fact,
	such knowledge is typically not relevant to their job. In		such knowledge is typically not relevant to their job. In
	addition, the network may not expose these details to its intent		addition, the network may not expose these details to its intent
	users. This class of intent users focuses on the applications that		users. This class of intent users focuses on the applications
	they run, and uses services offered by the network. Hence, they		that they run and uses services offered by the network. Hence,
	want to specify policies that provide consistent behaviour		they want to specify policies that provide consistent behavior
	according to their business needs. They do not have to worry about		according to their business needs. They do not have to worry
	how the intents are deployed onto the underlying network, and		about how the intents are deployed onto the underlying network and
	especially, whether the intents need to be translated to different		especially whether the intents need to be translated to different
	forms to enable network elements to understand them.		forms to enable network elements to understand them.
	o Application developers work in a set of abstractions defined by		* Application developers work in a set of abstractions defined by
	their application and programming environment(s). For example,		their application and programming environment(s). For example,
	many application developers think in terms of objects (e.g., a		many application developers think in terms of objects (e.g., a
	VPN). While this makes sense to the application developer, most		VPN). While this makes sense to the application developer, most
	network devices do not have a VPN object per se; rather, the VPN		network devices do not have a VPN object per se; rather, the VPN
	is formed through a set of configuration statements for that		is formed through a set of configuration statements for that
	device in concert with configuration statements for the other		device in concert with configuration statements for the other
	devices that together make up the VPN. Hence, the view of		devices that together make up the VPN. Hence, the view of
	application developers matches the services provided by the		application developers matches the services provided by the
	network, but may not directly correspond to other views of other		network but may not directly correspond to other views of other
	intent users.		intent users.
	o Network operators may have the knowledge of the underlying		* Network operators may have the knowledge of the underlying
	network. However, they may not understand the details of the		network. However, they may not understand the details of the
	applications and services of customers.		applications and services of customers.
	5.3. Intent Scope		5.3. Intent Scope
	Intents are used to manage the behaviour of the networks they are		Intents are used to manage the behavior of the networks they are
	applied to and all intents are applied within a specific scope, such		applied to and all intents are applied within a specific scope, such
	as:		as:
	o Connectivity scope, if the intent creates or modifies a		* connectivity scope, if the intent creates or modifies a connection
	connection.
	o Security/privacy scope, if the intent specifies the security
	characteristics of the network, customers, or end-users.
	o Application scope, when the intent specifies the applications to
	be affected by the intent request.
	o QoS scope, when the intent specifies the QoS characteristics of
	the network.
	These intent scopes are expendable through the methodology presented		* security/privacy scope, if the intent specifies the security
	in section 6.1. .		characteristics of the network, customers, or end users
	5.4. Intent Network Scope		* application scope, when the intent specifies the applications to
			be affected by the intent request
	Regardless on the intent user type, their intent request is affecting		* QoS scope, when the intent specifies the QoS characteristics of
	the network, or network components, which are representing the intent		the network
			These intent scopes are expendable through the methodology presented
			in Section 6.1.
			5.4. Intent Network Scope
			Regardless of the intent user type, their intent request affects the
			network, or network components, which are representing the intent
	targets.		targets.
	Thus, intent network scope, or policy target as known in the area of		Thus, the intent network scope, or policy target as known in the area
	declarative policy, can represent VNFs or PNFs, physical network		of declarative policy, can represent VNFs or PNFs, physical network
	elements, campus networks, SD-WAN networks, radio access networks,		elements, campus networks, SD-WANs, RANs, cloud edges, cloud cores,
	cloud edge, cloud core, branch, etc.		branches, etc.
	5.5. Intent Abstraction		5.5. Intent Abstraction
	Intent can be classified by whether it is necessary to feedback		Intent can be classified by whether it is necessary to feed back
	technical network information or non-technical information to the		technical network information or non-technical information to the
	intent user after the intent is executed. As well, intent abstraction		intent user after the intent is executed. As well, intent
	covers the level of technical details in the intent itself.		abstraction covers the level of technical details in the intent
			itself.
	o For non-technical intent users, they do not care how the intent is		* Non-technical intent users do not care how the intent is executed
	executed, or the details of the network. As a result, they do not		nor do they care about the details of the network. As a result,
	need to know the configuration information of the underlying		they do not need to know the configuration information of the
	network. They only focus on whether the intent execution result		underlying network. They only focus on whether the intent
	achieves the goal, and the execution effect such as the quality of		execution result achieves the goal and the execution effect such
	completion and the length of execution. In this scenario, we refer		as the quality of completion and the length of execution. In this
	to an abstraction without technical feedback.		scenario, we refer to an abstraction without technical feedback.
	o For administrators, such as network administrators, they perform		* Administrators, such as network administrators, perform intents,
	intents, such as allocating network resources, selecting		such as allocating network resources, selecting transmission
	transmission paths, handling network failures, etc. They require		paths, handling network failures, etc. They require multiple
	multiple feedback indicators for network resource conditions,		feedback indicators for network resource conditions, congestion
	congestion conditions, fault conditions, etc. after execution. In		conditions, fault conditions, etc., after execution. In this
	this case, we refer to an abstraction with technical feedback.		case, we refer to an abstraction with technical feedback.
	As per intent definition provided in [CLEMM], lower-level intents are		As per the definition of "intent" provided in [RFC9315], lower-level
	not considered to qualify as intents. However, we kept this		intents are not considered to qualify as intents. However, we kept
	classification to identify any PoCs/Demos/Use Cases that still either		this classification to identify any PoCs / Demos / Use Cases that
	require or implement lower level of abstraction for intents.		still either require or implement a lower level of abstraction for
			intents.
	5.6. Intent Life-cycle		5.6. Intent Life Cycle
	Intents can be classified into transient and persistent intents:		Intents can be classified into transient and persistent intents:
	o If the intent is transient, it has no life-cycle management. As		Transient: The intent has no life-cycle management. As soon as the
	soon as the specified operation is successfully carried out, the		specified operation is successfully carried out, the intent is
	intent is finished, and can no longer affect the target object.		finished and can no longer affect the target object.
	o If the intent is persistent, it has life-cycle management. Once		Persistent: The intent has life-cycle management. Once the intent
	the intent is successfully activated and deployed, the system will		is successfully activated and deployed, the system will keep all
	keep all relevant intents active until they are deactivated or		relevant intents active until they are deactivated or removed.
	removed.
	5.7. Autonomous Driving Levels		5.7. Autonomous Driving Levels
	In different phases of the autonomous driving network [TMF-auto], the		In different phases of the autonomous driving network [TMF-AUTO], the
	intents are different. Depending on the Autonomous Network Level of		intents are different. Depending on the Autonomous Network Level of
	the overall solution, we may have different intent requirements and		the overall solution, we may have different intent requirements and
	types. For example, at lower level the customer intent is		types. For example, at lower levels, the customer intent is:
	automatically converted to configuration policies only, while at the
	higher levels the customer intent is covering the full life cycle, it
	is converted to both configuration and monitoring policies and is
	self-assured using AI.
	A typical example of autonomous driving network level 0 to 5 are		* automatically converted to configuration policies only while at
	listed as below.		the higher levels,
	o Level 0 - Traditional manual network: O&M personnel manually		* covering the full life cycle,
	control the network and obtain network alarms and logs. - No
	intent
	o Level 1 - Partially automated network: Automated scripts are used		* converted to both configuration and monitoring policies, and
	to automate service provisioning, network deployment, and
	maintenance. Shallow perception of network status and decision
	making suggestions of machine; - No intent
	o Level 2 - Automated network: Automation of most service		* self assured using AI.
	provisioning, network deployment, and maintenance of a
	comprehensive perception of network status and local machine
	decision making; - simple intent on service provisioning
	o Level 3 - Self-optimization network: Deep awareness of network		Typical examples of autonomous driving networks level 0 to 5 are
	status and automatic network control, meeting requirements of		shown below.
	intent users of the network. - Intent based on network status
	cognition
	o Level 4 - Partial autonomous network: In a limited environment,		Level 0 - Traditional manual network:
	people do not need to participate in decision-making and networks		O&M personnel manually control the network and obtain network
	can adjust itself. - Intent based on limited AI		alarms and logs.
	o Level 5 - Autonomous network: In different network environments		- No intent
	and network conditions, the network can automatically adapt to and
	adjust to meet people's intentions. - Intent based on AI
	6. Intent Classification		Level 1 - Partially automated network:
			Automated scripts are used to automate service provisioning,
			network deployment, and maintenance. The network provides shallow
			perception of the network status and decision making suggestions.
	This section proposes an intent classification approach that may help		- No intent
	to classify mainstream intent related demos/tools.
			Level 2 - Automated network:
			This entails the automation of most service provisioning, network
			deployment, and maintenance of a comprehensive perception of
			network status and local machine decision-making.
			- simple intent on service provisioning
			Level 3 - Self-optimization network:
			This entails a deep awareness of network status and automatic
			network control, meeting requirements of intent users of the
			network.
			- Intent based on network status cognition
			Level 4 - Partial autonomous network:
			In a limited environment, people do not need to participate in
			decision-making and networks can adjust themselves.
			- Intent based on limited AI
			Level 5 - Autonomous network:
			In different network environments and network conditions, the
			network can automatically adapt and adjust to meet people's
			intentions.
			- Intent based on AI
			6. Intent Classification
			This section proposes an approach to intent classification that may
			help to classify mainstream intent-related demos/tools.
	The three classifications in this document have been proposed from		The three classifications in this document have been proposed from
	scratch, following the methodology presented, through three		scratch (following the methodology presented) through three
	iterations: one for carrier network intent solution, one for DC		iterations: one for a carrier network intent solution, one for a DC
	intent solution, and one for enterprise intent solution. For each		intent solution, and one for an enterprise intent solution. For each
	intent solution, we identified the specific intent users and intent		intent solution, we identified the specific intent users and intent
	types. Then, we further identified intent scope, network scope,		types. Then, we further identified intent scope, network scope,
	abstractions, and life-cycle requirements.		abstractions, and life-cycle requirements.
	These classifications and the generated tables can be easily		These classifications and the generated tables can be easily
	extended. For example, for the DC intent solution, a new category is		extended. For example, for the DC intent solution, a new category
	identified, i.e. resource scope, and the classification table has		"resource scope" is identified, and the classification table has been
	been extended accordingly.		extended accordingly.
	In the future, as new scenarios, applications, and domains are		In the future, as new scenarios, applications, and domains emerge,
	emerging, new classifications and taxonomies can be identified,		new classifications and taxonomies can be identified, following the
	following the proposed methodology.		proposed methodology.
	The intent classifications have been documented to the best of our		The intent classifications have been documented to the best of our
	knowledge at this point in time. Additional classifications will most		knowledge at the time of writing. Additional classifications will
	probably see the light in the future.		most likely come to light in the future.
	The output of the intent classification is the intent taxonomy		The output of the intent classification is the intent taxonomy
	introduced in the next sections.		introduced in the subsections of this section.
	Thus, this section first introduces the proposed intent		Thus, the subsections of Section 6 introduce the proposed intent
	classification methodology, followed by consolidated intent taxonomy		classification methodology, the consolidated intent taxonomy for
	for three intent solutions, and then by concrete examples of intent		three intent solutions, and the concrete examples of intent
	classifications for three different intent solutions (e.g. carrier		classifications for three different intent solutions (e.g., carrier
	network, data center, and enterprise) that were derived using the		network, data center, and enterprise) that were derived using the
	proposed methodology and then can be filled in for PoCs, demos,		proposed methodology and can be filled in for PoCs, demos, research
	research projects or future drafts.		projects, or future documents.
	6.1. Intent Classification Methodology		6.1. Intent Classification Methodology
	This section describes the methodology used to derive the initial		This section describes the methodology used to derive the initial
	classification proposed in the draft. The proposed methodology can be		classification proposed in the document. The proposed methodology
	used to create new intent classifications from scratch, by analysing		can be used to create new intent classifications from scratch by
	the solution knowledge. As well, the methodology can be used to		analyzing the solution knowledge. As well, the methodology can be
	update existing classification tables by adding or removing different		used to update existing classification tables by adding or removing
	solutions, intent users or intent types in order to cater for future		different solutions, intent users, or intent types in order to cater
	scenarios, applications or domains.		to future scenarios, applications, or domains.
	+------------------------------------------+		+------------------------------------------+
	|Solution Knowledge (requirements, |		|Solution Knowledge (requirements, |
	|use cases, technologies, network, intent |		|use cases, technologies, network, intent |
	|users, intent requirements) |		|users, intent requirements) |
	+----------------+-------------------------+		+----------------+-------------------------+
	| Input Rx=Read		| Input Rx=Read
	| Ux=Update (Add/Remove)		| Ux=Update (Add/Remove)
	+--------V--------+		+--------V--------+
	|1.Identify Intent|		|1.Identify Intent|
	skipping to change at page 19, line 27 ¶		skipping to change at line 795 ¶
	R1 | | U1 |		R1 | | U1 |
	+---------------+ U8 | | R2 +--v----------------+		+---------------+ U8 | | R2 +--v----------------+
	|8.Identify New +---------+ | | +-----------> 2.Identify |		|8.Identify New +---------+ | | +-----------> 2.Identify |
	| Categories | R8 | | | | U2 | Intent |		| Categories | R8 | | | | U2 | Intent |
	| <-------- | | | | +---------+ User Types |		| <-------- | | | | +---------+ User Types |
	+--------^------+ | | | | | | +-------|-----------+		+--------^------+ | | | | | | +-------|-----------+
	| | | | | | | |		| | | | | | | |
	| ++-+-v-v---+-v-+ |		| ++-+-v-v---+-v-+ |
	+--------+------+ U7 | | R3 +------v------------+		+--------+------+ U7 | | R3 +------v------------+
	|7.Identify +------> Intent +--------> 3.Identify |		|7.Identify +------> Intent +--------> 3.Identify |
	| Life-cycle | R7 |Classification| U3 | Type |		| Life-Cycle | R7 |Classification| U3 | Type |
	| Requirements <------+ <--------+ of Intent |		| Requirements <------+ <--------+ of Intent |
	+--------^------+ +^--^-+--^-+---+ +------|------------+		+--------^------+ +^--^-+--^-+---+ +------|------------+
	| || | | | | |		| || | | | | |
	| || | | | | |		| || | | | | |
	+--------+-----+ || | | | | R4 +-------v-----------+		+--------+-----+ || | | | | R4 +-------v-----------+
	|6.Identify | U6 || | | | +-----------> 4.Identify |		|6.Identify | U6 || | | | +-----------> 4.Identify |
	| Abstractions+---------| | | | U4 | Intent |		| Abstractions+---------| | | | U4 | Intent |
	| <---------+ | | +-------------+ Scope |		| <---------+ | | +-------------+ Scope |
	+-------^------+ R6 | | +-------+-----------+		+-------^------+ R6 | | +-------+-----------+
	| | | |		| | | |
	| U5 | |R5 |		| U5 | |R5 |
	| +-------+-v--------+ |		| +-------+-v--------+ |
	| |5.Identify Network| |		| |5.Identify Network| |
	+----------+ Scope <---------------+		+----------+ Scope <---------------+
	+------------------+		+------------------+
	Figure 1 - Intent Classification Methodology
			Figure 1: Intent Classification Methodology
	The intent classification workflow starts from the solution		The intent classification workflow starts from the solution
	knowledge, which can provide information on requirements, use cases,		knowledge, which can provide information on requirements, use cases,
	technologies used, network properties, intent users that define and		technologies used, network properties, intent users that define and
	issue the intent request, and requirements. The following, defines		issue the intent request, and requirements. The following defines
	the steps to classify an intent:		the steps to classify an intent:
	1. The information provided in the solution knowledge is given as		1. Receive the information provided in the solution knowledge as
	input for identifying the intent solution (e.g. carrier, enterprise,		input for identifying the intent solution (e.g., carrier,
	and data center). Intent solutions are reviewed against the existing		enterprise, and data center). Intent solutions are reviewed
	classification and they can either be used if present or added if not		against the existing classification and can either be used if
	there or removed if not needed, from the classification. (R1-U1).		present or added if not there; if not needed, they can be removed
			from the classification (R1-U1).
	2. Identify the intent user types (e.g. customer, network operators,		2. Identify the intent user types (e.g., customer, network
	service operators, etc.), review existing intent classification and		operators, service operators, etc.). Review the existing intent
	use the intent user type if present, add if it is not there or remove		classification. Then use the intent user type if present; add it
	it if not needed (R2-U2).		if it is not there or remove it if not needed (R2-U2).
	3. Identify the types of intent (e.g. network intent, customer		3. Identify the types of intent (e.g., network intent, customer
	service intent) and then review existing classification and		service intent). Review the existing classification and then
	use/add/remove the intent type (R3-U3).		use, add, or remove the intent type (R3-U3).
	4. Identify the intent scopes (e.g. connectivity, application) based		4. Identify the intent scopes (e.g., connectivity, application)
	on the solution knowledge and then review existing classification and		based on the solution knowledge. Then, review the existing
	use/add/remove the identified intent scope (R4-U4).		classification. Use, add, or remove the identified intent scope
			(R4-U4).
	5. Identify the network scopes (e.g. campus, radio access) and then		5. Identify the network scopes (e.g., campus, radio access). Then,
	review existing classification and either use it or add/remove the		review the existing classification. Either use, add, or remove
	identified network scope (R5-U5).		the identified network scope (R5-U5).
	6. Identify the abstractions (e.g. technical, non-technical) and		6. Identify the abstractions (e.g., technical, non-technical).
	then review existing classification and use/add/remove the		Then, review the existing classification and either use, add, or
	abstractions (R6-U6).		remove the abstractions (R6-U6).
	7. Identify the life-cycle requirements (e.g. persistent, transient)		7. Identify the life-cycle requirements (e.g., persistent,
	and then review existing classification and use/add/remove the life-		transient). Then, review the existing classification. Either
	cycle requirements (R7-U7).		use, add, or remove the life-cycle requirements (R7-U7).
	8. Identify any new categories and use/add the newly identified		8. Identify any new categories. Use and add the newly identified
	categories. New categories can be identified as new domains or		categories. New categories can be identified as new domains or
	applications are emerging, or new areas of concern (e.g. privacy,		applications emerge or as new areas of concern (e.g., privacy,
	compliance) might arise, which are not listed in the current		compliance) arise that are not listed in the current methodology.
	methodology.
	6.2. Intent Taxonomy		6.2. Intent Taxonomy
	The following taxonomy describes the various intent solutions, intent		The following taxonomy describes the various intent solutions, intent
	user types, intent types, intent scopes, network scopes, abstractions		user types, intent types, intent scopes, network scopes,
	and life-cycle and represents the output of the intent classification		abstractions, and life cycles. The taxonomy represents the output of
	tables for each of the solutions addressed (i.e. carrier, data		the intent classification tables for each of the solutions addressed
	center, and enterprise solutions).		(i.e., carrier, data center, and enterprise solutions).
	The intent scope categories in Figure 2 are shared among the carrier,		The intent scope categories in Figure 2 are shared among the carrier,
	DC, and enterprise solutions. The abbreviations (Cx) in sections		DC, and enterprise solutions. The abbreviations (Cx) in Sections
	6.3.2. 6.4.2. are introduced with the scope of fitting as column		6.3.2 and 6.4.2 are introduced with the scope of fitting as column
	title in the following tables.		title in the following tables.
	+--------------------------------+		+--------------------------------+
	+-->|Carrier Enterprise Data Center|		+-->|Carrier Enterprise Data Center|
	| +--------------------------------+		| +--------------------------------+
	| +--------------------------------+		| +--------------------------------+
	| |Customer/Subscriber/End-User |		| |Customer/Subscriber/End User |
	+----------+ | |Network or Service Operator |		+----------+ | |Network or Service Operator |
	+>+Solutions +--+ |Application Developer |		+>+Solution +--+ |Application Developer |
	| +----------+ +->|Enterprise Administrator |		| +----------+ +->|Enterprise Administrator |
	| | |Cloud Administrator |		| | |Cloud Administrator |
	| +----------+ | |Underlay Network Administrator |		| +----------+ | |Underlay Network Administrator |
	+>+Intent +---+ +--------------------------------+		+>+Intent +---+ +--------------------------------+
	| |User | +--------------------------------+		| |User | +--------------------------------+
	| |Types | |Customer Service Intent |		| |Type | |Customer Service Intent |
	| +----------+ |Strategy Intent |		| +----------+ |Strategy Intent |
	| +----------+ |Network Service Intent |		| +----------+ |Network Service Intent |
	+>+Intent +----->|Underlay Network Service Intent |		+>+Intent +----->|Underlay Network Service Intent |
	+------+ | |Type | |Network Intent |		+------+ | |Type | |Network Intent |
	|Intent+-+ +----------+ |Underlay Network Intent |		|Intent+-+ +----------+ |Underlay Network Intent |
	+------+ | |Operational Task Intent |		+------+ | |Operational Task Intent |
	| +----------+ |Cloud Management Intent |		| +----------+ |Cloud Management Intent |
	+>+Intent +---+ |Cloud Resource Management Intent|		+>+Intent +---+ |Cloud Resource Management Intent|
	| |Scope | | +--------------------------------+		| |Scope | | +--------------------------------+
	| +----------+ | +--------------------------------+		| +----------+ | +--------------------------------+
	| +->|Connectivity Application QoS |		| +->|Connectivity Application QoS |
	| +----------+ |Security/Privacy Storage Compute|		| +----------+ |Security/Privacy Storage Compute|
	+>+Network +---+ +--------------------------------+		+>+Network +---+ +--------------------------------+
	| |Scope | | +--------------------------------+		| |Scope | | +--------------------------------+
	| +----------+ | |Radio Access Branch |		| +----------+ | |Radio Access Branch |
	| +->|Transport Access SD-WAN |		| +->|Transport Access SD-WAN |
	| +----------+ |Transport Aggr. VNF PNF |		| +----------+ |Transport Aggr. VNF PNF |
	+>+Abstrac +----+ |Transport Core Physical |		+>+Abstrac- +----+ |Transport Core Physical |
	| |tion | | |Cloud Edge Logical |		| |tion | | |Cloud Edge Logical |
	| +----------+ | |Cloud Core Campus |		| +----------+ | |Cloud Core Campus |
	| +----------+ | +--------------------------------+		| +----------+ | +--------------------------------+
	+>+Life | | +--------------------------------+		+>+Life | | +--------------------------------+
	|cycle +--+ +>|Technical Non-Technical |		|Cycle +--+ +>|Technical Non-Technical |
	+----------+ | +--------------------------------+		+----------+ | +--------------------------------+
	| +--------------------------------+		| +--------------------------------+
	+-->|Persistent Transient |		+-->|Persistent Transient |
	+--------------------------------+		+--------------------------------+
	Figure 2 - Intent Taxonomy
	6.3. Intent Classification for Carrier Solution		Figure 2: Intent Taxonomy
	6.3.1. Intent Users and Intent Types		6.3. Intent Classification for Carrier Solution
	This section addresses step 1, 2, and 3 from Figure 1 and the		6.3.1. Intent Users and Intent Types
			This section addresses steps 1, 2, and 3 from Figure 1. The
	following table describes the intent users in carrier solutions and		following table describes the intent users in carrier solutions and
	intent types with their descriptions for different intent users.		intent types with their descriptions for different intent users.
	+-------------+-------------+---------------------------------------+		+=============+=============+=======================================+
	| Intent User | Intent Type | Intent Type Description |		| Intent User | Intent Type | Intent Type Description |
	+-------------------------------------------------------------------+		+=============+=============+=======================================+
	| Customer/ |Customer |Customer self-service with SLA and |		| Customer/ | Customer | Customer self service with SLA |
	| Subscriber |Service |value added service |		| Subscriber | Service | and value-added service. |
	| |Intent |Example: Always maintain high quality |		| | Intent | |
	| | |of service and high bandwidth for gold |		| | | Example: Always maintain a high |
	| | |level subscribers. |		| | | quality of service and high |
	| | |Operational statement: Measure the |		| | | bandwidth for gold-level |
	| | |network congestion status, give |		| | | subscribers. |
	| | |different adaptive parameters to |		| | | |
	| | |stations of different priority, thus in|		| | | Operation statement: Measure the |
	| | |heavy load situation, make the |		| | | network congestion status, give |
	| | |bandwidth of the high-priority |		| | | different adaptive parameters to |
	| | |customers guaranteed. |		| | | stations of different priority; |
	| | |At the same time ensure the overall |		| | | thus, in a heavy load situation, |
	| | |utilization of system, improve |		| | | make the bandwidth of the high- |
	| | |the overall throughput of the system. |		| | | priority customers guaranteed. |
	| +-----------------------------------------------------+		| | | At the same time, ensure the |
	| |Strategy |Customer designs models and policy |		| | | overall utilization of the |
	| |Intent |intents to be used by customer service |		| | | system and improve the overall |
	| | |intents. |		| | | throughput of the system. |
	| | |Example: Request reliable service |
	| | |during peak traffic periods for apps |
	| | |of type video. |
	+-------------------------------------------------------------------+
	|Network |Network |Service provided by network service |
	|Operator |Service |operator to the customer |
	| |Intent |(e.g. the service operator) |
	| | |Example: Request network service with |
	| | |delay guarantee for access customer A. |
	| +-------------+---------------------------------------+		| +-------------+---------------------------------------+
	| |Network |Network operator requests network-wide |		| | Strategy | Customer designs models and |
	| |Intent |(service underlay or other network-wide|		| | Intent | policy intents to be used by |
	| | |configuration) or network resource |		| | | customer service intents. |
	| | |configurations (switches, routers, |		| | | |
	| | |routing, policies). Includes |		| | | Example: Request reliable |
	| | |connectivity, routing, QoS, security, |		| | | service during peak traffic |
	| | |application policies, traffic steering |		| | | periods for video-type apps. |
	| | |policies, configuration policies, |
	| | |monitoring policies, alarm generation |
	| | |for non-compliance, auto-recovery, etc.|
	| | |Example: Request high priority queueing|
	| | |for traffic of class A. |
	| +-----------------------------------------------------+
	| |Operational |Network operator requests execution of |
	| |Task |any automated task other than network |
	| |Intent |service intent and network intent |
	| | |(e.g. network migration, server |
	| | |replacements, device replacements, |
	| | |network software upgrades). |
	| | |Example: Request migration of all |
	| | |services in network N to backup path P.|
	| +-----------------------------------------------------+
	| |Strategy |Network operator designs models, policy|
	| |Intent |intents and workflows to be used by |
	| | |network service Intents, network |
	| | |intents and operational task intents. |
	| | |Workflows can automate any tasks that |
	| | |network operator often performed in |
	| | |addition to network service intents and|
	| | |network intents |
	| | |Example: Ensure the load on any link in|
	| | |the network is not higher than 50%. |
	+-------------+-------------+---------------------------------------+		+-------------+-------------+---------------------------------------+
			| Network | Network | Service provided by the network |
			| Operator | Service | service operator to the customer |
			| | Intent | (e.g., the service operator). |
			| | | |
			| | | Example: Request network service |
			| | | with delay guarantee for access |
			| | | customer A. |
			| +-------------+---------------------------------------+
			| | Network | Network operator requests |
			| | Intent | network-wide (service underlay |
			| | | or other network-wide |
			| | | configuration) or network- |
			| | | resource configurations |
			| | | (switches, routers, routing, or |
			| | | policies). Includes |
			| | | connectivity, routing, QoS, |
			| | | security, application policies, |
			| | | traffic steering policies, alarm |
			| | | generation for non-compliance, |
			| | | auto-recovery, etc. |
			| | | |
			| | | Example: Request high priority |
			| | | queuing for traffic of class A. |
			| +-------------+---------------------------------------+
			| | Operational | Network operator requests |
			| | Task Intent | execution of any automated task |
			| | | other than network service |
			| | | intent and network intent (e.g., |
			| | | network migration, server |
			| | | replacements, device |
			| | | replacements, or network |
			| | | software upgrades). |
			| | | |
			| | | Example: Request migration of |
			| | | all services in network N to |
			| | | backup path P. |
			| +-------------+---------------------------------------+
			| | Strategy | Network operator designs models, |
			| | Intent | policy intents, and workflows to |
			| | | be used by network service |
			| | | intents, network intents, and |
			| | | operational task intents. |
			| | | Workflows can automate any tasks |
			| | | that the network operator often |
			| | | performs in addition to network |
			| | | service intents and network |
			| | | intents. |
			| | | |
			| | | Example: Ensure the load on any |
			| | | link in the network is not |
			| | | higher than 50%. |
	+-------------+-------------+---------------------------------------+		+-------------+-------------+---------------------------------------+
	| Service | Customer | Service operator's customer orders, |		| Service | Customer | Service operator's customer |
	| Operator | Service | customer service / SLA |		| Operator | Service | orders, customer service, or |
	| | Intent | Example: Provide service S with |		| | Intent | SLA. |
	| | | guaranteed bandwidth for customer A. |		| | | |
	| +-----------------------------------------------------+		| | | Example: Provide service S with |
	| | Network | Service operator's network orders / |		| | | guaranteed bandwidth for |
	| | Service | network SLA |		| | | customer A. |
	| | Intent | Example: Provide network guarantees in|		| +-------------+---------------------------------------+
	| | | terms of security, low latency and |		| | Network | Service operator's network |
	| | | high bandwidth |		| | Service | orders / network SLA. |
	| +-----------------------------------------------------+		| | Intent | |
	| | Operational | Service operator requests execution of|		| | | Example: Provide network |
	| | Task | any automated task other than |		| | | guarantees in terms of security, |
	| | Intent | customer service intent and network |		| | | low latency, and high bandwidth. |
	| | | service intent |		| +-------------+---------------------------------------+
			| | Operational | Service operator requests |
			| | Task Intent | execution of any automated task |
			| | | other than customer service |
			| | | intent and network service |
			| | | intent. |
			| | | |
	| | | Example: Update service operator |		| | | Example: Update service operator |
	| | | portal platforms and their software |		| | | portal platforms and their |
	| | | regularly. Move services from network |		| | | software regularly. Move |
	| | | operator 1 to network operator 2. |		| | | services from network operator 1 |
	| +-----------------------------------------------------+		| | | to network operator 2. |
			| +-------------+---------------------------------------+
	| | Strategy | Service operator designs models, |		| | Strategy | Service operator designs models, |
	| | Intent | policy intents and workflows to be |		| | Intent | policy intents, and workflows to |
	| | | used by customer service intents, |		| | | be used by customer service |
	| | | network service intents and |		| | | intents, network service |
	| | | operational task intents. Workflows |		| | | intents, and operational task |
	| | | can automate any tasks that service |		| | | intents. Workflows can automate |
	| | | operator often performed in addition |		| | | any task that the service |
	| | | to network service intents and network|		| | | operator often performs in |
	| | | intents. |		| | | addition to network service |
			| | | intents and network intents. |
			| | | |
	| | | Example: Request network service |		| | | Example: Request network service |
	| | | guarantee to avoid network congestion |		| | | guarantee to avoid network |
	| | | during special periods |		| | | congestion during special |
	| | | such as black Friday, and Christmas. |		| | | periods such as Black Friday and |
			| | | Christmas. |
	+-------------+-------------+---------------------------------------+		+-------------+-------------+---------------------------------------+
	| Application | Customer | Customer service intent API provided |		| Application | Customer | Customer service intent API |
	| Developer | Service | to the application developers |		| Developer | Service | provided to the application |
	| | Intent | Example: API to request network to |		| | Intent | developers. |
	| | | watch HD video 4K/8K. |		| | | |
	| +-----------------------------------------------------+
	| | Network | Network service intent API provided to|
	| | Service | the application developers |
	| | Intent | Example:API to request network service|
	| | | , monitoring and traffic grooming. |
	| +-----------------------------------------------------+
	| | Network | Network intent API provided to the |
	| | Intent | application developers |
	| | | Example: API to request network |		| | | Example: API to request network |
	| | | resources configuration. |		| | | to watch HD video (4K/8K). |
	| +-----------------------------------------------------+		| +-------------+---------------------------------------+
	| | Operational | Operational task intent API provided |		| | Network | Network service intent API |
	| | Task | to the application developers. This is|		| | Service | provided to the application |
	| | Intent | for the trusted internal operator / |		| | Intent | developers. |
	| | | service providers / customer DevOps |		| | | |
			| | | Example: API to request network |
			| | | service, monitoring, and traffic |
			| | | grooming. |
			| +-------------+---------------------------------------+
			| | Network | Network intent API provided to |
			| | Intent | the application developers. |
			| | | |
			| | | Example: API to request network |
			| | | resource configurations. |
			| +-------------+---------------------------------------+
			| | Operational | Operational task intent API |
			| | Task Intent | provided to the application |
			| | | developers. This is for the |
			| | | trusted internal operator / |
			| | | service providers / customer |
			| | | DevOps. |
			| | | |
	| | | Example: API to request server |		| | | Example: API to request server |
	| | | migrations. |		| | | migrations. |
	| +-----------------------------------------------------+		| +-------------+---------------------------------------+
	| | Strategy | Application developer designs models, |		| | Strategy | Application developer designs |
	| | Intent | policy and workflows to be used by |		| | Intent | models, policy, and workflows to |
	| | | customer service intents, network |		| | | be used by customer service |
	| | | service intents and operational |		| | | intents, network service |
	| | | task intents. This is for the trusted |		| | | intents, and operational task |
	| | | internal operator/service provider/ |		| | | intents. This is for the |
	| | | customer DevOps |		| | | trusted internal operator / |
	| | | Example: API to design network load |		| | | service provider / customer |
	| | | balancing strategies during peak times|		| | | DevOps. |
			| | | |
			| | | Example: API to design network |
			| | | load-balancing strategies during |
			| | | peak times. |
	+-------------+-------------+---------------------------------------+		+-------------+-------------+---------------------------------------+
	Table 2 - Intent Classification for Carrier Solution		Table 2: Intent Classification for Carrier Solution
	6.3.2. Intent Categories		6.3.2. Intent Categories
	This subsection addresses step 4 to 7 from Figure 1, and the		This subsection addresses steps 4 to 7 from Figure 1. The following
	following are the proposed categories:		are the proposed categories:
	o Intent Scope: C1=Connectivity, C2=Security/Privacy,		Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application,
	C3=Application, C4=QoS		C4=QoS
	o Network Scope:
	o Network Domain: C1=Radio Access, C2=Transport Access,
	C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge,
	C6=Cloud Core)
	o Network Function (NF) Scope: C1=VNFs, C2=PNFs
	o Abstraction (ABS): C1=Technical (with technical feedback),
	C2=Non-technical (without technical feedback) see section 5.2. .
	o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
	(short lived)
	6.3.3. Intent Classification Example		Network Scope:
	This section depicts an example on how the methodology described in		Network Domain: C1=Radio Access, C2=Transport
	section 6.1. can be used in order to classify intents introduced in		Access, C3=Transport Aggregation, C4=Transport Core, C5=Cloud
	the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. This		Edge, C6=Cloud Core
	PoC is led by academics carrying research in the area of SDN/NFV and
	the specific problem they are addressing is to apply the intent		Network Function (NF) Scope: C1=VNFs, C2=PNFs
	concept at different levels that correspond to different
	stakeholders. For this research work, they considered two types of		Abstraction (ABS): C1=Technical (with technical feedback), C2=Non-
	intents: slice intents and service chain intents.		technical (without technical feedback) (see Section 5.2).
			Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient
			(short lived)
			6.3.3. Intent Classification Example
			This section contains an example of how the methodology described in
			Section 6.1 can be used in order to classify intents introduced in
			the "A Multi-Level Approach to IBN" PoC demonstration [POC-IBN].
			This PoC is led by academics carrying out research in the area of
			SDN/NFV, and the specific problem they are addressing is the
			application of the intent concept at different levels that correspond
			to different stakeholders. For this research work, they considered
			two types of intents: slice intents and service chain intents.
	In this PoC [POC-IBN], a slice intent expresses a request for a		In this PoC [POC-IBN], a slice intent expresses a request for a
	network slice with two types of components: a set of top layer		network slice with two types of components: a set of top-layer
	virtual functions, and a set of virtual switches and/or routers of		virtual functions and a set of virtual switches and/or routers of L2/
	L2/L3 VNFs. A service chain intent expressed a request for a service		L3 VNFs. A service chain intent expresses a request for a service
	operated through a chain of service components running in L4-L7		operated through a chain of service components running in L4-L7
	virtual functions.		virtual functions.
	Following the intent classification methodology described step-by-		Following the intent classification methodology described step by
	step in section 6.1. , the following can be derived:		step in Section 6.1, the following can be derived:
	1. The intent solution for both intents is carrier network.		1. The intent solution for both intents is carrier network.
	2. The intent user type is network operator for the slice intent, and		2. The intent user type is network operator for the slice intent and
	service operator for the service chain intent.		service operator for the service chain intent.
	3. The type of intent, is a network service intent for the slice		3. The type of intent is a network service intent for the slice
	intent, and a customer service intent for the service chain intent.		intent and a customer service intent for the service chain
			intent.
	4. The intent scopes are connectivity and application.		4. The intent scopes are connectivity and application.
	5. The network scope is VNF, cloud edge, and cloud core.		5. The network scope is VNF, cloud edge, and cloud core.
	6. The abstractions are with technical feedback for the slice intent,		6. The abstractions are with technical feedback for the slice intent
	and without technical feedback for the service chain intent		and without technical feedback for the service chain intent.
	7. The life-cycle is persistent.		7. The life cycle is persistent.
	The following table shows how to represent this information in a		The following table shows how to represent this information in a
	tabular form. The 'X' in the table refers to the slice intent, and		tabular form. The "X" in the table refers to the slice intent; the
	the 'Y' in the table refers to the service chain intent.		"Y" in the table refers to the service chain intent.
	+---------+---------+-----------+-----+-----------------+-----+-----+		+==========+===========+===========+=====+=================+=====+=====+
	| Intent | Intent | Intent | NF | Network | ABS |L-C |		|Intent |Intent Type|Intent |NF |Network |ABS |L-C |
	| User | Type | Scope |Scope| Scope | | |		|User | |Scope |Scope|Scope | | |
	| | +-----------+-----+-----------------+-----+-----+		| | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
	| | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|		| | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
	+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
	|Customer |Customer | | | | | | | | | | | | | | | | |		|Customer/ |Customer | | | | | | | | | | | | | | | | |
	|/ Sub- |Service | | | | | | | | | | | | | | | | |		|Subscriber|Service | | | | | | | | | | | | | | | | |
	| scriber |Intent | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Strategy | | | | | | | | | | | | | | | | |		| |Strategy | | | | | | | | | | | | | | | | |
	| |Intent | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|Network |Network |X | |X | |X | | | | | |X | |X | |X | |		|Network |Network |X | |X | |X | | | | | |X | |X | |X | |
	|Operator |Service | | | | | | | | | | | | | | | | |		|Operator |Service | | | | | | | | | | | | | | | | |
	| |Intent | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Network | | | | | | | | | | | | | | | | |		| |Network | | | | | | | | | | | | | | | | |
	| |Intent | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Operatio-| | | | | | | | | | | | | | | | |		| |Operational| | | | | | | | | | | | | | | | |
	| |nal Task | | | | | | | | | | | | | | | | |		| |Task Intent| | | | | | | | | | | | | | | | |
	| |Intent | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Strategy | | | | | | | | | | | | | | | | |
	| |Strategy | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| |Intent | | | | | | | | | | | | | | | | |		+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		|Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | |
	|Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | |		|Operator |Intent | | | | | | | | | | | | | | | | |
	|Operator |Service | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Network | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Service | | | | | | | | | | | | | | | | |
	| |Network | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| |Service | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Op Task | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Intent | | | | | | | | | | | | | | | | |
	| |Op Task | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Strategy | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Intent | | | | | | | | | | | | | | | | |
	| |Strategy | | | | | | | | | | | | | | | | |		+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		|App |Customer | | | | | | | | | | | | | | | | |
	+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		|Developer |Intent | | | | | | | | | | | | | | | | |
	|App |Customer | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|Developer|Intent | | | | | | | | | | | | | | | | |		| |Network | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Service | | | | | | | | | | | | | | | | |
	| |Network | | | | | | | | | | | | | | | | |		| |Intent | | | | | | | | | | | | | | | | |
	| |Service | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Network | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Intent | | | | | | | | | | | | | | | | |
	| |Network | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Op Task | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Intent | | | | | | | | | | | | | | | | |
	| |Op Task | | | | | | | | | | | | | | | | |		| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |		| |Strategy | | | | | | | | | | | | | | | | |
	| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| |Intent | | | | | | | | | | | | | | | | |
	| |Strategy | | | | | | | | | | | | | | | | |		+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| |Intent | | | | | | | | | | | | | | | | |
	+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	Table 3 - Intent Classification Example for Carrier Solution		Figure 3: Intent Classification Example for Carrier Solution
	6.4. Intent Classification for Data Center Network Solutions		6.4. Intent Classification for Data Center Network Solutions
	6.4.1. Intent Users and Intent Types		6.4.1. Intent Users and Intent Types
	The following table describes the intent users in DC network		The following table describes the intent users in DC network
	solutions and intent types with their descriptions for different		solutions and intent types with their descriptions for different
	intent users.		intent users.
	+---------------+-------------+-------------------------------------+		+===============+=============+====================================+
	| Intent User | Intent Type | Intent Type Description |		| Intent User | Intent Type | Intent Type Description |
	+-------------------------------------------------------------------+		+===============+=============+====================================+
	| Customer / | Customer | Customer self-service via tenant |		| Customer/ | Customer | Customer self service via tenant |
	| Tenants | Service | portal. |		| Tenants | Service | portal. |
	| | | Example: Request GPU computing and |		| | | |
	| | | storage resources to meet 10k video |		| | | Example: Request GPU computing and |
	| | | surveillance services. |		| | | storage resources to meet 10k |
	| +---------------------------------------------------+		| | | video surveillance services. |
	| | Strategy | This includes models and policy |		| +-------------+------------------------------------+
	| | Intent | intents designed by customers/ |		| | Strategy | This includes models and policy |
	| | | tenants to be reused later during |		| | Intent | intents designed by customers/ |
	| | | instantiation. |		| | | tenants to be reused later during |
	| | | Example: Request dynamic computing |		| | | instantiation. |
	| | | and storage resources of the service|		| | | |
	| | | in special and daily times. |		| | | Example: Request dynamic computing |
	| | | |		| | | and storage resources of the |
	+-------------------------------------------------------------------+		| | | service in special and daily |
	| | Cloud | Configuration of VMs, DB Servers, |		| | | times. |
	| Cloud | Management | app servers, connectivity, |		+---------------+-------------+------------------------------------+
	| Administrator | Intent | communication between VMs. |		| Cloud | Cloud | Configuration of VMs, DB Servers, |
	| | | Example: Request connectivity |		| Administrator | Management | app servers, and communication |
	| | | between VMs A,B,and C in network N1.|		| | Intent | between servers and VMs. |
	| +---------------------------------------------------+		| | | |
	| | Cloud | Policy-driven self-configuration and|		| | | Example: Request connectivity |
	| | Resource | and recovery / optimization |		| | | between VMs A, B, and C in network |
	| | Management | Example: Request automatic life |		| | | N1. |
	| | Intent |-cycle management of VM cloud |		| +-------------+------------------------------------+
	| | | resources. |		| | Cloud | Policy-driven self configuration |
	| +---------------------------------------------------+		| | Resource | and recovery/optimization. |
	| | Operational | Cloud administrator requests |		| | Management | |
	| | Task Intent | execution of any automated task |		| | Intent | Example: Request automatic life- |
	| | | other than cloud management |		| | | cycle management of VM cloud |
	| | | intents and cloud resource |		| | | resources. |
	| | | management intents. |		| +-------------+------------------------------------+
	| | | Example: Request upgrade operating |		| | Operational | Cloud administrator requests |
	| | | system to version X on all VMs |		| | Task Intent | execution of any automated task |
	| | | in network N1. |		| | | other than cloud management |
	| | |Operational statement: an intent to |		| | | intents and cloud resource |
	| | |update a system might reconfigure the|		| | | management intents. |
	| | |system topology (connect to a service|		| | | |
	| | |and to peers), exchange data (update |		| | | Example: Request upgrade operating |
	| | |the content), and uphold a certain |		| | | system to version X on all VMs in |
	| | |QoE level (allocate sufficient |		| | | network N1. |
	| | |network resources). The network, |		| | | |
	| | |thus, carries out the necessary |		| | | Operational statement: An intent |
	| | |configuration to best serve such an |		| | | to update a system might |
	| | |intent; e.g. setting up direct |		| | | reconfigure the system topology |
	| | |connections between terminals, and |		| | | (connect to a service and to |
	| | |allocating fair shares of router |		| | | peers), exchange data (update the |
	| | |queues considering other network |		| | | content), and uphold a certain QoE |
	| | |services.		| | | level (allocate sufficient network |
	| +---------------------------------------------------+		| | | resources). Thus, the network |
	| | Strategy | Cloud administrator designs models, |		| | | carries out the necessary |
	| | Intent | policy intents and workflows to be |		| | | configuration to best serve such |
	| | | used by other intents. Automate any |		| | | an intent, e.g., setting up direct |
	| | | tasks that administrator often |		| | | connections between terminals and |
	| | | performs, in addition to life-cycle |		| | | allocating fair shares of router |
	| | | of cloud management intents and |		| | | queues considering other network |
	| | | cloud management resource intents. |		| | | services. |
	| | | Example: In case of emergency, |		| +-------------+------------------------------------+
	| | | automatically migrate all cloud |		| | Strategy | Cloud administrator designs |
	| | | resources to DC2. |		| | Intent | models, policy intents, and |
	+---------------+---------------------------------------------------+		| | | workflows to be used by other |
	| Underlay | Underlay | Service created and provided by |		| | | intents. Automate any tasks that |
	| Network | Network | the underlay network administrator. |		| | | administrator often performs in |
	| Administrator | Service | Example: Request underlay service |		| | | addition to life cycle of cloud |
	| | Intent | between DC1 and DC2 with |		| | | management intents and cloud |
	| | | bandwidth B. |		| | | management resource intents. |
	| +---------------------------------------------------+		| | | |
	| | Underlay | Underlay network administrator |		| | | Example: In case of emergency, |
	| | Network | requests some DCN-wide underlay |		| | | automatically migrate all cloud |
	| | Intent | network configuration or network |		| | | resources to DC2. |
	| | | resource configurations. |		+---------------+-------------+------------------------------------+
	| | | Example: Establish and allocate |		| Underlay | Underlay | Service created and provided by |
	| | | DHCP address pool. |		| Network | Network | the underlay network |
	| +---------------------------------------------------+		| Administrator | Service | administrator. |
	| | Operational | Underlay network administrator |		| | Intent | |
	| | Task Intent | requests execution of the any |		| | | Example: Request underlay service |
	| | | automated task other than underlay |		| | | between DC1 and DC2 with bandwidth |
	| | | network service and resource |		| | | B. |
	| | | intent. |		| +-------------+------------------------------------+
	| | | Example: Request automatic rapid |		| | Underlay | Underlay network administrator |
	| | | detection of device failures and |		| | Network | requests some DCN-wide underlay |
	| | | pre-alarm correlation. |		| | Intent | network configuration or network |
	| +---------------------------------------------------+		| | | resource configurations. |
	| | Strategy | Underlay network administrator |		| | | |
	| | Intent | designs models, policy intents & |		| | | Example: Establish and allocate |
	| | | workflows to be used by other |		| | | DHCP address pool. |
	| | | intents. Automate any tasks that |		| +-------------+------------------------------------+
	| | | administrator often performs. |		| | Operational | Underlay network administrator |
	| | | Example: For all traffic flows |		| | Task Intent | requests execution of any |
	| | | that need NFV service chaining, |		| | | automated task other than underlay |
	| | | restrict the maximum load of any |		| | | network service and resource |
	| | | VNF node/container below 50% and |		| | | intent. |
	| | | the maximum load of any network |		| | | |
	| | | link below 70%. |		| | | Example: Request automatic rapid |
	+-------------------------------------------------------------------+		| | | detection of device failures and |
	| | Cloud | Cloud management intent API |		| | | pre-alarm correlation. |
	| | Management | provided to the application |		| +-------------+------------------------------------+
	| | Intent | developers. |		| | Strategy | Underlay network administrator |
	| | | Example: API to request |		| | Intent | designs models, policy intents, |
	| | | configuration of VMs, or DB Servers.|		| | | and workflows to be used by other |
	| Application +---------------------------------------------------+		| | | intents. Automate any tasks that |
	| Developer | Cloud | Cloud resource management intent |		| | | the administrator often performs. |
	| | Resource | API provided to the application |		| | | |
	| | Management | developers. |		| | | Example: For all traffic flows |
	| | Intent | Example: API to request automatic |		| | | that need NFV service chaining, |
	| | | life-cycle management of cloud |		| | | restrict the maximum load of any |
	| | | resources. |		| | | VNF node/container below 50% and |
	| +---------------------------------------------------+		| | | the maximum load of any network |
	| | Underlay | Underlay network service API |		| | | link below 70%. |
	| | Network | provided to the application |		+---------------+-------------+------------------------------------+
	| | Service | developers. |		| Application | Cloud | Cloud management intent API |
	| | Intent | Example: API to request real-time |		| Developer | Management | provided to the application |
	| | | monitoring of device condition. |		| | Intent | developers. |
	| +---------------------------------------------------+		| | | |
	| | Underlay | Underlay network resource API |		| | | Example: API to request |
	| | Network | provided to the application |		| | | configuration of VMs or DB |
	| | Intent | developers. |		| | | Servers. |
	| | | Example: API to request dynamic |		| +-------------+------------------------------------+
	| | | management of IPv4 address pool |		| | Cloud | Cloud resource management intent |
	| | | resources. |		| | Resource | API provided to the application |
	| | | |		| | Management | developers. |
	| +---------------------------------------------------+		| | Intent | |
	| | Operational | Operational task intent API |		| | | Example: API to request automatic |
	| | Task Intent | provided to the trusted |		| | | life-cycle management of cloud |
	| | | application developer (internal |		| | | resources. |
	| | | DevOps). |		| +-------------+------------------------------------+
	| | | Example: API to request automatic |		| | Underlay | Underlay network service API |
	| | | rapid detection of device failures |		| | Network | provided to the application |
	| | | and pre-alarm correlation |		| | Service | developers. |
	| | | |		| | Intent | |
	| +---------------------------------------------------+		| | | Example: API to request real-time |
	| | Strategy | Application developer designs |		| | | monitoring of device condition. |
	| | Intent | models, policy intents and |		| +-------------+------------------------------------+
	| | | building blocks to be used by |		| | Underlay | Underlay network resource API |
	| | | other intents. This is for the |		| | Network | provided to the application |
	| | | trusted internal DCN DevOps. |		| | Intent | developers. |
	| | | Example: API to request load |		| | | |
	| | | balancing thresholds. |		| | | Example: API to request dynamic |
	+---------------+-------------+-------------------------------------+		| | | management of IPv4 address pool |
			| | | resources. |
			| +-------------+------------------------------------+
			| | Operational | Operational task intent API |
			| | Task Intent | provided to the trusted |
			| | | application developer (internal |
			| | | DevOps). |
			| | | |
			| | | Example: API to request automatic |
			| | | rapid detection of device failures |
			| | | and pre-alarm correlation. |
			| +-------------+------------------------------------+
			| | Strategy | Application developer designs |
			| | Intent | models, policy intents, and |
			| | | building blocks to be used by |
			| | | other intents. This is for the |
			| | | trusted internal DCN DevOps. |
			| | | |
			| | | Example: API to request load- |
			| | | balancing thresholds. |
			+---------------+-------------+------------------------------------+
	Table 4 - Intent Classification for Data Center Network Solutions		Table 3: Intent Classification for Data Center Network Solutions
	6.4.2. Intent Categories		6.4.2. Intent Categories
	The following are the proposed categories:		The following are the proposed categories:
	o Intent Scope: C1=Connectivity, C2=Security/Privacy,
	C3=Application, C4=QoS C5=Storage C6=Compute
	o Network Scope
	o Network Domain: DC Network
	o DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
	o DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
	o Abstraction (ABS): C1=Technical (with technical feedback),
	C2=Non-technical (without technical feedback), see section 5.2.
	o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
	(short lived)
	6.4.3. Intent Classification Example		Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application,
			C4=QoS, C5=Storage, C6=Compute
			Network Scope
			Network Domain: DC Network
			DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
			DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
			Abstraction (ABS): C1=Technical (with technical feedback), C2=Non-
			technical (without technical feedback) (see Section 5.2).
			Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient
			(short lived)
			6.4.3. Intent Classification Example
	This section depicts an example on how the methodology described in		This section depicts an example on how the methodology described in
	section 6.1. can be used by the research community to classify		Section 6.1 can be used by the research community to classify
	intents. As mentioned in 6.3.3. a successful use of the		intents. As mentioned in Section 6.3.3, a successful use of the
	classification proposed in this draft is introduced in the 'A Multi-		classification proposed in this document is introduced in the PoC
	Level Approach to IBN' PoC demonstration [POC-IBN]. The PoC is led by		demonstration titled "A Multi-Level Approach to IBN" [POC-IBN]. The
	academics carrying research in the area of SDN/NFV and the specific		PoC is led by academics carrying out research in the area of SDN/NFV;
	problem they are addressing is to apply the intent concept at		the specific problem they are addressing is the application of the
	different levels that correspond to different stakeholders.		intent concept at different levels that correspond to different
			stakeholders.
	For their research work, they considered two types of intents: slice		For their research work, they considered two types of intents: slice
	intents and service chain intents. For the data center solution, only		intents and service chain intents. For the data center solution,
	the slice intent is relevant.		only the slice intent is relevant.
	As already mentioned in section 6.3.3. , a slice intent expresses a		As already mentioned in Section 6.3.3, a slice intent expresses a
	request for a network slice with two types of components: a set of		request for a network slice with two types of components: a set of
	top layer virtual functions, and a set of virtual switches and/or		top-layer virtual functions and a set of virtual switches and/or
	routers of L2/L3 VNFs.		routers of L2/L3 VNFs.
	Following the intent classification methodology described step-by-		Following the intent classification methodology described step by
	step in section 6.1. , we identify the following:		step in Section 6.1, we identify the following:
	1. The intent solution is for the data center.		1. The intent solution is data center.
	2. The intent user type is the cloud administrator for the slice		2. The intent user type is the cloud administrator for the slice
	intent and service chain intent.		intent and service chain intent.
	3. The type of intent, is a cloud management intent, for the slice		3. The type of intent is a cloud management intent for the slice
	intent.		intent.
	4. The intent scopes are connectivity and application.		4. The intent scopes are connectivity and application.
	5. The network scope is logical, and the resource scope is virtual.		5. The network scope is logical; the resource scope is virtual.
	6. The abstractions are with technical feedback for the slice intent.		6. The abstractions are with technical feedback for the slice
			intent.
	7. The life-cycle is persistent.		7. The life cycle is persistent.
	The following table shows how to represent this information in a		The following table shows how to represent this information in a
	tabular form, where the 'X' in the table refers to the slice intent.		tabular form; the "X" in the table refers to the slice intent.
	+---------+-------------+-----------------+-----+-----+-----+-----+		+===========+=============+=================+=====+=====+=====+=====+
	|Intent | Intent | Intent | DCN | DCN | ABS | L-C |		|Intent User| Intent Type |Intent |DCN |DCN |ABS |L-C |
	|User | Type | Scope | Res | Net | | |		| | |Scope |Res |Net | | |
	| | +-----------------+-----+-----+-----+-----+		| | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+
	| | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|		| | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
	+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
	|Customer | Customer | | | | | | | | | | | | | | |		|Customer/ | Customer | | | | | | | | | | | | | | |
	|/Tenants | Service | | | | | | | | | | | | | | |		|Tenants | Service | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| Cloud | Cloud | | | | | | | | | | | | | | |		|Cloud Admin| Cloud |X | |X | | | |X | |X | |X | |X | |
	| Admin | Management |X | |X | | | |X | |X | |X | |X | |		| | Management | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Cloud | | | | | | | | | | | | | | |		| | Cloud | | | | | | | | | | | | | | |
	| | Resource | | | | | | | | | | | | | | |		| | Resource | | | | | | | | | | | | | | |
	| | Management | | | | | | | | | | | | | | |		| | Management | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Operational | | | | | | | | | | | | | | |		| | Operational | | | | | | | | | | | | | | |
	| | Task Intent | | | | | | | | | | | | | | |		| | Task Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|Underlay | Underlay | | | | | | | | | | | | | | |		|Underlay | Underlay | | | | | | | | | | | | | | |
	|Network | Network | | | | | | | | | | | | | | |		|Network | Network | | | | | | | | | | | | | | |
	|Admin | Intent | | | | | | | | | | | | | | |		|Admin | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Underlay | | | | | | | | | | | | | | |		| | Underlay | | | | | | | | | | | | | | |
	| | Network | | | | | | | | | | | | | | |		| | Network | | | | | | | | | | | | | | |
	| | Resource | | | | | | | | | | | | | | |		| | Resource | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Operational | | | | | | | | | | | | | | |		| | Operational | | | | | | | | | | | | | | |
	| | Task Intent | | | | | | | | | | | | | | |		| | Task Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|App | Cloud | | | | | | | | | | | | | | |		|App | Cloud | | | | | | | | | | | | | | |
	|Developer| Management | | | | | | | | | | | | | | |		|Developer | Management | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Cloud | | | | | | | | | | | | | | |		| | Cloud | | | | | | | | | | | | | | |
	| | Resource | | | | | | | | | | | | | | |		| | Resource | | | | | | | | | | | | | | |
	| | Management | | | | | | | | | | | | | | |		| | Management | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Underlay | | | | | | | | | | | | | | |		| | Underlay | | | | | | | | | | | | | | |
	| | Network | | | | | | | | | | | | | | |		| | Network | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Underlay | | | | | | | | | | | | | | |		| | Underlay | | | | | | | | | | | | | | |
	| | Network | | | | | | | | | | | | | | |		| | Network | | | | | | | | | | | | | | |
	| | Resource | | | | | | | | | | | | | | |		| | Resource | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Operational | | | | | | | | | | | | | | |		| | Operational | | | | | | | | | | | | | | |
	| | Task Intent | | | | | | | | | | | | | | |		| | Task Intent | | | | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | | | | |		| | Intent | | | | | | | | | | | | | | |
	+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	Table 5 - Intent Classification Example for Data Center Network		Figure 4: Intent Classification Example for Data Center Network
	Solutions		Solutions
	6.5. Intent Classification for Enterprise Solution		6.5. Intent Classification for Enterprise Solution
	6.5.1. Intent Users and Intent Types		6.5.1. Intent Users and Intent Types
	The following table describes the intent users in enterprise		The following table describes the intent users in enterprise
	solutions and their intent types.		solutions and their intent types.
	+--------------+-------------+-------------------------------------+		+---------------+-------------+------------------------------------+
	| Intent User | Intent Type | Intent Type Description |		| Intent User | Intent Type | Intent Type Description |
	+--------------+---------------------------------------------------+		+---------------+-------------+------------------------------------+
	| End-User | Customer | Enterprise end-user self-service or |		| End User | Customer | Enterprise end user self service |
	| | Service | applications, enterprise may have |		| | Service | or applications; enterprise may |
	| | Intent | multiple types of end-users. |		| | Intent | have multiple types of end users. |
	| | | Example: Request access to VPN |		| | | |
	| | | service. |		| | | Example: Request access to VPN |
	| | | Request video conference between |		| | | service. Request video conference |
	| | | end-user A and B. |		| | | between end user A and B. |
	| +---------------------------------------------------+		| +-------------+------------------------------------+
	| | Strategy | This includes models and policy |		| | Strategy | This includes models and policy |
	| | Intent | intents designed by end-users to be |		| | Intent | intents designed by end users to |
	| | | used by end-user intents and their |		| | | be used by end-user intents and |
	| | | applications. |		| | | their applications. |
	| | | Example: Create a video conference |		| | | |
	| | | type for a weekly meeting. |		| | | Example: Create a video conference |
	+------------------------------------------------------------------+		| | | type for a weekly meeting. |
	|Enterprise | Network | Service provided by the |		+---------------+-------------+------------------------------------+
	|Administrator | Service | administrator to the end-users |		| Enterprise | Network | Service provided by the |
	|(internal or | Intent | and their applications. |		| Administrator | Service | administrator to the end users and |
	| MSP) | | Example: For any end-user of |		| (internal or | Intent | their applications. |
	| | | application X, the arrival of |		| MSP) | | |
	| | | hologram objects of all the remote |		| | | Example: For any end user of |
	| | | tele-presenters should be |		| | | application X, the arrival of |
	| | | synchronised within 50ms to reach |		| | | hologram objects of all the remote |
	| | | the destination viewer for each |		| | | tele-presenters should be |
	| | | conversation session. |		| | | synchronized within 50 ms to reach |
	| | | Create management VPN connectivity |		| | | the destination viewer for each |
	| | | for type of service A. |		| | | conversation session. Create |
	| | | Operational statement: The job of |		| | | management VPN connectivity for |
	| | | the network layer is to ensure that |		| | | type of service A. |
	| | | the delay is between 50-70ms through|		| | | |
	| | | the routing algorithm. At the same |		| | | Operational statement: The job of |
	| | | time,the node resources need to meet|		| | | the network layer is to ensure |
	| | | the bandwidth requirements of 4K |		| | | that the delay is between 50-70 ms |
	| | | video conferences. |		| | | through the routing algorithm. At |
	+------------------------------------------------------------------+		| | | the same time, the node resources |
	| | Network | Administrator requires network wide |		| | | need to meet the bandwidth |
	| | Intent | configuration (e.g. underlay, |		| | | requirements of 4K video |
	| | | campus) or resource configuration |		| | | conferences. |
	| | | (switches, routers, policies). |		| +-------------+------------------------------------+
	| | | Example: Configure switches in |		| | Network | Administrator requires network- |
	| | | campus network 1 to prioritise |		| | Intent | wide configuration (e.g., underlay |
	| | | traffic of type A. |		| | | or campus) or resource |
	| | | Configure YouTube as business |		| | | configuration (switches, routers, |
	| | | non-relevant. |		| | | or policies). |
	| +---------------------------------------------------+		| | | |
	| | Operational | Administrator requests execution of |		| | | Example: Configure switches in |
	| | Task Intent | any automated task other than |		| | | campus network 1 to prioritize |
	| | | network service intents and network |		| | | traffic of type A. Configure |
	| | | intents. |		| | | YouTube as business non-relevant. |
	| | | Example: Request network security |		| +-------------+------------------------------------+
	| | | automated tasks such as web |		| | Operational | Administrator requests execution |
	| | | filtering and DDOS cloud protection.|		| | Task Intent | of any automated task other than |
	| +---------------------------------------------------+		| | | network service intents and |
	| | Strategy | Administrator designs models, policy|		| | | network intents. |
	| | Intent | intents and workflows to be used by |		| | | |
	| | | other intents. Automate any tasks |		| | | Example: Request network security |
	| | | that administrator often performs. |		| | | automated tasks such as web |
	| | | Example: In case of emergency, |		| | | filtering and DDoS cloud |
	| | | automatically shift all traffic of |		| | | protection. |
	| | | type A through network N. |		| +-------------+------------------------------------+
	| | | |		| | Strategy | Administrator designs models, |
	+--------------+-------------+-------------------------------------+		| | Intent | policy intents, and workflows to |
	| Application | End-User | End-user service / application |		| | | be used by other intents. |
	| Developer | Intent | intent API provided to the |		| | | Automate any tasks that the |
	| | | application developers. |		| | | administrator often performs. |
	| | | Example: API for request to open a |		| | | |
	| | | VPN service. |		| | | Example: In case of emergency, |
	| +---------------------------------------------------+		| | | automatically shift all traffic of |
	| | Network | Network service API provided to |		| | | type A through network N. |
	| | Service | application developers. |		+---------------+-------------+------------------------------------+
	| | Intent | Example: API for request network |		| Application | End-User | End-user service / application |
	| | | bandwidth and latency for |		| Developer | Intent | intent API provided to the |
	| | | hosting video conference. |		| | | application developers. |
	| +---------------------------------------------------+		| | | |
	| | Network | Network API provided to application |		| | | Example: API for request to open a |
	| | Intent | developers. |		| | | VPN service. |
	| | | Example: API for request of network |		| +-------------+------------------------------------+
	| | | devices configuration. |		| | Network | Network service API provided to |
	| +---------------------------------------------------+		| | Service | application developers. |
	| | Operational | Operational task intent API provided|		| | Intent | |
	| | Task Intent | to the trusted application developer|		| | | Example: API for request network |
	| | | (internal DevOps). |		| | | bandwidth and latency for hosting |
	| | | Example: API for requesting |		| | | a video conference. |
	| | | automatic monitoring and |		| +-------------+------------------------------------+
	| | | interception for network security |		| | Network | Network API provided to |
	| +---------------------------------------------------+		| | Intent | application developers. |
	| | Strategy | Application developer designs |		| | | |
	| | Intent | models, policy intents and building |		| | | Example: API for requesting |
	| | | blocks to be used by other intents. |		| | | network device configuration. |
	| | | This is for the trusted internal |		| +-------------+------------------------------------+
	| | | DevOps. |		| | Operational | Operational task intent API |
	| | | Example: API for strategy intent in |		| | Task Intent | provided to the trusted |
	| | | case of emergencies. |		| | | application developer (internal |
	| | | |		| | | DevOps). |
	+--------------+-------------+-------------------------------------+		| | | |
	Table 6 - Intent Classification for Enterprise Solution		| | | Example: API for requesting |
			| | | automatic monitoring and |
			| | | interception for network security. |
			| +-------------+------------------------------------+
			| | Strategy | Application developer designs |
			| | Intent | models, policy intents, and |
			| | | building blocks to be used by |
			| | | other intents. This is for the |
			| | | trusted internal DevOps. |
			| | | |
			| | | Example: API for strategy intent |
			| | | in case of emergencies. |
			+---------------+-------------+------------------------------------+
	6.5.2. Intent Categories		Table 4: Intent Classification for Enterprise Solution
			6.5.2. Intent Categories
	The following are the proposed categories:		The following are the proposed categories:
	o Intent Scope: C1=Connectivity, C2=Security/Privacy,
	C3=Application, C4=QoS		Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application,
	o Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN		C4=QoS
	o Abstraction (ABS): C1=Technical (with technical feedback),
	C2=Non-technical (without technical feedback), see section 5.2.		Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN
	o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
	(short lived)		Abstraction (ABS): C1=Technical (with technical feedback), C2=Non-
			technical (without technical feedback) (see Section 5.2)
			Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient
			(short lived)
	The following is the intent classification table example for		The following is the intent classification table example for
	enterprise solutions.		enterprise solutions.
	+---------------+-------------+-----------+--------+-----+-----+		+---------------+-------------+-----------+--------+-----+-----+
	| Intent User | Intent Type | Intent | Net | ABS | L-C |		| Intent User | Intent Type | Intent | Net | ABS | L-C |
	| | | Scope | | | |		| | | Scope | | | |
	| | +-----------+--------+-----+-----+		| | +-----------+--------+-----+-----+
	| | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|		| | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
	+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+		+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
	| End-User | Customer | | | | | | | | | | | |		| End User | Customer | | | | | | | | | | | |
	| | Service | | | | | | | | | | | |		| | Service | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+		+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
	| Enterprise | Network | | | | | | | | | | | |		| Enterprise | Network | | | | | | | | | | | |
	| Administrator | Service | | | | | | | | | | | |		| Administrator | Service | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+
	skipping to change at page 43, line 11 ¶		skipping to change at line 1712 ¶
	| | Network | | | | | | | | | | | |		| | Network | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+
	| | Operational | | | | | | | | | | | |		| | Operational | | | | | | | | | | | |
	| | Task | | | | | | | | | | | |		| | Task | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	| +-------------+--+--+--+--+--+--+--+--+--+--+--+		| +-------------+--+--+--+--+--+--+--+--+--+--+--+
	| | Strategy | | | | | | | | | | | |		| | Strategy | | | | | | | | | | | |
	| | Intent | | | | | | | | | | | |		| | Intent | | | | | | | | | | | |
	+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+		+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
	Table 7 - Intent Categories for Enterprise Solution
	7. Conclusions		Figure 5: Intent Categories for Enterprise Solution
			7. Conclusions
	This document is aligned with the RG objectives and supports		This document is aligned with the RG objectives and supports
	investigations into intent-based networking by proposing an intent		investigations into intent-based networking by proposing an intent
	categorization methodology and taxonomy. It brings clarification on		categorization methodology and taxonomy. It brings clarification to
	what an intent represents for different stakeholders through the		what an intent represents for different stakeholders through the
	proposal of an Intent Classification approach, ensuring that a		proposal of an intent classification approach, ensuring that a common
	common understanding among all the participants exists. This,		understanding among all the participants exists. This, together with
	together with the proposed intent taxonomy provides a solid		the proposed intent taxonomy provides a solid foundation for future
	foundation for future intent-related topic discussions within NMRG.		intent-related discussions within the NMRG.
	The benefits of this intent classification draft in the research		The benefits of this intent classification document in the research
	community have been demonstrated through a PoC implementation [POC-		community have been demonstrated through a PoC implementation
	IBN] in which the draft's concepts at different levels corresponding		[POC-IBN] in which the document's concepts have been applied at
	to different stakeholders have been applied to.		different levels corresponding to different stakeholders.
	8. Security Considerations		8. Security Considerations
	This document identifies the security and privacy as categories of		This document identifies security and privacy as categories of the
	the intent scope. The intents could be solely security intents and		intent scope. The intents could be solely security intents and
	privacy intents or security can be embedded in the intents that		privacy intents, or security can be embedded in the intents that
	include also connectivity, application, and QoS scope.		include also connectivity, application, and QoS scope.
	Security and privacy scope, is when the intent specifies the security		Security and privacy scope is when the intent specifies the security
	characteristics of the network, customers, or end-users, and privacy		characteristics of the network, customers, or end users, and privacy
	for customers and end-users.		for customers and end users.
	More details of these security intents would be described in future
	documents that specify architecture, functionality, user intents and
	models. As well, an analysis of the security considerations of the
	overall intent-based system is provided in section 10 of [CLEMM].
	9. IANA Considerations
	This document has no actions for IANA.
	10. Contributors
	The following people all contributed to creating this document:		More details of these security intents will be described in future
			documents that specify architecture, functionality, user intents, and
			models. An analysis of the security considerations of the overall
			intent-based system is provided in Section 9 of [RFC9315].
	Contributed significant text:		9. IANA Considerations
	Xueyuan Sun, China Telecom		This document has no IANA actions.
	Will (Shucheng) Liu, Huawei
	Contributed text in early drafts:		10. Informative References
	Ying Chen, China Unicom
	John Strassner, Huawei
	Weiping Xu, Huawei
	Richard Meade, Huawei
	11. Acknowledgments		[Banerjee21]
			Banerjee, A., Mwanje, S., and G. Carle, "Contradiction
			Management in Intent-driven Cognitive Autonomous RAN",
			September 2021.
	This document has benefited from reviews, suggestions, comments and		[Bezahaf19]
	proposed text provided by the following members, listed in		Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E.,
	alphabetical order: Mehdi Bezahaf, Brian E Carpenter, Laurent		Broadbent, M., King, D., and D. Hutchison, "Self-Generated
	Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome		Intent-Based System", 10th International Conference on
	Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav		Networks of the Future (NoF),
	Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff		DOI 10.1109/NoF47743.2019.9015045, October 2019,
	Tantsura.		<https://doi.org/10.1109/NoF47743.2019.9015045>.
	We thank to Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide		[Bezahaf21]
	Borsatti, for contributing with their 'A multi-level approach to		Bezahaf, M., Davies, E., Rotsos, C., and N. Race, "To All
	IBN' PoC demonstration a first attempt to adopt the intent		Intents and Purposes: Towards Flexible Intent Expression",
	classification methodology.		IEEE 7th International Conference on Network
			Softwarization (NetSoft),
			DOI 10.1109/NetSoft51509.2021.9492554, July 2021,
			<https://doi.org/10.1109/NetSoft51509.2021.9492554>.
	12. Informative References		[Davoli21] Davoli, G., "Programmability and Management of Software-
			Defined Network Infrastructures", 2021.
	[Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C. and Race, N., "To All		[IFIP-NSM] IFIP, "Network and Service Management Taxonomy",
	Intents and Purposes: Towards Flexible Intent Expression,"		<https://www.simpleweb.org/ifip/taxonomy.html>.
	2021 IEEE 7th International Conference on Network
	Softwarization (NetSoft), 2021.
	[Bezhaf19] Bezahaf, M., Hernandez, MP, Bardwell, L., Davies, E.,		[Jacobs18] Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville,
	Broadbent, M.,King, D. and Hutchison, D. , "Self-Generated		"Refining Network Intents for Self-Driving Networks",
	Intent-Based System," 2019 10th International Conference on		Proceedings of the Afternoon Workshop on Self-Driving
	Networks of the Future (NoF), 2019.		Networks (SelfDN), DOI 10.1145/3229584.3229590, August
			2018, <https://doi.org/10.1145/3229584.3229590>.
	[Jacobs18] Jacobs, A.S., Pfitscher,R.J., Ferreira, R.A., and		[Leivadeas21]
	Granville, L.Z., "Refining Network Intents for Self-Driving		Leivadeas, A. and M. Falkner, "VNF Placement Problem: A
	Networks", Proceedings of the Afternoon Workshop on Self-		Multi-Tenant Intent-Based Networking Approach", 24th
	Driving Networks (SelfDN 2018), 2018.		Conference on Innovation in Clouds, Internet and Networks
			and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553,
			March 2021,
			<https://doi.org/10.1109/ICIN51074.2021.9385553>.
	[Banerjee21] Banerjee,A., Mwanje. S. and Carle, G., "Contradiction		[Mehmood21]
	Management in Intent-driven Cognitive Autonomous RAN",		Mehmood, K., Kralevska, K., and D. Palma, "Intent-driven
	2021.		Autonomous Network and Service Management in Future
			Networks: A Structured Literature Review",
			DOI 10.48550/arXiv.2108.04560, August 2021,
			<https://doi.org/10.48550/arXiv.2108.04560>.
	[Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H. H., Ye, Q., Wang, C.,		[ONF] Open Networking Foundation, "Intent NBI - Definition and
	and Zhao, B. Y., "Safely and automatically updating in-		Principles", October 2016,
	network ACL configurations with intent language", SIGCOMM		<https://opennetworking.wpengine.com/wp-
	'19, 2019.		content/uploads/2014/10/TR-
			523_Intent_Definition_Principles.pdf>.
	[Leivadeas21] Leivadeas, A. and Falkner, M., "VNF Placement Problem:		[ONOS] Koshibe, A., "Intent Framework", 2016,
	A Multi-Tenant Intent-Based Networking Approach," 24th		<https://wiki.onosproject.org/display/ONOS/
	Conference on Innovation in Clouds, Internet and Networks		Intent+Framework/>.
	and Workshops (ICIN), 2021.
	[Davoli21] Davoli, G., "Programmability and Management of Software-		[Padovan20]
	defined Network Infrastructures", 2021.		Padovan, S., "Design and Implementation of a Blockchain
			Intent Management System", November 2020.
	[Padovan20] Padovan, S., "Design and Implementation of a Blockchain		[POC-IBN] Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti,
	Intent Management System", 2020.		"A Multi-Level Approach to IBN", IETF 108 Hackathon
			Report, July 2020,
			<https://www.ietf.org/proceedings/108/slides/slides-108-
			nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-
			ibn-02>.
	[Mehmood21] Mehmood, K., Kralevska, K., and Palma, D., "Intent-driven		[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
	Autonomous Network and Service Management in Future		Tantsura, "Intent-Based Networking - Concepts and
	Networks: A Structured Literature Review", 2021.		Definitions", RFC 9315, DOI 10.17487/RFC9315, October
			2022, <https://www.rfc-editor.org/info/rfc9315>.
	[Szilagyi21] Szilagyi, P., "I2BN: Intelligent Intent Based Networks",		[Szilagyi21]
	Journal of ICT Standardization, 2021.		Szilágyi, P., "I2BN: Intelligent Intent Based Networks",
			Journal of ICT Standardization, Volume 9, Issue 2,
			DOI 10.13052/jicts2245-800X.926, June 2021,
			<https://doi.org/10.13052/jicts2245-800X.926>.
	[POC-IBN] Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide		[Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C.,
	Borsatti, "A multi-level approach to IBN", July 2020,		Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C.,
	https://www.ietf.org/proceedings/108/slides/slides-108-		Zheng, H., and B. Zhao, "Safely and automatically updating
	nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-		in-network ACL configurations with intent language",
	ibn-02		SIGCOMM '19: Proceedings of the ACM Special Interest Group
			on Data Communication, DOI 10.1145/3341302.3342088, August
			2019, <https://doi.org/10.1145/3341302.3342088>.
	[IFIP-NSM] IFIP - Network and Service Management Taxonomy,		[TMF-AUTO] Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C.,
	https://www.simpleweb.org/ifip/taxonomy.html		Domingos, J., Troullides, Y., Mas, I., Traver, G., and G.
			Lupo, "Autonomous Networks: Empowering Digital
			Transformation For The Telecoms Industry", May 2019.
	[ONF] ONF, "Intent Definition Principles", 2017,		Acknowledgments
	<https://www.opennetworking.org/images/stories/downloads/
	sdn-resources/technical-reports/TR-
	523_Intent_Definition_Principles.pdf>.
	[ONOS] ONOS, "ONOS Intent Framework", 2017,		This document has benefited from reviews, suggestions, comments, and
	<https://wiki.onosproject.org/display/ONOS/Intent+Framework		proposed text provided by the following members listed in
	/>.		alphabetical order: Mehdi Bezahaf, Brian E. Carpenter, Laurent
			Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome
			Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav
			Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, and Jeff
			Tantsura.
	[CLEMM] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent-		We thank Barbara Martini, Walter Cerroni, Molka Gharbaoui, and Davide
	Based Networking - Concepts and Overview", Work in		Borsatti for contributing with their "A multi-level approach to IBN"
	Progress, draft-irtf-nmrg-ibn-concepts-definitions-05,		PoC demonstration, a first attempt to adopt the intent classification
	February 2021, https://tools.ietf.org/html/draft-irtf-nmrg-		methodology.
	ibn-concepts-definitions-05
	[TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of		Contributors
	Autonomous Networks: Empowering Digital Transformation For
	the Telecoms Industry, inform.tmforum.org, 15 May, 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		The following people all contributed to creating this document:
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,		Contributed significant text:
	Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
	Networking: Definitions and Design Goals", RFC 7575, June
	2015.
	[RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,		Xueyuan Sun
	M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based		China Telecom
	Management Framework for the Simplified Use of Policy
	Abstractions (SUPA)", March 2018.
	[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,		Will (Shucheng) Liu
	Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson,		Huawei
	M., Perry, J., Waldbusser, S., "Terminology for Intent-
	driven Management", RFC 3198, November 2001.
	[RFC6020] Bjorlund, M., "YANG - A Data Modelling Language for Network		Contributed text in early draft versions of this document:
	Configuration Protocol (NETCONF)", RFC 6020, October 2010.
	[RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.		Ying Chen
	Roome, S. Shalunov, R. Woundy "Application-Layer Traffic		China Unicom
	Optimization (ALTO) Protocol", September 2014.
	[ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017,		John Strassner
	<https://datatracker.ietf.org/doc/draft-du-anima-an-		Huawei
	intent/>.
	[SUPA] Strassner, J., "Simplified Use of Policy Abstractions",		Weiping Xu
	2017, <https://datatracker.ietf.org/doc/draft-ietf-supa-		Huawei
	generic-policy-info-model/?include_text=1>.
	[ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun,		Richard Meade
	"Autonomic IPv6 Edge Prefix Management in Large-scale		Huawei
	Networks", draft-ietf-anima-prefix-management-07 (work in
	progress), December 2017.
	Authors' Addresses		Authors' Addresses
	Chen Li		Chen Li
	China Telecom		China Telecom
	No.118 Xizhimennei street, Xicheng District		Xicheng District
	Beijing 100035		No.118 Xizhimennei street
	P.R. China		Beijing
	Email: lichen.bri@chinatelecom.cn		100035
			China
			Email: lichen6@chinatelecom.cn
	Olga Havel		Olga Havel
	Huawei Technologies		Huawei Technologies
	Ireland		Ireland
	Email: olga.havel@huawei.com		Email: olga.havel@huawei.com
	Adriana Olariu		Adriana Olariu
	Huawei Technologies		Huawei Technologies
	Ireland		Ireland
	Email: adriana.olariu@huawei.com		Email: adriana.olariu@huawei.com
	Pedro Martinez-Julia		Pedro Martinez-Julia
	NICT		NICT
	Japan		Japan
	Email: pedro@nict.go.jp		Email: pedro@nict.go.jp
	Jeferson Campos Nobre		Jeferson Campos Nobre
	Federal University of Rio Grande do Sul		Federal University of Rio Grande do Sul (UFRGS)
	Porto Alegre		Porto Alegre-RS
	Brazil		Brazil
	Email: jcnobre@inf.ufrgs.br		Email: jcnobre@inf.ufrgs.br
	Diego R. Lopez		Diego R. Lopez
	Telefonica I+D		Telefonica I+D
	Don Ramon de la Cruz, 82		Don Ramon de la Cruz, 82
	Madrid 28006		28006 Madrid
	Spain		Spain
	Email: diego.r.lopez@telefonica.com		Email: diego.r.lopez@telefonica.com
End of changes. 312 change blocks.
	1279 lines changed or deleted		1387 lines changed or added
This html diff was produced by rfcdiff 1.48.