Diff: draft-ietf-mpls-entropy-label-01.txt - draft-ietf-mpls-entropy-label-02.txt

	< draft-ietf-mpls-entropy-label-01.txt	draft-ietf-mpls-entropy-label-02.txt >

	Network Working Group K. Kompella	Network Working Group K. Kompella
	Internet-Draft J. Drake	Internet-Draft J. Drake
	Updates: 3031 (if approved) Juniper Networks	Updates: 3031 (if approved) Juniper Networks
	Intended status: Standards Track S. Amante	Intended status: Standards Track S. Amante

	Expires: May 3, 2012 Level 3 Communications, LLC	Expires: November 8, 2012 Level 3 Communications, LLC
	W. Henderickx	W. Henderickx
	Alcatel-Lucent	Alcatel-Lucent
	L. Yong	L. Yong
	Huawei USA	Huawei USA

	October 31, 2011	May 7, 2012

	The Use of Entropy Labels in MPLS Forwarding	The Use of Entropy Labels in MPLS Forwarding

	draft-ietf-mpls-entropy-label-01	draft-ietf-mpls-entropy-label-02

	Abstract	Abstract

	Load balancing is a powerful tool for engineering traffic across a	Load balancing is a powerful tool for engineering traffic across a
	network. This memo suggests ways of improving load balancing across	network. This memo suggests ways of improving load balancing across
	MPLS networks using the concept of "entropy labels". It defines the	MPLS networks using the concept of "entropy labels". It defines the
	concept, describes why entropy labels are useful, enumerates	concept, describes why entropy labels are useful, enumerates
	properties of entropy labels that allow maximal benefit, and shows	properties of entropy labels that allow maximal benefit, and shows
	how they can be signaled and used for various applications.	how they can be signaled and used for various applications.


	skipping to change at page 1, line 41 ¶	skipping to change at page 1, line 41 ¶
	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 May 3, 2012.	This Internet-Draft will expire on November 8, 2012.

	Copyright Notice	Copyright Notice


	Copyright (c) 2011 IETF Trust and the persons identified as the	Copyright (c) 2012 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
	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. Conventions used . . . . . . . . . . . . . . . . . . . . . 4	1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 4

	1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5	1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6	2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 7	3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 8
	4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 8	4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 9
	4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 8	4.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 9	4.2. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9	4.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 10	4.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 11
	5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 10	5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 11
	5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 11	5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 12
	5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 12	5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 12
		5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 13
	6. Operations, Administration, and Maintenance (OAM) and	6. Operations, Administration, and Maintenance (OAM) and
	Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13	Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14	7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14
	8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15	8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15

	9. Entropy Labels and Applications . . . . . . . . . . . . . . . 15	9. Entropy Labels in Various Scenarios . . . . . . . . . . . . . 15
	9.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 15	9.1. LDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.2. LDP Pseudowires . . . . . . . . . . . . . . . . . . . . . 17	9.2. LDP Over RSVP-TE . . . . . . . . . . . . . . . . . . . . . 18
	9.3. BGP Applications . . . . . . . . . . . . . . . . . . . . . 18	9.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 18
	9.3.1. Inter-AS BGP VPNs . . . . . . . . . . . . . . . . . . 19	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9.4. Multiple Applications . . . . . . . . . . . . . . . . . . 20	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 21	11.1. Reserved Label for ELI . . . . . . . . . . . . . . . . . . 19
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22	11.2. LDP Entropy Label Capability TLV . . . . . . . . . . . . . 19
	11.1. LDP Entropy Label TLV . . . . . . . . . . . . . . . . . . 22	11.3. BGP Entropy Label Capability Attribute . . . . . . . . . . 19
	11.2. BGP Entropy Label Attribute . . . . . . . . . . . . . . . 22	11.4. RSVP-TE Entropy Label Capability flag . . . . . . . . . . 19
	11.3. Attribute Flags for LSP_Attributes Object . . . . . . . . 22	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	11.4. Attributes TLV for LSP_Attributes Object . . . . . . . . . 22	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23	13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23	13.2. Informative References . . . . . . . . . . . . . . . . . . 20
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 23	Appendix A. Applicability of LDP Entropy Label Capability TLV . . 21
	13.2. Informative References . . . . . . . . . . . . . . . . . . 23	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix A. Applicability of LDP Entropy Label sub-TLV . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

	1. Introduction	1. Introduction

	Load balancing, or multi-pathing, is an attempt to balance traffic	Load balancing, or multi-pathing, is an attempt to balance traffic
	across a network by allowing the traffic to use multiple paths. Load	across a network by allowing the traffic to use multiple paths. Load
	balancing has several benefits: it eases capacity planning; it can	balancing has several benefits: it eases capacity planning; it can
	help absorb traffic surges by spreading them across multiple paths;	help absorb traffic surges by spreading them across multiple paths;
	it allows better resilience by offering alternate paths in the event	it allows better resilience by offering alternate paths in the event
	of a link or node failure.	of a link or node failure.


	skipping to change at page 4, line 15 ¶	skipping to change at page 4, line 15 ¶
	One way to eliminate the need for this deep inspection is to have the	One way to eliminate the need for this deep inspection is to have the
	ingress LSR of an MPLS Label Switched Path extract the appropriate	ingress LSR of an MPLS Label Switched Path extract the appropriate
	keys from a given packet, input them to its load balancing function,	keys from a given packet, input them to its load balancing function,
	and place the result in an additional label, termed the 'entropy	and place the result in an additional label, termed the 'entropy
	label', as part of the MPLS label stack it pushes onto that packet.	label', as part of the MPLS label stack it pushes onto that packet.

	The packet's MPLS entire label stack can then be used by transit LSRs	The packet's MPLS entire label stack can then be used by transit LSRs
	to perform load balancing, as the entropy label introduces the right	to perform load balancing, as the entropy label introduces the right
	level of "entropy" into the label stack.	level of "entropy" into the label stack.


	There are four key reasons why this is beneficial:	There are five key reasons why this is beneficial:

	1. at the ingress LSR, MPLS encapsulation hasn't yet occurred, so	1. at the ingress LSR, MPLS encapsulation hasn't yet occurred, so
	deep inspection is not necessary;	deep inspection is not necessary;

	2. the ingress LSR has more context and information about incoming	2. the ingress LSR has more context and information about incoming
	packets than transit LSRs;	packets than transit LSRs;

	3. ingress LSRs usually operate at lower bandwidths than transit	3. ingress LSRs usually operate at lower bandwidths than transit

	LSRs, allowing them to do more work per packet, and	LSRs, allowing them to do more work per packet;

	4. transit LSRs do not need to perform deep packet inspection and	4. transit LSRs do not need to perform deep packet inspection and
	can load balance effectively using only a packet's MPLS label	can load balance effectively using only a packet's MPLS label

	stack.	stack; and

		5. transit LSRs, not having the full context that an ingress LSR
		does, have the hard choice between potentially misinterpreting
		fields in a packet as valid keys for load balancing (causing
		packet ordering problems) or adopting a conservative approach
		(giving rise to sub-optimal load balancing). Entropy labels
		relieves them of making this choice.

	This memo describes why entropy labels are needed and defines the	This memo describes why entropy labels are needed and defines the
	properties of entropy labels; in particular how they are generated	properties of entropy labels; in particular how they are generated
	and received, and the expected behavior of transit LSRs. Finally, it	and received, and the expected behavior of transit LSRs. Finally, it
	describes in general how signaling works and what needs to be	describes in general how signaling works and what needs to be
	signaled, as well as specifics for the signaling of entropy labels	signaled, as well as specifics for the signaling of entropy labels

	for LDP ([RFC5036]), BGP ([RFC3107], [RFC4364]), and RSVP-TE	for LDP ([RFC5036]), BGP ([RFC3107]), and RSVP-TE ([RFC3209]).
	([RFC3209]).

	1.1. Conventions used	1.1. Conventions used

	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 [RFC2119].	document are to be interpreted as described in [RFC2119].

	The following acronyms are used:	The following acronyms are used:


	LSR: Label Switching Router;	BoS: Bottom of Stack


	LER: Label Edge Router;	CE: Customer Edge device


	PE: Provider Edge router;	ECMP: Equal Cost Multi-Path
	CE: Customer Edge device; and


	FEC: Forwarding Equivalence Class.	EL: Entropy Label

		ELC: Entropy Label Capability

		ELI: Entropy Label Indicator

		FEC: Forwarding Equivalence Class

		LAG: Link Aggregation Group

		LER: Label Edge Router

		LSR: Label Switching Router

		PE: Provider Edge Router

		PHP: Penultimate Hop Popping

		TC: Traffic Class

		TTL: Time-to-Live

		UHP: Ultimate Hop Popping

		VPLS: Virtual Private LAN (Local Area Network) Service

		VPN: Virtual Private Network

	The term ingress (or egress) LSR is used interchangeably with ingress	The term ingress (or egress) LSR is used interchangeably with ingress
	(or egress) LER. The term application throughout the text refers to	(or egress) LER. The term application throughout the text refers to
	an MPLS application (such as a VPN or VPLS).	an MPLS application (such as a VPN or VPLS).

	A label stack (say of three labels) is denoted by <L1, L2, L3>, where	A label stack (say of three labels) is denoted by <L1, L2, L3>, where
	L1 is the "outermost" label and L3 the innermost (closest to the	L1 is the "outermost" label and L3 the innermost (closest to the
	payload). Packet flows are depicted left to right, and signaling is	payload). Packet flows are depicted left to right, and signaling is
	shown right to left (unless otherwise indicated).	shown right to left (unless otherwise indicated).


	skipping to change at page 6, line 37 ¶	skipping to change at page 7, line 20 ¶
	particular, there will be no reason to duplicate an ingress LSR's	particular, there will be no reason to duplicate an ingress LSR's
	complex packet/payload parsing functionality in a transit LSR. This	complex packet/payload parsing functionality in a transit LSR. This
	will result in less complex transit LSRs, enabling them to more	will result in less complex transit LSRs, enabling them to more
	easily scale to higher forwarding rates, larger port density, lower	easily scale to higher forwarding rates, larger port density, lower
	power consumption, etc. The idea in this memo is to capture this	power consumption, etc. The idea in this memo is to capture this
	flow information as a label, the so-called entropy label.	flow information as a label, the so-called entropy label.

	Ingress LSRs can also adapt more readily to new protocols and extract	Ingress LSRs can also adapt more readily to new protocols and extract
	the appropriate keys to use for load balancing packets of those	the appropriate keys to use for load balancing packets of those
	protocols. This means that deploying new protocols or services in	protocols. This means that deploying new protocols or services in

	edge devices requires fewer concommitant changes in the core,	edge devices requires fewer concomitant changes in the core,
	resulting in higher edge service velocity and at the same time more	resulting in higher edge service velocity and at the same time more
	stable core networks.	stable core networks.

	2. Approaches	2. Approaches

	There are two main approaches to encoding load balancing information	There are two main approaches to encoding load balancing information
	in the label stack. The first allocates multiple labels for a	in the label stack. The first allocates multiple labels for a

	particular Forwarding Equivalance Class (FEC). These labels are	particular Forwarding Equivalence Class (FEC). These labels are
	equivalent in terms of forwarding semantics, but having multiple	equivalent in terms of forwarding semantics, but having multiple
	labels allows flexibility in assigning labels to flows belonging to	labels allows flexibility in assigning labels to flows belonging to
	the same FEC. This approach has the advantage that the label stack	the same FEC. This approach has the advantage that the label stack
	has the same depth whether or not one uses label-based load	has the same depth whether or not one uses label-based load
	balancing; and so, consequently, there is no change to forwarding	balancing; and so, consequently, there is no change to forwarding
	operations on transit and egress LSRs. However, it has a major	operations on transit and egress LSRs. However, it has a major
	drawback in that there is a significant increase in both signaling	drawback in that there is a significant increase in both signaling
	and forwarding state.	and forwarding state.

	The other approach encodes the load balancing information as an	The other approach encodes the load balancing information as an
	additional label in the label stack, thus increasing the depth of the	additional label in the label stack, thus increasing the depth of the
	label stack by one. With this approach, there is minimal change to	label stack by one. With this approach, there is minimal change to
	signaling state for a FEC; also, there is no change in forwarding	signaling state for a FEC; also, there is no change in forwarding
	operations in transit LSRs, and no increase of forwarding state in	operations in transit LSRs, and no increase of forwarding state in
	any LSR. The only purpose of the additional label is to increase the	any LSR. The only purpose of the additional label is to increase the
	entropy in the label stack, so this is called an "entropy label".	entropy in the label stack, so this is called an "entropy label".
	This memo focuses solely on this approach.	This memo focuses solely on this approach.


		This latter approach uses upstream generated entropy labels, which
		may conflict with downstream allocated application labels. There are
		a few approaches to deal with this: 1) allocate a pair of labels for
		each FEC, one that must have an entropy label below it, and one that
		must not; 2) use a label (the "Entropy Label Indicator") to indicate
		that the next label is an entropy label; and 3) allow entropy labels
		only where there is no possible confusion. The first doubles control
		and data plane state in the network; the last is too restrictive.
		The approach taken here is the second. In making both the above
		choices, the trade-off is to increase label stack depth rather than
		control and data plane state in the network.

		Finally, one may choose to associate ELs with MPLS tunnels (LSPs), or
		with MPLS applications (e.g., VPNs). (What this entails is described
		in later sections.) We take the former approach, for the following
		reasons:

		1. There are a small number of tunneling protocols for MPLS, but a
		large and growing number of applications. Defining ELs on a
		tunnel basis means simpler standards, lower development,
		interoperability and testing efforts.

		2. As a consequence, there will be much less churn in the network as
		new applications (services) are defined and deployed.

		3. Processing application labels in the data plane is more complex
		than processing tunnel labels. Thus, it is preferable to burden
		the latter rather than the former with EL processing.

		4. Associating ELs with tunnels makes it simpler to deal with
		hierarchy, be it LDP-over-RSVP-TE or Carrier's Carrier VPNs.
		Each layer in the hierarchy can choose independently whether or
		not they want ELs.

		The cost of this approach is that ELIs will be mandatory; again, the
		trade-off is the size of the label stack. To summarize, the net
		increase in the label stack to use entropy labels is two: one
		reserved label for the ELI, and the entropy label itself.

	3. Entropy Labels and Their Structure	3. Entropy Labels and Their Structure

	An entropy label (as used here) is a label:	An entropy label (as used here) is a label:

	1. that is not used for forwarding;	1. that is not used for forwarding;

	2. that is not signaled; and	2. that is not signaled; and

	3. whose only purpose in the label stack is to provide 'entropy' to	3. whose only purpose in the label stack is to provide 'entropy' to
	improve load balancing.	improve load balancing.

	Entropy labels are generated by an ingress LSR, based entirely on	Entropy labels are generated by an ingress LSR, based entirely on
	load balancing information. However, they MUST NOT have values in	load balancing information. However, they MUST NOT have values in

	the reserved label space (0-15). To ensure that they are not used	the reserved label space (0-15) [IANA MPLS Label Values]. To ensure
	inadvertently for forwarding, entropy labels SHOULD have a TTL of 0.	that they are not used inadvertently for forwarding, entropy labels
	The CoS field of an entropy label can be set to any value deemed	SHOULD have a TTL of 0. The CoS field of an entropy label can be set
	appropriate.	to any value deemed appropriate.

	Since entropy labels are generated by an ingress LSR, an egress LSR	Since entropy labels are generated by an ingress LSR, an egress LSR

	MUST be able to tell unambiguously that a given label is an entropy	MUST be able to distinguish unambiguously between entropy labels and
	label. If any ambiguity is possible, the label above the entropy	application labels. This is accomplished by REQUIRING that the label
	label MUST be an 'entropy label indicator' (ELI), which indicates	immediately preceding an entropy label (EL) in the MPLS label stack
	that the following Label is an entropy label. An ELI is typically	be an 'entropy label indicator' (ELI). The ELI is a reserved label
	signaled by an egress LSR and is added to the MPLS label stack along	with value (TBD by IANA). An ELI MUST have 'Bottom of Stack' (BoS)
	with an entropy label by an ingress LSR. For many applications, the	bit = 0 ([RFC3032]). The TTL SHOULD be set to whatever value the
	use of entropy labels is unambiguous, and an ELI is not needed. An	label above it in the stack has. The CoS field can be set to any
	ELI MUST have 'Bottom of Stack' (S) bit = 0 ([RFC3032]). The TTL	value deemed appropriate; typically, this will be the value in the
	SHOULD be set to whatever value the label above it in the stack has.	label above the ELI in the label stack.
	The CoS field can be set to any value deemed appropriate; typically,
	this will be the value in the label above it in the stack.


	Applications for MPLS entropy labels include pseudowires ([RFC4447]),	Entropy labels are useful for pseudowires ([RFC4447]).
	Layer 3 VPNs ([RFC4364]), VPLS ([RFC4761], [RFC4762]) and Tunnel LSPs	[I-D.ietf-pwe3-fat-pw] explains how entropy labels can be used for
	carrying, say, IP traffic. [I-D.ietf-pwe3-fat-pw] explains how	RFC 4447-style pseudowires, and thus is complementary to this memo,
	entropy labels can be used for RFC 4447-style pseudowires, and thus	which focuses on how entropy labels can be used for tunnels, and thus
	is complementary to this memo, which focuses on several other	for all other MPLS applications.
	applications of entropy labels.

	4. Data Plane Processing of Entropy Labels	4. Data Plane Processing of Entropy Labels


	4.1. Ingress LSR	4.1. Egress LSR


	Suppose that for a particular application (or service or FEC), an	Suppose egress LSR Y is capable of processing entropy labels for a
	ingress LSR X is to push label stack <TL, AL>, where TL is the	tunnel. Y indicates this to all ingresses via signaling (see
	'tunnel label' and AL is the 'application label'. (Note the use of	Section 5). Y MUST be prepared to deal both with packets with an
	the convention for label stacks described in Section 1.1. The use of	imposed EL and those without; the ELI will distinguish these cases.
	a two-label stack is just for illustrative purposes.) Suppose	If a particular ingress chooses not to impose an EL, Y's processing
	furthermore that the egress LSR Y has told X that it is capable of	of the received label stack (which might be empty) is as if Y chose
	processing entropy labels for this application. If X cannot insert	not to accept ELs.
	entropy labels, it simply uses a label stack of <TL, AL> for this
	application. If X can insert entropy labels, it does the following
	for an incoming packet:


	1. X identifies the application to which the packet belongs,	If an ingress X chooses to impose an EL, then Y will receive a tunnel
	identifies the egress LSR as Y, and thereby picks the outgoing	termination packet with label stack <TL, ELI, EL> <remaining packet
	label stack <TL, AL> to push onto the packet to send to Y.	header>. Y recognizes TL as the label it distributed to its
		upstreams for the tunnel, and pops it. (Note that TL may be the
		implicit null label, in which case it doesn't appear in the label
		stack.) Y then recognizes the ELI and pops two labels: the ELI and
		the EL. Y then processes the remaining packet header as normal; this
		may require further processing of tunnel termination, perhaps with
		further ELI+EL pairs. When processing the final tunnel termination,
		Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value,
		and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the
		remaining packet header. The EL's TTL MUST be ignored.


	2. X determines which keys that it will use for load balancing.	If any ELI processed by Y has BoS bit set, Y MUST discard the packet,
		and MAY log an error. The EL's BoS bit will indicate whether or not
		there are more labels in the stack.


	3. X, having kept state that Y can process entropy labels for this	4.2. Ingress LSR
	application, generates an entropy label EL (based on the output
	of the load balancing function).


	4. If Y does not need an ELI, X pushes <TL, AL, EL> onto the packet	If an egress LSR Y indicates via signaling that it can process ELs on
	before forwarding it to the next hop to Y.	a particular tunnel, an ingress LSR X can choose whether or not to
		insert ELs for packets going into that tunnel. Y MUST handle both
		cases.


	5. If Y requires an ELI, X pushes <TL, AL, E, EL> onto the packet	The steps that X performs to insert ELs are as follows:
	before forwarding it to the next hop to Y, where E is a label
	whose 20-bit label field is the ELI that Y signaled, and whose
	other fields are set as per Section 3.


	Note that ingress LSR X MUST NOT include an entropy label unless the	1. On an incoming packet, identify the application to which the
	egress LSR Y for this application has indicated that it is ready to	packet belongs, and thereby pick the fields to input to the load
	receive entropy labels. Furthermore, if Y has signaled that an ELI	balancing function; call the output LB.
	is needed, then X MUST include the ELI before the entropy label.


	Note that the signaling and use of entropy labels in one direction	2. Determine the application label AL (if any). Push <AL> onto the
	(signaling from Y to X, and data path from X to Y) has no bearing on	packet.
	the behavior in the opposite direction (signaling from X to Y, and
	data path from Y to X).


	4.2. Transit LSR	3. Based on the application, the load balancing output LB and other
		factors, determine the egress LSR Y, the tunnel to Y, the
		specific interface to the next hop, and thus the tunnel label TL.
		Use LB to generate the entropy label EL.


	Transit LSRs have virtually no change in forwarding behavior. For	4. If, for the chosen tunnel, Y has not indicated that it can
	load balancing, transit LSRs SHOULD use the whole label stack as keys	process ELs, push <TL> onto the packet. If Y has indicated that
	for the load balancing function. Transit LSRs MUST NOT include	it can process ELs for the tunnel, push <TL, ELI, EL> onto the
	reserved labels as input to its load balancing function. Transit	packet. X SHOULD put the same TTL and TC fields for the ELI as
	LSRs MAY choose to look beyond the label stack for further keys;	it does for TL. The TTL for the EL MUST be zero. The TC for the
	however, if entropy labels are being used, this may not be very	EL may be any value.
	useful. Looking beyond the label stack may be the simplest approach
	in an environment where some ingress LSRs use entropy labels and
	others don't, or for backward compatibility. Thus, other than using
	the full label stack as input to the load balancing function, transit
	LSRs are almost unaffected by the use of entropy labels.


	4.3. Egress LSR	5. X then determines whether further tunnel hierarchy is needed; if
		so, X goes back to step 3, possibly with a new egress Y for the
		new tunnel. Otherwise, X is done, and sends out the packet.


	Suppose egress LSR Y signals that it is capable of processing entropy	Notes:
	labels for a tunnel or an application with label L. There are three
	cases of interest: (a) L is the implicit NULL label, in which case an
	ELI is mandatory; (b) L is not the implicit NULL label and an ELI is
	not required (L's S bit will be used to determine whether or not
	there is an EL); and (c) L is not the implicit NULL label but an ELI
	is required.


	a1) Y receives an unlabeled packet. There is obviously no EL; Y	a. X computes load balancing information and generates the EL based
	processes the packet as usual.	on the incoming application packet, even though the signaling of
		EL capability is associated with tunnels.


	a2) Y receives a packet whose top label is the ELI. Y processes the	b. X MAY insert several entropy labels in the stack (each, of
	TTL and CoS fields of the ELI label, ensures that the S bit is 0,	course, preceded by an ELI), potentially one for each
	then pops it, and pops the next label as well (which must be the	hierarchical tunnel, provided that the egress for that tunnel has
	EL), then pops it. Y processes the remaining payload as usual.	indicated that it can process ELs for that tunnel.


	b) Y receives a packet with top label L, and an ELI is not required.	c. X MUST NOT include an entropy label for a given tunnel unless the
	Y processes L as usual; if L's S bit is 1, the label stack is	egress LSR Y has indicated that it can process entropy labels for
	done. If L's S bit is 0, the following label is the EL. Y pops	that tunnel.
	the EL. Y processes the payload as usual.


	c) Y receives a packet with top label L. Y processes L as usual; if	d. The signaling and use of entropy labels in one direction
	L's S bit is 1, the label stack is done. If L's S bit is 0, Y	(signaling from Y to X, and data path from X to Y) is completely
	checks the following label. If it is the ELI label, Y processes	independent of the signaling and use of entropy labels in the
	the TTL and CoS fields of the ELI, ensures that the S bit is 0,	reverse direction (signaling from X to Y, and data path from Y to
	pops the ELI label and the following label (which is the EL), and	X).
	processes the remaining payload as usual.


	If there is an ELI with S bit = 1, there is an error in the label	4.3. Transit LSR
	stack. Note that the TTL field of the EL (if present) will be 0; Y
	MUST NOT react to this.


	5. Signaling for Entropy Labels	Transit LSRs MAY operate with no change in forwarding behavior. The
		following are suggestions for optimizations that improve load
		balancing, reduce the amount of packet data processed, and/or enhance
		backward compatibility.


	An egress LSR Y may signal to ingress LSR(s) its ability to process	If a transit LSR recognizes the ELI, it MAY choose to load balance
	entropy labels on a per-application (or per-FEC) basis. As part of	solely on the following label (the EL); otherwise, it SHOULD use as
	this signaling, Y also signals the ELI to use, if any.	much of the whole label stack as feasible as keys for the load
		balancing function, with the exception that reserved labels MUST NOT
		be used.


	In cases where an application label is used and must be the	Some transit LSRs look beyond the label stack for better load
	bottommost label in the label stack, Y MAY signal that no ELI is	balancing information. This is a simple, backward compatible
	needed for that application.	approach in networks where some ingress LSRs impose ELs and others
		don't. However, this is of limited incremental value if an EL is
		indeed present, and requires more packet processing from the LSR. A
		transit LSR MAY choose to parse the label stack for the presence of
		the ELI, and look beyond the label stack only if it does not find it,
		thus retaining the old behavior when needed, yet avoided unnecessary
		work if not.


	In cases where no application label exists, or where the application	4.4. Penultimate Hop LSR
	label may not be the bottommost label in the label stack, Y MUST
	signal a valid ELI to be used in conjunction with the entropy label
	for this FEC. In this case, an ingress LSR will either not add an
	entropy label, or push the ELI before the entropy label. This makes
	the use or non-use of an entropy label by the ingress LSR
	unambiguous. Valid ELI label values are strictly greater than 15.


	It should be noted that egress LSR Y may use the same ELI value for	No change is needed at penultimate hop LSRs.
	all applications for which an ELI is needed. The ELI MUST be a label
	that does not conflict with any other labels that Y has advertised to	5. Signaling for Entropy Labels
	other LSRs for other applications. Furthermore, it should be noted
	that the ability to process entropy labels (and the corresponding	An egress LSR Y can signal to ingress LSR(s) its ability to process
	ELI) may be asymmetric: an LSR X may be willing to process entropy	entropy labels (henceforth called "Entropy Label Capability" or ELC)
	labels, whereas LSR Y may not be willing to process entropy labels.	on a given tunnel. Note that Entropy Label Capability may be
	The signaling extensions below allow for this asymmetry.	asymmetric: if LSRs X and Y are at opposite ends of a tunnel, X may
		be able to process entropy labels, whereas Y may not. The signaling
		extensions below allow for this asymmetry.

	For an illustration of signaling and forwarding with entropy labels,	For an illustration of signaling and forwarding with entropy labels,

	see Figure 9.	see Section 9.

	5.1. LDP Signaling	5.1. LDP Signaling


	When using LDP for signaling tunnel labels ([RFC5036]), a Label	A new LDP TLV ([RFC5036]) is defined to signal an egress's ability to
	Mapping Message sub-TLV (Entropy Label sub-TLV) is used to signal an	process entropy labels. This is called the ELC TLV, and may appear
	egress LSR's ability to process entropy labels.	as an Optional Parameter of the Label Mapping Message TLV.


	The presence of the Entropy Label sub-TLV in the Label Mapping	The presence of the ELC TLV in a Label Mapping Message indicates to
	Message indicates to ingress LSRs that the egress LSR can process an	ingress LSRs that the egress LSR can process entropy labels for the
	entropy label. In addition, the Entropy Label sub-TLV contains a	associated LDP tunnel. The ELC TLV has Type (TBD by IANA) and Length
	label value for the ELI. If the ELI is zero, this indicates the	0.
	egress doesn't need an ELI for the signaled application; if not, the
	egress requires the given ELI with entropy labels. An example where
	an ELI is needed is when the signaled application is an LSP that can
	carry IP traffic.


	The structure of the Entropy Label sub-TLV is shown below.	The structure of the ELC TLV is shown below.

	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\|U\|F\| Type (TBD) \| Length (8) \|	\|U\|F\| Type (TBD) \| Length (0) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Value \| Must Be Zero \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Figure 1: Entropy Label sub-TLV	Figure 1: Entropy Label Capability TLV

	where:	where:

	U: Unknown bit. This bit MUST be set to 1. If the Entropy Label	U: Unknown bit. This bit MUST be set to 1. If the Entropy Label

	sub-TLV is not understood, then the TLV is not known to the	Capability TLV is not understood, then the TLV is not known to the
	receiver and MUST be ignored.	receiver and MUST be ignored.

	F: Forward bit. This bit MUST be set be set to 1. Since this	F: Forward bit. This bit MUST be set be set to 1. Since this

	sub-TLV is going to be propagated hop-by-hop, the sub-TLV should	Capability TLV is going to be propagated hop-by-hop, the TLV
	be forwarded even by nodes that may not understand it.	should be forwarded even by nodes that may not understand it.

	Type: sub-TLV Type field, as specified by IANA.


	Length: sub-TLV Length field. This field specifies the total	Type: Type field. To be assigned by IANA.
	length in octets of the Entropy Label sub-TLV.


	Value: value of the Entropy Label Indicator Label.	Length: Length field. This field specifies the total length in
		octets of the ELC TLV, and is currently defined to be 0.

	5.2. BGP Signaling	5.2. BGP Signaling

	When BGP [RFC4271] is used for distributing Network Layer	When BGP [RFC4271] is used for distributing Network Layer
	Reachability Information (NLRI) as described in, for example,	Reachability Information (NLRI) as described in, for example,

	[RFC3107], [RFC4364] and [RFC4761], the BGP UPDATE message may	[RFC3107], the BGP UPDATE message may include the ELC attribute as
	include the Entropy Label attribute. This is an optional, transitive	part of the Path Attributes. This is an optional, transitive BGP
	BGP attribute of type TBD. The inclusion of this attribute with an	attribute of type (to be assigned by IANA). The inclusion of this
	NLRI indicates that the advertising BGP router can process entropy	attribute with an NLRI indicates that the advertising BGP router can
	labels as an egress LSR for that NLRI. If the attribute length is	process entropy labels as an egress LSR for all routes in that NLRI.
	less than three octets, this indicates that the egress doesn't need
	an ELI for the signaled application. If the attribute length is at
	least three octets, the first three octets encode an ELI label value
	as the high order 20 bits; the egress requires this ELI with entropy
	labels. An example where an ELI is needed is when the NLRI contains
	unlabeled IP prefixes.


	A BGP speaker S that originates an UPDATE should only include the	A BGP speaker S that originates an UPDATE should include the ELC
	Entropy Label attribute if both of the following are true:	attribute only if both of the following are true:

	A1: S sets the BGP NEXT_HOP attribute to itself; AND	A1: S sets the BGP NEXT_HOP attribute to itself; AND


	A2: S can process entropy labels for the given application.	A2: S can process entropy labels.

	If both A1 and A2 are true, and S needs an ELI to recognize entropy
	labels, then S MUST include the ELI label value as part of the
	Entropy Label attribute. An UPDATE SHOULD contain at most one
	Entropy Label attribute.


	Suppose a BGP speaker T receives an UPDATE U with the Entropy Label	Suppose a BGP speaker T receives an UPDATE U with the ELC attribute.
	attribute ELA. T has two choices. T can simply re-advertise U with	T has two choices. T can simply re-advertise U with the ELC
	the same ELA if either of the following is true:	attribute if either of the following is true:

	B1: T does not change the NEXT_HOP attribute; OR	B1: T does not change the NEXT_HOP attribute; OR

	B2: T simply swaps labels without popping the entire label stack and	B2: T simply swaps labels without popping the entire label stack and
	processing the payload below.	processing the payload below.


	An example of the use of B1 is Route Reflectors; an example of the	An example of the use of B1 is Route Reflectors.
	use of B2 is illustrated in Section 9.3.1.2.

	However, if T changes the NEXT_HOP attribute for U and in the data	However, if T changes the NEXT_HOP attribute for U and in the data

	plane pops the entire label stack to process the payload, T MUST	plane pops the entire label stack to process the payload, T MAY
	remove ELA. T MAY include a new Entropy Label attribute ELA' for	include an ELC attribute for UPDATE U' if both of the following are
	UPDATE U' if both of the following are true:	true:

	C1: T sets the NEXT_HOP attribute of U' to itself; AND	C1: T sets the NEXT_HOP attribute of U' to itself; AND


	C2: T can process entropy labels for the given application.	C2: T can process entropy labels.


	Again, if both C1 and C2 are true, and T needs an ELI to recognize	Otherwise, T MUST remove the ELC attribute.
	entropy labels, then T MUST include the ELI label value as part of
	the Entropy Label attribute.

	5.3. RSVP-TE Signaling	5.3. RSVP-TE Signaling


	Entropy Label support is signaled in RSVP-TE [RFC3209] using an	Entropy Label support is signaled in RSVP-TE [RFC3209] using the
	Entropy Label Attribute TLV (Type TBD) of the LSP_ATTRIBUTES object	Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the
	[RFC5420]. The presence of this attribute indicates that the	LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a
	signaler (the egress in the downstream direction using Resv messages;	Path message indicates that the ingress can process entropy labels in
	the ingress in the upstream direction using Path messages) can	the upstream direction; this only makes sense for a bidirectional LSP
	process entropy labels. The Entropy Label Attribute contains a value	and MUST be ignored otherwise. The presence of the ELC flag in a
	for the ELI. If the ELI is zero, this indicates that the signaler	Resv message indicates that the egress can process entropy labels in
	doesn't need an ELI for this application; if not, then the signaler	the downstream direction.
	requires the given ELI with entropy labels. An example where an ELI
	is needed is when the signaled LSP can carry IP traffic.

	The format of the Entropy Label Attribute is as follows:

	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Entropy Label Attribute \| Length (4) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| ELI Label \| MBZ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	An egress LSR includes the Entropy Label Attribute in a Resv message
	to indicate that it can process entropy labels in the downstream
	direction of the signaled LSP.

	An ingress LSR includes the Entropy Label Attribute in a Path message
	for a bi-directional LSP to indicate that it can process entropy
	labels in the upstream direction of the signaled LSP. If the
	signaled LSP is not bidirectional, the Entropy Label Attribute SHOULD
	NOT be included in the Path message, and egress LSR(s) SHOULD ignore
	the attribute, if any.

	As described in Section 8, there is also the need to distribute an
	ELI from the ingress (upstream label allocation). In the case of
	RSVP-TE, this is accomplished using the Upstream ELI Attribute TLV of
	the LSP_ATTRIBUTES object, as shown below:


	0 1 2 3	The bit number for the ELC flag is to be assigned by IANA.
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Upstream ELI Attribute \| Length (4) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| ELI Label \| MBZ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	6. Operations, Administration, and Maintenance (OAM) and Entropy Labels	6. Operations, Administration, and Maintenance (OAM) and Entropy Labels

	Generally OAM comprises a set of functions operating in the data	Generally OAM comprises a set of functions operating in the data
	plane to allow a network operator to monitor its network	plane to allow a network operator to monitor its network
	infrastructure and to implement mechanisms in order to enhance the	infrastructure and to implement mechanisms in order to enhance the
	general behavior and the level of performance of its network, e.g.,	general behavior and the level of performance of its network, e.g.,
	the efficient and automatic detection, localization, diagnosis and	the efficient and automatic detection, localization, diagnosis and
	handling of defects.	handling of defects.


	skipping to change at page 14, line 35 ¶	skipping to change at page 14, line 44 ¶
	the label range is to be placed in the entropy label. Deep packet	the label range is to be placed in the entropy label. Deep packet
	inspection is thus not necessary, although an LSR may use it,	inspection is thus not necessary, although an LSR may use it,
	provided it do so consistently, i.e., if the label range to go to a	provided it do so consistently, i.e., if the label range to go to a
	given downstream LSR is computed with deep packet inspection, then	given downstream LSR is computed with deep packet inspection, then
	the data path should use the same approach and the same keys.	the data path should use the same approach and the same keys.

	In order to have a BFD session on a given path, a value from the	In order to have a BFD session on a given path, a value from the
	label range for that path should be used as the EL value for BFD	label range for that path should be used as the EL value for BFD
	packets sent on that path.	packets sent on that path.


	As part of the MPLS-TP work, an in-band OAM channel is defined in
	[RFC5586]. Packets sent in this channel are identified with a
	reserved label, the Generic Associated Channel Label (GAL) placed at
	the bottom of the MPLS label stack. In order to use the inband OAM
	channel with entropy labels, this memo relaxes the restriction that
	the GAL must be at the bottom of the MPLS label stack. Rather, the
	GAL is placed in the MPLS label stack above the entropy label so that
	it effectively functions as an application label.

	7. MPLS-TP and Entropy Labels	7. MPLS-TP and Entropy Labels

	Since MPLS-TP does not use ECMP, entropy labels are not applicable to	Since MPLS-TP does not use ECMP, entropy labels are not applicable to
	an MPLS-TP deployment.	an MPLS-TP deployment.

	8. Point-to-Multipoint LSPs and Entropy Labels	8. Point-to-Multipoint LSPs and Entropy Labels

	Point-to-Multipoint (P2MP) LSPs [RFC4875] typically do not use ECMP	Point-to-Multipoint (P2MP) LSPs [RFC4875] typically do not use ECMP
	for load balancing, as the combination of replication and	for load balancing, as the combination of replication and
	multipathing can lead to duplicate traffic delivery. However, P2MP	multipathing can lead to duplicate traffic delivery. However, P2MP

	LSPs can traverse Bundled Links [RFC4201] and LAGs. In both these	LSPs can traverse bundled links [RFC4201] and LAGs. In both these
	cases, load balancing is useful, and hence entropy labels can be of	cases, load balancing is useful, and hence entropy labels can be of

	some value for P2MP LSPs.	value for P2MP LSPs.


	There are two potential complications with the use of entropy labels	There is a potential complication with the use of entropy labels in
	in the context of P2MP LSPs, both a consequence of the fact that the	the context of P2MP LSPs, a consequence of the fact that the entire
	entire label stack below the P2MP label must be the same for all	label stack below the P2MP label must be the same for all egress
	egress LSRs. First, all egress LSRs must be willing to receive	LSRs. This is that all egress LSRs must be willing to receive
	entropy labels; if even one egress LSR is not willing, then entropy	entropy labels; if even one egress LSR is not willing, then entropy

	labels MUST NOT be used for this P2MP LSP. Second, if an ELI is	labels MUST NOT be used for this P2MP LSP.
	required, all egress LSRs must agree to the same value of ELI. This
	can be achieved by upstream allocation of the ELI; in particular, for
	RSVP-TE P2MP LSPs, the ingress LSR distributes the ELI value using
	the Upstream ELI Attribute TLV of the LSP_ATTRIBUTES object, defined
	in Section 5.3.

	With regard to the first issue, the ingress LSR MUST keep track of
	the ability of each egress LSR to process entropy labels, especially
	since the set of egress LSRs of a given P2MP LSP may change over
	time. Whenever an existing egress LSR leaves, or a new egress LSR
	joins the P2MP LSP, the ingress MUST re-evaluate whether or not to
	include entropy labels for the P2MP LSP.

	In some cases, it may be feasible to deploy two P2MP LSPs, one to
	entropy label capable egress LSRs, and the other to the remaining
	egress LSRs. However, this requires more state in the network, more
	bandwidth, and more operational overhead (tracking EL-capable LSRs,
	and provisioning P2MP LSPs accordingly). Furthermore, this approach
	may not work for some applications (such mVPNs and VPLS) which
	automatically create and/or use P2MP LSPs for their multicast
	requirements.

	9. Entropy Labels and Applications

	This section describes the usage of entropy labels in various
	scenarios with different applications.

	9.1. Tunnels

	Tunnel LSPs, signaled with either LDP or RSVP-TE, typically carry
	other MPLS applications such as VPNs or pseudowires. This being the
	case, if the egress LSR of a tunnel LSP is willing to process entropy
	labels, it would signal the need for an Entropy Label Indicator to
	distinguish between entropy labels and other application labels.

	In the figures below, the following convention is used to depict
	information signaled between X and Y:

	X ---------- ... ---------- Y
	app: <--- [label L, ELI value]

	This means Y signals to X label L for application app. The ELI value
	can be one of:

	-: meaning entropy labels are NOT accepted;

	0: meaning entropy labels are accepted, no ELI is needed; or

	E: entropy labels are accepted, ELI label E is required.

	The following illustrates a simple intra-AS tunnel LSP.

	X -------- A --- ... --- B -------- Y
	tunnel LSP L: [TL, E] <--- ... <--- [TL0, E]

	IP pkt: push <TL, E, EL> --------------->

	Figure 2: Tunnel LSPs and Entropy Labels

	Tunnel LSPs may cross Autonomous System (AS) boundaries, usually
	using BGP ([RFC3107]). In this case, the AS Border Routers (ASBRs)
	MAY simply propagate the egress LSR's ability to process entropy
	labels, or they MAY declare that entropy labels may not be used. If
	an ASBR (say A2 below) chooses to propagate the egress LSR Y's
	ability to process entropy labels, A2 MUST also propagate Y's choice
	of ELI.

	X ---- ... ---- A1 ------- A2 ---- ... ---- Y
	intra-AS LSP A2-Y: <--- [TL0, E]
	inter-AS LSP A1-A2: [AL, E]
	intra-AS LSP X-A1: <--- [TL1, E]

	IP pkt: push <TL1, E, EL>

	Here, ASBR A2 chooses to propagate Y's ability to process entropy
	labels, by "translating" Y's signaling of entropy label capability
	(say using LDP) to BGP; and A1 translate A2's BGP signaling to (say)
	RSVP-TE. The end-to-end tunnel (X to Y) will have entropy labels if
	X chooses to insert them.

	Figure 3: Inter-AS Tunnel LSP with Entropy Labels

	X ---- ... ---- A1 ------- A2 ---- ... ---- Y
	intra-AS LSP A2-Y: <--- [TL0, E]
	inter-AS LSP A1-A2: [AL, E]
	intra-AS LSP X-A1: <--- [TL1, -]

	IP pkt: push <TL1> -->

	Here, ASBR A1 decided that entropy labels are not to be used; thus,
	the end-to-end tunnel cannot have entropy labels, even though both X
	and Y may be capable of inserting and processing entropy labels.

	Figure 4: Inter-AS Tunnel LSP with no Entropy Labels

	9.2. LDP Pseudowires

	[I-D.ietf-pwe3-fat-pw] describes the signaling and use of entropy
	labels in the context of RFC 4447 pseudowires, so this will not be
	described further here.

	[RFC4762] specifies the use of LDP for signaling VPLS pseudowires.
	An egress VPLS PE that can process entropy labels can indicate this
	by adding the Entropy Label sub-TLV in the LDP message it sends to
	other PEs. An ELI is not required. An ingress PE must maintain
	state per egress PE as to whether it can process entropy labels.

	X -------- A --- ... --- B -------- Y
	tunnel LSP L: [TL, E] <--- ... <--- [TL0, E]
	VPLS label: <------------------------ [VL, 0]

	VPLS pkt: push <TL, VL, EL> -------------->

	Figure 5: Entropy Labels with LDP VPLS

	Note that although the underlying tunnel LSP signaling indicated the
	need for an ELI, VPLS packets don't need an ELI, and thus the label
	stack pushed by X do not have one.

	[RFC4762] also describes the notion of "hierarchical VPLS" (H-VPLS).
	In H-VPLS, 'hub PEs' remove the label stack and process VPLS packets;
	thus, they must make their own decisions on the use of entropy
	labels, independent of other hub PEs or spoke PEs with which they
	exchange signaling. In the example below, spoke PEs X and Y and hub
	PE B can process entropy labels, but hub PE A cannot.

	X ---- ... ---- A ---- ... ---- B ---- ... ---- Y
	spoke PW1: <--- [SL1, 0]
	hub-hub PW: <---- [HL, 0]
	spoke PW2: <--- [SL2, -]

	SPW2 pkt: push <TL1, SL2>
	H-H PW pkt: push <TL2,HL,EL>
	SPW1 pkt: push <TL3,SL1,EL>

	Figure 6: Entropy Labels with H-VPLS

	9.3. BGP Applications


	Section 9.1 described a BGP application for the creation of inter-AS	In this regard, the ingress LSR MUST keep track of the ability of
	tunnel LSPs. This section describes two other BGP applications, IP	each egress LSR to process entropy labels, especially since the set
	VPNs ([RFC4364]) and BGP VPLS ([RFC4761]). An egress PE for either	of egress LSRs of a given P2MP LSP may change over time. Whenever an
	of these applications indicates its ability to process entropy labels	existing egress LSR leaves, or a new egress LSR joins the P2MP LSP,
	by adding the Entropy Label attribute to its BGP UPDATE message.	the ingress MUST re-evaluate whether or not to include entropy labels
	Again, ingress PEs must maintain per-egress PE state regarding its	for the P2MP LSP.
	ability to process entropy labels. In this section, both of these
	applications will be referred to as VPNs.


	In the intra-AS case, PEs signal application labels and entropy label	In some cases, it may be feasible to deploy two P2MP LSPs, one to ELC
	capability to each other, either directly, or via Route Reflectors	egress LSRs, and the other to the remaining non-ELC egress LSRs.
	(RRs). If RRs are used, they must not change the BGP NEXT_HOP	However, this requires more state in the network, more bandwidth, and
	attribute in the UPDATE messages; furthermore, they can simply pass	more operational overhead (tracking ELC LSRs, and provisioning P2MP
	on the Entropy Label attribute as is.	LSPs accordingly). Alternatively, an ingress LSR may choose to
		signal two separate P2MP LSPs, one to ELC egresses, the other to non-
		ELC egresses, trading off implementation complexity for operational
		complexity.


	X -------- A --- ... --- B -------- Y	9. Entropy Labels in Various Scenarios
	tunnel LSP L: [TL, E] <--- ... <--- [TL0, E]
	BGP VPN label: <------------------------ [VL, 0]


	BGP VPN pkt: push <TL, VL, EL> -------------->	This section describes the use of entropy labels in various
		scenarios.


	Figure 7: Entropy Labels with Intra-AS BGP apps	In the figures below, the following conventions used to depict
		processing between X and Y. Note that control plane signaling goes
		right to left, whereas data plane processing goes left to right.


	For BGP VPLS, the application label is at the bottom of stack, so no	Protocols
	ELI is needed. For BGP IP VPNs, the application label is usually at	Y: <--- [L, E] Y signals L to X
	the bottom of stack, so again no ELI is needed. However, in the case	X ------------- Y
	of Carrier's Carrier (CsC) VPNs, the BGP VPN label may not be at the	LS: <L, ELI, EL> Label stack
	bottom of stack. In this case, an ELI is necessary for CsC VPN	X: +<L, ELI, EL> X pushes <L, ELI, EL>
	packets with entropy labels to distinguish them from nested VPN	Y: -<L, ELI, EL> Y pops <L, ELI, EL>
	packets. In the example below, the nested VPN signaling is not	This means that Y signals to X label L for an LDP tunnel. E can be
	shown; the egress PE for the nested VPN (not shown) must signal	one of:
	whether or not it can process egress labels, and the ingress nested
	VPN PE may insert an entropy label if so.


	Three cases are shown: a plain BGP VPN packet, a CsC VPN packet	0: meaning egress is NOT entropy label capable, or
	originating from X, and a transit nested VPN packet originating from
	a nested VPN ingress PE (conceptually to the left of X). It is
	assumed that the nested VPN packet arrives at X with label stack <ZL,
	CVL> where ZL is the tunnel label (to be swapped with <TL, CL>) and
	CVL is the nested VPN label. Note that Y can use the same ELI for
	the tunnel LSP and the CsC VPN (and any other application that needs
	an ELI).


	X -------- A --- ... --- B -------- Y	1: meaning egress is entropy label capable.
	tunnel LSP L: [TL, E] <--- ... <--- [TL0, E]
	BGP VPN label: <------------------------ [VL, 0]
	BGP CsC VPN label: <------------------------ [CL, E]


	BGP VPN pkt: push <TL, VL, EL> -------------->	The line with LS: shows the label stack on the wire. Below that is
	CsC VPN pkt: push <TL, CL, E, EL> ----------->	the operation that each LSR does in the data plane, where + means
	nested VPN pkt: swap <ZL> with <TL, CL> -------->	push the following label stack, - means pop the following label
		stack, L~L' means swap L with L', and * means that the operation is
		not depicted.


	Figure 8: Entropy Labels with CoC VPN	9.1. LDP Tunnel


	9.3.1. Inter-AS BGP VPNs	The following illustrates several simple intra-AS LDP tunnels. The
		first diagram shows ultimate hop popping (UHP) with ingress inserting
		an EL, the second UHP with no ELs, the third PHP with ELs, and
		finally, PHP with no ELs, but also with an application label AL
		(which could, for example, be a VPN label).


	There are three commonly used options for inter-AS IP VPNs and BGP	Note that, in all the cases below, the MPLS application does not
	VPLS, known informally as "Option A", "Option B" and "Option C".	matter; it may be that X pushes some more labels (perhaps for a VPN
	This section describes how entropy labels can be used in these	or VPLS) below the ones shown, and Y pops them.
	options.


	9.3.1.1. Option A Inter-AS VPNs	A: <--- [TL4, 1]
		B: <-- [TL3, 1]
		...
		W: <-- [TL1, 1]
		Y: <-- [TL0, 1]
		X --------------- A --------- B ... W ---------- Y
		LS: <TL4, ELI, EL> <TL3,ELI,EL> <TL0,ELI,EL>
		X: +<TL4, ELI, EL>
		A: TL4~TL3
		B: TL3~TL2
		...
		W: TL1~TL0
		Y: -<TL0, ELI, EL>


	In option A, an ASBR pops the full label stack of a VPN packet	LDP with UHP; ingress inserts ELs
	exiting an AS, processes the payload header (IP or Ethernet), and
	forwards the packet natively (i.e., as IP or Ethernet, but not as
	MPLS) to the peer ASBR. Thus, entropy label signaling and insertion
	are completely local to each AS. The inter-AS paths do not use
	entropy labels, as they do not use a label stack.


	9.3.1.2. Option B Inter-AS VPNs	A: <--- [TL4, 1]
		B: <-- [TL3, 1]
		...
		W: <-- [TL1, 1]
		Y: <-- [TL0, 1]
		X --------------- A --------- B ... W ---------- Y
		LS: <TL4> <TL3> <TL0>
		X: +<TL4>
		A: TL4~TL3
		B: TL3~TL2
		...
		W: TL1~TL0
		Y: -<TL0>


	The ASBRs in option B inter-AS VPNs have a choice (usually determined	LDP with UHP; ingress does not insert ELs
	by configuration) of whether to just swap labels (from within the AS
	to the neighbor AS or vice versa), or to pop the full label stack and
	process the packet natively. This choice occurs at each ASBR in each
	direction. In the case of native packet processing at an ASBR,
	entropy label signaling and insertion is local to each AS and to the
	inter-AS paths (which, unlike option A, do have labeled packets).


	In the case of simple label swapping at an ASBR, the ASBR can	A: <--- [TL4, 1]
	propagate received entropy label signaling onward. That is, if a PE	B: <-- [TL3, 1]
	signals to its ASBR that it can process entropy labels (via an	...
	Entropy Label attribute), the ASBR can propagate that attribute to	W: <-- [TL1, 1]
	its peer ASBR; if a peer ASBR signals that it can process entropy	Y: <-- [3, 1]
	labels, the ASBR can propagate that to all PEs within its AS). Note	X --------------- A --------- B ... W ---------- Y
	that this is the case even though ASBRs change the BGP NEXT_HOP	X: +<TL4, ELI, EL>
	attribute to "self", because of clause B2 in Section 5.2.	A: TL4~TL3
		B: TL3~TL2
		...
		W: -TL1
		Y: -<ELI, EL>


	9.3.1.3. Option C Inter-AS VPNs	LDP with PHP; ingress inserts ELs


	In Option C inter-AS VPNs, the ASBRs are not involved in signaling;	A: <--- [TL4, 1]
	they do not have VPN state; they simply swap labels of inter-AS	B: <-- [TL3, 1]
	tunnels. Signaling is PE to PE, usually via Route Reflectors;	...
	however, if RRs are used, the RRs do not change the BGP NEXT_HOP	W: <-- [TL1, 1]
	attribute. Thus, entropy label signaling and insertion are on a PE-	Y: <-- [3, 1]
	pair basis, and the intermediate routers, ASBRs and RRs do not play a	VPN: <------------------------------------------ [AL]
	role.	X --------------- A --------- B ... W ---------- Y
		LS: <TL4, AL> <TL3, AL> <AL>
		X: +<TL4, AL>
		A: TL4~TL3
		B: TL3~TL2
		...
		W: -TL1
		Y: -<AL>
		LDP with PHP + VPN; ingress does not insert ELs


	9.4. Multiple Applications	9.2. LDP Over RSVP-TE


	It has been mentioned earlier that an ingress PE must keep state per	The following illustrates "LDP over RSVP-TE" tunnels. X and Y are
	egress PE with regard to its ability to process entropy labels. An	the ingress and egress (respectively) of the LDP tunnel; A and W are
	ingress PE must also keep state per application, as entropy label	the ingress and egress of the RSVP-TE tunnel. It is assumed that
	processing must be based on the application context in which a packet	both the LDP and RSVP-TE tunnels have PHP.
	is received (and of course, the corresponding entropy label
	signaling).


	In the example below, an egress LSR Y signals a tunnel LSP L, and is	LDP with ELs, RSVP-TE without ELs
	prepared to receive entropy labels on L, but requires an ELI.	LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
	Furthermore, Y signals two pseudowires PW1 and PW2 with labels PL1	RSVP-TE: <-- [Rn, 0]
	and PL2, respectively, and indicates that it can receive entropy	<-- [3, 0]
	labels for both pseudowires without the need of an ELI; and finally,	X --------------- A --------- B ... W ---------- Y
	Y signals a L3 VPN with label VL, but Y does not indicate that it can	LS: <L4, ELI, EL> <Rn,L3,ELI,EL> ... <ELI, EL>
	receive entropy labels for the L3 VPN. Ingress LSR X chooses to send	DP: +<L4, ELI, EL> L4~<Rn, L3> * -L1 -<ELI, EL>
	native IP packets to Y over L with entropy labels, thus X must
	include the given ELI (yielding a label stack of <TL, ELI, EL>). X
	chooses to add entropy labels on PW1 packets to Y, with a label stack
	of <TL, PL1, EL>, but chooses not to do so for PW2 packets. X must
	not send entropy labels on L3 VPN packets to Y, i.e., the label stack
	must be <TL, VL>.


	X -------- A --- ... --- B -------- Y	Figure 2: LDP over RSVP-TE Tunnels
	tunnel LSP L: [TL, E] <--- ... <--- [TL0, E]
	PW1 label: <----------------------- [PL1, 0]
	PW2 label: <----------------------- [PL2, 0]
	VPN label: <----------------------- [VL, -]


	IP pkt: push <TL, ELI, EL> ------------->	9.3. MPLS Applications
	PW1 pkt: push <TL, PL1, EL> ------------->
	PW2 pkt: push <TL, PL2> ----------------->
	VPN pkt: push <TL, VL> ------------------>


	Figure 9: Entropy Labels for Multiple Applications	An ingress LSR X must keep state per unicast tunnel as to whether the
		egress for that tunnel can process entropy labels. X does not have
		to keep state per application running over that tunnel. However, an
		ingress PE can choose on a per-application basis whether or not to
		insert ELs. For example, X may have an application for which it does
		not wish to use ECMP (e.g., circuit emulation), or for which it does
		not know which keys to use for load balancing (e.g., Appletalk over a
		pseudowire). In either of those cases, X may choose not to insert
		entropy labels, but may choose to insert entropy labels for an IP VPN
		over the same tunnel.

	10. Security Considerations	10. Security Considerations

	This document describes advertisement of the capability to support	This document describes advertisement of the capability to support

	receipt of entropy-labels and an Entropy Label Indicator that an	receipt of entropy labels which an ingress LSR may insert in MPLS
	ingress LSR may apply to MPLS packets in order to allow transit LSRs	packets in order to allow transit LSRs to attain better load
	to attain better load-balancing across LAG and/or ECMP paths in the	balancing across LAG and/or ECMP paths in the network.
	network.


	This document does not introduce new security vulnerabilities to LDP.	This document does not introduce new security vulnerabilities to LDP,
	Please refer to the Security Considerations section of LDP	BGP or RSVP-TE. Please refer to the Security Considerations section
	([RFC5036]) for security mechanisms applicable to LDP.	of these protocols ([RFC5036], [RFC4271] and [RFC3209]) for security
		mechanisms applicable to each.

	Given that there is no end-user control over the values used for	Given that there is no end-user control over the values used for
	entropy labels, there is little risk of Entropy Label forgery which	entropy labels, there is little risk of Entropy Label forgery which
	could cause uneven load-balancing in the network.	could cause uneven load-balancing in the network.

	If Entropy Label Capability is not signaled from an egress PE to an	If Entropy Label Capability is not signaled from an egress PE to an
	ingress PE, due to, for example, malicious configuration activity on	ingress PE, due to, for example, malicious configuration activity on

	the egress PE, then the PE's will fall back to not using entropy	the egress PE, then the PE will fall back to not using entropy labels
	labels for load-balancing traffic over LAG or ECMP paths which, in	for load-balancing traffic over LAG or ECMP paths which is in general
	some cases, in no worse than the behavior observed in current	no worse than the behavior observed in current production networks.
	production networks. That said, operators are recommended to monitor	That said, it is recommended that operators monitor changes to PE
	changes to PE configurations and, more importantly, the fairness of	configurations and, more importantly, the fairness of load
	load distribution over equal-cost LAG or ECMP paths. If the fairness	distribution over LAG or ECMP paths. If the fairness of load
	of load distribution over a set of paths changes that could indicate	distribution over a set of paths changes that could indicate a
	a misconfiguration, bug or other non-optimal behavior on their PE's	misconfiguration, bug or other non-optimal behavior on their PEs and
	and they should take corrective action.	they should take corrective action.


	Given that most applications already signal an Application Label,	11. IANA Considerations
	e.g.: IPVPNs, LDP VPLS, BGP VPLS, whose Bottom of Stack bit is being
	re-used to signal entropy label capability, there is little to no
	additional risk that traffic could be misdirected into an
	inappropriate IPVPN VRF or VPLS VSI at the egress PE.


	In the context of downstream-signaled entropy labels that require the	11.1. Reserved Label for ELI
	use of an Entropy Label Indicator (ELI), there should be little to no
	additional risk because the egress PE is solely responsible for
	allocating an ELI value and ensuring that ELI label value DOES NOT
	conflict with other MPLS labels it has previously allocated. On the
	other hand, for upstream-signaled entropy labels, e.g.: RSVP-TE
	point-to-point or point-to-multipoint LSP's or Multicast LDP (mLDP)
	point-to-multipoint or multipoint-to-multipoint LSP's, there is a
	risk that the head-end MPLS LER may choose an ELI value that is
	already in use by a downstream LSR or LER. In this case, it is the
	responsibility of the downstream LSR or LER to ensure that it MUST
	NOT accept signaling for an ELI value that conflicts with MPLS
	label(s) that are already in use.


	11. IANA Considerations	IANA is requested to allocate a reserved label for the Entropy Label
		Indicator (ELI) from the "Multiprotocol Label Switching Architecture
		(MPLS) Label Values" Registry.


	11.1. LDP Entropy Label TLV	11.2. LDP Entropy Label Capability TLV

	IANA is requested to allocate the next available value from the IETF	IANA is requested to allocate the next available value from the IETF
	Consensus range in the LDP TLV Type Name Space Registry as the	Consensus range in the LDP TLV Type Name Space Registry as the

	"Entropy Label TLV".	"Entropy Label Capability TLV".


	11.2. BGP Entropy Label Attribute	11.3. BGP Entropy Label Capability Attribute

	IANA is requested to allocate the next available Path Attribute Type	IANA is requested to allocate the next available Path Attribute Type
	Code from the "BGP Path Attributes" registry as the "BGP Entropy	Code from the "BGP Path Attributes" registry as the "BGP Entropy

	Label Attribute".	Label Capability Attribute".


	11.3. Attribute Flags for LSP_Attributes Object	11.4. RSVP-TE Entropy Label Capability flag

	IANA is requested to allocate a new bit from the "Attribute Flags"	IANA is requested to allocate a new bit from the "Attribute Flags"
	sub-registry of the "RSVP TE Parameters" registry.	sub-registry of the "RSVP TE Parameters" registry.


	Bit \| Name \| Attribute \| Attribute \| RRO	Bit \| Name \| Attribute \| Attribute \| RRO
	No \| \| Flags Path \| Flags Resv \|	No \| \| Flags Path \| Flags Resv \|
	----+----------------------+------------+------------+-----	----+--------------------------+------------+------------+-----
	TBD Entropy Label LSP Yes Yes No	TBD Entropy Label Capability Yes Yes No

	11.4. Attributes TLV for LSP_Attributes Object

	IANA is requested to allocate the next available value from the
	"Attributes TLV" sub-registry of the "RSVP TE Parameters" registry.

	12. Acknowledgments	12. Acknowledgments

	We wish to thank Ulrich Drafz for his contributions, as well as the	We wish to thank Ulrich Drafz for his contributions, as well as the
	entire 'hash label' team for their valuable comments and discussion.	entire 'hash label' team for their valuable comments and discussion.


		Sincere thanks to Nischal Sheth for his many suggestions and
		comments, and his careful reading of the document, especially with
		regard to data plane processing of entropy labels.

	13. References	13. References

	13.1. Normative References	13.1. Normative References

	[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.

	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, January 2001.	Encoding", RFC 3032, January 2001.

	skipping to change at page 24, line 33 ¶	skipping to change at page 21, line 37 ¶
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.	Specification", RFC 5036, October 2007.

	[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic	[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
	Associated Channel", RFC 5586, June 2009.	Associated Channel", RFC 5586, June 2009.

	[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,	[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
	"Bidirectional Forwarding Detection (BFD) for MPLS Label	"Bidirectional Forwarding Detection (BFD) for MPLS Label
	Switched Paths (LSPs)", RFC 5884, June 2010.	Switched Paths (LSPs)", RFC 5884, June 2010.


	Appendix A. Applicability of LDP Entropy Label sub-TLV	Appendix A. Applicability of LDP Entropy Label Capability TLV

	In the case of unlabeled IPv4 (Internet) traffic, the Best Current	In the case of unlabeled IPv4 (Internet) traffic, the Best Current
	Practice is for an egress LSR to propagate eBGP learned routes within	Practice is for an egress LSR to propagate eBGP learned routes within
	a SP's Autonomous System after resetting the BGP next-hop attribute	a SP's Autonomous System after resetting the BGP next-hop attribute
	to one of its Loopback IP addresses. That Loopback IP address is	to one of its Loopback IP addresses. That Loopback IP address is
	injected into the Service Provider's IGP and, concurrently, a label	injected into the Service Provider's IGP and, concurrently, a label
	assigned to it via LDP. Thus, when an ingress LSR is performing a	assigned to it via LDP. Thus, when an ingress LSR is performing a
	forwarding lookup for a BGP destination it recursively resolves the	forwarding lookup for a BGP destination it recursively resolves the
	associated next-hop to a Loopback IP address and associated LDP label	associated next-hop to a Loopback IP address and associated LDP label
	of the egress LSR.	of the egress LSR.

	Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label	Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label

	sub-TLV will typically be applied only to the FEC for the Loopback IP	Capability TLV will typically be applied only to the FEC for the
	address of the egress LSR and the egress LSR will not announce an	Loopback IP address of the egress LSR and the egress LSR need not
	entropy label capability for the eBGP learned route.	announce an entropy label capability for the eBGP learned route.

	Authors' Addresses	Authors' Addresses

	Kireeti Kompella	Kireeti Kompella
	Juniper Networks	Juniper Networks
	1194 N. Mathilda Ave.	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089	Sunnyvale, CA 94089
	US	US

	Email: kireeti@juniper.net	Email: kireeti@juniper.net

	skipping to change at page 25, line 38 ¶	skipping to change at page 23, line 4 ¶

	Email: shane@level3.net	Email: shane@level3.net

	Wim Henderickx	Wim Henderickx
	Alcatel-Lucent	Alcatel-Lucent
	Copernicuslaan 50	Copernicuslaan 50
	2018 Antwerp	2018 Antwerp
	Belgium	Belgium

	Email: wim.henderickx@alcatel-lucent.com	Email: wim.henderickx@alcatel-lucent.com


	Lucy Yong	Lucy Yong
	Huawei USA	Huawei USA

	1700 Alma Dr. Suite 500	5340 Legacy Dr.
	Plano, TX 75075	Plano, TX 75024
	US	US


	Email: lucyyong@huawei.com	Email: lucy.yong@huawei.com

End of changes. 112 change blocks.
	579 lines changed or deleted	440 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/