draft-kini-mpls-spring-entropy-label-01.txt		draft-kini-mpls-spring-entropy-label-02.txt
	Network Working Group S. Kini, Ed.		Network Working Group S. Kini, Ed.
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational K. Kompella		Intended status: Informational K. Kompella
	Expires: April 2, 2015 Juniper		Expires: April 28, 2015 Juniper
	S. Sivabalan		S. Sivabalan
	Cisco		Cisco
	S. Litkowski		S. Litkowski
	Orange		Orange
	R. Shakir		R. Shakir
	B.T.		B.T.
	X. Xu		X. Xu
	Huawei		Huawei
	W. Hendrickx		W. Hendrickx
	Alcatel-Lucent		Alcatel-Lucent
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	September 29, 2014		October 25, 2014
	Entropy labels for source routed stacked tunnels		Entropy labels for source routed stacked tunnels
	draft-kini-mpls-spring-entropy-label-01		draft-kini-mpls-spring-entropy-label-02
	Abstract		Abstract
	Source routed tunnel stacking is a technique that can be leveraged to		Source routed tunnel stacking is a technique that can be leveraged to
	provide a method to steer a packet through a controlled set of		provide a method to steer a packet through a controlled set of
	segments. This can be applied to the Multi Protocol Label Switching		segments. This can be applied to the Multi Protocol Label Switching
	(MPLS) data plane. Entropy label (EL) is a technique used in MPLS to		(MPLS) data plane. Entropy label (EL) is a technique used in MPLS to
	improve load balancing. This document examines and describes how ELs		improve load balancing. This document examines and describes how ELs
	are to be applied to source routed stacked tunnels.		are to be applied to source routed stacked tunnels.
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 April 2, 2015.		This Internet-Draft will expire on April 28, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 26		skipping to change at page 2, line 26
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3		2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3
	3. Use-case for multipath load balancing in source stacked		3. Use-case for multipath load balancing in source stacked
	tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Recommended EL solution for SPRING . . . . . . . . . . . . . 4		4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5
	5. Options considered . . . . . . . . . . . . . . . . . . . . . 5		5. Options considered . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Single EL at the bottom of the stack of tunnels . . . . . 5		5.1. Single EL at the bottom of the stack of tunnels . . . . . 6
	5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 6		5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7
	5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 7		5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8
	5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 7		5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8
	5.4. ELs at readable label stack depths . . . . . . . . . . . 7		5.4. ELs at readable label stack depths . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The source routed stacked tunnels paradigm is leveraged by techniques		The source routed stacked tunnels paradigm is leveraged by techniques
	such as Segment Routing (SR) [I-D.filsfils-spring-segment-routing] to		such as Segment Routing (SR) [I-D.filsfils-spring-segment-routing] to
	steer a packet through a set of segments. This can be directly		steer a packet through a set of segments. This can be directly
	applied to the MPLS data plane, but it has implications on label		applied to the MPLS data plane, but it has implications on label
	stack depth.		stack depth.
	Clarifying statements on label stack depth have been provided in		Clarifying statements on label stack depth have been provided in
	skipping to change at page 3, line 18		skipping to change at page 3, line 18
	Entropy label (EL) [RFC6790] is a technique used in the MPLS data		Entropy label (EL) [RFC6790] is a technique used in the MPLS data
	plane to provide entropy for load balancing. When using LSP		plane to provide entropy for load balancing. When using LSP
	hierarchies there are implications on how [RFC6790] should be		hierarchies there are implications on how [RFC6790] should be
	applied. One such issue is addressed by		applied. One such issue is addressed by
	[I-D.ravisingh-mpls-el-for-seamless-mpls] but that is when different		[I-D.ravisingh-mpls-el-for-seamless-mpls] but that is when different
	levels of the hierarchy are created at different LSRs. The current		levels of the hierarchy are created at different LSRs. The current
	document addresses the case where the hierarchy is created at a		document addresses the case where the hierarchy is created at a
	single LSR as required by source stacked tunnels.		single LSR as required by source stacked tunnels.
	A use-case requiring load balancing with source stacked tunnels is		A use-case requiring load balancing with source stacked tunnels is
	given in Section 3. A recommended solution is described in		given in Section 3. A recommended solution is described in Section 4
	Section 4. Options that were considered to arrive at the recommended		keeping in consideration the limitations of implementations when
	solution are documented for historical purposes in Section 5.		applying [RFC6790] to deeper label stacks. Options that were
			considered to arrive at the recommended solution are documented for
			historical purposes in Section 5.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
			Although this document is not a protocol specification, the use of
			this language clarifies the instructions to protocol designers
			producing solutions that satisfy the requirements set out in this
			document.
	2. Abbreviations and Terminology		2. Abbreviations and Terminology
	EL - Entropy Label		EL - Entropy Label
	ELI - Entropy Label Identifier		ELI - Entropy Label Identifier
	ELC - Entropy Label Capability		ELC - Entropy Label Capability
	SR - Segment Routing		SR - Segment Routing
	ECMP - Equal Cost Multi Paths		ECMP - Equal Cost Multi Paths
	MPLS - Multiprotocol Label Switching		MPLS - Multiprotocol Label Switching
	SID - Segment Identifier		SID - Segment Identifier
			RLD - Readable Label Depth
			OAM - Operation, Administration and Maintenance
	3. Use-case for multipath load balancing in source stacked tunnels		3. Use-case for multipath load balancing in source stacked tunnels
	Source stacked tunnels have several use-cases, one of which is		Source stacked tunnels have several use-cases, one of which is
	service chaining [I-D.filsfils-spring-segment-routing-use-cases].		service chaining [I-D.filsfils-spring-segment-routing-use-cases].
	Consider the service-chaining network in Figure 1 that has MPLS as		Consider the service-chaining network in Figure 1 that has MPLS as
	the data plane. The requirement of the use-case is to create a LSP		the data plane. The requirement of the use-case is to create a LSP
	from source LSR S, apply the services S1, S2 and finally terminate		from source LSR S, apply the services S1, S2 and finally terminate
	the LSP at destination LSR D. Local load balancing is required		the LSP at destination LSR D. Local load balancing is required
	across the parallel links between P1 and S1. Local load balancing is		across the parallel links between P1 and S1. Local load balancing is
	also required between the ECMP paths from S1 to S2 i.e., between the		also required between the ECMP paths from S1 to S2 i.e., between the
	skipping to change at page 5, line 5		skipping to change at page 5, line 33
	Figure 1: Service chaining use-case		Figure 1: Service chaining use-case
	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 in its ability to read and process the
	label stack in order to do multipath load balancing. This limitation		label stack in order to do multipath load balancing. This limitation
	expressed in terms of the number of label stack entries that the LSR		expressed in terms of the number of label stack entries that the LSR
	can read and is henceforth referred to as the Readable Label Depth		can read is henceforth referred to as the Readable Label Depth (RLD)
	(RLD) capability. In order for the EL to occur within the RLD of		capability of that LSR. If an EL does not occur within the RLD of an
	LSRs along the path corresponding to a label stack, multiple <ELI,		LSR in the label stack of the MPLS packet that it receives, then it
	EL> pairs MAY be inserted. The recommendations for inserting <ELI,		would lead to poor load balancing at that LSR. The RLD of an LSR is
	EL> pairs are:		a characteristic of the forwarding plane of that LSR's implementation
			and determining it is outside the scope of this document.
	o <ELI, EL> pairs MUST be inserted below those labels that are		In order for the EL to occur within the RLD of LSRs along the path
	advertised with ELC.		corresponding to a label stack, multiple <ELI, EL> pairs MAY be
			inserted in the label stack as long as the labels below which they
			are inserted are entropy label capable. The LSR that inserts <ELI,
			EL> pairs MAY have limitations on the number of such pairs that it
			can insert and also the depth at which it can insert them. If due to
			any limitation, the inserted ELs are at positions such that an LSR
			along the path receives an MPLS packet without an EL in the label
			stack within that LSR's RLD, then the load balancing performed by
			that LSR would be poor. Special attention should be paid when a
			forwarding adjacency LSP (FA-LSP) [RFC4206] is used as a link along
			the path of a source stacked LSP, since the labels of the FA-LSP
			would additionally count towards the depth of the label stack when
			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 prefer to insert such pairs deeper in the stack.		can insert SHOULD insert such pairs deeper in the stack.
	o An LSR SHOULD try to insert an <ELI, EL> pair within the RLD of		o An LSR SHOULD try to insert an <ELI, EL> pair within the RLD of
	the maximum number of LSRs along the path as it can.		the maximum number of LSRs along the path as it can.
	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 to insert ELs is shown below. Implementations can
	choose any algorithm as long as it follows the above recommendations.		choose any algorithm as long as it follows the above recommendations.
	set current EL insertion point to the bottommost EL-capable location		Initialize the current EL insertion point to the
	while local-node can push more labels or top of stack has been reached {		bottommost label in the stack that is EL-capable
	insert an ELI+EL at current insertion point		while local-node can push more labels OR
	move insertion point up until current EL is out of RLD		top of stack has been reached {
	AND		insert an ELI+EL at current insertion point
	insertion point is EL-capable		move insertion point up until current EL is out of RLD
	set current insertion point to new insertion point		AND
	}		insertion point is EL-capable
			set current insertion point to new insertion point
			}
	Figure 2: Algorithm to insert <ELI, EL> pairs in a label stack		Figure 2: Algorithm to insert <ELI, EL> pairs in a label stack
	The RLD can be advertised via protocols and those extensions would be		The RLD can be advertised via protocols and those extensions would be
	described in a separate document.		described in a separate document.
			The recommendations above are not expected to bring any additional
			OAM considerations beyond those described in section 6 of [RFC6790].
			However, the OAM requirements and solutions for source stacked
			tunnels are still under discussion and future revisions of this
			document will address those if needed.
	5. Options considered		5. Options considered
	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) below the labels of all		source LSR S encodes the entropy label (EL) below the labels of all
	the stacked tunnels. In Figure 1 label stack at LSR S would look		the stacked tunnels. In Figure 1 label stack at LSR S would look
	like <SP1, SS1, S-SvcS1, SS2, S-SvcS2, SD, ELI, EL> <remaining packet		like <SP1, SS1, S-SvcS1, SS2, S-SvcS2, SD, ELI, EL> <remaining packet
	header>. Note that the notation in [RFC6790] is used to describe the		header>. Note that the notation in [RFC6790] is used to describe the
	label stack. An issue with this approach is that as the label stack		label stack. An issue with this approach is that as the label stack
	skipping to change at page 6, line 29		skipping to change at page 7, line 32
	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. For the		load balancing is required to direct traffic on that tunnel. For the
	same Figure 1 above, the source LSR S encoded label stack would be		same Figure 1 above, the source LSR S encoded label stack would be
	<SS1, ELI, EL1, S-SvcS1, SS2, ELI, EL2, SD> where all the ELs can		<SS1, ELI, EL1, S-SvcS1, SS2, ELI, EL2, S-SvcS2, SD> where all the
	have the same value. Accessing the EL at an intermediate LSR is		ELs can have the same value. Accessing the EL at an intermediate LSR
	independent of the depth of the label stack and hence independent of		is independent of the depth of the label stack and hence independent
	the specific use-case to which the stacked tunnels are applied. A		of the specific use-case to which the stacked tunnels are applied. A
	drawback is that the depth of the label stack grows significantly,		drawback is that the depth of the label stack grows significantly,
	almost 3 times as the number of labels in the label stack. The		almost 3 times as the number of labels in the label stack. The
	network design should ensure that source LSRs should have the		network design should ensure that source LSRs should have the
	capability to push such a deep label stack. Also, the bandwidth		capability to push such a deep label stack. Also, the bandwidth
	overhead and potential MTU issues of deep label stacks should be		overhead and potential MTU issues of deep label stacks should be
	accounted for in the network design.		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
	skipping to change at page 7, line 19		skipping to change at page 8, line 21
	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
	EL even though they are exposed as the top labels since the		EL even though they are exposed as the top labels since the
	terminating LSR of that segment would re-use the EL for the next		terminating LSR of that segment would re-use the EL for the next
	segment.		segment.
	For the same Figure 1 above, the source LSR S encoded label stack		For the same Figure 1 above, the source LSR S encoded label stack
	would be <SS11, ELI, EL, S-SvcS1, SS2, SD>. At P1 the outgoing label		would be <SS11, ELI, EL, S-SvcS1, SS2, S-SvcS2, SD>. At P1 the
	stack would be <SS1, ELI, EL, S-SvcS1, SS2, SD> after it has load		outgoing label stack would be <SS1, ELI, EL, S-SvcS1, SS2, S-SvcS2,
	balanced to one of the links L1 or L2. At S1 the outgoing label		SD> after it has load balanced to one of the links L1 or L2. At S1
	stack would be <SS2, ELI, EL, SD>. At P2 the outgoing label stack		the outgoing label stack would be <SS2, S-SvS2, ELI, EL, SD>. At P2
	would be <SS2, ELI, EL, SD> and it would load balance to one of the		the outgoing label stack would be <SS2, ELI, EL, S-SvcS2, SD> and it
	nexthop LSRs P3 or P4. Accessing the EL at an intermediate LSR (e.g.		would load balance to one of the nexthop LSRs P3 or P4. Accessing
	P3) is independent of the depth of the label stack and hence		the EL at an intermediate LSR (e.g. P3) is independent of the depth
	independent of the specific use-case to which the stacked tunnels are		of the label stack and hence independent of the specific use-case to
	applied.		which the stacked tunnels are applied.
	This option was discounted due to the significant change in label		This option was discounted due to the significant change in label
	swap operations that would be required for existing hardware.		swap 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
	skipping to change at page 8, line 32		skipping to change at page 9, line 35
	The authors would like to thank John Drake and Loa Andersson for		The authors would like to thank John Drake and Loa Andersson for
	their comments.		their comments.
	7. IANA Considerations		7. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	8. Security Considerations		8. Security Considerations
			This document does not introduce any new security considerations
			beyond those already listed in [RFC6790].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.filsfils-spring-segment-routing]		[I-D.filsfils-spring-segment-routing]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
	Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,		Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
	"Segment Routing Architecture", draft-filsfils-spring-		"Segment Routing Architecture", draft-filsfils-spring-
	segment-routing-04 (work in progress), July 2014.		segment-routing-04 (work in progress), July 2014.
	[I-D.filsfils-spring-segment-routing-use-cases]		[I-D.filsfils-spring-segment-routing-use-cases]
	Filsfils, C., Francois, P., Previdi, S., Decraene, B.,		Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.		Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
	Crabbe, "Segment Routing Use Cases", draft-filsfils-		Crabbe, "Segment Routing Use Cases", draft-filsfils-
	spring-segment-routing-use-cases-00 (work in progress),		spring-segment-routing-use-cases-01 (work in progress),
	March 2014.		October 2014.
	[I-D.gredler-spring-mpls]		[I-D.gredler-spring-mpls]
	Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu,		Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu,
	"Supporting Source/Explicitly Routed Tunnels via Stacked		"Supporting Source/Explicitly Routed Tunnels via Stacked
	LSPs", draft-gredler-spring-mpls-06 (work in progress),		LSPs", draft-gredler-spring-mpls-06 (work in progress),
	May 2014.		May 2014.
	[I-D.ravisingh-mpls-el-for-seamless-mpls]		[I-D.ravisingh-mpls-el-for-seamless-mpls]
	Singh, R., Shen, Y., and J. Drake, "Entropy label for		Singh, R., Shen, Y., and J. Drake, "Entropy label for
	seamless MPLS", draft-ravisingh-mpls-el-for-seamless-		seamless MPLS", draft-ravisingh-mpls-el-for-seamless-
	mpls-02 (work in progress), July 2014.		mpls-02 (work in progress), July 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
			Hierarchy with Generalized Multi-Protocol Label Switching
			(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
	[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, November 2012.		RFC 6790, November 2012.
	[RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A., and		[RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A., and
	C. Pignataro, "MPLS Forwarding Compliance and Performance		C. Pignataro, "MPLS Forwarding Compliance and Performance
	Requirements", RFC 7325, August 2014.		Requirements", RFC 7325, August 2014.
	9.2. Informative References		9.2. Informative References
End of changes. 18 change blocks.
	53 lines changed or deleted		92 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/