< draft-ietf-mpls-spring-entropy-label-08.txt		draft-ietf-mpls-spring-entropy-label-09.txt >
	Network Working Group S. Kini		Network Working Group S. Kini
	Internet-Draft		Internet-Draft
	Intended status: Informational K. Kompella		Intended status: Informational K. Kompella
	Expires: August 3, 2018 Juniper		Expires: October 28, 2018 Juniper
	S. Sivabalan		S. Sivabalan
	Cisco		Cisco
	S. Litkowski		S. Litkowski
	Orange		Orange
	R. Shakir		R. Shakir
	Google		Google
	J. Tantsura		J. Tantsura
	January 30, 2018		April 26, 2018
	Entropy label for SPRING tunnels		Entropy label for SPRING tunnels
	draft-ietf-mpls-spring-entropy-label-08		draft-ietf-mpls-spring-entropy-label-09
	Abstract		Abstract
	Segment Routing (SR) leverages the source routing paradigm. A node		Segment Routing (SR) leverages the source routing paradigm. A node
	steers a packet through an ordered list of instructions, called		steers a packet through an ordered list of instructions, called
	segments. Segment Routing can be applied to the Multi Protocol Label		segments. Segment Routing can be applied to the Multi Protocol Label
	Switching (MPLS) data plane. Entropy label (EL) is a technique used		Switching (MPLS) data plane. Entropy label (EL) is a technique used
	in MPLS to improve load-balancing. This document examines and		in MPLS to improve load-balancing. This document examines and
	describes how ELs are to be applied to Segment Routing when applied		describes how ELs are to be applied to Segment Routing MPLS.
	to the MPLS dataplane.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 3, 2018.		This Internet-Draft will expire on October 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4		2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4
	3. Use-case requiring multipath load-balancing . . . . . . . . . 4		3. Use-case requiring multipath load-balancing . . . . . . . . . 4
	4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 5		4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6
	5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7		5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7
	6. LSP stitching using the binding SID . . . . . . . . . . . . . 8		6. LSP stitching using the binding SID . . . . . . . . . . . . . 9
	7. Insertion of entropy labels for SPRING path . . . . . . . . . 10		7. Insertion of entropy labels for SPRING path . . . . . . . . . 10
	7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10		7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1.1. Example 1 where the ingress node has a sufficient MSD 11		7.1.1. Example 1 where the ingress node has a sufficient MSD 11
	7.1.2. Example 2 where the ingress node has not a sufficient		7.1.2. Example 2 where the ingress node has not a sufficient
	MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12		MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Considerations for the placement of entropy labels . . . 12		7.2. Considerations for the placement of entropy labels . . . 13
	7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 13		7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 14
	7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14		7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14
	7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 14		7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 15
	7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15		7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15
	7.2.2.3. Adjacency-SID representing a single IP link . . . 15		7.2.2.3. Adjacency-SID representing a single IP link . . . 15
	7.2.2.4. Adjacency-SID representing a single link within a		7.2.2.4. Adjacency-SID representing a single link within a
	L2 bundle . . . . . . . . . . . . . . . . . . . . 15		L2 bundle . . . . . . . . . . . . . . . . . . . . 16
	7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 15		7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 16
	7.2.3. Maximizing number of LSRs that will load-balance . . 15		7.2.3. Maximizing number of LSRs that will load-balance . . 16
	7.2.4. Preference for a part of the path . . . . . . . . . . 16		7.2.4. Preference for a part of the path . . . . . . . . . . 16
	7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 16		7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 17
	8. A simple example algorithm . . . . . . . . . . . . . . . . . 16		8. A simple example algorithm . . . . . . . . . . . . . . . . . 17
	9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17		9. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
	10. Options considered . . . . . . . . . . . . . . . . . . . . . 18		10. Options considered . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Single EL at the bottom of the stack . . . . . . . . . . 18		10.1. Single EL at the bottom of the stack . . . . . . . . . . 18
	10.2. An EL per segment in the stack . . . . . . . . . . . . . 18		10.2. An EL per segment in the stack . . . . . . . . . . . . . 19
	10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19		10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19
	10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 19		10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 20
	10.5. ELs at readable label stack depths . . . . . . . . . . . 20		10.5. ELs at readable label stack depths . . . . . . . . . . . 20
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 21		14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	15.1. Normative References . . . . . . . . . . . . . . . . . . 21		15.1. Normative References . . . . . . . . . . . . . . . . . . 22
	15.2. Informative References . . . . . . . . . . . . . . . . . 22		15.2. Informative References . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Segment Routing [I-D.ietf-spring-segment-routing] is based on source		Segment Routing [I-D.ietf-spring-segment-routing] is based on source
	routed tunnels to steer a packet along a particular path. This path		routed tunnels to steer a packet along a particular path. This path
	is encoded as an ordered list of segments. When applied to the MPLS		is encoded as an ordered list of segments. When applied to the MPLS
	dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an		dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an
	LSP with an associated MPLS label value. Hence, label stacking is		LSP with an associated MPLS label value. Hence, label stacking is
	used to represent the ordered list of segments and the label stack		used to represent the ordered list of segments and the label stack
	associated with an SR tunnel can be seen as nested LSPs (LSP		associated with an SR tunnel can be seen as nested LSPs (LSP
	hierarchy) in the MPLS architecture.		hierarchy) in the MPLS architecture.
	Using label stacking to encode the list of segment has implications		Using label stacking to encode the list of segment has implications
	on the label stack depth.		on the label stack depth.
	Entropy label (EL) [RFC6790] is a technique used in the MPLS data		Traffic load-balancing over ECMP (Equal Cost MultiPath) or LAGs (Link
	plane to provide entropy for load-balancing. When using LSP		Aggregation Groups) is usually based on a hashing function. The
	hierarchies, there are implications on how [RFC6790] should be		local node who performs the load-balancing is required to read some
	applied. The current document addresses the case where a hierarchy		header fields in the incoming packets and then computes a hash based
	is created at a single LSR as required by Segment Routing.		on these fields. The result of the hash is finally mapped to a list
			of outgoing nexthops. The hashing technique is required to perfom a
			per-flow load-balancing and thus prevent packet disordering. For IP
			traffic, the usual fields that are looked up are the source address,
			the destination address, the protocol type, and, if the upper layer
			is TCP or UDP, the source port and destination port can be added as
			well in the hash.
			The MPLS architecture brings some challenges on the load-balancing as
			an LSR (Label Switch Router) should be able to look at header fields
			that are beyond the MPLS label stack. An LSR must perform a deeper
			inspection compared to an ingress router which could be challenging
			for some hardware. Entropy label (EL) [RFC6790] is a technique used
			in the MPLS data plane to provide entropy for load-balancing. The
			idea behind entropy label is that the ingress router computes a hash
			based on several fields from a given packet and place the result in
			an additional label, named "entropy label". When using entropy
			label, an LSR is only required to hash on the MPLS label stack or
			solely on the entropy label to get a full benefit of load-balancing;
			deep hashing is not required anymore.
			When using LSP hierarchies, there are implications on how [RFC6790]
			should be applied. The current document addresses the case where a
			hierarchy is created at a single LSR as required by Segment Routing.
	A use-case requiring load-balancing with SR is given in Section 3. A		A use-case requiring load-balancing with SR is given in Section 3. A
	recommended solution is described in Section 7 keeping in		recommended solution is described in Section 7 keeping in
	consideration the limitations of implementations when applying		consideration the limitations of implementations when applying
	[RFC6790] to deeper label stacks. Options that were considered to		[RFC6790] to deeper label stacks. Options that were considered to
	arrive at the recommended solution are documented for historical		arrive at the recommended solution are documented for historical
	purposes in Section 10.		purposes in Section 10.
	1.1. Requirements Language		1.1. Requirements Language
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 23 ¶
	+-----+ +-----+ +-----+ | +----+ | +-----+		+-----+ +-----+ +-----+ | +----+ | +-----+
	+--| P5 |--+		+--| P5 |--+
	+----+		+----+
	S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs,		S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs,
	L1,L2,L3,L4=Links		L1,L2,L3,L4=Links
	Figure 1: Traffic engineering use-case		Figure 1: Traffic engineering use-case
	Traffic-engineering is one of the applications of MPLS and is also a		Traffic-engineering is one of the applications of MPLS and is also a
	requirement for source routed tunnels with label stacks [RFC7855].		requirement for source routed tunnels with label stacks [RFC7855].
	Consider the topology shown in Figure 1. The LSR S requires data to		Consider the topology shown in Figure 1. The LSR S requires data to
	be sent to LSR D along a traffic-engineered path that goes over the		be sent to LSR D along a traffic-engineered path that goes over the
	link L1. Good load-balancing is also required across equal cost		link L1. Good load-balancing is also required across equal cost
	paths (including parallel links). To engineer traffic along a path		paths (including parallel links). To engineer traffic along a path
	that takes link L1, the label stack that LSR S creates consists of a		that takes link L1, the label stack that LSR S creates consists of a
	label to the node SID of LSR P3, stacked over the label for the		label to the node SID of LSR P3, stacked over the label for the
	adjacency SID of link L1 and that in turn is stacked over the label		adjacency SID of link L1 and that in turn is stacked over the label
	to the node SID of LSR D. For simplicity lets assume that all LSRs		to the node SID of LSR D. For simplicity lets assume that all LSRs
	use the same label space (SRGB) for source routed label stacks. Let		use the same label space (SRGB) for source routed label stacks. Let
	L_N-Px denote the label to be used to reach the node SID of LSR Px.		L_N-Px denote the label to be used to reach the node SID of LSR Px.
	Let L_A-Ln denote the label used for the adjacency SID for link Ln.		Let L_A-Ln denote the label used for the adjacency SID for link Ln.
	The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for		The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for
	traffic-engineering. However to achieve good load-balancing over the		traffic-engineering. However to achieve good load-balancing over the
	equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a		equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a
	mechanism such as Entropy labels [RFC6790] should be adapted for		mechanism such as Entropy labels [RFC6790] should be adapted for
	source routed label stacks. Indeed, the SPRING architecture with the		source routed label stacks. Indeed, the SPRING architecture with the
	MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested		MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested
	MPLS LSPs composing the source routed label stacks. As each MPLS		MPLS LSPs composing the source routed label stacks.
	node may have limitations in the number of labels it can push when it
	is ingress or inspect when doing load-balancing, an entropy label		An MPLS node may have limitations in the number of labels it can
	insertion strategy becomes important to keep the benefit of the load-		push. It may also have a limitation in the number of labels it can
	balancing. Multiple ways to apply entropy labels were considered and		inspect when looking for hash keys during load-balancing. While
	are documented in Section 10 along with their trade-offs. A		entropy label is normally inserted at the bottom of the transport
	recommended solution is described in Section 7.		tunnel, this may prevent an LSR to take into account the EL in its
			load-balancing function if the EL is too deep in the stack. In a
			segment routing environment, it is important to define the
			considerations that needs to be taken into account when inserting EL.
			Multiple ways to apply entropy labels were considered and are
			documented in Section 10 along with their trade-offs. A recommended
			solution is described in Section 7.
	4. Entropy Readable Label Depth		4. Entropy Readable Label Depth
	The Entropy Readable Label Depth (ERLD) is defined as the number of		The Entropy Readable Label Depth (ERLD) is defined as the number of
	labels a router can both:		labels a router can both:
	a. Read in an MPLS packet received on its incoming interface(s)		a. Read in an MPLS packet received on its incoming interface(s)
	(starting from the top of the stack).		(starting from the top of the stack).
	b. Use in its load-balancing function.		b. Use in its load-balancing function.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 40 ¶
	PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2		PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2
	--> +----+ +----+ +----+ +----+		--> +----+ +----+ +----+ +----+
	IP Pkt | IP | | IP | | IP | | IP |		IP Pkt | IP | | IP | | IP | | IP |
	+----+ +----+ +----+ +----+		+----+ +----+ +----+ +----+
	|1020| |1020| | 20 |		|1020| |1020| | 20 |
	+----+ +----+ +----+		+----+ +----+ +----+
	SPRING LDP		SPRING LDP
	In term of packet forwarding, by learning the mapping-server		In term of packet forwarding, by learning the mapping-server
	advertisement from PE5, PE1 imposes a label 1020 to an IP packet		advertisement from P5, PE1 imposes a label 1020 to an IP packet
	destinated to PE2. SPRING routers along the shortest path to PE2		destinated to PE2. SPRING routers along the shortest path to PE2
	will switch the traffic until it reaches P5 which will perform the		will switch the traffic until it reaches P5 which will perform the
	LSP stitching. P5 will swap the SPRING label 1020 to the LDP label		LSP stitching. P5 will swap the SPRING label 1020 to the LDP label
	20 advertised by the nexthop P6. P6 will then forward the packet		20 advertised by the nexthop P6. P6 will then forward the packet
	using the LDP label towards PE2.		using the LDP label towards PE2.
	PE1 cannot push an ELI/EL for the binding SID without knowing that		PE1 cannot push an ELI/EL for the binding SID without knowing that
	the tail-end of the LSP associated with the binding (PE2) is entropy		the tail-end of the LSP associated with the binding (PE2) is entropy
	label capable.		label capable.
	skipping to change at page 22, line 22 ¶		skipping to change at page 22, line 41 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-15 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), January 2018.		in progress), January 2018.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-11		data plane", draft-ietf-spring-segment-routing-mpls-13
	(work in progress), October 2017.		(work in progress), April 2018.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-isis-mpls-elc]		[I-D.ietf-isis-mpls-elc]
	Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.		Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
	Litkowski, "Signaling Entropy Label Capability and		Litkowski, "Signaling Entropy Label Capability and
	Readable Label-stack Depth Using IS-IS", draft-ietf-isis-		Readable Label-stack Depth Using IS-IS", draft-ietf-isis-
	mpls-elc-03 (work in progress), January 2018.		mpls-elc-03 (work in progress), January 2018.
	[I-D.ietf-ospf-mpls-elc]		[I-D.ietf-ospf-mpls-elc]
End of changes. 23 change blocks.
	43 lines changed or deleted		70 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/