< draft-ietf-mpls-spring-entropy-label-03.txt		draft-ietf-mpls-spring-entropy-label-04.txt >
	Network Working Group S. Kini, Ed.		Network Working Group S. Kini, Ed.
	Internet-Draft		Internet-Draft
	Intended status: Standards Track K. Kompella		Intended status: Informational K. Kompella
	Expires: October 9, 2016 Juniper		Expires: January 9, 2017 Juniper
	S. Sivabalan		S. Sivabalan
	Cisco		Cisco
	S. Litkowski		S. Litkowski
	Orange		Orange
	R. Shakir		R. Shakir
	J. Tantsura
	April 7, 2016		J. Tantsura
			July 8, 2016
	Entropy labels for source routed tunnels with label stacks		Entropy labels for source routed tunnels with label stacks
	draft-ietf-mpls-spring-entropy-label-03		draft-ietf-mpls-spring-entropy-label-04
	Abstract		Abstract
	Source routed tunnels with label stacking is a technique that can be		Source routed tunnels with label stacking is a technique that can be
	leveraged to provide a method to steer a packet through a controlled		leveraged to provide a method to steer a packet through a controlled
	set of segments. This can be applied to the Multi Protocol Label		set of segments. This 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 source routed tunnels with		describes how ELs are to be applied to source routed tunnels with
	label stacks.		label stacks.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 9, 2016.		This Internet-Draft will expire on January 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5		4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5
	5. Options considered . . . . . . . . . . . . . . . . . . . . . 6		5. Options considered . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Single EL at the bottom of the stack of tunnels . . . . . 6		5.1. Single EL at the bottom of the stack of tunnels . . . . . 6
	5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7		5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7
	5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8		5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8
	5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8		5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8
	5.4. ELs at readable label stack depths . . . . . . . . . . . 8		5.4. ELs at readable label stack depths . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The source routed tunnels with label stacking paradigm is leveraged		The source routed tunnels with label stacking paradigm is leveraged
	by techniques such as Segment Routing (SR)		by techniques such as Segment Routing (SR)
	[I-D.ietf-spring-segment-routing] to steer a packet through a set of		[I-D.ietf-spring-segment-routing] to steer a packet through a set of
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	multipath decisions. All other transit LSRs in the figure can read		multipath decisions. All other transit LSRs in the figure can read
	deep label stacks and the LSR S can insert as many <ELI, EL> pairs as		deep label stacks and the LSR S can insert as many <ELI, EL> pairs as
	needed. The LSR S requires data to be sent to LSR D along a traffic-		needed. The LSR S requires data to be sent to LSR D along a traffic-
	engineered path that goes over the link L1. Good load balancing is		engineered path that goes over the link L1. Good load balancing is
	also required across equal cost paths (including parallel links). To		also required across equal cost paths (including parallel links). To
	engineer traffic along a path that takes link L1, the label stack		engineer traffic along a path that takes link L1, the label stack
	that LSR S creates consists of a label to the node SID of LSR P3,		that LSR S creates consists of a label to the node SID of LSR P3,
	stacked over the label for the adjacency SID of link L1 and that in		stacked over the label for the adjacency SID of link L1 and that in
	turn is stacked over the label to the node SID of LSR D. For		turn is stacked over the label to the node SID of LSR D. For
	simplicity lets assume that all LSRs use the same label space for		simplicity lets assume that all LSRs use the same label space for
	source routed label stacks. Lets L_N-P denote the label to be used		source routed label stacks. Let L_N-Px denote the label to be used
	to reach the node SID of LSR P. Let L_A-Ln denote the label used for		to reach the node SID of LSR Px. Let L_A-Ln denote the label used
	the adjacency SID for link Ln. The LSR S must use the label stack		for the adjacency SID for link Ln. The LSR S must use the label
	<L_N-P3, L_A-L1, L_N-D> for traffic-engineering. However to achieve		stack <L_N-P3, L_A-L1, L_N-D> for traffic-engineering. However to
	good load balancing over the equal cost paths P2-P4-D, P2-P5-D and		achieve good load balancing over the equal cost paths P2-P4-D,
	the parallel links L3, L4, a mechanism such as Entropy labels		P2-P5-D and the parallel links L3, L4, a mechanism such as Entropy
	[RFC6790] should be adapted for source routed label stacks. Multiple		labels [RFC6790] should be adapted for source routed label stacks.
	ways to apply entropy labels were considered and are documented in		Multiple ways to apply entropy labels were considered and are
	Section 5 along with their tradeoffs. A recommended solution is		documented in Section 5 along with their tradeoffs. A recommended
	described in Section 4.		solution is described in Section 4.
	4. Recommended EL solution for SPRING		4. Recommended EL solution for SPRING
	The solution described in this section follows [RFC6790].		The solution described in this section follows [RFC6790].
	An LSR may have a limitation in its ability to read and process the		An LSR may have a limitation on the depth of the label stack that it
	label stack in order to do multipath load balancing. This limitation		can read and process in order to do multipath load balancing. This
	expressed in terms of the number of label stack entries that the LSR		limitation expressed in terms of the number of label stack entries
	can read is henceforth referred to as the Readable Label Depth (RLD)		that the LSR can read is defined as the Readable Label Depth (RLD)
	capability of that LSR. If an EL does not occur within the RLD of an		capability of that LSR. If an EL does not occur within the RLD of an
	LSR in the label stack of the MPLS packet that it receives, then it		LSR in the label stack of the MPLS packet that it receives, then it
	would lead to poor load balancing at that LSR. The RLD of an LSR is		would lead to poor load balancing at that LSR. Hence an ELI, EL pair
	a characteristic of the forwarding plane of that LSR's implementation		MUST be within the RLD of the LSR in order for the LSR to use the EL
	and determining it is outside the scope of this document.		during load balancing. The RLD of an LSR is a characteristic of the
			forwarding plane of that LSR's implementation and determining it is
			outside the scope of this document.
	In order for the EL to occur within the RLD of LSRs along the path		In order for the EL to occur within the RLD of LSRs along the path
	corresponding to a label stack, multiple <ELI, EL> pairs MAY be		corresponding to a label stack, multiple <ELI, EL> pairs MAY be
	inserted in the label stack as long as the tunnel's label below which		inserted in the label stack as long as the tunnel's label below which
	they are inserted are advertised with entropy label capability		they are inserted are advertised with entropy label capability
	enabled. The LSR that inserts <ELI, EL> pairs MAY have limitations		enabled. The ELs among multiple <ELI, EL> pairs inserted in the
	on the number of such pairs that it can insert and also the depth at		stack may be same or different. The LSR that inserts <ELI, EL> pairs
	which it can insert them. If due to any limitation, the inserted ELs		MAY have limitations on the number of such pairs that it can insert
	are at positions such that an LSR along the path receives an MPLS		and also the depth at which it can insert them. If due to any
	packet without an EL in the label stack within that LSR's RLD, then		limitation, the inserted ELs are at positions such that an LSR along
	the load balancing performed by that LSR would be poor. Special		the path receives an MPLS packet without an EL in the label stack
	attention should be paid when a forwarding adjacency LSP (FA-LSP)		within that LSR's RLD, then the load balancing performed by that LSR
	[RFC4206] is used as a link along the path of a source routed LSP's		would be poor. Special attention should be paid when a forwarding
	label stack, since the labels of the FA-LSP would additionally count		adjacency LSP (FA-LSP) [RFC4206] is used as a link along the path of
	towards the depth of the label stack when calculating the appropriate		a source routed LSP's label stack, since the labels of the FA-LSP
	positions to insert the ELs. The recommendations for inserting <ELI,		would additionally count towards the depth of the label stack when
	EL> pairs are:		calculating the appropriate positions to insert the ELs. The
			recommendations for inserting <ELI, EL> pairs are:
	o An LSR that is limited in the number of <ELI, EL> pairs that it		o An LSR that is limited in the number of <ELI, EL> pairs that it
	can insert SHOULD insert such pairs deeper in the stack.		can insert SHOULD insert such pairs deeper in the stack.
	o An LSR SHOULD try to insert <ELI, EL> pairs at positions so that		o An LSR SHOULD try to insert <ELI, EL> pairs at positions so that
	for the maximum number of transit LSRs, the EL occurs within the		for the maximum number of transit LSRs, the EL occurs within the
	RLD of the incoming packet to that LSR.		RLD of the incoming packet to that LSR.
	o An LSR SHOULD try to insert the minimum number of such pairs while		o An LSR SHOULD try to insert the minimum number of such pairs while
	trying to satisfy the above criteria.		trying to satisfy the above criteria.
	A sample algorithm to insert ELs is shown below. Implementations can		A sample algorithm that follows the above recommendations to insert
	choose any algorithm as long as it follows the above recommendations.		ELs is shown below. For node SIDs, the minimum value of RLDs of LSRs
			on that node segment should be used.
	Initialize the current EL insertion point to the		Initialize the current EL insertion point to the
	bottommost label in the stack that is EL-capable		bottommost label in the stack that is EL-capable
	while (local-node can push more <ELI,EL> pairs OR		while (local-node can push more <ELI,EL> pairs OR
	insertion point is not above label stack) {		insertion point is not above label stack) {
	insert an <ELI,EL> pair below current insertion point		insert an <ELI,EL> pair below current insertion point
	move new insertion point up from current insertion point until		move new insertion point up from current insertion point until
	((last inserted EL is below the RLD) AND (RLD > 2)		((last inserted EL is below the RLD) AND (RLD > 2)
	AND		AND
	(new insertion point is EL-capable))		(new insertion point is EL-capable))
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	When this algorithm is applied to the example described in Section 3		When this algorithm is applied to the example described in Section 3
	it will result in ELs being inserted in two positions, one below the		it will result in ELs being inserted in two positions, one below the
	label L_N-D and another below L_N-P3. Thus the resulting label stack		label L_N-D and another below L_N-P3. Thus the resulting label stack
	would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL>		would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL>
	The RLD can be advertised via protocols and those extensions are		The RLD can be advertised via protocols and those extensions are
	described in separate documents [I-D.xu-isis-mpls-elc] and		described in separate documents [I-D.xu-isis-mpls-elc] and
	[I-D.xu-ospf-mpls-elc].		[I-D.xu-ospf-mpls-elc].
			It should be noted that the above algorithm is a sample and other
			algorithms that optimize for other criteria and provide additional
			tuning parameters to give operators the control of the optimization
			criteria may be developed.
	The recommendations above are not expected to bring any additional		The recommendations above are not expected to bring any additional
	OAM considerations beyond those described in section 6 of [RFC6790].		OAM considerations beyond those described in section 6 of [RFC6790].
	However, the OAM requirements and solutions for source routed tunnels		However, the OAM requirements and solutions for source routed tunnels
	formed by label stacking are still under discussion and future		formed by label stacking are still under discussion and future
	revisions of this document will address those if needed.		revisions of this document will address those if needed.
	5. Options considered		5. Options considered
	Different options that were considered to arrive at the recommended		Different options that were considered to arrive at the recommended
	solution are documented in this section.		solution are documented in this section.
	5.1. Single EL at the bottom of the stack of tunnels		5.1. Single EL at the bottom of the stack of tunnels
	In this option a single EL is used for the entire label stack. The		In this option a single EL is used for the entire label stack. The
	source LSR S encodes the entropy label (EL) at the bottom of the		source LSR S encodes the entropy label (EL) at the bottom of the
	label stack. In the example described in Section 3 it will result in		label stack. In the example described in Section 3, it will result
	the label stack at LSR S to look like <L_N-P3, L_A-L1, L_N-D, ELI,		in the label stack at LSR S to look like <L_N-P3, L_A-L1, L_N-D, ELI,
	EL> <remaining packet header>. Note that the notation in [RFC6790]		EL> <remaining packet header>. Note that the notation in [RFC6790]
	is used to describe the label stack. An issue with this approach is		is used to describe the label stack. An issue with this approach is
	that as the label stack grows due an increase in the number of SIDs,		that as the label stack grows due an increase in the number of SIDs,
	the EL goes correspondingly deeper in the label stack. Hence transit		the EL goes correspondingly deeper in the label stack. Hence transit
	LSRs have to access a larger number of bytes in the packet header		LSRs have to access a larger number of bytes in the packet header
	when making forwarding decisions. In the example described in		when making forwarding decisions. In the example described in
	Section 3 the LSR P1 would poorly load-balance traffic on the		Section 3, the LSR P1 would poorly load-balance traffic on the
	parallel links L3, L4 since the EL is below the RLD of the packet		parallel links L3, L4 since the EL is below the RLD of the packet
	received by P1. A load balanced network design using this approach		received by P1. A load balanced network design using this approach
	must ensure that all intermediate LSRs have the capability to		must ensure that all intermediate LSRs have the capability to
	traverse the maximum label stack depth as required for that		traverse the maximum label stack depth as required for that
	application that uses source routed stacking.		application that uses source routed stacking.
	In the case where the hardware is capable of pushing a single <ELI,		In the case where the hardware is capable of pushing a single <ELI,
	EL> pair at any depth, this option is the same as the recommended		EL> pair at any depth, this option is the same as the recommended
	solution in Section 4.		solution in Section 4.
	This option was discounted since there exist a number of hardware		This option was rejected since there exist a number of hardware
	implementations which have a low maximum readable label depth.		implementations which have a low maximum readable label depth.
	Choosing this option can lead to a loss of load-balancing using EL in		Choosing this option can lead to a loss of load-balancing using EL in
	a significant part of the network but that is a critical requirement		a significant part of the network but that is a critical requirement
	in a service provider network.		in a service provider network.
	5.2. An EL per tunnel in the stack		5.2. An EL per tunnel in the stack
	In this option each tunnel in the stack can be given its own EL. The		In this option each tunnel in the stack can be given its own EL. The
	source LSR pushes an <ELI, EL> before pushing a tunnel label when		source LSR pushes an <ELI, EL> before pushing a tunnel label when
	load balancing is required to direct traffic on that tunnel. In the		load balancing is required to direct traffic on that tunnel. In the
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 46 ¶
	the label stack. The network design should ensure that source LSRs		the label stack. The network design should ensure that source LSRs
	should have the capability to push such a deep label stack. Also,		should have the capability to push such a deep label stack. Also,
	the bandwidth overhead and potential MTU issues of deep label stacks		the bandwidth overhead and potential MTU issues of deep label stacks
	should be accounted for in the network design.		should be accounted for in the network design.
	In the case where the RLD is the minimum value (3) for all LSRs, all		In the case where the RLD is the minimum value (3) for all LSRs, all
	LSRs are EL capable and the LSR that is inserting <ELI, EL> pairs has		LSRs are EL capable and the LSR that is inserting <ELI, EL> pairs has
	no limit on how many it can insert then this option is the same as		no limit on how many it can insert then this option is the same as
	the recommended solution in Section 4.		the recommended solution in Section 4.
	This option was discounted due to the existence of hardware		This option was rejected due to the existence of hardware
	implementations that can push a limited number of labels on the label		implementations that can push a limited number of labels on the label
	stack. Choosing this option would result in a hardware requirement		stack. Choosing this option would result in a hardware requirement
	to push two additional labels per tunnel label. Hence it would		to push two additional labels per tunnel label. Hence it would
	restrict the number of tunnels that can form a LSP and constrain the		restrict the number of tunnels that can be stacked in a LSP and hence
	types of LSPs that can be created. This was considered unacceptable.		constrain the types of LSPs that can be created. This was considered
			unacceptable.
	5.3. A re-usable EL for a stack of tunnels		5.3. A re-usable EL for a stack of tunnels
	In this option an LSR that terminates a tunnel re-uses the EL of the		In this option an LSR that terminates a tunnel re-uses the EL of the
	terminated tunnel for the next inner tunnel. It does this by storing		terminated tunnel for the next inner tunnel. It does this by storing
	the EL from the outer tunnel when that tunnel is terminated and re-		the EL from the outer tunnel when that tunnel is terminated and re-
	inserting it below the next inner tunnel label during the label swap		inserting it below the next inner tunnel label during the label swap
	operation. The LSR that stacks tunnels should insert an EL below the		operation. The LSR that stacks tunnels should insert an EL below the
	outermost tunnel. It should not insert ELs for any inner tunnels.		outermost tunnel. It should not insert ELs for any inner tunnels.
	Also, the penultimate hop LSR of a segment must not pop the ELI and		Also, the penultimate hop LSR of a segment must not pop the ELI and
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 30 ¶
	In Section 3 above, the source LSR S encoded label stack would be		In Section 3 above, the source LSR S encoded label stack would be
	<L_N-P3, ELI, EL, L_A-L1, L_N-D>. At P1 the outgoing label stack		<L_N-P3, ELI, EL, L_A-L1, L_N-D>. At P1 the outgoing label stack
	would be <L_N-P3, ELI, EL, L_A-L1, L_N-D> after it has load balanced		would be <L_N-P3, ELI, EL, L_A-L1, L_N-D> after it has load balanced
	to one of the links L3 or L4. At P3 the outgoing label stack would		to one of the links L3 or L4. At P3 the outgoing label stack would
	be <L_N-D, ELI, EL>. At P2 the outgoing label stack would be <L_N-D,		be <L_N-D, ELI, EL>. At P2 the outgoing label stack would be <L_N-D,
	ELI, EL> and it would load balance to one of the nexthop LSRs P4 or		ELI, EL> and it would load balance to one of the nexthop LSRs P4 or
	P5. Accessing the EL at an intermediate LSR (e.g. P1) is		P5. Accessing the EL at an intermediate LSR (e.g. P1) is
	independent of the depth of the label stack and hence independent of		independent of the depth of the label stack and hence independent of
	the specific use-case to which the label stack is applied.		the specific use-case to which the label stack is applied.
	This option was discounted due to the significant change in label		This option was rejected due to the significant change in label swap
	swap operations that would be required for existing hardware.		operations that would be required for existing hardware.
	5.3.1. EL at top of stack		5.3.1. EL at top of stack
	A slight variant of the re-usable EL option is to keep the EL at the		A slight variant of the re-usable EL option is to keep the EL at the
	top of the stack rather than below the tunnel label. In this case		top of the stack rather than below the tunnel label. In this case
	each LSR that is not terminating a segment should continue to keep		each LSR that is not terminating a segment should continue to keep
	the received EL at the top of the stack when forwarding the packet		the received EL at the top of the stack when forwarding the packet
	along the segment. An LSR that terminates a segment should use the		along the segment. An LSR that terminates a segment should use the
	EL from the terminated segment at the top of the stack when		EL from the terminated segment at the top of the stack when
	forwarding onto the next segment.		forwarding onto the next segment.
	This option was discounted due to the significant change in label		This option was rejected due to the significant change in label swap
	swap operations that would be required for existing hardware.		operations that would be required for existing hardware.
	5.4. ELs at readable label stack depths		5.4. ELs at readable label stack depths
	In this option the source LSR inserts ELs for tunnels in the label		In this option the source LSR inserts ELs for tunnels in the label
	stack at depths such that each LSR along the path that must load		stack at depths such that each LSR along the path that must load
	balance is able to access at least one EL. Note that the source LSR		balance is able to access at least one EL. Note that the source LSR
	may have to insert multiple ELs in the label stack at different		may have to insert multiple ELs in the label stack at different
	depths for this to work since intermediate LSRs may have differing		depths for this to work since intermediate LSRs may have differing
	capabilities in accessing the depth of a label stack. The label		capabilities in accessing the depth of a label stack. The label
	stack depth access value of intermediate LSRs must be known to create		stack depth access value of intermediate LSRs must be known to create
	such a label stack. How this value is determined is outside the		such a label stack. How this value is determined is outside the
	scope of this document. This value can be advertised using a		scope of this document. This value can be advertised using a
	protocol such as an IGP. For the same Section 3 above, if LSR P1		protocol such as an IGP.
			Applying this method to the example in Section 3 above, if LSR P1
	needs to have the EL within a depth of 4, then the source LSR S		needs to have the EL within a depth of 4, then the source LSR S
	encoded label stack would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI,		encoded label stack would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI,
	EL> where all the ELs would typically have the same value.		EL> where all the ELs would typically have the same value.
	In the case where the RLD has different values along the path and the		In the case where the RLD has different values along the path and the
	LSR that is inserting <ELI, EL> pairs has no limit on how many pairs		LSR that is inserting <ELI, EL> pairs has no limit on how many pairs
	it can insert, and it knows the appropriate positions in the stack		it can insert, and it knows the appropriate positions in the stack
	where they should be inserted, then this option is the same as the		where they should be inserted, then this option is the same as the
	recommended solution in Section 4.		recommended solution in Section 4.
	A variant of this solution was selected which balances the number of		Note that a refinement of this solution which balances the number of
	labels that need to be pushed against the requirement for entropy.		pushed labels against the desired entropy is the solution described
			in Section 4.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank John Drake, Loa Andersson, Curtis		The authors would like to thank John Drake, Loa Andersson, Curtis
	Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for		Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for
	their review comments and suggestions.		their review comments and suggestions.
	7. Contributors		7. Contributors
	Xiaohu Xu		Xiaohu Xu
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 29 ¶
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<http://www.rfc-editor.org/info/rfc6790>.		<http://www.rfc-editor.org/info/rfc6790>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and R. Shakir, "Segment Routing Architecture", draft-ietf-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-07 (work in progress), December		spring-segment-routing-09 (work in progress), July 2016.
	2015.
	[I-D.xu-isis-mpls-elc]		[I-D.xu-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 Using IS-		Litkowski, "Signaling Entropy Label Capability Using IS-
	IS", draft-xu-isis-mpls-elc-02 (work in progress), April		IS", draft-xu-isis-mpls-elc-02 (work in progress), April
	2015.		2015.
	[I-D.xu-ospf-mpls-elc]		[I-D.xu-ospf-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 Using		Litkowski, "Signaling Entropy Label Capability Using
End of changes. 22 change blocks.
	54 lines changed or deleted		66 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/