draft-nsdt-teas-transport-slice-definition-02.txt		draft-nsdt-teas-transport-slice-definition-02-isolation-changes1.txt
	skipping to change at page 1, line 15		skipping to change at page 1, line 15
	Intended status: Informational S. Homma		Intended status: Informational S. Homma
	Expires: October 23, 2020 NTT		Expires: October 23, 2020 NTT
	K. Makhijani		K. Makhijani
	Futurewei		Futurewei
	LM. Contreras		LM. Contreras
	Telefonica		Telefonica
	April 21, 2020		April 21, 2020
	IETF Definition of Transport Slice		IETF Definition of Transport Slice
	draft-nsdt-teas-transport-slice-definition-02		draft-nsdt-teas-transport-slice-definition-02
			+ Suggested changes by Jari Arkko
			for resolving isolation-related comments from Joel Halpern.
			Approach #1, removing non-observable isolation parts.
	Abstract		Abstract
	This document describes the definition of a slice in the transport		This document describes the definition of a slice in the transport
	networks and its characteristics. The purpose here is to bring		networks and its characteristics. The purpose here is to bring
	clarity and a common understanding of the transport slice concept and		clarity and a common understanding of the transport slice concept and
	describe related terms and their meaning. It explains how transport		describe related terms and their meaning. It explains how transport
	slices can be used in end to end network slices, or independently.		slices can be used in end to end network slices, or independently.
	Status of This Memo		Status of This Memo
	skipping to change at page 5, line 34		skipping to change at page 8, line ?
	backup or duplicate resources such as path (same SLOs - latency,		backup or duplicate resources such as path (same SLOs - latency,
	bandwidth, etc.), network functions (same compute, memory, etc.)		bandwidth, etc.), network functions (same compute, memory, etc.)
	To meet no packet loss objective, packet replication maybe		To meet no packet loss objective, packet replication maybe
	necessary to guarantee that at least packets from one path was		necessary to guarantee that at least packets from one path was
	achieved. However, we should consider this as 'how' aspect of		achieved. However, we should consider this as 'how' aspect of
	objective and not 'what'.		objective and not 'what'.
	o Security: The objective of securing a transport slice concern with		o Security: The objective of securing a transport slice concern with
	three attributes: a) end-to-end encryption between source and		three attributes: a) end-to-end encryption between source and
	destination endpoints, this can be seen as the logical link		destination endpoints, this can be seen as the logical link
	between source and destination end points requiring encryption, b)		between source and destination end points requiring encryption and b)
	Authentication and access control (ACLs) objectives to permit data		Authentication and access control (ACLs) objectives to permit data
	on this transport slice, c) Isolation, is also a characteristic of		on this transport slice. The definition of transport slice itself
	security, to prevent interference between two or more slices or		implies logical partitioning to keep traffic separate between
	other flows on the same infrastructure. Isolation is implied by		different slices, but without a promise of encryption or other
	the definition of transport slice itself (logical		mechanisms.
	partitioning...).
	o Resolution of guarantee: The above objectives can be resolved in		o Expected likelihood to be able to satisfy a "guarantee". Note
	to either hard or soft guarantees. A hard guarantee is the one		that no guarantee can prevent hardware failures, such as losing
	that is not affected by other traffic. In a soft guarantee, a		a node. Additional protection against such issues is possible,
	violation (of the guarantee) may occur in rare cases due to		by specifying those characteristics separately (see item
	resource interference. In such cases, the guarantee will be		"resource redundancy" above).
	maintained by the network controller within a certain tolerance
	level of that objective. Note that a hard guarantee does not
	prevent from hardware failures, such as losing a node. Additional
	protection against such issues is possible, by specifying those
	characteristics separately (see item "resource redundancy" below).
	Note also that the hard and soft guarantees do not say anything		Note also that the likelihood does not say anything
	about the specific implementation of how these guarantees are		about the specific implementation of how these guarantees are
	achieved. Different implementations might use different		achieved. Different implementations might use different
	techniques, from avoiding oversubsription to dedicating particular		techniques, from avoiding oversubsription to dedicating particular
	links or their virtual fractions to particular transport slices.		links or their virtual fractions to particular transport slices.
	o Resource isolation: In some cases it may be necessary to dedicate
	specific resources to the slice, for instance, for security
	reasons.
	o etc.		o etc.
	The framework [I-D.nsdt-teas-ns-framework] may further specify		The framework [I-D.nsdt-teas-ns-framework] may further specify
	mechanisms for the performance, assurance and monitoring of these		mechanisms for the performance, assurance and monitoring of these
	objectives.		objectives.
	Note: Additional objectives may be necessary to capture, such as		Note: Additional objectives may be necessary to capture, such as
	specifying well defined paths or domains that a slice may transit. A		specifying well defined paths or domains that a slice may transit. A
	transport slice carries multiple flows between the 2 endpoints,		transport slice carries multiple flows between the 2 endpoints,
	therefore objectives should also say if they are aggregates or on per		therefore objectives should also say if they are aggregates or on per
	skipping to change at page 6, line 42		skipping to change at page 8, line ?
	instead of SLA is used even though SLAs are more commonly used term		instead of SLA is used even though SLAs are more commonly used term
	by the operators. SLOs are definitive and measurable parameters		by the operators. SLOs are definitive and measurable parameters
	associated with a service, therefore, network resource and		associated with a service, therefore, network resource and
	connectivity requirements are defined accurately. In contrast,		connectivity requirements are defined accurately. In contrast,
	service level agreements represent contracts for a service between a		service level agreements represent contracts for a service between a
	service provider and a service consumer (or subscriber). Providers		service provider and a service consumer (or subscriber). Providers
	then translate SLA into SLO; these translations vary from one service		then translate SLA into SLO; these translations vary from one service
	provider to the other. Therefore, all through within the scope of		provider to the other. Therefore, all through within the scope of
	transport slices term SLO will be used.		transport slices term SLO will be used.
	4.1.1. Isolation discussion
	Due to overloading of the term, a further discussion is added to
	highlight two aspects of isolation, first the resolution of isolation
	of an objective (as described above) and second, the dedicated use or
	a hard-separation perspective of the resource.
	Providing a hard resolution of guarantee for the characteristics of a
	transport slice means that the behavior and performance of other
	transport slices should not impact that slice, even if they run over
	the same underlying infrastructure or use logically shared network
	resources.
	In the context of soft resolution of guarantees, since the transport
	slices are logically partitioned over the shared resources, a certain
	degree of commitment to the guarantee is expected even when it is not
	hard. When the shared resource pools begin to become saturated, SLO
	violations can happen, however, impacting only the performance or
	operation of service associated with the transport slice.
	This degree of isolation can be derived from availability
	characteristics requested, such as whether a hard or soft guarantee
	was requested. Requesting a hard guarantee may commit more resources
	than would be required for a softer limit.
	In addition, resource isolation may be applied to ensure dedicated
	access to a particular node, for instance. In such requests a
	dedicated allocation to a link, node and/or other resources to create
	a transport slice for a particular service. For example, a mission-
	critical service may ask for a dedicated router and/or a link or port
	for complete isolation from other services.
	When realizing a transport slice, a network controller should be
	responsible for allocating and providing resources according to the
	specified objectives.
	SLO violations can occur for two reasons and corresponding statements
	apply
	o Shared resource interference: i.e. multiple transport slices
	simultaneously share the same resource, and one of them consume
	the resource in surplus. If the SLO guarantees are strictly
	required, then the network controller can be informed of this by
	requesting a hard guarantee. Note that the terms hard and soft
	limit are requirement oriented and different from what is
	specified in, [I-D.ietf-teas-enhanced-vpn]).
	o Resource failure or fault occurs, such as a link or node failure.
	Where it is important to defend against these, the relevant
	characteristics on resource redundancy (and perhaps some other
	characteristics on restoration speed and other factors) need to be
	specified.
	* Restoration isolation: the network is not impacted for a period
	longer than the given time. For example, failover or the
	service restoration takes no longer than some number of
	seconds. This is specified by Availability SLO.
	* Protection isolation: the network path is protected with
	specified backup path. This is specified by Availability SLO.
	4.2. Endpoint Variation		4.2. Endpoint Variation
	Transport slice endpoints are the terminating or originating nodes		Transport slice endpoints are the terminating or originating nodes
	requiring connectivity with specific SLO. Endpoints may be devices		requiring connectivity with specific SLO. Endpoints may be devices
	or functions.		or functions.
	4.2.1. Types of Endpoints		4.2.1. Types of Endpoints
	There are two types of endpoints based on the functions they perform.		There are two types of endpoints based on the functions they perform.
End of changes. 7 change blocks.
	82 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/