draft-nsdt-teas-transport-slice-definition-02.txt		draft-nsdt-teas-transport-slice-definition-02-isolation-changes2.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 #2,
	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 confidence level to be able to satisfy a
	to either hard or soft guarantees. A hard guarantee is the one		"guarantee". This confidence level should be expressed
	that is not affected by other traffic. In a soft guarantee, a		separately for each different characteristic listed above.
	violation (of the guarantee) may occur in rare cases due to
	resource interference. In such cases, the guarantee will be
	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 that no guarantee can prevent hardware failures, such as
			losing a node. Additional protection against such issues is
			possible, by specifying those characteristics separately (see
			item "resource redundancy" above).
			Note also that the confidence 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		For further discussion on this, see also Appendix A.
	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,
	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.
	skipping to change at line 804		skipping to change at line 741
	Kiran Makhijani		Kiran Makhijani
	Futurewei		Futurewei
	USA		USA
	Email: kiranm@futurewei.com		Email: kiranm@futurewei.com
	Luis M. Contreras		Luis M. Contreras
	Telefonica		Telefonica
	Spain		Spain
	Email: luismiguel.contrerasmurillo@telefonica.com		Email: luismiguel.contrerasmurillo@telefonica.com
			Appendix A: Making Guarantees
			Due to this complex topic and the use of number of different
			approaches and terms in the industry, this appendix attempts to
			describe some of the issues surrounding making guarantees.
			It should be noted first that absolute guarantees cannot be made,
			because in the end there can be situations where (for instance) all
			nodes fail, preventing service to be offered. There are also a large
			number of factors affecting failures, from common power source to
			common software implementation prone to the same failures, to the
			simpler cable cuts and node failures. The set of dependencies between
			different a slice and the components it needs to function is complex.
			There are also dependencies between different slices, even when some
			of their resources (such as the links they use) are separated.
			Nevertheless, reasonable proclamations of the likelihood of
			failures can be provided, based on the specific techniques used in
			a specific realisation of a slice. For instance, using redudant
			paths and redundant nodes many errors can be eliminated.
			This document does not attempt to classify different implementation
			techniques, and as such, the only requirement is to be able to specify
			and commit to the "reasonable likelihood" of a failure in some rational
			way.
			This reasonable likelihood is also going to be dependent on what
			characteristic is being guaranteed, for instance latency may be more
			prone to fluctuations than bandwidth, if there's contention to a link
			but buffer space is plentiful.
			Some general categories of such likelihoods can be given, however.
			A failure to respect a guarantee can be due to a failure or the
			traffic situation, but it should be noted that this is not simply
			a question of (for instance) separate links not affecting each other.
			Two entirely different traffic flows may affect each other, e.g.,
			due to overload of some management or control function.
			We define three terms:
			Shared resource contention: i.e. multiple transport slices
			simultaneously consume the same resource, in amounts greater
			than what is available.
			Disjoint resource interference (also known as the "surprisingly
			shared resource contention"): i.e. multiple transport slices depend
			on resources whose fate is affected by each other, e.g., due to
			control plane interaction.
			Component interference: Multiple transport slices depend on the
			same components or design, e.g., piece of software.
			Nertheless, the impact of traffic on guarantees is something that
			at the base level can be calculated through traffic models and
			the network configuration. There's a clear difference to being
			able to provide the full link bandwidth almost always vs. only
			during the non-busy hours of the day.
			The effect of failures and more complex interactions is more
			difficult to model, and caution should be paid when attempting
			to provide too simplistic, "this will never fail" type guarantees.
End of changes. 8 change blocks.
	81 lines changed or deleted		18 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/