< draft-ietf-teas-ietf-network-slices-06.txt		draft-ietf-teas-ietf-network-slices-07.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 J. Drake
	Expires: 3 September 2022 Independent		Expires: 5 September 2022 Juniper Networks
	J. Drake, Ed.
	Juniper Networks
	R. Rokui		R. Rokui
	Ciena		Ciena
	S. Homma		S. Homma
	NTT		NTT
	K. Makhijani		K. Makhijani
	Futurewei		Futurewei
	LM. Contreras		L.M. Contreras
	Telefonica		Telefonica
	J. Tantsura		J. Tantsura
	Microsoft		Microsoft
	2 March 2022		4 March 2022
	Framework for IETF Network Slices		Framework for IETF Network Slices
	draft-ietf-teas-ietf-network-slices-06		draft-ietf-teas-ietf-network-slices-07
	Abstract		Abstract
	This document describes network slicing in the context of networks		This document describes network slicing in the context of networks
	built from IETF technologies. It defines the term "IETF Network		built from IETF technologies. It defines the term "IETF Network
	Slice" and establishes the general principles of network slicing in		Slice" and establishes the general principles of network slicing in
	the IETF context.		the IETF context.
	The document discusses the general framework for requesting and		The document discusses the general framework for requesting and
	operating IETF Network Slices, the characteristics of an IETF Network		operating IETF Network Slices, the characteristics of an IETF Network
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 10 ¶
	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 3 September 2022.		This Internet-Draft will expire on 5 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
	2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6		2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 5
	3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7		3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7
	3.1. Definition and Scope of IETF Network Slice . . . . . . . 7		3.1. Definition and Scope of IETF Network Slice . . . . . . . 7
	3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 8		3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 8
	3.2.1. Ancillary SDPs . . . . . . . . . . . . . . . . . . . 10		3.2.1. Ancillary SDPs . . . . . . . . . . . . . . . . . . . 11
	4. IETF Network Slice System Characteristics . . . . . . . . . . 11		4. IETF Network Slice System Characteristics . . . . . . . . . . 11
	4.1. Objectives for IETF Network Slices . . . . . . . . . . . 11		4.1. Objectives for IETF Network Slices . . . . . . . . . . . 11
	4.1.1. Service Level Objectives . . . . . . . . . . . . . . 12		4.1.1. Service Level Objectives . . . . . . . . . . . . . . 12
	4.1.2. Service Level Expectations . . . . . . . . . . . . . 13		4.1.2. Service Level Expectations . . . . . . . . . . . . . 14
	4.2. IETF Network Slice Service Demarcation Points . . . . . . 15		4.2. IETF Network Slice Service Demarcation Points . . . . . . 16
	4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 18		4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 18
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 19		5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 19
	5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 19		5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 19
	5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 21		5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 21
	5.3.1. IETF Network Slice Controller Interfaces . . . . . . 23		5.3.1. IETF Network Slice Controller Interfaces . . . . . . 23
	5.3.2. Management Architecture . . . . . . . . . . . . . . . 25		5.3.2. Management Architecture . . . . . . . . . . . . . . . 25
	5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 25		5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 25
	6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 27		6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 27
	6.1. Architecture to Realize IETF Network Slices . . . . . . . 27		6.1. Architecture to Realize IETF Network Slices . . . . . . . 27
	6.2. Procedures to Realize IETF Network Slices . . . . . . . . 30		6.2. Procedures to Realize IETF Network Slices . . . . . . . . 30
	6.3. Applicability of ACTN to IETF Network Slices . . . . . . 31		6.3. Applicability of ACTN to IETF Network Slices . . . . . . 31
	6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 31		6.4. Applicability of Enhanced VPNs to IETF Network Slices . . 31
	6.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 32		6.5. Network Slicing and Aggregation in IP/MPLS Networks . . . 32
	7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 32		7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 32
	7.1. Isolation as a Service Requirement . . . . . . . . . . . 32		7.1. Isolation as a Service Requirement . . . . . . . . . . . 32
	7.2. Isolation in IETF Network Slice Realization . . . . . . . 33		7.2. Isolation in IETF Network Slice Realization . . . . . . . 33
	8. Management Considerations . . . . . . . . . . . . . . . . . . 33		8. Management Considerations . . . . . . . . . . . . . . . . . . 33
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 33		9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	12. Informative References . . . . . . . . . . . . . . . . . . . 35		12. Informative References . . . . . . . . . . . . . . . . . . . 35
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	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 with respect to network resources use. This connectivity		objectives with respect to network resources use. This connectivity
	and resource commitment is referred to as a network slice. Since the		and resource commitment is referred to as a network slice. Since the
	term network slice is rather generic, the qualifying term "IETF" is		term network slice is rather generic, the qualifying term "IETF" is
	used in this document to limit the scope of network slice to network		used in this document to limit the scope of network slice to network
	technologies described and standardized by the IETF. This document		technologies described and standardized by the IETF. This document
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 30 ¶
	Note that it is conceivable that extensions to these IETF		Note that it is conceivable that extensions to these IETF
	technologies are needed in order to fully support all the ideas that		technologies are needed in order to fully support all the ideas that
	can be implemented with slices. Evaluation of existing technologies,		can be implemented with slices. Evaluation of existing technologies,
	proposed extensions to existing protocols and interfaces, and the		proposed extensions to existing protocols and interfaces, and the
	creation of new protocols or interfaces is outside the scope of this		creation of new protocols or interfaces is outside the scope of this
	document.		document.
	1.1. Background		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], and
	and [BBF-SD406]). In [TS23501], a Network Slice is defined as "a		[TS28530]). In [TS23501], a Network Slice is defined as "a logical
	logical network that provides specific network capabilities and		network that provides specific network capabilities and network
	network characteristics", and a Network Slice Instance is defined as		characteristics", and a Network Slice Instance is defined as "A set
	"A set of Network Function instances and the required resources (e.g.		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). An IETF		Network (RAN), Transport Network (TN) and Core Network (CN). An 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 customer's use		slice, the topology and performance requirement on a customer'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
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 19 ¶
	and management planes.		and management planes.
	The customer expresses requirements for a particular IETF Network		The customer 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 customer's view		is to be fulfilled. That is, the IETF Network Slice customer's view
	of an 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 customer of such a logical network can		required characteristics. The customer 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 overlay VPNs. Additionally, the IETF
	the IETF Network Slice customer might ask for some level of control		Network Slice customer might ask for some level of control of their
	of their virtual networks, e.g., to customize the service paths in a		virtual networks, e.g., to customize the service paths in a network
	network slice.		slice.
	This document specifies definitions and a framework for the provision		This document specifies definitions and a framework for the provision
	of an IETF Network Slice service. Section 6 briefly indicates some		of an IETF Network Slice service. Section 6 briefly indicates some
	candidate technologies for realizing IETF Network Slices.		candidate technologies for realizing IETF Network Slices.
	2. Terms and Abbreviations		2. Terms and Abbreviations
	The following abbreviations are used in this document.		The following abbreviations are used in this document.
	* NSC: Network Slice Controller		* NSC: Network Slice Controller
	skipping to change at page 7, line 4 ¶		skipping to change at page 6, line 30 ¶
	accelerators, server load balancers, HTTP header enrichment		accelerators, server load balancers, HTTP header enrichment
	functions, and PEPs (Performance Enhancing Proxy). In some		functions, and PEPs (Performance Enhancing Proxy). In some
	circumstances CEs are provided to the customer and managed by the		circumstances CEs are provided to the customer and managed by the
	provider.		provider.
	Provider Edge: The device within the provider network to which a CE		Provider Edge: The device within the provider network to which a CE
	is attached. A CE may be attached to multiple PEs, and multiple		is attached. A CE may be attached to multiple PEs, and multiple
	CEs may be attached to a given PE.		CEs may be attached to a given PE.
	Attachment Circuit (AC): A channel connecting a CE and a PE over		Attachment Circuit (AC): A channel connecting a CE and a PE over
	which packets are exchanged. The customer and provider agree		which packets that belong to an IETF Network Slice service are
	(through configuration) on which values in which combination of		exchanged. The customer and provider agree (through
	layer 2 and layer 3 fields within a packet identify to which {IETF		configuration) on which values in which combination of layer 2 and
	Network Slice service, connectivity construct, and SLOs/SLEs} that		layer 3 header and payload fields within a packet identify to
	packet is assigned. The customer and provider may agree on a per		which {IETF Network Slice service, connectivity construct, and
	{IETF Network Slice service, connectivity construct, and SLOs/		SLOs/SLEs} that packet is assigned. The customer and provider may
	SLEs} basis to police or shape traffic in both the ingress (CE to		agree on a per {IETF Network Slice service, connectivity
	PE) direction and egress (PE to CE) direction: this ensures that		construct, and SLOs/SLEs} basis to police or shape traffic on the
	the traffic is within the capacity profile that is agreed in an		AC in both the ingress (CE to PE) direction and egress (PE to CE)
	IETF Network Slice service. Excess traffic is dropped by default,		direction, This ensures that the traffic is within the capacity
	unless specific out-of-profile policies are agreed between the		profile that is agreed in an IETF Network Slice service. Excess
	customer and the provider. As described in Section 4.2 the AC may		traffic is dropped by default, unless specific out-of-profile
	be part of the IETF Network Slice service or may be external to		policies are agreed between the customer and the provider. As
	it.		described in Section 4.2 the AC may be part of the IETF Network
			Slice service or may be external to it.
	Service Demarcation Point (SDP): The point at which an IETF Network		Service Demarcation Point (SDP): The point at which an IETF Network
	Slice service is delivered by a service provider to a customer.		Slice service is delivered by a service provider to a customer.
	Depending on the service delivery model (see Section 4.2 this may		Depending on the service delivery model (see Section 4.2 this may
	be a CE or a PE, and could be a device, a software component, or		be a CE or a PE, and could be a device, a software component, or
	in the case of network functions virtualization (for example), be		in the case of network functions virtualization (for example), be
	an abstract function supported within the provider's network.		an abstract function supported within the provider's network.
	Each SDP must have a unique identifier (e.g., an IP address or MAC		Each SDP must have a unique identifier (e.g., an IP address or MAC
	address) within a given IETF Network Slice Service and may use the		address) within a given IETF Network Slice service and may use the
	same identifier in multiple IETF Network Slice Services.		same identifier in multiple IETF Network Slice services.
			An SDP may be abstracted as a Service Attachment Point (SAP)
			[I-D.ietf-opsawg-sap] for the purpose generalizing the concept
			across multiple service types and representing it in management
			and configuration systems.
	3. IETF Network Slice Objectives		3. IETF Network Slice Objectives
	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.
	It is also intended that, once created, these slices can be		It is also intended that, once created, these slices can be
	monitored, 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 of the service in accordance with specified		end-points of the service in accordance with specified
	characteristics.		characteristics.
	3.1. Definition and Scope of IETF Network Slice		3.1. Definition and Scope of IETF Network Slice
	An IETF Network Slice Service enables connectivity between a set of		An IETF Network Slice service enables connectivity between a set of
	Service Demarcation Points (SDPs) with specific Service Level		Service Demarcation Points (SDPs) with specific Service Level
	Objectives (SLOs) and Service Level Expectations (SLEs) over a common		Objectives (SLOs) and Service Level Expectations (SLEs) over a common
	underlay network.		underlay network.
	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. The definition of an IETF Network Slice		and storage availability. The definition of an IETF Network Slice
	Service is independent of the connectivity and technologies used in		service is independent of the connectivity and technologies used in
	the underlay network. This allows an IETF Network Slice Service		the underlay network. This allows an IETF Network Slice service
	customer to describe their network connectivity and relevant		customer to describe their network connectivity and relevant
	objectives in a common format, independent of the underlying		objectives in a common format, independent of the underlying
	technologies used.		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 Service is agnostic to the technology of the		An IETF Network Slice service is agnostic to the technology of the
	underlying network, and its realization may be selected based upon		underlying network, and its realization may be selected based upon
	multiple considerations including its service requirements and the		multiple considerations including its service requirements and the
	capabilities of the underlay network.		capabilities of the underlay network.
	The term "Slice" refers to a set of characteristics and behaviours		The term "Slice" refers to a set of characteristics and behaviours
	that separate one type of user-traffic from another. An IETF Network		that separate one type of user-traffic from another. An IETF Network
	Slice assumes that an underlay network is capable of changing the		Slice assumes that an underlay 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/		signaling or via controller(s) and fulfilling all or some of SLOs/
	SLEs to all of the traffic in the slice or to specific flows.		SLEs to all of the traffic in the slice or to specific flows.
	3.2. IETF Network Slice Service		3.2. IETF Network Slice Service
	A service provider instantiates an IETF Network Slice service for a		A service provider delivers an IETF Network Slice service for a
	customer. The IETF Network Slice service is specified in terms of a		customer. The IETF Network Slice service is specified in terms of a
	set of SDPs, a set of one or more connectivity constructs (point-to-		set of SDPs, a set of one or more connectivity constructs between
	point (P2P) both unidirectional and bidirectional, point-to-		subsets of these SDPs, and a set of SLOs and SLEs for each SDP
			sending to each connectivity construct. A communication type (point-
			to-point (P2P) both unidirectional and bidirectional, point-to-
	multipoint (P2MP), multipoint-to-point (MP2P), multipoint-to-		multipoint (P2MP), multipoint-to-point (MP2P), multipoint-to-
	multipoint (MP2MP), or any-to-any (A2A)) between subsets of these		multipoint (MP2MP), or any-to-any (A2A)) is specified for each
	SDPs, and a set of SLOs and SLEs for each SDP sending to each
	connectivity construct. That is, in a given IETF Network Slice		connectivity construct. That is, in a given IETF Network Slice
	service there may be one or more connectivity constructs of the same		service there may be one or more connectivity constructs of the same
	or different type, each connectivity construct may be between a		or different type, each connectivity construct may be between a
	different subset of SDPs, and for a given connectivity construct each		different subset of SDPs, and for a given connectivity construct each
	sending SDP has its own set of SLOs and SLEs, and the SLOs and SLEs		sending SDP has its own set of SLOs and SLEs, and the SLOs and SLEs
	in each set may be different. Note that it is a service provider's		in each set may be different. Note that a service provider may
	prerogative to decide how many connectivity constructs per IETF		decide how many connectivity constructs per IETF Network Slice
	Network Slice Service it wishes to offer.		service it wishes to support.
	This approach results in the following possible connectivity		This approach results in the following possible connectivity
	constructs:		constructs:
	* For a P2P connectivity construct, there is one sending SDP and one		* For a P2P connectivity construct, there is one sending SDP and one
	receiving SDP. This construct is like a private wire or a tunnel.		receiving SDP. This construct is like a private wire or a tunnel.
	All traffic injected at the sending SDP is intended to be received		All traffic injected at the sending SDP is intended to be received
	by the receiving SDP. The SLOs and SLEs apply at the sender (and		by the receiving SDP. The SLOs and SLEs apply at the sender (and
	implicitly at the receiver).		implicitly at the receiver).
	* A bidirectional P2P connectivity construct may also be defined,		* A bidirectional P2P connectivity construct may also be defined,
	with two SDPs each of which may send to the other. There are two		with two SDPs each of which may send to the other. There are two
	sets of SLOs and SLEs which may be different and each of which		sets of SLOs and SLEs which may be different and each of which
	applies to one of the SDPs as a sender.		applies to one of the SDPs as a sender.
	* For a P2MP connectivity construct, there is only one sending SDP		* For a P2MP connectivity construct, there is only one sending SDP
	and more than one receiving SDP. This is like a P2MP tunnel or		and more than one receiving SDP. This is like a P2MP tunnel or
	multi-access VLAN segment. All traffic from the sending SDP is		multi-access VLAN segment. All traffic from the sending SDP is
	intended to be received by all the receiving SDPs. There is one		intended to be received by all the receiving SDPs. There is one
	set of SLOs and SLEs that apply at the sending SDP (and implicitly		set of SLOs and SLEs that apply at the sending SDP (and implicitly
	at all receiving SDPs).		at all receiving SDPs). Activating unicast or multicast
			capabilities to deliver an IETF Slice service can be explicitly
			requested by a customer or can be an engineering decision of a
			service provider based on capabilities of the network and
			operational choices.
	* An MP2P connectivity construct has N SDPs: there is one receiving		* An MP2P connectivity construct has N SDPs: there is one receiving
	SDP and (N - 1) sending SDPs. This is like a set of P2P		SDP and (N - 1) sending SDPs. This is like a set of P2P
	connections all with a common receiver. All traffic injected at		connections all with a common receiver. All traffic injected at
	any sending SDP is received by the single receiving SDP. Each		any sending SDP is received by the single receiving SDP. Each
	sending SDP has its own set of SLOs and SLEs, and they may all be		sending SDP has its own set of SLOs and SLEs, and they may all be
	different (the combination of those SLOs and SLEs gives the		different (the combination of those SLOs and SLEs gives the
	implicit SLOs and SLEs for the receiving SDP - that is, the		implicit SLOs and SLEs for the receiving SDP - that is, the
	receiving SDP is expected to receive all traffic from all		receiving SDP is expected to receive all traffic from all
	senders).		senders).
	* In an MP2MP connectivity construct each of the N SDPs can be a		* In an MP2MP connectivity construct each of the N SDPs can be a
	sending SDP such that its traffic is delivered to all of the other		sending SDP such that its traffic is delivered to all of the other
	SDPs. Each sending SDP has its own set of SLOs and SLEs and they		SDPs. Each sending SDP has its own set of SLOs and SLEs and they
	may all be different. The combination of those SLOs/SLEs gives		may all be different. The combination of those SLOs/SLEs gives
	the implicit SLOs/SLEs for each/all of the receiving SDPs since		the implicit SLOs/SLEs for each/all of the receiving SDPs since
	each receiving SDP is expect to receive all traffic from all/any		each receiving SDP is expect to receive all traffic from all/any
	sender.		sender.
	* With an A2A construct, any sending SDP may send to any one		* With an A2A construct, any sending SDP may send to any one
	receiving SDP or any set of receiving SDPs. There is an implicit		receiving SDP or any set of receiving SDPs in the construct.
	level of routing in this connectivity construct that is not		There is an implicit level of routing in this connectivity
	present in the other connectivity constructs as the construct must		construct that is not present in the other connectivity constructs
	determine to which receiving SDPs to deliver each packet. The		as the construct must determine to which receiving SDPs to deliver
	SLOs/SLEs apply to individual sending SDPs and individual		each packet. The SLOs/SLEs apply to individual sending SDPs and
	receiving SDPs, but there is no implicit linkage and a sending SDP		individual receiving SDPs, but there is no implicit linkage and a
	may be "disappointed" if the receiver is over-subscribed.		sending SDP may be "disappointed" if the receiver is over-
			subscribed. This construct may be used to support P2P traffic
			between any pair of SDPs or to support multicast or broadcast
			traffic from one SDP to a set of other SDPs. In the latter case,
			whether the service is delivered using multicast within the
			provider's network or using "ingress replication" or some other
			means is out of scope of the specification of the service. A
			service provider may choose to support A2A constructs but limit
			the traffic to P2P.
	If an SDP has multiple attachment circuits to a given IETF Network		If an SDP has multiple attachment circuits to a given IETF Network
	Slice Service and they are operating in single-active mode, then all		Slice service and they are operating in single-active mode, then all
	traffic between the SDP and its attached PEs transits a single		traffic between the SDP and its attached PEs transits a single
	attachment circuit; if they are operating in in all-active mode, then		attachment circuit; if they are operating in in all-active mode, then
	traffic between the SDP and its attached PEs is distributed across		traffic between the SDP and its attached PEs is distributed across
	all of the active attachment circuits.		all of the active attachment circuits.
	A given sending SDP may be part of multiple connectivity constructs		A given sending SDP may be part of multiple connectivity constructs
	within a single IETF Network Slice service, and the SDP may have		within a single IETF Network Slice service, and the SDP may have
	different SLOs and SLEs for each connectivity construct to which it		different SLOs and SLEs for each connectivity construct to which it
	is sending. Note that a given sending SDP's SLOs and SLEs for a		is sending. Note that a given sending SDP's SLOs and SLEs for a
	given connectivity construct apply between it and each of the		given connectivity construct apply between it and each of the
	skipping to change at page 11, line 49 ¶		skipping to change at page 12, line 23 ¶
	Network Slice makes of the provider. An SLE is distinct from an		Network Slice makes of the provider. An SLE is distinct from an
	SLO because the customer may have little or no way of determining		SLO because the customer may have little or no way of determining
	whether the SLE is being met, but they still contract with the		whether the SLE is being met, but they still contract with the
	provider for a service that meets the expectation.		provider for a service that meets the expectation.
	* A Service Level Agreement (SLA) is an explicit or implicit		* A Service Level Agreement (SLA) is an explicit or implicit
	contract between the customer of an IETF Network Slice service and		contract between the customer of an IETF Network Slice service and
	the provider of the slice. The SLA is expressed in terms of a set		the provider of the slice. The SLA is expressed in terms of a set
	of SLOs and SLEs that are to be applied for a given connectivity		of SLOs and SLEs that are to be applied for a given connectivity
	construct between a sending SDP and the set of receiving SDPs, and		construct between a sending SDP and the set of receiving SDPs, and
	may include commercial terms as well as any consequences for		may describe the extent to which divergence from individual SLOs
	violating these SLOs and SLEs.		and SLEs can be tolerated, and commercial terms as well as any
			consequences for violating these SLOs and SLEs.
	4.1.1. Service Level Objectives		4.1.1. Service Level Objectives
	SLOs define a set of measurable network attributes and		SLOs define a set of measurable network attributes and
	characteristics that describe an IETF Network Slice Service. SLOs do		characteristics that describe an IETF Network Slice service. SLOs do
	not describe how an IETF Network Slice Service is realized in the		not describe how an IETF Network Slice service is implemented or
	underlay network. Instead, they define the dimensions of operation		realized in the underlying network layers. Instead, they are defined
	(time, capacity, etc.), availability, and other attributes. An SLO		in terms of dimensions of operation (time, capacity, etc.),
	is applied to a given connectivity construct between a sending SDP		availability, and other attributes.
	and the set of receiving SDPs.
	An IETF Network Slice service may include multiple connection		An IETF Network Slice service may include multiple connection
	constructs that associate sets of endpoints (SDPs). SLOs apply to		constructs that associate sets of endpoints (SDPs). SLOs apply to a
	sets of two or more SDPs and apply to specific directions of traffic		given connectivity construct and apply to specific directions of
	flow. That is, they apply to a specific source SDP and the		traffic flow. That is, they apply to a specific sending SDP and the
	connection to specific destination SDPs.		connection to specific receiving SDPs.
	The SLOs are combined with Service Level Expectations in an SLA.		The SLOs are combined with Service Level Expectations in an SLA.
	4.1.1.1. Some Common SLOs		4.1.1.1. Some Common SLOs
	SLOs can be described as 'Directly Measurable Objectives': they are		SLOs can be described as 'Directly Measurable Objectives': they are
	always measurable. See Section 4.1.2 for the description of Service		always measurable. See Section 4.1.2 for the description of Service
	Level Expectations which are unmeasurable service-related requests		Level Expectations which are unmeasurable service-related requests
	sometimes known as 'Indirectly Measurable Objectives'.		sometimes known as 'Indirectly Measurable Objectives'.
	Objectives such as guaranteed minimum bandwidth, guaranteed maximum		Objectives such as guaranteed minimum bandwidth, guaranteed maximum
	latency, maximum permissible delay variation, maximum permissible		latency, maximum permissible delay variation, maximum permissible
	packet loss rate, and availability are 'Directly Measurable		packet loss rate, and availability are 'Directly Measurable
	Objectives'. Future specifications (such as IETF Network Slice		Objectives'. Future specifications (such as IETF Network Slice
	service YANG models) may precisely define these SLOs, and other SLOs		service YANG models) may precisely define these SLOs, and other SLOs
	may be introduced as described in Section 4.1.1.2.		may be introduced as described in Section 4.1.1.2.
	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. The bandwidth is measured in data rate
	Minimum guaranteed bandwidth between two endpoints at any time.		units of bits per second and is measured unidirectionally.
	The bandwidth is measured in data rate units of bits per second
	and is measured unidirectionally.
	Guaranteed Maximum Latency
	Upper bound of network latency when transmitting between two
	endpoints. The latency is measured in terms of network
	characteristics (excluding application-level latency).
	[RFC2681] and [RFC7679] discuss round trip times and one-way
	metrics, respectively.
	Maximum Permissible Delay Variation
	Packet delay variation (PDV) as defined by [RFC3393], is the
	difference in the one-way delay between sequential packets in a
	flow. This SLO sets a maximum value PDV for packets between
	two endpoints.
	Maximum Permissible Packet Loss Rate		Guaranteed Maximum Latency: Upper bound of network latency when
			transmitting between two endpoints. The latency is measured in
			terms of network characteristics (excluding application-level
			latency). [RFC2681] and [RFC7679] discuss round trip times and
			one-way metrics, respectively.
	The ratio of packets dropped to packets transmitted between two		Maximum Permissible Delay Variation: Packet delay variation (PDV) as
	endpoints over a period of time. See [RFC7680].		defined by [RFC3393], is the difference in the one-way delay
			between sequential packets in a flow. This SLO sets a maximum
			value PDV for packets between two endpoints.
	Availability		Maximum Permissible Packet Loss Rate: The ratio of packets dropped
			to packets transmitted between two endpoints over a period of
			time. See [RFC7680].
	The ratio of uptime to the sum of uptime and downtime, where		Availability: The ratio of uptime to the sum of uptime and downtime,
	uptime is the time the IETF Network Slice is available in		where 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.
	4.1.1.2. Other Service Level Objectives		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 service that a customer requests. These would		the IETF Network Slice service that a customer requests. These would
	be specified in further documents.		be specified in further documents.
	If the IETF Network Slice service is traffic aware, other traffic		If the IETF Network Slice service is traffic aware, other traffic
	specific characteristics may be valuable including MTU, traffic-type		specific characteristics may be valuable including MTU, traffic-type
	(e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level		(e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level
	skipping to change at page 13, line 51 ¶		skipping to change at page 14, line 21 ¶
	important part of the contract between customer and provider.		important part of the contract between customer and provider.
	Quite often, an SLE will imply some details of how an IETF Network		Quite often, an SLE will imply some details of how an IETF Network
	Slice service is realized by the provider, although most aspects of		Slice service is realized by the provider, although most aspects of
	the implementation in the underlying network layers remain a free		the implementation in the underlying network layers remain a free
	choice for the provider.		choice for the provider.
	SLEs may be seen as aspirational on the part of the customer, and		SLEs may be seen as aspirational on the part of the customer, and
	they are expressed as behaviors that the provider is expected to		they are expressed as behaviors that the provider is expected to
	apply to the network resources used to deliver the IETF Network Slice		apply to the network resources used to deliver the IETF Network Slice
	service. An IETF Network Slice service can have one or more SLEs		service. The SLEs are combined with SLOs in an SLA.
	associated with it. The SLEs are combined with SLOs in an SLA.
	An IETF Network Slice service may include multiple connection		An IETF Network Slice service may include multiple connection
	constructs that associate sets of endpoints (SDPs). SLEs apply to		constructs that associate sets of endpoints (SDPs). SLEs apply to a
	sets of two or more SDPs and apply to specific directions of traffic		given connectivity construct and apply to specific directions of
	flow. That is, they apply to a specific source and the connection to		traffic flow. That is, they apply to a specific sending SDP and the
	specific destinations. However, being more general in nature, SLEs		connection to specific receiving SDPs. However, being more general
	may commonly be applied to all connection constructs in an IETF		in nature that SLOs, SLEs may commonly be applied to all connection
	Network Slice service.		constructs in an IETF Network Slice service.
	4.1.2.1. Some Common SLEs		4.1.2.1. Some Common SLEs
	SLEs can be described as 'Indirectly Measurable Objectives': they are		SLEs can be described as 'Indirectly Measurable Objectives': they are
	not generally directly measurable by the customer.		not generally directly measurable by the customer.
	Security, geographic restrictions, maximum occupancy level, and		Security, geographic restrictions, maximum occupancy level, and
	isolation are example SLEs as follows.		isolation are example SLEs as follows.
	Security		Security: A customer may request that the provider applies
			encryption or other security techniques to traffic flowing between
	A customer may request that the provider applies encryption or		SDPs of an IETF Network Slice service. For example, the customer
	other security techniques to traffic flowing between SDPs of an		could request that only network links that have MACsec [MACsec]
	IETF Network Slice service. For example, the customer could		enabled are used to realize the IETF Network Slice service.
	request that only network links that have MACsec [MACsec]
	enabled are used to realize the IETF Network Slice service.
	This SLE may include the request for encryption (e.g.,
	[RFC4303]) between the two SDPs explicitly to meet architecture
	recommendations as in [TS33.210] or for compliance with [HIPAA]
	or [PCI].
	Whether or not the provider has met this SLE is generally not
	directly observable by the customer and cannot be measured as a
	quantifiable metric.
	Please see further discussion on security in Section 9.
	Geographic Restrictions		This SLE may include the request for encryption (e.g., [RFC4303])
			between the two SDPs explicitly to meet architecture
			recommendations as in [TS33.210] or for compliance with [HIPAA] or
			[PCI].
	A customer may request that certain geographic limits are		Whether or not the provider has met this SLE is generally not
	applied to how the provider routes traffic for the IETF Network		directly observable by the customer and cannot be measured as a
	Slice service. For example, the customer may have a preference		quantifiable metric.
	that its traffic does not pass through a particular country for
	political or security reasons.
	Whether or not the provider has met this SLE is generally not		Please see further discussion on security in Section 9.
	directly observable by the customer and cannot be measured as a
	quantifiable metric.
	Maximal Occupancy Level		Geographic Restrictions: A customer may request that certain
	The maximal occupancy level specifies the number of flows to be		geographic limits are applied to how the provider routes traffic
	admitted and optionally a maximum number of countable resource		for the IETF Network Slice service. For example, the customer may
	units (e.g., IP or MAC addresses) an IETF Network Slice service		have a preference that its traffic does not pass through a
	can consume. Since an IETF Network Slice service may include		particular country for political or security reasons.
	multiple connection constructs, this SLE should also say
	whether it applies for the entire IETF Network Service slice,
	for group of connections, or on a per connection basis.
	Again, a customer may not be able to fully determine whether		Whether or not the provider has met this SLE is generally not
	this SLE is being met by the provider.		directly observable by the customer and cannot be measured as a
			quantifiable metric.
	Isolation		Maximal Occupancy Level: The maximal occupancy level specifies the
			number of flows to be admitted and optionally a maximum number of
			countable resource units (e.g., IP or MAC addresses) an IETF
			Network Slice service can consume. Since an IETF Network Slice
			service may include multiple connection constructs, this SLE
			should also say whether it applies for the entire IETF Network
			Slice service, for group of connections, or on a per connection
			basis.
	As described in Section 7, a customer may request that its		Again, a customer may not be able to fully determine whether this
	traffic within its IETF Network Slice service is isolated from		SLE is being met by the provider.
	the effects of other network services supported by the same
	provider. That is, if another service exceeds capacity or has
	a burst of traffic, the customer's IETF Network Slice service
	should remain unaffected and there should be no noticeable
	change to the quality of traffic delivered.
	In general, a customer cannot tell whether a service provider		Isolation: As described in Section 7, a customer may request that
	is meeting this SLE. They cannot tell whether the variation of		its traffic within its IETF Network Slice service is isolated from
	an SLI is because of changes in the underlying network or		the effects of other network services supported by the same
	because of interference from other services carried by the		provider. That is, if another service exceeds capacity or has a
	network. And if the service varies within the allowed bounds		burst of traffic, the customer's IETF Network Slice service should
	of the SLOs, there may be no noticeable indication that this		remain unaffected and there should be no noticeable change to the
	SLE has been violated.		quality of traffic delivered.
	Diversity		In general, a customer cannot tell whether a service provider is
			meeting this SLE. They cannot tell whether the variation of an
			SLI is because of changes in the underlying network or because of
			interference from other services carried by the network. And if
			the service varies within the allowed bounds of the SLOs, there
			may be no noticeable indication that this SLE has been violated.
	A customer may request that traffic on the connection between		Diversity: A customer may request that traffic on the connection
	one set of SDPs should use different network resources from the		between one set of SDPs should use different network resources
	traffic between another set of SDPs. This might be done to		from the traffic between another set of SDPs. This might be done
	enhance the availability of the IETF Network Slice service.		to enhance the availability of the IETF Network Slice service.
	While availability is a measurable objective (see		While availability is a measurable objective (see Section 4.1.1.1)
	Section 4.1.1.1) this SLE requests a finer grade of control and		this SLE requests a finer grade of control and is not directly
	is not directly measurable (although the customer might become		measurable (although the customer might become suspicious if two
	suspicious if two connections fail at the same time).		connections fail at the same time).
	4.2. IETF Network Slice Service Demarcation Points		4.2. IETF Network Slice Service Demarcation Points
	As noted in Section 3.1, an IETF Network Slice is a logical network		As noted in Section 3.1, an IETF Network Slice is a logical network
	topology connecting a number of endpoints. Section 3.2 goes on to		topology connecting a number of endpoints. Section 3.2 goes on to
	describe how the IETF Network Slice service is composed of a set of		describe how the IETF Network Slice service is composed of a set of
	one or more connectivity constructs that describe connectivity		one or more connectivity constructs that describe connectivity
	between the service demarcation points across the underlying network.		between the service demarcation points across the underlying network.
	The characteristics of IETF Network Slice Service Demarcation Points		The characteristics of IETF Network Slice Service Demarcation Points
	(SDPs) are as follows:		(SDPs) are as follows:
	* SDPs are conceptual points of connection to an IETF Network Slice.		* SDPs are conceptual points of connection to an IETF Network Slice.
	As such, they serve as the IETF Network Slice ingress/ egress		As such, they serve as the IETF Network Slice ingress/ egress
	points.		points.
	* Each SDP maps to a device, application, or a network function,		* Each SDP maps to a device, application, or a network function,
	such as (but not limited to) routers, switches, firewalls, WAN,		such as (but not limited to) routers, switches, firewalls, WAN,
	4G/5G RAN nodes, 4G/5G Core nodes, application accelerators, Deep		4G/5G RAN nodes, 4G/5G Core nodes, application accelerators,
	Packet Inspection (DPI) engines, server load balancers, NAT44		server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP
	[RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and		header enrichment functions, and Performance Enhancing Proxies
	TCP optimizers.		(PEPs) [RFC3135].
	* An SDP is identified by a unique identifier in the context of an		* An SDP is identified by a unique identifier in the context of an
	IETF Network Slice customer.		IETF Network Slice customer.
	* Each SDP is associated with a set of provider-scope identifiers		* Each SDP is associated with a set of provider-scope identifiers
	such as IP addresses, encapsulation-specific identifiers (e.g.,		such as IP addresses, encapsulation-specific identifiers (e.g.,
	VLAN tag, MPLS Label), interface/port numbers, node ID, etc.		VLAN tag, MPLS Label), interface/port numbers, node ID, etc.
	* SDPs are mapped to endpoints of services/tunnels/paths within the		* SDPs are mapped to endpoints of services/tunnels/paths within the
	IETF Network Slice during its initialization and realization.		IETF Network Slice during its initialization and realization.
	- A combination of the SDP identifier and SDP network-scope		- A combination of the SDP identifier and SDP provider-network-
	identifiers define an SDP in the context of the Network Slice		scope identifiers define an SDP in the context of the Network
	Controller (NSC).		Slice Controller (NSC).
	- The NSC will use the SDP network-scope identifiers as part of		- The NSC will use the SDP provider-network-scope identifiers as
	the process of realizing the IETF Network Slice.		part of the process of realizing the IETF Network Slice.
	For a given IETF Network Slice service, the IETF Network Slice		For a given IETF Network Slice service, the IETF Network Slice
	customer and provider agree where the endpoint (i.e., the service		customer and provider agree where the endpoint (i.e., the service
	demarcation point) is located. This determines what resources at the		demarcation point) is located. This determines what resources at the
	edge of the network form part of the IETF Network Slice and are		edge of the network form part of the IETF Network Slice and are
	subject to the set of SLOs and SLEs for a specific endpoint.		subject to the set of SLOs and SLEs for a specific endpoint.
	Figure 1 shows different potential scopes of an IETF Network Slice		Figure 1 shows different potential scopes of an IETF Network Slice
	that are consistent with the different SDP positions. For the		that are consistent with the different SDP positions. For the
	purpose of example and without loss of generality, the figure shows		purpose of example and without loss of generality, the figure shows
	skipping to change at page 18, line 22 ¶		skipping to change at page 18, line 28 ¶
	decision can be taken on a per-SDP basis through agreement between		decision can be taken on a per-SDP basis through agreement between
	the customer and provider.		the customer and provider.
	In practice, it may be necessary to map traffic not only onto an IETF		In practice, it may be necessary to map traffic not only onto an IETF
	Network Slice, but also onto a specific connectivity construct if the		Network Slice, but also onto a specific connectivity construct if the
	IETF Network Slice supports more than one connectivity construct with		IETF Network Slice supports more than one connectivity construct with
	a source at the specific SDP. The mechanism used will be one of the		a source at the specific SDP. The mechanism used will be one of the
	mechanisms described above, dependent on how the SDP is realized.		mechanisms described above, dependent on how the SDP is realized.
	Finally, note (as described in Section 2.1) that an SDP is an		Finally, note (as described in Section 2.1) that an SDP is an
	abstract endpoint of an IETF Network Slice Service and as such may be		abstract endpoint of an IETF Network Slice service and as such may be
	a device or software component and may, in the case of netork		a device or software component and may, in the case of netork
	functions virtualization (for example), be an abstract function		functions virtualization (for example), be an abstract function
	supported within the provider's network.		supported within the provider's network.
	4.3. IETF Network Slice Decomposition		4.3. IETF Network Slice Decomposition
	Operationally, an IETF Network Slice may be composed of two or more		Operationally, an IETF Network Slice may be composed of two or more
	IETF Network Slices as specified below. Decomposed network slices		IETF Network Slices as specified below. Decomposed network slices
	are independently realized and managed.		are independently realized and managed.
	skipping to change at page 19, line 18 ¶		skipping to change at page 19, line 28 ¶
	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. The IETF Network Slice customer and IETF Network Slice		terminology. The IETF Network Slice customer and IETF Network Slice
	provider (see Section 2.1) are also stakeholders.		provider (see Section 2.1) are also stakeholders.
	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 NSC.		the IETF NSC.
	IETF Network Slice Controller (NSC): It realizes an IETF Network		IETF Network Slice Controller (NSC): The NSC realizes an IETF
	Slice in the underlying network, maintains and monitors the run-		Network Slice in the underlying network, and maintains and
	time state of resources and topologies associated with it. A		monitors the run-time state of resources and topologies associated
	well-defined interface is needed between different types of IETF		with it. A well-defined interface is needed to support
	NSCs and different types of orchestrators. An IETF Network Slice		interworking between different NSC implementations and different
	operator (or slice operator for short) manages one or more IETF		orchestrator implementations.
	Network Slices using the IETF NSCs.
	Network Controller: is a form of network infrastructure controller		Network Controller: The Network Controller is a form of network
	that offers network resources to the NSC to realize a particular		infrastructure controller that offers network resources to the NSC
	network slice. These may be existing network controllers		to realize a particular network slice. These may be existing
	associated with one or more specific technologies that may be		network controllers associated with one or more specific
	adapted to the function of realizing IETF Network Slices in a		technologies that may be adapted to the function of realizing IETF
	network.		Network Slices in a network.
	5.2. Expressing Connectivity Intents		5.2. Expressing Connectivity Intents
	An IETF Network Slice customer communicates with the NSC using the		An IETF Network Slice customer communicates with the NSC using the
	IETF Network Slice Service Interface.		IETF Network Slice Service Interface.
	An IETF Network Slice customer may be a network operator who, in		An IETF Network Slice customer may be a network operator who, in
	turn, provides the IETF Network Slice to another IETF Network Slice		turn, provides the IETF Network Slice to another IETF Network Slice
	customer.		customer.
	skipping to change at page 20, line 34 ¶		skipping to change at page 20, line 41 ¶
	* Scalability: customers do not need to know any information beyond		* Scalability: customers do not need to know any information beyond
	that which is exposed via the IETF Network Slice Service		that which is exposed via the IETF Network Slice Service
	Interface.		Interface.
	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 other
	documents and are widely supported. See, for instance, GMPLS-based		IETF documents. See, for instance, GMPLS-based networks [RFC5212]
	networks [RFC5212] and [RFC4397], or Abstraction and Control of TE		and [RFC4397], or Abstraction and Control of TE Networks (ACTN)
	Networks (ACTN) [RFC8453] and [RFC8454]. The principles and		[RFC8453] and [RFC8454]. The principles and mechanisms associated
	mechanisms associated with layered networking are applicable to IETF		with layered networking are applicable to IETF Network Slices.
	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 IETF Network Slice Service Interface		a desired logical network. The IETF Network Slice Service Interface
	carries data either in a protocol-defined format, or in a formalism		carries data either in a protocol-defined format, or in a formalism
	associated with a modeling language.		associated with a modeling language.
	For instance:		For instance:
	* Path Computation Element (PCE) Communication Protocol (PCEP)		* 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 21, line 21 ¶		skipping to change at page 21, line 28 ¶
	* gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded		* gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
	programmable interface;		programmable interface;
	* For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to		* 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.
	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. Further, it is
			possible that mechanisms will be needed to determine the feasibility
			of service requests before they are actually made.
	5.3. IETF Network Slice Controller (NSC)		5.3. IETF Network Slice Controller (NSC)
	The IETF NSC takes abstract requests for IETF Network Slices and		The IETF NSC takes abstract requests for IETF Network Slices and
	implements them using a suitable underlying technology. An IETF NSC		implements them using a suitable underlying technology. An IETF NSC
	is the key building block for control and management of the IETF		is the key building block for control and management of the IETF
	Network Slice. It provides the creation/modification/deletion,		Network Slice. It provides the creation/modification/deletion,
	monitoring and optimization of IETF Network Slices in a multi-domain,		monitoring and optimization of IETF Network Slices in a multi-domain,
	a multi-technology and multi-vendor environment.		a multi-technology and multi-vendor environment.
	skipping to change at page 22, line 24 ¶		skipping to change at page 22, line 26 ¶
	* Determines an abstract topology connecting the SDPs of the IETF		* Determines an abstract topology connecting the SDPs of the IETF
	Network Slice that meets criteria specified via the IETF Network		Network Slice that meets criteria specified via the IETF Network
	Slice Service Interface. The NSC also retains information about		Slice Service Interface. The NSC also retains information about
	the mapping of this abstract topology to underlying components of		the mapping of this abstract topology to underlying components of
	the IETF Network Slice as necessary to monitor IETF Network Slice		the IETF Network Slice as necessary to monitor IETF Network Slice
	status and performance.		status and performance.
	* Provides "Mapping Functions" for the realization of IETF Network		* 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 IETF Network Slice Service Interface		- map IETF Network Slice Service Interface requests that are
	request to technology-specific network configuration interfaces		agnostic to the technology of the underlying network to
			technology-specific network configuration interfaces
	- map filtering/selection information as necessary to entities in		- map filtering/selection information as necessary to entities in
	the underlay network.		the underlay network.
	* Via a network configuration interface, the controller collects		* Via a network configuration interface, the controller collects
	telemetry data (e.g., OAM results, statistics, states, etc.) for		telemetry data (e.g., OAM results, statistics, states, etc.) for
	all elements in the abstract topology used to realize the IETF		all elements in the abstract topology used to realize the IETF
	Network Slice.		Network Slice.
	* Using the telemetry data from the underlying realization of a IETF		* Using the telemetry data from the underlying realization of a IETF
	skipping to change at page 23, line 32 ¶		skipping to change at page 23, line 35 ¶
	5.3.1. IETF Network Slice Controller Interfaces		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 2).		communication interfaces (see Figure 2).
	IETF Network Slice Service Interface: The IETF Network Slice Service		IETF Network Slice Service Interface: The IETF Network Slice Service
	Interface is an interface between a customer's higher level		Interface is an interface between a customer's higher level
	operation system (e.g., a network slice orchestrator) and the NSC.		operation system (e.g., a network slice orchestrator) and the NSC.
	It agnostic to the technology of the underlying network. The		It is agnostic to the technology of the underlying network. The
	customer can use this interface to communicate the requested		customer can use this interface to communicate the requested
	characteristics and other requirements (i.e., the SLOs) for the		characteristics and other requirements (i.e., the SLOs) for the
	IETF Network Slice, and the NSC can use the interface to report		IETF Network Slice, and the NSC can use the interface to report
	the operational state of an IETF Network Slice to the customer.		the operational state of an IETF Network Slice to the customer.
	Network Configuration Interface: The Network Configuration Interface		Network Configuration Interface: The Network Configuration Interface
	is an interface between the NSC and network controllers. It is		is an 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.
	skipping to change at page 26, line 30 ¶		skipping to change at page 26, line 30 ¶
	[EPm] [EPn]		[EPm] [EPn]
	Legend		Legend
	SDP: IETF Network Slice Service Demarcation Point		SDP: IETF Network Slice Service Demarcation Point
	EP: Serivce/tunnel/path Endpoint used to realize the		EP: Serivce/tunnel/path Endpoint used to realize the
	IETF Network Slice		IETF Network Slice
	Figure 4: IETF Network Slice		Figure 4: IETF Network Slice
	Figure 4 illustrates a case where an IETF Network Slice provides		Figure 4 illustrates a case where an IETF Network Slice provides
	connectivity between a set of IETF Network Slice service Demarcation		connectivity between a set of IETF Network Slice Service Demarcation
	Point (SDP) pairs with specific SLOs (e.g., guaranteed minimum		Point (SDP) pairs with specific SLOs (e.g., guaranteed minimum
	bandwidth of x bps and guaranteed delay of no more than y ms). The		bandwidth of x bps and guaranteed delay of no more than y ms). The
	IETF Network Slice endpoints are mapped to the service/tunnel/path		IETF Network Slice endpoints are mapped to the service/tunnel/path
	Endpoints (EPs) in the underlay network. Also, the SDPs in the same		Endpoints (EPs) in the underlay network. Also, the SDPs in the same
	IETF Network Slice may belong to the same or different address		IETF Network Slice may belong to the same or different address
	spaces.		spaces.
	IETF Network Slice structure fits into a broader concept of end-to-		IETF Network Slice structure fits into a broader concept of end-to-
	end network slices. A network operator may be responsible for		end network slices. A network operator may be responsible for
	delivering services over a number of technologies (such as radio		delivering services over a number of technologies (such as radio
	skipping to change at page 29, line 10 ¶		skipping to change at page 29, line 10 ¶
	Program the ( - - )		Program the ( - - )
	Network ----------------------------------------------		Network ----------------------------------------------
	Figure 5: Architecture of an IETF Network Slice		Figure 5: Architecture of an IETF Network Slice
	The network itself (at the bottom of the figure) comprises an		The network itself (at the bottom of the figure) comprises an
	underlay network. This could be a physical network, but may be a		underlay network. This could be a physical network, but may be a
	virtual network. The underlay network is provisioned through network		virtual network. The underlay network is provisioned through network
	controllers.		controllers.
	The underlay network may optionally be filtered by the network		The underlay network may optionally be filtered or customized by the
	operator into a number of Filter Topologies. Filter actions may		network operator to produce a number of network topologies that we
	include selection of specific resources (e.g., nodes and links)		call Filter Topologies. Customization is just a way of selecting
	according to their capabilities, and are based on network-wide		specific resources (e.g., nodes and links) from the underlay network
			according to their capabilities and connectivity in the underlay
			network. These actions are configuration options or operator
	policies. The resulting topologies can be used as candidates to host		policies. The resulting topologies can be used as candidates to host
	IETF Network Slices and provide a useful way for the network operator		IETF Network Slices and provide a useful way for the network operator
	to know in advance that all of the resources they are using to plan		to know in advance that all of the resources they are using to plan
	an IETF Network Slice would be able to meet specific SLOs and SLEs.		an IETF Network Slice would be able to meet specific SLOs and SLEs.
	The filtering procedure could be an offline planning activity or		The creation of a Filter Topology could be an offline planning
	could be performed dynamically as new demands arise. The use of		activity or could be performed dynamically as new demands arise. The
	Filter Topologies is entirely optional in the architecture, and IETF		use of Filter Topologies is entirely optional in the architecture,
	Network Slices could be hosted directly on the underlay network.		and IETF Network Slices could be hosted directly on the underlay
			network.
	Recall that an IETF Network Slice is a service requested by /		Recall that an IETF Network Slice is a service requested by /
	provided for the customer. The IETF Network Slice service is		provided for the customer. The IETF Network Slice service is
	expressed in terms of one or more connectivity constructs. An		expressed in terms of one or more connectivity constructs. An
	implementation or operator is free to limit the number of		implementation or operator is free to limit the number of
	connectivity constructs in a slice to exactly one. Each connectivity		connectivity constructs in a slice to exactly one. Each connectivity
	construct is associated within the IETF Network Slice service request		construct is associated within the IETF Network Slice service request
	with a set of SLOs and SLEs. The set of SLOs and SLEs does not need		with a set of SLOs and SLEs. The set of SLOs and SLEs does not need
	to be the same for every connectivity construct in the slice, but an		to be the same for every connectivity construct in the slice, but an
	implementation or operator is free to require that all connectivity		implementation or operator is free to require that all connectivity
	skipping to change at page 31, line 36 ¶		skipping to change at page 31, line 36 ¶
	Further discussion of the applicability of ACTN to IETF Network		Further discussion of the applicability of ACTN to IETF Network
	Slices including a discussion of the relevant YANG models can be		Slices including a discussion of the relevant YANG models can be
	found in [I-D.king-teas-applicability-actn-slicing].		found in [I-D.king-teas-applicability-actn-slicing].
	6.4. Applicability of Enhanced VPNs to IETF Network Slices		6.4. Applicability of Enhanced VPNs to IETF Network Slices
	An enhanced VPN (VPN+) is designed to support the needs of new		An enhanced VPN (VPN+) is designed to support the needs of new
	applications, particularly applications that are associated with 5G		applications, particularly applications that are associated with 5G
	services, by utilizing an approach that is based on existing VPN and		services, by utilizing an approach that is based on existing VPN and
	TE technologies and adds characteristics that specific services		TE technologies and adds characteristics that specific services
	require over and above traditional VPNs.		require over and above VPNs as they have previously been specified.
	An enhanced VPN can be used to provide enhanced connectivity services		An enhanced VPN can be used to provide enhanced connectivity services
	between customer sites (a concept similar to an IETF Network Slice)		between customer sites and can be used to create the infrastructure
	and can be used to create the infrastructure to underpin network		to underpin a network slicing service.
	slicing.
	It is envisaged that enhanced VPNs will be delivered using a		It is envisaged that enhanced VPNs will be delivered using a
	combination of existing, modified, and new networking technologies.		combination of existing, modified, and new networking technologies.
	[I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced		[I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced
	Virtual Private Network (VPN+) services.		Virtual Private Network (VPN+) services.
	6.5. Network Slicing and Aggregation in IP/MPLS Networks		6.5. Network Slicing and Aggregation in IP/MPLS Networks
	Network slicing provides the ability to partition a physical network		Network slicing provides the ability to partition a physical network
	skipping to change at page 34, line 12 ¶		skipping to change at page 34, line 12 ¶
	general, isolation is expected to strengthen the IETF Network		general, isolation is expected to strengthen the IETF Network
	Slice security.		Slice security.
	* Data Integrity of an IETF Network Slice: A customer wanting to		* Data Integrity of an IETF Network Slice: A customer 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 customer is		Slice. It is expected that for data integrity, a customer 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.
	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,
	skipping to change at page 35, line 11 ¶		skipping to change at page 35, line 11 ¶
	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 customer.		IETF Network Slice customer.
	11. IANA Considerations		11. IANA Considerations
	This document makes no requests for IANA action.		This document makes no requests for IANA action.
	12. Informative References		12. Informative References
	[BBF-SD406]
	Broadband Forum, "End-to-end network slicing", BBF SD-406,
	<https://wiki.broadband-forum.org/display/BBF/SD-406+End-
	to-End+Network+Slicing>.
	[HIPAA] HHS, "Health Insurance Portability and Accountability Act		[HIPAA] HHS, "Health Insurance Portability and Accountability Act
	- The Security Rule", February 2003,		- The Security Rule", February 2003,
	<https://www.hhs.gov/hipaa/for-professionals/security/		<https://www.hhs.gov/hipaa/for-professionals/security/
	index.html>.		index.html>.
			[I-D.ietf-opsawg-sap]
			Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
			Lopez, "A Network YANG Model for Service Attachment Points
			(SAPs)", Work in Progress, Internet-Draft, draft-ietf-
			opsawg-sap-02, 22 February 2022,
			<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
			sap-02>.
	[I-D.ietf-teas-enhanced-vpn]		[I-D.ietf-teas-enhanced-vpn]
	Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A		Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
	Framework for Enhanced Virtual Private Network (VPN+)		Framework for Enhanced Virtual Private Network (VPN+)
	Services", Work in Progress, Internet-Draft, draft-ietf-		Services", Work in Progress, Internet-Draft, draft-ietf-
	teas-enhanced-vpn-09, 25 October 2021,		teas-enhanced-vpn-09, 25 October 2021,
	<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-		<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
	vpn-09.txt>.		enhanced-vpn-09>.
	[I-D.king-teas-applicability-actn-slicing]		[I-D.king-teas-applicability-actn-slicing]
	King, D., Drake, J., Zheng, H., and A. Farrel,		King, D., Drake, J., Zheng, H., and A. Farrel,
	"Applicability of Abstraction and Control of Traffic		"Applicability of Abstraction and Control of Traffic
	Engineered Networks (ACTN) to Network Slicing", Work in		Engineered Networks (ACTN) to Network Slicing", Work in
	Progress, Internet-Draft, draft-king-teas-applicability-		Progress, Internet-Draft, draft-king-teas-applicability-
	actn-slicing-10, 31 March 2021,		actn-slicing-10, 31 March 2021,
	<https://www.ietf.org/archive/id/draft-king-teas-		<https://datatracker.ietf.org/doc/html/draft-king-teas-
	applicability-actn-slicing-10.txt>.		applicability-actn-slicing-10>.
	[I-D.openconfig-rtgwg-gnmi-spec]		[I-D.openconfig-rtgwg-gnmi-spec]
	Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,		Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
	C., and C. Morrow, "gRPC Network Management Interface		C., and C. Morrow, "gRPC Network Management Interface
	(gNMI)", Work in Progress, Internet-Draft, draft-		(gNMI)", Work in Progress, Internet-Draft, draft-
	openconfig-rtgwg-gnmi-spec-01, 5 March 2018,		openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
	<https://www.ietf.org/archive/id/draft-openconfig-rtgwg-		<https://datatracker.ietf.org/doc/html/draft-openconfig-
	gnmi-spec-01.txt>.		rtgwg-gnmi-spec-01>.
	[MACsec] IEEE, "IEEE Standard for Local and metropolitan area		[MACsec] IEEE, "IEEE Standard for Local and metropolitan area
	networks - Media Access Control (MAC) Security", 2018,		networks - Media Access Control (MAC) Security", 2018,
	<https://1.ieee802.org/security/802-1ae>.		<https://1.ieee802.org/security/802-1ae>.
	[NGMN-NS-Concept]		[NGMN-NS-Concept]
	NGMN Alliance, "Description of Network Slicing Concept",		NGMN Alliance, "Description of Network Slicing Concept",
	https://www.ngmn.org/uploads/		https://www.ngmn.org/uploads/
	media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf ,		media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf ,
	2016.		2016.
	skipping to change at page 36, line 27 ¶		skipping to change at page 36, line 27 ¶
	[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip		[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
	Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,		Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
	September 1999, <https://www.rfc-editor.org/info/rfc2681>.		September 1999, <https://www.rfc-editor.org/info/rfc2681>.
	[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
	Address Translator (Traditional NAT)", RFC 3022,		Address Translator (Traditional NAT)", RFC 3022,
	DOI 10.17487/RFC3022, January 2001,		DOI 10.17487/RFC3022, January 2001,
	<https://www.rfc-editor.org/info/rfc3022>.		<https://www.rfc-editor.org/info/rfc3022>.
			[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
			Shelby, "Performance Enhancing Proxies Intended to
			Mitigate Link-Related Degradations", RFC 3135,
			DOI 10.17487/RFC3135, June 2001,
			<https://www.rfc-editor.org/info/rfc3135>.
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	DOI 10.17487/RFC3393, November 2002,		DOI 10.17487/RFC3393, November 2002,
	<https://www.rfc-editor.org/info/rfc3393>.		<https://www.rfc-editor.org/info/rfc3393>.
	[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,		[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
	"Generalized Multiprotocol Label Switching (GMPLS) User-		"Generalized Multiprotocol Label Switching (GMPLS) User-
	Network Interface (UNI): Resource ReserVation Protocol-		Network Interface (UNI): Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Support for the Overlay		Traffic Engineering (RSVP-TE) Support for the Overlay
	Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,		Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
	skipping to change at page 39, line 4 ¶		skipping to change at page 39, line 16 ¶
	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 the		attended one or more of the design team meetings, including the
	following people not listed elsewhere:		following people not listed elsewhere:
	* Aihua Guo		* Aihua Guo
	* Bo Wu		* Bo Wu
	* Greg Mirsky		* Greg Mirsky
	* Lou Berger		* Lou Berger
	* Rakesh Gandhi		* Rakesh Gandhi
	* Ran Chen		* Ran Chen
	* Sergio Belotti		* Sergio Belotti
	* Stewart Bryant		* Stewart Bryant
	* Tomonobu Niwa		* Tomonobu Niwa
	* Xuesong Geng		* Xuesong Geng
	Further useful comments were received from Daniele Ceccarelli, Uma		Further useful comments were received from Daniele Ceccarelli, Uma
	Chunduri, Pavan Beeram, Tarek Saad, Med Boucadair, Kenichi Ogaki,		Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de
	Oscar Gonzalez de Dios, Xiaobing Niu, Dan Voyer.		Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel
			Halpern, and John Scudder.
	The editor of this document would like to express particular thanks
	to John Drake who has consistently provided expert advice, opinons,
	and editorial suggestions for this document.
	This work is partially supported by the European Commission under		This work is partially supported by the European Commission under
	Horizon 2020 grant agreement number 101015857 Secured autonomic		Horizon 2020 grant agreement number 101015857 Secured autonomic
	traffic management for a Tera of SDN flows (Teraflow).		traffic management for a Tera of SDN flows (Teraflow).
	Contributors		Contributors
	The following authors contributed significantly to this document:		The following authors contributed significantly to this document:
			Eric Gray (The original editor of the foundation documents)
			Independent
			Email: ewgray@graiymage.com
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
			Mohamed Boucadair
			Orange
			Email: mohamed.boucadair@orange.com
	Dhruv Dhody		Dhruv Dhody
	Huawei, India		Huawei, India
	Email: dhruv.ietf@gmail.com		Email: dhruv.ietf@gmail.com
	Jie Dong		Jie Dong
	Huawei		Huawei
	Email: jie.dong@huawei.com		Email: jie.dong@huawei.com
	Xufeng Liu		Xufeng Liu
	Volta Networks		Volta Networks
	skipping to change at page 40, line 4 ¶		skipping to change at page 40, line 30 ¶
	Jie Dong		Jie Dong
	Huawei		Huawei
	Email: jie.dong@huawei.com		Email: jie.dong@huawei.com
	Xufeng Liu		Xufeng Liu
	Volta Networks		Volta Networks
	Email: xufeng.liu.ietf@gmail.com		Email: xufeng.liu.ietf@gmail.com
	Authors' Addresses		Authors' Addresses
	Adrian Farrel (editor)		Adrian Farrel (editor)
	Old Dog Consulting		Old Dog Consulting
	United Kingdom		United Kingdom
	Email: adrian@olddog.co.uk		Email: adrian@olddog.co.uk
	Eric Gray		John Drake
	Independent
	United States of America
	Email: ewgray@graiymage.com
	John Drake (editor)
	Juniper Networks		Juniper Networks
	United States of America		United States of America
	Email: jdrake@juniper.net		Email: jdrake@juniper.net
	Reza Rokui		Reza Rokui
	Ciena		Ciena
	Email: rrokui@ciena.com		Email: rrokui@ciena.com
	Shunsuke Homma		Shunsuke Homma
	NTT		NTT
End of changes. 77 change blocks.
	240 lines changed or deleted		252 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/