< draft-ietf-teas-ietf-network-slices-00.txt		draft-ietf-teas-ietf-network-slices-01.txt >
	Network Working Group A. Farrel, Ed.		Network Working Group A. Farrel, Ed.
	Internet-Draft Old Dog Consulting		Internet-Draft Old Dog Consulting
	Intended status: Informational E. Gray		Intended status: Informational E. Gray
	Expires: October 16, 2021 Ericsson		Expires: October 18, 2021 Ericsson
	J. Drake		J. Drake
	Juniper Networks		Juniper Networks
	R. Rokui		R. Rokui
	Nokia		Nokia
	S. Homma		S. Homma
	NTT		NTT
	K. Makhijani		K. Makhijani
	Futurewei		Futurewei
	LM. Contreras		LM. Contreras
	Telefonica		Telefonica
	J. Tantsura		J. Tantsura
	Juniper Networks		Juniper Networks
	April 14, 2021		April 16, 2021
	Framework for IETF Network Slices		Framework for IETF Network Slices
	draft-ietf-teas-ietf-network-slices-00		draft-ietf-teas-ietf-network-slices-01
	Abstract		Abstract
	<FAb>		This document describes network slicing in the context of networks
			built from IETF technologies. It defines the term "IETF Network
	This memo discusses setting up special-purpose network connections		Slice" and establishes the general principles of network slicing in
	using existing IETF technologies. These connections are called IETF		the IETF context.
	network slices for the purposes of this memo. The memo discusses the
	general framework for this setup, the necessary system components and
	interfaces, and how abstract requests can be mapped to more specific
	technologies. The memo also discusses related considerations with
	monitoring and security.
	This memo is intended for discussing interfaces and technologies. It
	is not intended to be a new set of concrete interfaces or
	technologies. Rather, it should be seen as an explanation of how
	some existing, concrete IETF VPN and traffic-engineering technologies
	can be used to create IETF network slices. Note that there are a
	number of these technologies, and new technologies or capabilities
	keep being added. This memo is also not intended presume any
	particular technology choice.
	<DAb>
	This document provides a definition of the term "IETF Network Slice"		The document discusses the general framework for requesting and
	for use within the IETF and specifically as a reference for other		operating IETF Network Slices, the characteristics of an IETF Network
	IETF documents that describe or use aspects of network slices.		Slice, the necessary system components and interfaces, and how
			abstract requests can be mapped to more specific technologies. The
			document also discusses related considerations with monitoring and
			security.
	The document also describes the characteristics of an IETF network		This document also provides definitions of related terms to enable
	slice, related terms and their meanings, and explains how IETF		consistent usage in other IETF documents that describe or use aspects
	network slices can be used in combination with end-to-end network		of IETF Network Slices.
	slices or independent of them.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 16, 2021.		This Internet-Draft will expire on October 18, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://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. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
	3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
	3.1. Definition and Scope of IETF Network Slice . . . . . . . 7		3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6
	4. IETF Network Slice System Characteristics . . . . . . . . . . 8		3.1. Definition and Scope of IETF Network Slice . . . . . . . 6
	4.1. Objectives for IETF Network Slices . . . . . . . . . . . 8		4. IETF Network Slice System Characteristics . . . . . . . . . . 7
	4.1.1. Service Level Objectives . . . . . . . . . . . . . . 9		4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7
	4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 9		4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8
	4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 11		4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 10
			4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 12
	4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 11		4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 12
	4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 13		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. IETF Network Slice Composition . . . . . . . . . . . . . 13		5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 12
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 13
	5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 15		5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 15
	5.2. Management Systems or Other Applications . . . . . . . . 15		5.3.1. IETF Network Slice Controller Interfaces . . . . . . 17
	5.3. Expressing Connectivity Intents . . . . . . . . . . . . . 16		5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 17
	5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 17		5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 18
	5.5. IETF Network Slice Controller (NSC) . . . . . . . . . . . 19		5.5. Realizing IETF Network Slice . . . . . . . . . . . . . . 20
	5.5.1. IETF Network Slice Controller Interfaces . . . . . . 20		5.5.1. Underlying Technology . . . . . . . . . . . . . . . . 20
	5.5.2. Northbound Interface (NBI) . . . . . . . . . . . . . 21		6. Applicability of ACTN to IETF Network Slices . . . . . . . . 21
	5.6. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22		7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 23
	5.7. Realizing IETF Network Slice . . . . . . . . . . . . . . 22		7.1. Isolation as a Service Requirement . . . . . . . . . . . 23
	5.7.1. Underlying Technology . . . . . . . . . . . . . . . . 22		7.2. Isolation in IETF Network Slice Realization . . . . . . . 24
	6. Applicability of ACTN to IETF Network Slices . . . . . . . . 23		8. Management Considerations . . . . . . . . . . . . . . . . . . 24
	7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 25		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	7.1. Isolation as a Service Requirement . . . . . . . . . . . 25		9.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25
	7.2. Isolation in IETF Network Slice Realization . . . . . . . 26		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	8. Management Considerations . . . . . . . . . . . . . . . . . . 26		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 26		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	9.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		13.1. Normative References . . . . . . . . . . . . . . . . . . 27
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		13.2. Informative References . . . . . . . . . . . . . . . . . 27
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		Appendix A. Unused Material . . . . . . . . . . . . . . . . . . 31
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		A.1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 32
	13.1. Normative References . . . . . . . . . . . . . . . . . . 30		A.2. Management Systems or Other Applications . . . . . . . . 32
	13.2. Informative References . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	Appendix A. Unused Material . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	===================== EDITOR'S NOTE =====================		===================== EDITOR'S NOTE =====================
	This document is a merge of the text in		This document is a merge of the text in
	[I-D.ietf-teas-ietf-network-slice-definition] and		[I-D.ietf-teas-ietf-network-slice-definition] and
	[I-D.ietf-teas-ietf-network-slice-framework]. In this version, the		[I-D.ietf-teas-ietf-network-slice-framework]. In this version, the
	text is presented as a simple inclusion of all text from the		text included from the contributing documents has been re-arranged to
	contributing documents. The only work performed by the Editor in		rationalise the structure, but no substantive changes have been made.
	this revision is the assignment of text to the sections of the		Additionally, the Editor has made a number of stylistic edits and
	document, and the marking of the text to indicate its origin, as well		fixed further simple editorial and formatting issues.
	as simple editorial fixes to resolve the most basic typographic and
	formatting issues.
	For this purpose, the text in this revision is tagged to show its
	origin using the format <D1.3> or <F2.4> where the letters 'D' and
	'F' indicate the definitions draft
	[I-D.ietf-teas-ietf-network-slice-definition] and the framework draft
	[I-D.ietf-teas-ietf-network-slice-framework] respectively, and the
	subsequent numbers indicate the the section of the source document.
	In the case that the source text is not used within the document, it		In the case that the source text is not used within the document, it
	is presented in Appendix A.		is presented in Appendix A.
	It is expected that this is a short term measure and that later
	revisions will be presented as text in its own right.
	=================== END EDITOR'S NOTE ===================		=================== END EDITOR'S NOTE ===================
	<D1.>
	A number of use cases benefit from network connections that along		A number of use cases benefit from network connections that along
	with the connectivity provide assurance of meeting a specific set of		with the connectivity provide assurance of meeting a specific set of
	objectives wrt network resources use. In this document, as detailed		objectives with respect to network resources use. This connectivity
	in the subsequent sections, we refer to this connectivity and		and resource commitment is referred to as a network slice. Since the
	resource commitment as an IETF Network Slice. Services that might		term network slice is rather generic, the qualifying term "IETF" is
	benefit from the network slices include but not limited to:		used in this document to limit the scope of network slice to network
			technologies described and standardized by the IETF. This document
			defines the concept of IETF Network Slices that provide connectivity
			coupled with a set of specific commitments of network resources
			between a number of endpoints over a shared network infrastructure.
			Services that might benefit from IETF Network Slices include, but are
			not limited to:
	o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501])		o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501])
	o Network wholesale services		o Network wholesale services
	o Network infrastructure sharing among operators		o Network infrastructure sharing among operators
	o NFV connectivity and Data Center Interconnect		o NFV connectivity and Data Center Interconnect
	The use cases are further described in		IETF Network Slices are created and managed within the scope of one
	[I-D.ietf-teas-ietf-network-slice-framework].
	This document defines the concept of IETF network slices that provide
	connectivity coupled with a set of specific commitments of network
	resources between a number of endpoints over a shared network
	infrastructure. Since the term network slice is rather generic, the
	qualifying term 'IETF' is used in this document to limit the scope of
	network slice to network technologies described and standardized by
	the IETF.
	IETF network slices are created and managed within the scope of one
	or more network technologies (e.g., IP, MPLS, optical). They are		or more network technologies (e.g., IP, MPLS, optical). They are
	intended to enable a diverse set of applications that have different		intended to enable a diverse set of applications that have different
	requirements to coexist on the shared network infrastructure. A		requirements to coexist on the shared network infrastructure. A
	request for an IETF network slice is technology-agnostic so as to		request for an IETF Network Slice is technology-agnostic so as to
	allow a consumer to describe their network connectivity objectives in		allow a consumer to describe their network connectivity objectives in
	a common format, independent of the underlying technologies used.		a common format, independent of the underlying technologies used.
	<F1.>		This document also provides a framework for discussing IETF Network
	This document provides a framework for discussing IETF network		Slices. This framework is intended as a structure for discussing
	slices, as defined in [I-D.ietf-teas-ietf-network-slice-definition].		interfaces and technologies. It is not intended to specify a new set
	It is the intention in this document to use terminology consistent		of concrete interfaces or technologies. Rather, the idea is that
	with this and other definitions provided in that document.
	In particular, this document uses the following terminology defined
	in the definitions document:
	o IETF Network Slice
	o IETF Network Slice Controller (NSC)
	o Network Controller (NC)
	o Northbound Interface (NBI)
	o Southbound Interface (SBI)
	This framework is intended as a structure for discussing interfaces
	and technologies. It is not intended to specify a new set of
	concrete interfaces or technologies. Rather, the idea is that
	existing or under-development IETF technologies (plural) can be used		existing or under-development IETF technologies (plural) can be used
	to realize the concepts expressed herein.		to realize the concepts expressed herein.
	For example, virtual private networks (VPNs) have served the industry		For example, virtual private networks (VPNs) have served the industry
	well as a means of providing different groups of users with logically		well as a means of providing different groups of users with logically
	isolated access to a common network. The common or base network that		isolated access to a common network. The common or base network that
	is used to provide the VPNs is often referred to as an underlay		is used to provide the VPNs is often referred to as an underlay
	network, and the VPN is often called an overlay network. As an		network, and the VPN is often called an overlay network. As an
	example technology, a VPN may in turn serve as an underlay network		example technology, a VPN may in turn serve as an underlay network
	for IETF network slices.		for IETF Network Slices.
	Note: It is conceivable that extensions to these IETF technologies		Note that it is conceivable that extensions to these IETF
	are needed in order to fully support all the ideas that can be		technologies are needed in order to fully support all the ideas that
	implemented with slices, but at least in the beginning there is no		can be implemented with slices, but at least in the beginning there
	plan for the creation of new protocols or interfaces.		is no plan for the creation of new protocols or interfaces.
			1.1. Background
	Driven largely by needs surfacing from 5G, the concept of network		Driven largely by needs surfacing from 5G, the concept of network
	slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530],		slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530],
	and [BBF-SD406]). In [TS23501], Network Slice is defined as "a		and [BBF-SD406]). In [TS23501], a Network Slice is defined as "a
	logical network that provides specific network capabilities and		logical network that provides specific network capabilities and
	network characteristics", and a Network Slice Instance is defined as		network characteristics", and a Network Slice Instance is defined as
	"A set of Network Function instances and the required resources (e.g.		"A set of Network Function instances and the required resources (e.g.
	compute, storage and networking resources) which form a deployed		compute, storage and networking resources) which form a deployed
	Network Slice." According to [TS28530], an end-to-end network slice		Network Slice." According to [TS28530], an end-to-end network slice
	consists of three major types of network segments: Radio Access		consists of three major types of network segments: Radio Access
	Network (RAN), Transport Network (TN) and Core Network (CN). IETF		Network (RAN), Transport Network (TN) and Core Network (CN). IETF
	network slice provides the required connectivity between different		Network Slice provides the required connectivity between different
	entities in RAN and CN segments of an end-to-end network slice, with		entities in RAN and CN segments of an end-to-end network slice, with
	a specific performance commitment. For each end-to-end network		a specific performance commitment. For each end-to-end network
	slice, the topology and performance requirement on a consumer's use		slice, the topology and performance requirement on a consumer's use
	of IETF network slice can be very different, which requires the		of IETF Network Slice can be very different, which requires the
	underlay network to have the capability of supporting multiple		underlay network to have the capability of supporting multiple
	different IETF network slices.		different IETF Network Slices.
	While network slices are commonly discussed in the context of 5G, it		While network slices are commonly discussed in the context of 5G, it
	is important to note that IETF network slices are a narrower concept,		is important to note that IETF Network Slices are a narrower concept,
	and focus primarily on particular network connectivity aspects.		and focus primarily on particular network connectivity aspects.
	Other systems, including 5G deployments, may use IETF network slices		Other systems, including 5G deployments, may use IETF Network Slices
	as a component to create entire systems and concatenated constructs		as a component to create entire systems and concatenated constructs
	that match their needs, including end-to-end connectivity.		that match their needs, including end-to-end connectivity.
	A IETF network slice could span multiple technologies and multiple		A IETF Network Slice could span multiple technologies and multiple
	administrative domains. Depending on the IETF network slice		administrative domains. Depending on the IETF Network Slice
	consumer's requirements, an IETF network slice could be isolated from		consumer's requirements, an IETF Network Slice could be isolated from
	other, often concurrent IETF network slices in terms of data, control		other, often concurrent IETF Network Slices in terms of data, control
	and management planes.		and management planes.
	The consumer expresses requirements for a particular IETF network		The consumer expresses requirements for a particular IETF Network
	slice by specifying what is required rather than how the requirement		Slice by specifying what is required rather than how the requirement
	is to be fulfilled. That is, the IETF network slice consumer's view		is to be fulfilled. That is, the IETF Network Slice consumer's view
	of a IETF network slice is an abstract one.		of an IETF Network Slice is an abstract one.
	Thus, there is a need to create logical network structures with		Thus, there is a need to create logical network structures with
	required characteristics. The consumer of such a logical network can		required characteristics. The consumer of such a logical network can
	require a degree of isolation and performance that previously might		require a degree of isolation and performance that previously might
	not have been satisfied by traditional overlay VPNs. Additionally,		not have been satisfied by traditional overlay VPNs. Additionally,
	the IETF network slice consumer might ask for some level of control		the IETF Network Slice consumer might ask for some level of control
	of their virtual networks, e.g., to customize the service paths in a		of their virtual networks, e.g., to customize the service paths in a
	network slice.		network slice.
	This document specifies a framework for the use of existing		This document specifies a framework for the use of existing
	technologies as components to provide a IETF network slice service,		technologies as components to provide an IETF Network Slice service,
	and might also discuss (or reference) modified and potential new		and might also discuss (or reference) modified and potential new
	technologies, as they develop (such as candidate technologies		technologies, as they develop (such as candidate technologies
	described in section 5 of [I-D.ietf-teas-enhanced-vpn]).		described in section 5 of [I-D.ietf-teas-enhanced-vpn]).
	2. Terms and Abbreviations		2. Terms and Abbreviations
	<D2.>
	The terms and abbreviations used in this document are listed below.		The terms and abbreviations used in this document are listed below.
			o NBI: NorthBound Interface
	o NS: Network Slice		o NS: Network Slice
	o NSC: Network Slice Controller		o NSC: Network Slice Controller
	o NBI: NorthBound Interface		o NSE: Network Slice Endpoint
	o SBI: SouthBound Interface		o SBI: SouthBound Interface
			o SLA: Service Level Agreement
	o SLI: Service Level Indicator		o SLI: Service Level Indicator
	o SLO: Service Level Objective		o SLO: Service Level Objective
	o SLA: Service Level Agreement
	The above terminology is defined in greater details in the remainder		The above terminology is defined in greater details in the remainder
	of this document.		of this document.
	3. IETF Network Slice Objectives		3. IETF Network Slice Objectives
	<F2.>		It is intended that IETF Network Slices can be created to meet
	It is intended that IETF network slices can be created to meet
	specific requirements, typically expressed as bandwidth, latency,		specific requirements, typically expressed as bandwidth, latency,
	latency variation, and other desired or required characteristics.		latency variation, and other desired or required characteristics.
	Creation is initiated by a management system or other application		Creation is initiated by a management system or other application
	used to specify network-related conditions for particular traffic		used to specify network-related conditions for particular traffic
	flows.		flows.
	And it is intended that, once created, these slices can be monitored,		It is also intended that, once created, these slices can be
	modified, deleted, and otherwise managed.		monitored, modified, deleted, and otherwise managed.
	It is also intended that applications and components will be able to		It is also intended that applications and components will be able to
	use these IETF network slices to move packets between the specified		use these IETF Network Slices to move packets between the specified
	end-points in accordance with specified characteristics.		end-points in accordance with specified characteristics.
	As an example of requirements that might apply to IETF network		As an example of requirements that might apply to IETF Network
	slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3).		Slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3).
	3.1. Definition and Scope of IETF Network Slice		3.1. Definition and Scope of IETF Network Slice
	<D3.>
	The definition of a network slice in IETF context is as follows:		The definition of a network slice in IETF context is as follows:
	An IETF network slice is a logical network topology connecting a		An IETF Network Slice is a logical network topology connecting a
	number of endpoints using a set of shared or dedicated network		number of endpoints using a set of shared or dedicated network
	resources that are used to satisfy specific Service Level Objectives		resources that are used to satisfy specific Service Level Objectives
	(SLOs).		(SLOs).
	An IETF network slice combines the connectivity resource requirements		An IETF Network Slice combines the connectivity resource requirements
	and associated network behaviors such as bandwidth, latency, jitter,		and associated network behaviors such as bandwidth, latency, jitter,
	and network functions with other resource behaviors such as compute		and network functions with other resource behaviors such as compute
	and storage availability. IETF network slices are independent of the		and storage availability. IETF Network Slices are independent of the
	underlying infrastructure connectivity and technologies used. This		underlying infrastructure connectivity and technologies used. This
	is to allow an IETF network slice consumer to describe their network		is to allow an IETF Network Slice consumer to describe their network
	connectivity and relevant objectives in a common format, independent		connectivity and relevant objectives in a common format, independent
	of the underlying technologies used.		of the underlying technologies used.
	IETF network slices may be combined hierarchically, so that a network		IETF Network Slices may be combined hierarchically, so that a network
	slice may itself be sliced. They may also be combined sequentially		slice may itself be sliced. They may also be combined sequentially
	so that various different networks can each be sliced and the network		so that various different networks can each be sliced and the network
	slices placed into a sequence to provide an end-to-end service. This		slices placed into a sequence to provide an end-to-end service. This
	form of sequential combination is utilized in some services such as		form of sequential combination is utilized in some services such as
	in 3GPP's 5G network [TS23501].		in 3GPP's 5G network [TS23501].
	An IETF network slice is technology-agnostic, and the means for IETF		An IETF Network Slice is technology-agnostic, and the means for IETF
	network slice realization can be chosen depending on several factors		Network Slice realization can be chosen depending on several factors
	such as: service requirements, specifications or capabilities of		such as: service requirements, specifications or capabilities of
	underlying infrastructure. The structure and different		underlying infrastructure. The structure and different
	characteristics of IETF network slices are described in the following		characteristics of IETF Network Slices are described in the following
	sections.		sections.
	Term "Slice" refers to a set of characteristics and behaviours that		Term "Slice" refers to a set of characteristics and behaviours that
	separate one type of user-traffic from another. IETF network slice		separate one type of user-traffic from another. IETF Network Slice
	assumes that an underlying network is capable of changing the		assumes that an underlying network is capable of changing the
	configurations of the network devices on demand, through in-band		configurations of the network devices on demand, through in-band
	signaling or via controller(s) and fulfilling all or some of SLOs to		signaling or via controller(s) and fulfilling all or some of SLOs to
	all of the traffic in the slice or to specific flows.		all of the traffic in the slice or to specific flows.
	4. IETF Network Slice System Characteristics		4. IETF Network Slice System Characteristics
	<D4.>
	The following subsections describe the characteristics of IETF		The following subsections describe the characteristics of IETF
	network slices.		Network Slices.
	4.1. Objectives for IETF Network Slices		4.1. Objectives for IETF Network Slices
	<D4.1.>		An IETF Network Slice is defined in terms of several quantifiable
			characteristics or Service Level Objectives (SLOs). SLOs along with
	An IETF network slice is defined in terms of several quantifiable		the terms Service Level Indicator (SLI) and Service Level Agreement
	characteristics or service level objectives (SLOs). SLOs along with		(SLA) are used to define the performance of a service at different
	terms Service Level Indicator (SLI) and Service Level Agreement (SLA)		levels.
	are used to define the performance of a service at different levels.
	A Service Level Indicator (SLI) is a quantifiable measure of an		A Service Level Indicator (SLI) is a quantifiable measure of an
	aspect of the performance of a network. For example, it may be a		aspect of the performance of a network. For example, it may be a
	measure of throughput in bits per second, or it may be a measure of		measure of throughput in bits per second, or it may be a measure of
	latency in milliseconds.		latency in milliseconds.
	A Service Level Objective (SLO) is a target value or range for the		A Service Level Objective (SLO) is a target value or range for the
	measurements returned by observation of an SLI. For example, an SLO		measurements returned by observation of an SLI. For example, an SLO
	may be expressed as "SLI <= target", or "lower bound <= SLI <= upper		may be expressed as "SLI <= target", or "lower bound <= SLI <= upper
	bound". A network slice is expressed in terms of the set of SLOs		bound". A network slice is expressed in terms of the set of SLOs
	that are to be delivered for the different connections between		that are to be delivered for the different connections between
	endpoints.		endpoints.
	A Service Level Agreement (SLA) is an explicit or implicit contract		A Service Level Agreement (SLA) is an explicit or implicit contract
	between the consumer of an IETF network slice and the provider of the		between the consumer of an IETF Network Slice and the provider of the
	slice. The SLA is expressed in terms of a set of SLOs and may		slice. The SLA is expressed in terms of a set of SLOs and may
	include commercial terms as well as the consequences of missing/		include commercial terms as well as the consequences of missing/
	violating the SLOs they contain.		violating the SLOs they contain.
	Additional descriptions of IETF network slice attributes is covered		Additional descriptions of IETF Network Slice attributes is covered
	in [I-D.contreras-teas-slice-nbi].		in [I-D.contreras-teas-slice-nbi].
	4.1.1. Service Level Objectives		4.1.1. Service Level Objectives
	<D4.1.1.>
	SLOs define a set of network attributes and characteristics that		SLOs define a set of network attributes and characteristics that
	describe an IETF network slice. SLOs do not describe 'how' the IETF		describe an IETF Network Slice. SLOs do not describe how the IETF
	network slices are implemented or realized in the underlying network		Network Slices are implemented or realized in the underlying network
	layers. Instead, they are defined in terms of dimensions of		layers. Instead, they are defined in terms of dimensions of
	operation (time, capacity, etc.), availability, and other attributes.		operation (time, capacity, etc.), availability, and other attributes.
	An IETF network slice can have one or more SLOs associated with it.		An IETF Network Slice can have one or more SLOs associated with it.
	The SLOs are combined in an SLA. The SLOs are defined for sets of		The SLOs are combined in an SLA. The SLOs are defined for sets of
	two or more endpoints and apply to specific directions of traffic		two or more endpoints and apply to specific directions of traffic
	flow. That is, they apply to specific source endpoints and specific		flow. That is, they apply to specific source endpoints and specific
	connections between endpoints within the set of endpoints and		connections between endpoints within the set of endpoints and
	connections in the network slice.		connections in the IETF Network Slice.
	4.1.2. Minimal Set of SLOs
	<D4.1.2.>		4.1.1.1. Minimal Set of SLOs
	This document defines a minimal set of SLOs and later systems or		This document defines a minimal set of SLOs and later systems or
	standards could extend this set as per Section 4.1.3.		standards could extend this set as described in Section 4.1.1.2.
	SLOs can be categorized in to 'Directly Measurable Objectives' or		SLOs can be categorized in to 'Directly Measurable Objectives' or
	'Indirectly Measurable Objectives'. Objectives such as guaranteed		'Indirectly Measurable Objectives'. Objectives such as guaranteed
	minimum bandwidth, guaranteed maximum latency, maximum permissible		minimum bandwidth, guaranteed maximum latency, maximum permissible
	delay variation, maximum permissible packet loss rate, and		delay variation, maximum permissible packet loss rate, and
	availability are 'Directly Measurable Objectives'. While 'Indirectly		availability are 'Directly Measurable Objectives'. While 'Indirectly
	Measurable Objectives' include security, geographical restrictions,		Measurable Objectives' include security, geographical restrictions,
	maximum occupancy level objectives. The later standard might define		maximum occupancy level objectives. The later standard might define
	other SLOs as needed.		other SLOs as needed.
	Editor's Note TODO: replace Minimal set to most commonly used		Editor's Note TODO: replace Minimal set to most commonly used
	objectives to describe network behavior. Other directly or		objectives to describe network behavior. Other directly or
	indirectly measurable objectives may be requested by that consumer of		indirectly measurable objectives may be requested by that consumer of
	an IETF network slice.		an IETF Network Slice.
	The definition of these objectives are as follows:		The definition of these objectives are as follows:
	Guaranteed Minimum Bandwidth		Guaranteed Minimum Bandwidth
	Minimum guaranteed bandwidth between two endpoints at any time.		Minimum guaranteed bandwidth between two endpoints at any time.
	The bandwidth is measured in data rate units of bits per second		The bandwidth is measured in data rate units of bits per second
	and is measured unidirectionally.		and is measured unidirectionally.
	Guaranteed Maximum Latency		Guaranteed Maximum Latency
	Upper bound of network latency when transmitting between two		Upper bound of network latency when transmitting between two
	endpoints. The latency is measured in terms of network		endpoints. The latency is measured in terms of network
	characteristics (excluding application-level latency).		characteristics (excluding application-level latency).
	[RFC2681] and [RFC7679] discuss round trip times and one-way		[RFC2681] and [RFC7679] discuss round trip times and one-way
	skipping to change at page 10, line 41 ¶		skipping to change at page 9, line 31 ¶
	two endpoints.		two endpoints.
	Maximum permissible packet loss rate		Maximum permissible packet loss rate
	The ratio of packets dropped to packets transmitted between two		The ratio of packets dropped to packets transmitted between two
	endpoints over a period of time. See [RFC7680].		endpoints over a period of time. See [RFC7680].
	Availability		Availability
	The ratio of uptime to the sum of uptime and downtime, where		The ratio of uptime to the sum of uptime and downtime, where
	uptime is the time the IETF network slice is available in		uptime is the time the IETF Network Slice is available in
	accordance with the SLOs associated with it.		accordance with the SLOs associated with it.
	Security		Security
	An IETF network slice consumer may request that the network		An IETF Network Slice consumer may request that the network
	applies encryption or other security techniques to traffic		applies encryption or other security techniques to traffic
	flowing between endpoints.		flowing between endpoints.
	Note that the use of security or the violation of this SLO is		Note that the use of security or the violation of this SLO is
	not directly observable by the IETF network slice consumer and		not directly observable by the IETF Network Slice consumer and
	cannot be measured as a quantifiable metric.		cannot be measured as a quantifiable metric.
	Also note that the objective may include request for encryption		Also note that the objective may include request for encryption
	(e.g., [RFC4303]) between the two endpoints explicitly to meet		(e.g., [RFC4303]) between the two endpoints explicitly to meet
	architecture recommendations as in [TS33.210] or for compliance		architecture recommendations as in [TS33.210] or for compliance
	with [HIPAA] and/or [PCI].		with [HIPAA] and/or [PCI].
	Editor's Note: Please see more discussion on security in		Please see more discussion on security in Section 9.
	Section 9.
	4.1.3. Other Objectives
	<D4.1.3.>		4.1.1.2. Other Service Level Objectives
	Additional SLOs may be defined to provide additional description of		Additional SLOs may be defined to provide additional description of
	the IETF network slice that a consumer requests.		the IETF Network Slice that a consumer requests.
	If the IETF network slice consumer service is traffic aware, other		If the IETF Network Slice consumer service is traffic aware, other
	traffic specific characteristics may be valuable including MTU,		traffic specific characteristics may be valuable including MTU,
	traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a		traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a
	higher-level behavior to process traffic according to user-		higher-level behavior to process traffic according to user-
	application (which may be realized using network functions).		application (which may be realized using network functions).
	Maximal occupancy for an IETF network slice should be provided.		Maximal occupancy for an IETF Network Slice should be provided.
	Since it carries traffic for multiple flows between the two		Since it carries traffic for multiple flows between the two
	endpoints, the objectives should also say if they are for the entire		endpoints, the objectives should also say if they are for the entire
	connection, group of flows or on per flow basis. Maximal occupancy		connection, group of flows or on per flow basis. Maximal occupancy
	should specify the scale of the flows (i.e., maximum number of flows		should specify the scale of the flows (i.e., maximum number of flows
	to be admitted) and optionally a maximum number of countable resource		to be admitted) and optionally a maximum number of countable resource
	units, e.g., IP or MAC addresses a slice might consume.		units, e.g., IP or MAC addresses a slice might consume.
	4.2. IETF Network Slice Endpoints		4.2. IETF Network Slice Endpoints
	<D4.2.>		As noted in Section 3.1, an IETF Network Slice describes connectivity
	As noted in Section 3.1, an IETF network slice describes connectivity
	between multiple endpoints across the underlying network. These		between multiple endpoints across the underlying network. These
	connectivity types are: point-to-point, point-to-multipoint,		connectivity types are: point-to-point, point-to-multipoint,
	multipoint-to-point multipoint-to-point, or multipoint-to-multipoint.		multipoint-to-point, multipoint-to-point, or multipoint-to-
			multipoint.
	Figure 1 shows an IETF network slice along with its NSEs.		Figure 1 shows an IETF Network Slice along with its Network Slice
			Endpoints (NSEs).
	The characteristics of IETF network slice endpoints (NSEs) are as		The characteristics of IETF NSEs are as follows:
	follows:
	o The IETF network slice endpoints (NSEs) are conceptual points of		o The IETF NSE are conceptual points of connection to IETF network
	connection to IETF network slice. As such, they serve as the IETF		slice. As such, they serve as the IETF Network Slice ingress/
	network slice ingress/egress points.		egress points.
	o Each endpoint could map to a device, application or a network		o Each endpoint could map to a device, application or a network
	function. A non-exhaustive list of devices, applications or		function. A non-exhaustive list of devices, applications or
	network functions might include but not limited to: routers,		network functions might include but not limited to: routers,
	switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes,		switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes,
	application acceleration, Deep Packet Inspection (DPI), server		application acceleration, Deep Packet Inspection (DPI), server
	load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header		load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header
	enrichment functions, and TCP optimizers.		enrichment functions, and TCP optimizers.
	o An NSE should be identified by a unique ID in the context of an		o An NSE should be identified by a unique ID in the context of an
	IETF network slice consumer.		IETF Network Slice consumer.
	o In addition to an identifier, each NSE should contain a subset of		o In addition to an identifier, each NSE should contain a subset of
	attributes such as IPv4/IPv6 addresses, encapsulation type (i.e.,		attributes such as IPv4/IPv6 addresses, encapsulation type (i.e.,
	VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc.		VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc.
	o A combination of NSE unique ID and NSE attributes defines an NSE		o A combination of NSE unique ID and NSE attributes defines an NSE
	in the context of the IETF network slice controller.		in the context of the IETF Network Slice Controller (NSC).
	o During the realization of the IETF network slice, in addition to		o During the realization of the IETF Network Slice, in addition to
	SLOs, all or subset of IETF NSE attributes will be utilized by		SLOs, all or subset of IETF NSE attributes will be utilized by the
	IETF network slice controller (NSC) to find the optimal		IETF NSC to find the optimal realization in the IETF network.
	realization in the IETF network.
	o Similarly to IETF network slices, the IETF network slice endpoints		o Similarly to IETF Network Slices, the IETF Network Slice Endpoints
	are logical entities that are mapped to services/tunnels/paths		are logical entities that are mapped to services/tunnels/paths
	endpoints in IETF network slice during its initialization and		endpoints in IETF Network Slice during its initialization and
	realization.		realization.
	Note that there are various IETF TE terms such as access points (AP)		Note that there are various IETF TE terms such as access points (AP)
	defined in [RFC8453], Termination Point (TP) defined in [RFC8345],		defined in [RFC8453], Termination Point (TP) defined in [RFC8345],
	and Link Termination Point (LTP) defined in [RFC8795] which are		and Link Termination Point (LTP) defined in [RFC8795] which are
	tightly coupled with TE network type and various realization		tightly coupled with TE network type and various realization
	techniques. At the time of realization of the IETF network slice,		techniques. At the time of realization of the IETF Network Slice,
	the NSE could be mapped to one or more of these based on the network		the NSE could be mapped to one or more of these based on the network
	slice realization technique in use.		slice realization technique in use.
	|----------------------------------|		|----------------------------------|
	NSE1 | | NSE2		NSE1 | | NSE2
	O.....| |.....O		O.....| |.....O
	. | | .		. | | .
	. | | .		. | | .
	. | | .		. | | .
	| |		| |
	skipping to change at page 13, line 28 ¶		skipping to change at page 12, line 7 ¶
	between endpoints NSE1 to NSEn		between endpoints NSE1 to NSEn
	Legend:		Legend:
	NSE: IETF Network Slice Endpoint		NSE: IETF Network Slice Endpoint
	O: Represents IETF Network Slice Endpoints		O: Represents IETF Network Slice Endpoints
	Figure 1: An IETF Network Slice Endpoints (NSE)		Figure 1: An IETF Network Slice Endpoints (NSE)
	4.2.1. IETF Network Slice Connectivity Types		4.2.1. IETF Network Slice Connectivity Types
	<D4.2.1.>
	The IETF Network Slice connection types can be point to point (P2P),		The IETF Network Slice connection types can be point to point (P2P),
	point to multipoint (P2MP), multi-point to point (MP2P), or multi-		point to multipoint (P2MP), multi-point to point (MP2P), or multi-
	point to multi-point (MP2MP). They will requested by the higher		point to multi-point (MP2MP). They will requested by the higher
	level operation system.		level operation system.
	4.3. IETF Network Slice Composition		4.3. IETF Network Slice Decomposition
	<D4.3.>
	Operationally, an IETF network slice may be decomposed in two or more		Operationally, an IETF Network Slice may be decomposed in two or more
	IETF network slices as specified below. Decomposed network slices		IETF Network Slices as specified below. Decomposed network slices
	are then independently realized and managed.		are then independently realized and managed.
	o Hierarchical (i.e., recursive) composition: An IETF network slice		o Hierarchical (i.e., recursive) composition: An IETF Network Slice
	can be further sliced into other network slices. Recursive		can be further sliced into other network slices. Recursive
	composition allows an IETF network slice at one layer to be used		composition allows an IETF Network Slice at one layer to be used
	by the other layers. This type of multi-layer vertical IETF		by the other layers. This type of multi-layer vertical IETF
	network slice associates resources at different layers.		Network Slice associates resources at different layers.
	o Sequential composition: Different IETF network slices can be		o Sequential composition: Different IETF Network Slices can be
	placed into a sequence to provide an end-to-end service. In		placed into a sequence to provide an end-to-end service. In
	sequential composition, each IETF network slice would potentially		sequential composition, each IETF Network Slice would potentially
	support different dataplanes that need to be stitched together.		support different dataplanes that need to be stitched together.
	5. Framework		5. Framework
	<F3.>		A number of IETF Network Slice services will typically be provided
			over a shared underlying network infrastructure. Each IETF Network
	A number of IETF network slice services will typically be provided		Slice consists of both the overlay connectivity and a specific set of
	over a shared underlying network infrastructure. Each IETF network
	slice consists of both the overlay connectivity and a specific set of
	dedicated network resources and/or functions allocated in a shared		dedicated network resources and/or functions allocated in a shared
	underlay network to satisfy the needs of the IETF network slice		underlay network to satisfy the needs of the IETF Network Slice
	consumer. In at least some examples of underlying network		consumer. In at least some examples of underlying network
	technologies, the integration between the overlay and various		technologies, the integration between the overlay and various
	underlay resources is needed to ensure the guaranteed performance		underlay resources is needed to ensure the guaranteed performance
	requested for different IETF network slices.		requested for different IETF Network Slices.
	IETF Network Slice Definition
	([I-D.ietf-teas-ietf-network-slice-definition] defines the role of a
	Customer (or User) and a IETF Network Slice Controller. That
	document also defines a NSC Northbound Interface (NBI).
	A IETF network slice user is served by the IETF Network Slice
	Controller (NSC), as follows:
	o The NSC takes requests from a management system or other
	application, which are then communicated via an NBI. This
	interface carries data objects the IETF network slice user
	provides, describing the needed IETF network slices in terms of
	topology, applicable service level objectives (SLO), and any
	monitoring and reporting requirements that may apply. Note that -
	in this context - "topology" means what the IETF network slice
	connectivity is meant to look like from the user's perspective; it
	may be as simple as a list of mutually (and symmetrically)
	connected end points, or it may be complicated by details of
	connection asymmetry, per-connection SLO requirements, etc.
	o These requests are assumed to be translated by one or more
	underlying systems, which are used to establish specific IETF
	network slice instances on top of an underlying network
	infrastructure.
	o The NSC maintains a record of the mapping from user requests to
	slice instantiations, as needed to allow for subsequent control
	functions (such as modification or deletion of the requested
	slices), and as needed for any requested monitoring and reporting
	functions.
	Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example		Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example
	architecture that might apply in using the technology described in		architecture that might apply in using the technology described in
	that document.		this document.
	5.1. IETF Network Slice Stakeholders		5.1. IETF Network Slice Stakeholders
	<D6.>		An IETF Network Slice and its realization involves the following
	An IETF network slice and its realization involves the following
	stakeholders and it is relevant to define them for consistent		stakeholders and it is relevant to define them for consistent
	terminology.		terminology.
	Consumer: A consumer is the requester of an IETF network slice.		Consumer: A consumer is the requester of an IETF Network Slice.
	Consumers may request monitoring of SLOs. A consumer may manage		Consumers may request monitoring of SLOs. A consumer may manage
	the IETF network slice service directly by interfacing with the		the IETF Network Slice service directly by interfacing with the
	IETF network slice controller or indirectly through an		IETF NSC or indirectly through an orchestrator.
	orchestrator.
	Orchestrator: An orchestrator is an entity that composes different		Orchestrator: An orchestrator is an entity that composes different
	services, resource and network requirements. It interfaces with		services, resource and network requirements. It interfaces with
	the IETF network slice controllers.		the IETF NSC.
	IETF Network Slice Controller (NSC): It realizes an IETF network		IETF Network Slice Controller (NSC): It realizes an IETF Network
	lice in the underlying network, maintains and monitors the run-		Slice in the underlying network, maintains and monitors the run-
	time state of resources and topologies associated with it. A		time state of resources and topologies associated with it. A
	well-defined interface is needed between different types of IETF		well-defined interface is needed between different types of IETF
	network slice controllers and different types of orchestrators.		NSCs and different types of orchestrators. An IETF Network Slice
	An IETF network slice operator (or slice operator for short)		operator (or slice operator for short) manages one or more IETF
	manages one or more IETF network slices using the IETF network		Network Slices using the IETF NSCs.
	slice Controller(s).
	Network Controller: is a form of network infrastructure controller		Network Controller: is a form of network infrastructure controller
	that offers network resources to NSC to realize a particular		that offers network resources to the NSC to realize a particular
	network slice. These may be existing network controllers		network slice. These may be existing network controllers
	associated with one or more specific technologies that may be		associated with one or more specific technologies that may be
	adapted to the function of realizing IETF network slices in a		adapted to the function of realizing IETF Network Slices in a
	network.		network.
	5.2. Management Systems or Other Applications		5.2. Expressing Connectivity Intents
	<F3.1.>
	The IETF network slice system is used by a management system or other
	application. These systems and applications may also be a part of a
	higher level function in the system, e.g., putting together network
	functions, access equipment, application specific components, as well
	as the IETF network slices.
	5.3. Expressing Connectivity Intents
	<F3.2.>
	The IETF Network Slice Controller (NSC) northbound interface (NBI)		The NSC northbound interface (NBI) can be used to communicate between
	can be used to communicate between IETF network slice users (or		IETF Network Slice users (or consumers) and the NSC.
	consumers) and the NSC.
	A IETF network slice user may be a network operator who, in turn,		An IETF Network Slice user may be a network operator who, in turn,
	provides the IETF network slice to another IETF network slice user or		provides the IETF Network Slice to another IETF Network Slice user or
	consumer.		consumer.
	Using the NBI, a consumer expresses requirements for a particular		Using the NBI, a consumer expresses requirements for a particular
	slice by specifying what is required rather than how that is to be		slice by specifying what is required rather than how that is to be
	achieved. That is, the consumer's view of a slice is an abstract		achieved. That is, the consumer's view of a slice is an abstract
	one. Consumers normally have limited (or no) visibility into the		one. Consumers normally have limited (or no) visibility into the
	provider network's actual topology and resource availability		provider network's actual topology and resource availability
	information.		information.
	This should be true even if both the consumer and provider are		This should be true even if both the consumer and provider are
	associated with a single administrative domain, in order to reduce		associated with a single administrative domain, in order to reduce
	the potential for adverse interactions between IETF network slice		the potential for adverse interactions between IETF Network Slice
	consumers and other users of the underlay network infrastructure.		consumers and other users of the underlay network infrastructure.
	The benefits of this model can include:		The benefits of this model can include:
	o Security: because the underlay network (or network operator) does		o Security: because the underlay network (or network operator) does
	not need to expose network details (topology, capacity, etc.) to		not need to expose network details (topology, capacity, etc.) to
	IETF network slice consumers the underlay network components are		IETF Network Slice consumers the underlay network components are
	less exposed to attack;		less exposed to attack;
	o Layered Implementation: the underlay network comprises network		o Layered Implementation: the underlay network comprises network
	elements that belong to a different layer network than consumer		elements that belong to a different layer network than consumer
	applications, and network information (advertisements, protocols,		applications, and network information (advertisements, protocols,
	etc.) that a consumer cannot interpret or respond to (note - a		etc.) that a consumer cannot interpret or respond to (note - a
	consumer should not use network information not exposed via the		consumer should not use network information not exposed via the
	NSC NBI, even if that information is available);		NSC NBI, even if that information is available);
	o Scalability: consumers do not need to know any information beyond		o Scalability: consumers do not need to know any information beyond
	that which is exposed via the NBI.		that which is exposed via the NBI.
	The general issues of abstraction in a TE network is described more		The general issues of abstraction in a TE network is described more
	fully in [RFC7926].		fully in [RFC7926].
	This framework document does not assume any particular layer at which		This framework document does not assume any particular layer at which
	IETF network slices operate as a number of layers (including virtual		IETF Network Slices operate as a number of layers (including virtual
	L2, Ethernet or IP connectivity) could be employed.		L2, Ethernet or IP connectivity) could be employed.
	Data models and interfaces are of course needed to set up IETF		Data models and interfaces are of course needed to set up IETF
	network slices, and specific interfaces may have capabilities that		Network Slices, and specific interfaces may have capabilities that
	allow creation of specific layers.		allow creation of specific layers.
	Layered virtual connections are comprehensively discussed in IETF		Layered virtual connections are comprehensively discussed in IETF
	documents and are widely supported. See, for instance, GMPLS-based		documents and are widely supported. See, for instance, GMPLS-based
	networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and		networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and
	[RFC8454]). The principles and mechanisms associated with layered		[RFC8454]). The principles and mechanisms associated with layered
	networking are applicable to IETF network slices.		networking are applicable to IETF Network Slices.
	There are several IETF-defined mechanisms for expressing the need for		There are several IETF-defined mechanisms for expressing the need for
	a desired logical network. The NBI carries data either in a		a desired logical network. The NBI carries data either in a
	protocol-defined format, or in a formalism associated with a modeling		protocol-defined format, or in a formalism associated with a modeling
	language.		language.
	For instance:		For instance:
	o Path Computation Element (PCE) Communication Protocol (PCEP)		o Path Computation Element (PCE) Communication Protocol (PCEP)
	[RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE		[RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE
	skipping to change at page 17, line 44 ¶		skipping to change at page 15, line 17 ¶
	o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to		o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to
	model configuration and other data for NETCONF, RESTCONF, and GNMI		model configuration and other data for NETCONF, RESTCONF, and GNMI
	- among others; ProtoBufs can be used to model gRPC and GNMI data;		- among others; ProtoBufs can be used to model gRPC and GNMI data;
	Structure of Management Information (SMI) [RFC2578] may be used to		Structure of Management Information (SMI) [RFC2578] may be used to
	define Management Information Base (MIB) modules for SNMP, using		define Management Information Base (MIB) modules for SNMP, using
	an adapted subset of OSI's Abstract Syntax Notation One (ASN.1,		an adapted subset of OSI's Abstract Syntax Notation One (ASN.1,
	1988).		1988).
	While several generic formats and data models for specific purposes		While several generic formats and data models for specific purposes
	exist, it is expected that IETF network slice management may require		exist, it is expected that IETF Network Slice management may require
	enhancement or augmentation of existing data models.		enhancement or augmentation of existing data models.
	5.4. IETF Network Slice Structure		5.3. IETF Network Slice Controller (NSC)
	<D5.>
	Editor's note: This content of this section merged with Relationship
	with E2E slice discussion.
	An IETF network slice is a set of connections among various endpoints
	to form a logical network that meets the SLOs agreed upon.
	|------------------------------------------|
	NSE1 O....| |....O NSE2
	. | | .
	. | IETF Network Slice | .
	. | (SLOs e.g. B/W > x bps, Delay < y ms) | .
	NSEm O....| |....O NSEn
	|------------------------------------------|
	== == == == == == == == == == == == == == == == == == == == == ==
	.--. .--.
	[EP1] ( )- . ( )- . [EP2]
	. .' IETF ' SLO .' IETF ' .
	. ( Network-1 ) ... ( Network-p ) .
	`-----------' `-----------'
	[EPm] [EPn]
	Legend
	NSE: IETF Network Slice Endpoints
	EP: Serivce/tunnels/path Endpoints used to realize the
	IETF Network Slice
	Figure 2: IETF Network slice
	Figure 2 illustrates a case where an IETF network slice provides
	connectivity between a set of IEFT network slice endpoints (NSE)
	pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps
	and guaranteed delay of no more than y ms). The IETF network slice
	endpoints are mapped to the underlay IETF networks endpoints (EP).
	Also, the IETF network slice endpoints on the same IETF network slice
	may belong to the same or different address spaces.
	IETF Network slice structure fits into a broader concept of end-to-
	end network slices. A network operator may be responsible for
	delivering services over a number of technologies (such as radio
	networks) and for providing specific and fine-grained services (such
	as CCTV feed or High definition realtime traffic data). That
	operator may need to combine slices of various networks to produce an
	end-to-end network service. Each of these networks may include
	multiple physical or virtual nodes and may also provide network
	functions beyond simply carrying of technology-specific protocol data
	units. An end-to-end network slice is defined by the 3GPP as a
	complete logical network that provides a service in its entirety with
	a specific assurance to the consumer [TS23501].
	An end-to-end network slice may be composed from other network slices
	that include IETF network slices. This composition may include the
	hierarchical (or recursive) use of underlying network slices and the
	sequential (or stitched) combination of slices of different networks.
	5.5. IETF Network Slice Controller (NSC)
	<F3.3.>		The IETF NSC takes abstract requests for IETF Network Slices and
			implements them using a suitable underlying technology. An IETF NSC
			is the key building block for control and management of the IETF
			Network Slice. It provides the creation/modification/deletion,
			monitoring and optimization of IETF Network Slices in a multi-domain,
			a multi-technology and multi-vendor environment.
	The IETF Network Slice Controller takes abstract requests for IETF		The main task of the IETF NSC is to map abstract IETF Network Slice
	network slices and implements them using a suitable underlying		requirements to concrete technologies and establish required
	technology. A IETF Network Slice Controller is the key building		connectivity, and ensuring that required resources are allocated to
	block for control and management of the IETF network slice. It		the IETF Network Slice.
	provides the creation/modification/deletion, monitoring and
	optimization of IETF network slices in a multi-domain, a multi-
	technology and multi-vendor environment.
	A NSC northbound interface (NBI) is needed for communicating details		A NSC northbound interface (NBI) is needed for communicating details
	of a IETF network slice (configuration, selected policies,		of a IETF Network Slice (configuration, selected policies,
	operational state, etc.), as well as providing information to a slice		operational state, etc.), as well as providing information to a slice
	requester/consumer about IETF network slice status and performance.		requester/consumer about IETF Network Slice status and performance.
	The details for this NBI are not in scope for this document.		The details for this NBI are not in scope for this document.
	The controller provides the following functions:		The controller provides the following functions:
	o Provides a technology-agnostic NBI for creation/modification/		o Provides a technology-agnostic NBI for creation/modification/
	deletion of the IETF network slices. The API exposed by this NBI		deletion of the IETF Network Slices. The API exposed by this NBI
	communicates the endpoints of the IETF network slice, IETF network		communicates the endpoints of the IETF network slice, IETF Network
	slice SLO parameters (and possibly monitoring thresholds),		Slice SLO parameters (and possibly monitoring thresholds),
	applicable input selection (filtering) and various policies, and		applicable input selection (filtering) and various policies, and
	provides a way to monitor the slice.		provides a way to monitor the slice.
	o Determines an abstract topology connecting the endpoints of the		o Determines an abstract topology connecting the endpoints of the
	IETF network slice that meets criteria specified via the NBI.The		IETF Network Slice that meets criteria specified via the NBI. The
	NSC also retains information about the mapping of this abstract		NSC also retains information about the mapping of this abstract
	topology to underlying components of the IETF network slice as		topology to underlying components of the IETF network slice as
	necessary to monitor IETF network slice status and performance.		necessary to monitor IETF Network Slice status and performance.
	o Provides "Mapping Functions" for the realization of IETF network		o Provides "Mapping Functions" for the realization of IETF Network
	slices. In other words, it will use the mapping functions that:		Slices. In other words, it will use the mapping functions that:
	* map technology-agnostic NBI request to technology-specific SBIs		* map technology-agnostic NBI request to technology-specific SBIs
	* map filtering/selection information as necessary to entities in		* map filtering/selection information as necessary to entities in
	the underlay network.		the underlay network.
	o Via an SBI, the controller collects telemetry data (e.g., OAM		o Via an SBI, the controller collects telemetry data (e.g., OAM
	results, statistics, states etc.) for all elements in the abstract		results, statistics, states, etc.) for all elements in the
	topology used to realize the IETF network slice.		abstract topology used to realize the IETF Network Slice.
	o Using the telemetry data from the underlying realization of a IETF		o Using the telemetry data from the underlying realization of a IETF
	network slice (i.e. services/paths/tunnels), evaluates the current		Network Slice (i.e., services/paths/tunnels), evaluates the
	performance against IETF network slice SLO parameters and exposes		current performance against IETF Network Slice SLO parameters and
	them to the IETF network slice consumer via the NBI. The NSC NBI		exposes them to the IETF Network Slice consumer via the NBI. The
	may also include a capability to provide notification in case the		NSC NBI may also include a capability to provide notification in
	IETF network slice performance reaches threshold values defined by		case the IETF Network Slice performance reaches threshold values
	the IETF network slice consumer.		defined by the IETF Network Slice consumer.
	5.5.1. IETF Network Slice Controller Interfaces		An IETF Network Slice user is served by the IETF Network Slice
			Controller (NSC), as follows:
	<D7.>		o The NSC takes requests from a management system or other
			application, which are then communicated via an NBI. This
			interface carries data objects the IETF Network Slice user
			provides, describing the needed IETF Network Slices in terms of
			topology, applicable service level objectives (SLO), and any
			monitoring and reporting requirements that may apply. Note that -
			in this context - "topology" means what the IETF Network Slice
			connectivity is meant to look like from the user's perspective; it
			may be as simple as a list of mutually (and symmetrically)
			connected end points, or it may be complicated by details of
			connection asymmetry, per-connection SLO requirements, etc.
			o These requests are assumed to be translated by one or more
			underlying systems, which are used to establish specific IETF
			Network Slice instances on top of an underlying network
			infrastructure.
			o The NSC maintains a record of the mapping from user requests to
			slice instantiations, as needed to allow for subsequent control
			functions (such as modification or deletion of the requested
			slices), and as needed for any requested monitoring and reporting
			functions.
			5.3.1. IETF Network Slice Controller Interfaces
	The interworking and interoperability among the different		The interworking and interoperability among the different
	stakeholders to provide common means of provisioning, operating and		stakeholders to provide common means of provisioning, operating and
	monitoring the IETF network slices is enabled by the following		monitoring the IETF Network Slices is enabled by the following
	communication interfaces (see Figure 3).		communication interfaces (see Figure 2).
	NSC Northbound Interface (NBI): The NSC Northbound Interface is an		NSC Northbound Interface (NBI): The NSC Northbound Interface is an
	interface between a consumer's higher level operation system		interface between a consumer's higher level operation system
	(e.g., a network slice orchestrator) and the NSC. It is a		(e.g., a network slice orchestrator) and the NSC. It is a
	technology agnostic interface. The consumer can use this		technology agnostic interface. The consumer can use this
	interface to communicate the requested characteristics and other		interface to communicate the requested characteristics and other
	requirements (i.e., the SLOs) for the IETF network slice, and the		requirements (i.e., the SLOs) for the IETF Network Slice, and the
	NSC can use the interface to report the operational state of an		NSC can use the interface to report the operational state of an
	IETF network slice to the consumer.		IETF Network Slice to the consumer.
	NSC Southbound Interface (SBI): The NSC Southbound Interface is an		NSC Southbound Interface (SBI): The NSC Southbound Interface is an
	interface between the NSC and network controllers. It is		interface between the NSC and network controllers. It is
	technology-specific and may be built around the many network		technology-specific and may be built around the many network
	models defined within the IETF.		models defined within the IETF.
	+------------------------------------------+		+------------------------------------------+
	| Consumer higher level operation system |		| Consumer higher level operation system |
	| (e.g E2E network slice orchestrator) |		| (e.g E2E network slice orchestrator) |
	+------------------------------------------+		+------------------------------------------+
	skipping to change at page 21, line 22 ¶		skipping to change at page 17, line 43 ¶
	+------------------------------------------+		+------------------------------------------+
	| IETF Network Slice Controller (NSC) |		| IETF Network Slice Controller (NSC) |
	+------------------------------------------+		+------------------------------------------+
	A		A
	| NSC SBI		| NSC SBI
	V		V
	+------------------------------------------+		+------------------------------------------+
	| Network Controllers |		| Network Controllers |
	+------------------------------------------+		+------------------------------------------+
	Figure 3: Interface of IETF Network Slice Controller		Figure 2: Interface of IETF Network Slice Controller
	5.5.2. Northbound Interface (NBI)
	<F3.3.1.>		5.3.2. Northbound Interface (NBI)
	The IETF Network Slice Controller provides a Northbound Interface		The IETF Network Slice Controller provides a Northbound Interface
	(NBI) that allows consumers of network slices to request and monitor		(NBI) that allows consumers of network slices to request and monitor
	IETF network slices. Consumers operate on abstract IETF network		IETF Network Slices. Consumers operate on abstract IETF Network
	slices, with details related to their realization hidden.		Slices, with details related to their realization hidden.
	The NBI complements various IETF services, tunnels, path models by		The NBI complements various IETF services, tunnels, path models by
	providing an abstract layer on top of these models.		providing an abstract layer on top of these models.
	The NBI is independent of type of network functions or services that		The NBI is independent of type of network functions or services that
	need to be connected, i.e., it is independent of any specific		need to be connected, i.e., it is independent of any specific
	storage, software, protocol, or platform used to realize physical or		storage, software, protocol, or platform used to realize physical or
	virtual network connectivity or functions in support of IETF network		virtual network connectivity or functions in support of IETF Network
	slices.		Slices.
	The NBI uses protocol mechanisms and information passed over those		The NBI uses protocol mechanisms and information passed over those
	mechanisms to convey desired attributes for IETF network slices and		mechanisms to convey desired attributes for IETF Network Slices and
	their status. The information is expected to be represented as a		their status. The information is expected to be represented as a
	well-defined data model, and should include at least endpoint and		well-defined data model, and should include at least endpoint and
	connectivity information, SLO specification, and status information.		connectivity information, SLO specification, and status information.
	To accomplish this, the NBI needs to convey information needed to		To accomplish this, the NBI needs to convey information needed to
	support communication across the NBI, in terms of identifying the		support communication across the NBI, in terms of identifying the
	IETF network slices, as well providing the above model information.		IETF Network Slices, as well providing the above model information.
	5.6. Mapping		5.4. IETF Network Slice Structure
	<F3.4.>		An IETF Network Slice is a set of connections among various endpoints
			to form a logical network that meets the SLOs agreed upon.
	The main task of the IETF network slice controller is to map abstract		|------------------------------------------|
	IETF network slice requirements to concrete technologies and		NSE1 O....| |....O NSE2
	establish required connectivity, and ensuring that required resources		. | | .
	are allocated to the IETF network slice.		. | IETF Network Slice | .
			. | (SLOs e.g. B/W > x bps, Delay < y ms) | .
			NSEm O....| |....O NSEn
			|------------------------------------------|
	5.7. Realizing IETF Network Slice		== == == == == == == == == == == == == == == == == == == == == ==
	<D8.>		.--. .--.
			[EP1] ( )- . ( )- . [EP2]
			. .' IETF ' SLO .' IETF ' .
			. ( Network-1 ) ... ( Network-p ) .
			`-----------' `-----------'
			[EPm] [EPn]
	Realization of IETF network slices is out of scope of this document.		Legend
	It is a mapping of the definition of the IETF network slice to the		NSE: IETF Network Slice Endpoints
			EP: Serivce/tunnels/path Endpoints used to realize the
			IETF Network Slice
			Figure 3: IETF Network Slice
			Figure 3 illustrates a case where an IETF Network Slice provides
			connectivity between a set of IEFT network slice endpoints (NSE)
			pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps
			and guaranteed delay of no more than y ms). The IETF Network Slice
			endpoints are mapped to the underlay IETF Network Slice Endpoints
			(NEPs). Also, the IETF NSEs on the same IETF network slice may
			belong to the same or different address spaces.
			IETF Network Slice structure fits into a broader concept of end-to-
			end network slices. A network operator may be responsible for
			delivering services over a number of technologies (such as radio
			networks) and for providing specific and fine-grained services (such
			as CCTV feed or High definition realtime traffic data). That
			operator may need to combine slices of various networks to produce an
			end-to-end network service. Each of these networks may include
			multiple physical or virtual nodes and may also provide network
			functions beyond simply carrying of technology-specific protocol data
			units. An end-to-end network slice is defined by the 3GPP as a
			complete logical network that provides a service in its entirety with
			a specific assurance to the consumer [TS23501].
			An end-to-end network slice may be composed from other network slices
			that include IETF Network Slices. This composition may include the
			hierarchical (or recursive) use of underlying network slices and the
			sequential (or stitched) combination of slices of different networks.
			5.5. Realizing IETF Network Slice
			Realization of IETF Network Slices is out of scope of this document.
			It is a mapping of the definition of the IETF Network Slice to the
	underlying infrastructure and is necessarily technology-specific and		underlying infrastructure and is necessarily technology-specific and
	achieved by the NSC over the SBI.		achieved by the NSC over the SBI.
	The realization can be achieved in a form of either physical or		The realization can be achieved in a form of either physical or
	logical connectivity through VPNs (see, for example,		logical connectivity through VPNs (see, for example,
	[I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies		[I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies
	such as Segment Routing, MPLS, etc. Accordingly, endpoints may be		such as Segment Routing, MPLS, etc. Accordingly, endpoints may be
	realized as physical or logical service or network functions.		realized as physical or logical service or network functions.
	5.7.1. Underlying Technology		5.5.1. Underlying Technology
	<F3.5.>
	There are a number of different technologies that can be used,		There are a number of different technologies that can be used,
	including physical connections, MPLS, TSN, Flex-E, etc.		including physical connections, MPLS, TSN, Flex-E, etc.
	See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for		See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for
	example underlying technologies.		example underlying technologies.
	Also, as outlined in "applicability of ACTN to IETF Network Slices"		Also, as outlined in "applicability of ACTN to IETF Network Slices"
	below, ACTN ([RFC8453]) offers a framework that is used elsewhere in		below, ACTN ([RFC8453]) offers a framework that is used elsewhere in
	IETF specifications to create virtual network (VN) services similar		IETF specifications to create virtual network (VN) services similar
	to IETF network slices.		to IETF Network Slices.
	A IETF network slice can be realized in a network, using specific		A IETF Network Slice can be realized in a network, using specific
	underlying technology or technologies. The creation of a new IETF		underlying technology or technologies. The creation of a new IETF
	network slice will be initiated with following three steps:		Network Slice will be initiated with following three steps:
	o Step 1: A higher level system requests connections with specific		o Step 1: A higher level system requests connections with specific
	characteristics via NBI.		characteristics via NBI.
	o Step 2: This request will be processed by a IETF Network Slice		o Step 2: This request will be processed by an IETF NSC which
	Controller which specifies a mapping between northbound request to		specifies a mapping between northbound request to any IETF
	any IETF Services, Tunnels, and paths models.		Services, Tunnels, and paths models.
	o Step 3: A series of requests for creation of services, tunnels and		o Step 3: A series of requests for creation of services, tunnels and
	paths will be sent to the network to realize the trasport slice.		paths will be sent to the network to realize the trasport slice.
	It is very clear that regardless of how IETF network slice is		It is very clear that regardless of how IETF Network Slice is
	realized in the network (i.e., using tunnels of type RSVP or SR), the		realized in the network (i.e., using tunnels of type RSVP or SR), the
	definition of IETF network slice does not change at all but rather		definition of IETF Network Slice does not change at all but rather
	its realization.		its realization.
	6. Applicability of ACTN to IETF Network Slices		6. Applicability of ACTN to IETF Network Slices
	<F4.>
	Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an		Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an
	example of similar IETF work. ACTN defines three controllers to		example of similar IETF work. ACTN defines three controllers to
	support virtual network (VN) services -		support virtual network (VN) services -
	o Customer Network Controller (CNC),		o Customer Network Controller (CNC),
	o Multi-Domain Service Coordinator (MDSC) and		o Multi-Domain Service Coordinator (MDSC) and
	o Provisioning Network Controller (PNC).		o Provisioning Network Controller (PNC).
	skipping to change at page 23, line 44 ¶		skipping to change at page 21, line 30 ¶
	(or abstraction), customer mapping/translation and virtual service		(or abstraction), customer mapping/translation and virtual service
	coordination to realize the VN requirement. Its key role is to		coordination to realize the VN requirement. Its key role is to
	detach the network/service requirements from the underlying		detach the network/service requirements from the underlying
	technology.		technology.
	A PNC oversees the configuration, monitoring and collection of the		A PNC oversees the configuration, monitoring and collection of the
	network topology. The PNC is a underlay technology specific		network topology. The PNC is a underlay technology specific
	controller.		controller.
	While the ACTN framework is a generic VN framework that is used for		While the ACTN framework is a generic VN framework that is used for
	various VN service beyond the IETF network slice, it is still a		various VN service beyond the IETF Network Slice, it is still a
	suitable basis to understand how the various controllers interact to		suitable basis to understand how the various controllers interact to
	realize a IETF network slice.		realize a IETF Network Slice.
	One possible mapping between the IETF network slice, and ACTN,		One possible mapping between the IETF Network Slice, and ACTN,
	definitions is as shown in Figure 4.		definitions is as shown in Figure 4.
	IETF Network Slice | ACTN analogous		IETF Network Slice | ACTN analogous
	Terminology / Concepts Terminology		Terminology / Concepts Terminology
	| and Concepts		| and Concepts
	+--------------------------------------+		+--------------------------------------+
	|Consumer higher level operation system| | +-----+		|Consumer higher level operation system| | +-----+
	| (e.g E2E network slice orchestrator) | =====> | CNC |		| (e.g E2E network slice orchestrator) | =====> | CNC |
	+--------------------------------------+ | +-----+		+--------------------------------------+ | +-----+
	^ ^		^ ^
	skipping to change at page 24, line 25 ¶		skipping to change at page 22, line 25 ¶
	+-------------------------------------+ | +------+		+-------------------------------------+ | +------+
	| IETF Network Slice Controller (NSC) | =====> | MDSC |		| IETF Network Slice Controller (NSC) | =====> | MDSC |
	+-------------------------------------+ | +------+		+-------------------------------------+ | +------+
	^ ^		^ ^
	| NSC SBI | | MPI		| NSC SBI | | MPI
	v v		v v
	+-------------------------------------+ | +-----+		+-------------------------------------+ | +-----+
	| Network Controller(s) | =====> | PNC |		| Network Controller(s) | =====> | PNC |
	+-------------------------------------+ | +-----+		+-------------------------------------+ | +-----+
	Figure 4: Mapping between IETF network slices and ACTN		Figure 4: Mapping between IETF Network Slices and ACTN
	Note that the left-hand side of this figure comes from IETF Network
	Slice Definition ([I-D.ietf-teas-ietf-network-slice-definition]).
	The NSC NBI conveys the generic IETF network slice requirements.		The NSC NBI conveys the generic IETF Network Slice requirements.
	These may then be realized using an SBI within the NSC.		These may then be realized using an SBI within the NSC.
	As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC		As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC
	Interface (CMI) is used to convey the virtual network service		Interface (CMI) is used to convey the virtual network service
	requirements along with the service models and the MDSC-PNC Interface		requirements along with the service models and the MDSC-PNC Interface
	(MPI) is used to realize the service along network configuration		(MPI) is used to realize the service along network configuration
	models. [I-D.ietf-teas-te-service-mapping-yang] further describe how		models. [I-D.ietf-teas-te-service-mapping-yang] further describe how
	the VPN services can be mapped to the underlying TE resources.		the VPN services can be mapped to the underlying TE resources.
	The Network Controller is depicted as a single block, analogous to a		The Network Controller is depicted as a single block, analogous to a
	skipping to change at page 25, line 13 ¶		skipping to change at page 23, line 11 ¶
	hence the specifics of the relationship between NC and PNC, and the		hence the specifics of the relationship between NC and PNC, and the
	possibility that the MDSC and PNC may be combined are at most		possibility that the MDSC and PNC may be combined are at most
	academically interesting in this context. Another way to view this		academically interesting in this context. Another way to view this
	is that, in the same way that ACTN might combine MDSC and PNC, the		is that, in the same way that ACTN might combine MDSC and PNC, the
	NSC might also directly include NC functionality.		NSC might also directly include NC functionality.
	[RFC8453] also describes TE Network Slicing in the context of ACTN as		[RFC8453] also describes TE Network Slicing in the context of ACTN as
	a collection of resources that is used to establish a logically		a collection of resources that is used to establish a logically
	dedicated virtual network over one or more TE networks. In case of		dedicated virtual network over one or more TE networks. In case of
	TE enabled underlying network, ACTN VN can be used as a base to		TE enabled underlying network, ACTN VN can be used as a base to
	realize the IETF network slicing by coordination among multiple peer		realize the IETF Network Slicing by coordination among multiple peer
	domains as well as underlay technology domains.		domains as well as underlay technology domains.
	Section 6 shows only one possible mapping as each ACTN component (or		Section 6 shows only one possible mapping as each ACTN component (or
	interface) in the figure may be a composed differently in other		interface) in the figure may be a composed differently in other
	mappings, and the exact role of both components and subcomponents		mappings, and the exact role of both components and subcomponents
	will not be always an exact analogy between the concepts used in this		will not be always an exact analogy between the concepts used in this
	document and those defined in ACTN.		document and those defined in ACTN.
	This is - in part - shown in a previous paragraph in this section		This is - in part - shown in a previous paragraph in this section
	where it is pointed out that the NC may actually subsume some aspects		where it is pointed out that the NC may actually subsume some aspects
	of both the MDSC and PNC.		of both the MDSC and PNC.
	Similarly, in part depending on how "customer" is interpreted, CNC		Similarly, in part depending on how "customer" is interpreted, CNC
	might merge some aspects of the higher level system and the NSC. As		might merge some aspects of the higher level system and the NSC. As
	in the NC/PNC case, this way of comparing ACTN to this work is not		in the NC/PNC case, this way of comparing ACTN to this work is not
	useful as the NSC and NSC NBI are the focus on this document.		useful as the NSC and NSC NBI are the focus on this document.
	7. Isolation in IETF Network Slices		7. Isolation in IETF Network Slices
	<D9.>		An IETF Network Slice consumer may request, that the IETF Network
	An IETF network slice consumer may request, that the IETF Network
	Slice delivered to them is isolated from any other network slices of		Slice delivered to them is isolated from any other network slices of
	services delivered to any other consumers. It is expected that the		services delivered to any other consumers. It is expected that the
	changes to the other network slices of services do not have any		changes to the other network slices of services do not have any
	negative impact on the delivery of the IETF network slice.		negative impact on the delivery of the IETF Network Slice.
	7.1. Isolation as a Service Requirement		7.1. Isolation as a Service Requirement
	<D9.1.>		Isolation may be an important requirement of IETF Network Slices for
	Isolation may be an important requirement of IETF network slices for
	some critical services. A consumer may express this request as an		some critical services. A consumer may express this request as an
	SLO.		SLO.
	This requirement can be met by simple conformance with other SLOs.		This requirement can be met by simple conformance with other SLOs.
	For example, traffic congestion (interference from other services)		For example, traffic congestion (interference from other services)
	might impact on the latency experienced by an IETF network slice.		might impact on the latency experienced by an IETF Network Slice.
	Thus, in this example, conformance to a latency SLO would be the		Thus, in this example, conformance to a latency SLO would be the
	primary requirement for delivery of the IETF network slice service,		primary requirement for delivery of the IETF Network Slice service,
	and isolation from other services might be only a means to that end.		and isolation from other services might be only a means to that end.
	It should be noted that some aspects of isolation may be measurable		It should be noted that some aspects of isolation may be measurable
	by a consumer who have the information about the traffic on a number		by a consumer who have the information about the traffic on a number
	of IETF network slices or other services.		of IETF Network Slices or other services.
	7.2. Isolation in IETF Network Slice Realization		7.2. Isolation in IETF Network Slice Realization
	<D9.2.>		Delivery of isolation is achieved in the realization of IETF Network
			Slices, with existing, in-development, and potential new technologies
	Delivery of isolation is achieved in the realization of IETF network
	slices, with existing, in-development, and potential new technologies
	in IETF. It depends on how a network operator decides to operate		in IETF. It depends on how a network operator decides to operate
	their network and deliver services.		their network and deliver services.
	Isolation may be achieved in the underlying network by various forms		Isolation may be achieved in the underlying network by various forms
	of resource partitioning ranging from dedicated allocation of		of resource partitioning ranging from dedicated allocation of
	resources for a specific IETF network slice, to sharing or resources		resources for a specific IETF Network Slice, to sharing or resources
	with safeguards. For example, traffic separation between different		with safeguards. For example, traffic separation between different
	IETF network slices may be achieved using VPN technologies, such as		IETF Network Slices may be achieved using VPN technologies, such as
	L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by		L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by
	network capacity planning, allocating dedicated network resources,		network capacity planning, allocating dedicated network resources,
	traffic policing or shaping, prioritizing in using shared network		traffic policing or shaping, prioritizing in using shared network
	resources, etc. Finally, service continuity may be ensured by		resources, etc. Finally, service continuity may be ensured by
	reserving backup paths for critical traffic, dedicating specific		reserving backup paths for critical traffic, dedicating specific
	network resources for a selected number of network slices, etc.		network resources for a selected number of network slices, etc.
	8. Management Considerations		8. Management Considerations
	<F5.1.>		IETF Network Slice realization needs to be instrumented in order to
	IETF network slice realization needs to be instrumented in order to
	track how it is working, and it might be necessary to modify the IETF		track how it is working, and it might be necessary to modify the IETF
	network slice as requirements change. Dynamic reconfiguration might		Network Slice as requirements change. Dynamic reconfiguration might
	be needed.		be needed.
	9. Security Considerations		9. Security Considerations
	<D10.>
	This document specifies terminology and has no direct effect on the		This document specifies terminology and has no direct effect on the
	security of implementations or deployments. In this section, a few		security of implementations or deployments. In this section, a few
	of the security aspects are identified.		of the security aspects are identified.
	o Conformance to security constraints: Specific security requests		o Conformance to security constraints: Specific security requests
	from consumer defined IETF network slices will be mapped to their		from consumer defined IETF Network Slices will be mapped to their
	realization in the unerlay networks. It will be required by		realization in the unerlay networks. It will be required by
	underlay networks to have capabilities to conform to consumer's		underlay networks to have capabilities to conform to consumer's
	requests as some aspects of security may be expressed in SLOs.		requests as some aspects of security may be expressed in SLOs.
	o IETF network slice controller authentication: Unerlying networks		o IETF NSC authentication: Unerlying networks need to be protected
	need to be protected against the attacks from an adversary NSC as		against the attacks from an adversary NSC as they can destablize
	they can destablize overall network operations. It is		overall network operations. It is particularly critical since an
	particularly critical since an IETF network slice may span across		IETF Network Slice may span across different networks, therefore,
	different networks, therefore, IETF NSC should have strong		IETF NSC should have strong authentication with each those
	authentication with each those networks. Futhermore, both SBI and		networks. Futhermore, both SBI and NBI need to be secured.
	NBI need to be secured.
	o Specific isolation criteria: The nature of conformance to		o Specific isolation criteria: The nature of conformance to
	isolation requests means that it should not be possible to attack		isolation requests means that it should not be possible to attack
	an IETF network slice service by varying the traffic on other		an IETF Network Slice service by varying the traffic on other
	services or slices carried by the same underlay network. In		services or slices carried by the same underlay network. In
	general, isolation is expected to strengthen the IETF network		general, isolation is expected to strengthen the IETF Network
	slice security.		Slice security.
	o Data Integrity of an IETF network slice: A consumer wanting to		o Data Integrity of an IETF Network Slice: A consumer wanting to
	secure their data and keep it private will be responsible for		secure their data and keep it private will be responsible for
	applying appropriate security measures to their traffic and not		applying appropriate security measures to their traffic and not
	depending on the network operator that provides the IETF network		depending on the network operator that provides the IETF Network
	slice. It is expected that for data integrity, a consumer is		Slice. It is expected that for data integrity, a consumer is
	responsible for end-to-end encryption of its own traffic.		responsible for end-to-end encryption of its own traffic.
	Note: see NGMN document[NGMN_SEC] on 5G network slice security for		Note: see NGMN document[NGMN_SEC] on 5G network slice security for
	discussion relevant to this section.		discussion relevant to this section.
	<F5.2.>		IETF Network Slices might use underlying virtualized networking. All
	IETF network slices might use underlying virtualized networking. All
	types of virtual networking require special consideration to be given		types of virtual networking require special consideration to be given
	to the separation of traffic between distinct virtual networks, as		to the separation of traffic between distinct virtual networks, as
	well as some degree of protection from effects of traffic use of		well as some degree of protection from effects of traffic use of
	underlying network (and other) resources from other virtual networks		underlying network (and other) resources from other virtual networks
	sharing those resources.		sharing those resources.
	For example, if a service requires a specific upper bound of latency,		For example, if a service requires a specific upper bound of latency,
	then that service can be degraded by added delay in transmission of		then that service can be degraded by added delay in transmission of
	service packets through the activities of another service or		service packets through the activities of another service or
	application using the same resources.		application using the same resources.
	Similarly, in a network with virtual functions, noticeably impeding		Similarly, in a network with virtual functions, noticeably impeding
	access to a function used by another IETF network slice (for		access to a function used by another IETF Network Slice (for
	instance, compute resources) can be just as service degrading as		instance, compute resources) can be just as service degrading as
	delaying physical transmission of associated packet in the network.		delaying physical transmission of associated packet in the network.
	While a IETF network slice might include encryption and other		While a IETF Network Slice might include encryption and other
	security features as part of the service, consumers might be well		security features as part of the service, consumers might be well
	advised to take responsibility for their own security needs, possibly		advised to take responsibility for their own security needs, possibly
	by encrypting traffic before hand-off to a service provider.		by encrypting traffic before hand-off to a service provider.
	9.1. Privacy Considerations		9.1. Privacy Considerations
	<F5.3.>		Privacy of IETF Network Slice service consumers must be preserved.
			It should not be possible for one IETF Network Slice consumer to
	Privacy of IETF network slice service consumers must be preserved.
	It should not be possible for one IETF network slice consumer to
	discover the presence of other consumers, nor should sites that are		discover the presence of other consumers, nor should sites that are
	members of one IETF network slice be visible outside the context of		members of one IETF Network Slice be visible outside the context of
	that IETF network slice.		that IETF Network Slice.
	In this sense, it is of paramount importance that the system use the		In this sense, it is of paramount importance that the system use the
	privacy protection mechanism defined for the specific underlying		privacy protection mechanism defined for the specific underlying
	technologies used, including in particular those mechanisms designed		technologies used, including in particular those mechanisms designed
	to preclude acquiring identifying information associated with any		to preclude acquiring identifying information associated with any
	IETF network slice consumer.		IETF Network Slice consumer.
	10. IANA Considerations		10. IANA Considerations
	<F5.4.>
	There are no requests to IANA in this framework document.		There are no requests to IANA in this framework document.
	11. Acknowledgments		11. Acknowledgments
	<D12.>
	The entire TEAS NS design team and everyone participating in those
	discussion has contributed to this draft. Particularly, Eric Gray,
	Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough
	review among other contributions.
	<F6.>
	The entire TEAS NS design team and everyone participating in related		The entire TEAS NS design team and everyone participating in related
	discussions has contributed to this document. Some text fragments in		discussions has contributed to this document. Some text fragments in
	the document have been copied from the [I-D.ietf-teas-enhanced-vpn],		the document have been copied from the [I-D.ietf-teas-enhanced-vpn],
	for which we are grateful.		for which we are grateful.
	Significant contributions to this document were gratefully received		Significant contributions to this document were gratefully received
	from the contributing authors listed in the "Contributors" section.		from the contributing authors listed in the "Contributors" section.
	In addition we would like to also thank those others who have		In addition we would like to also thank those others who have
	attended one or more of the design team meetings, including:		attended one or more of the design team meetings, including the
			following people not listed elsewhere:
	o Aihua Guo		o Aihua Guo
	o Bo Wu		o Bo Wu
	o Greg Mirsky		o Greg Mirsky
	o Jeff Tantsura
	o Kiran Makhijani
	o Lou Berger		o Lou Berger
	o Luis M. Contreras
	o Rakesh Gandhi		o Rakesh Gandhi
	o Ran Chen		o Ran Chen
	o Sergio Belotti		o Sergio Belotti
	o Shunsuke Homma
	o Stewart Bryant		o Stewart Bryant
	o Tomonobu Niwa		o Tomonobu Niwa
	o Xuesong Geng		o Xuesong Geng
	12. Contributors		12. Contributors
	The following authors contributed significantly to this document:		The following authors contributed significantly to this document:
	skipping to change at page 34, line 38 ¶		skipping to change at page 31, line 47 ¶
	3GPP, "3G security; Network Domain Security (NDS); IP		3GPP, "3G security; Network Domain Security (NDS); IP
	network layer security (Release 14).", December 2016,		network layer security (Release 14).", December 2016,
	<https://portal.3gpp.org/desktopmodules/Specifications/		<https://portal.3gpp.org/desktopmodules/Specifications/
	SpecificationDetails.aspx?specificationId=2279>.		SpecificationDetails.aspx?specificationId=2279>.
	Appendix A. Unused Material		Appendix A. Unused Material
	This section includes material from the source documents that is not		This section includes material from the source documents that is not
	used in the body of this document. It is intended for deletion.		used in the body of this document. It is intended for deletion.
			For this purpose, the text is tagged to show its origin using the
			format <D1.3> or <F2.4> where the letters 'D' and 'F' indicate the
			definitions draft [I-D.ietf-teas-ietf-network-slice-definition] and
			the framework draft [I-D.ietf-teas-ietf-network-slice-framework]
			respectively, and the subsequent numbers indicate the the section of
			the source document.
			A.1. Abstract
			<FAb>
			This memo is intended for discussing interfaces and technologies. It
			is not intended to be a new set of concrete interfaces or
			technologies. Rather, it should be seen as an explanation of how
			some existing, concrete IETF VPN and traffic-engineering technologies
			can be used to create IETF network slices. Note that there are a
			number of these technologies, and new technologies or capabilities
			keep being added. This memo is also not intended presume any
			particular technology choice.
			A.2. Management Systems or Other Applications
			<F3.1.>
			The IETF Network Slice system is used by a management system or other
			application. These systems and applications may also be a part of a
			higher level function in the system, e.g., putting together network
			functions, access equipment, application specific components, as well
			as the IETF Network Slices.
	Authors' Addresses		Authors' Addresses
	Adrian Farrel (editor)		Adrian Farrel (editor)
	Old Dog Consulting		Old Dog Consulting
	Email: adrian@olddog.co.uk		Email: adrian@olddog.co.uk
	Eric Gray		Eric Gray
	Ericsson		Ericsson
End of changes. 180 change blocks.
	520 lines changed or deleted		393 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/