draft-ietf-isis-mpls-elc-08.txt		draft-ietf-isis-mpls-elc-09.txt
	Network Working Group X. Xu		Network Working Group X. Xu
	Internet-Draft Alibaba Inc		Internet-Draft Alibaba Inc
	Intended status: Standards Track S. Kini		Intended status: Standards Track S. Kini
	Expires: March 6, 2020		Expires: April 6, 2020
	P. Psenak		P. Psenak
	C. Filsfils		C. Filsfils
	Cisco
	S. Litkowski		S. Litkowski
	Orange		Cisco
	September 3, 2019		October 4, 2019
	Signaling Entropy Label Capability and Entropy Readable Label Depth		Signaling Entropy Label Capability and Entropy Readable Label Depth
	Using IS-IS		Using IS-IS
	draft-ietf-isis-mpls-elc-08		draft-ietf-isis-mpls-elc-09
	Abstract		Abstract
	Multiprotocol Label Switching (MPLS) has defined a mechanism to load-		Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
	balance traffic flows using Entropy Labels (EL). An ingress Label		balance traffic flows using Entropy Labels (EL). An ingress Label
	Switching Router (LSR) cannot insert ELs for packets going into a		Switching Router (LSR) cannot insert ELs for packets going into a
	given Label Switched Path (LSP) unless an egress LSR has indicated		given Label Switched Path (LSP) unless an egress LSR has indicated
	via signaling that it has the capability to process ELs, referred to		via signaling that it has the capability to process ELs, referred to
	as Entropy Label Capability (ELC), on that tunnel. In addition, it		as Entropy Label Capability (ELC), on that tunnel. In addition, it
	would be useful for ingress LSRs to know each LSR's capability for		would be useful for ingress LSRs to know each LSR's capability for
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 6, 2020.		This Internet-Draft will expire on April 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 3		3. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3
	4. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		5. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4
	6. BGP-LS Extension . . . . . . . . . . . . . . . . . . . . . . 4		6. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 5		8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	9. Normative References . . . . . . . . . . . . . . . . . . . . 5		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 5
			9.2. Informative References . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	[RFC6790] describes a method to load-balance Multiprotocol Label		[RFC6790] describes a method to load-balance Multiprotocol Label
	Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use		Switching (MPLS) traffic flows using Entropy Labels (EL). "The Use
	of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the		of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the
	concept of Entropy Label Capability (ELC) and defines the signalings		concept of Entropy Label Capability (ELC) and defines the signalings
	of this capability via MPLS signaling protocols. Recently,		of this capability via MPLS signaling protocols. Recently,
	mechanisms have been defined to signal labels via link-state Interior		mechanisms have been defined to signal labels via link-state Interior
	Gateway Protocols (IGP) such as IS-IS		Gateway Protocols (IGP) such as IS-IS
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 12 ¶
	useful for ingress LSRs to know each intermediate LSR's capability of		useful for ingress LSRs to know each intermediate LSR's capability of
	reading the maximum label stack depth and performing EL-based load-		reading the maximum label stack depth and performing EL-based load-
	balancing. This capability, referred to as Entropy Readable Label		balancing. This capability, referred to as Entropy Readable Label
	Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may		Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may
	be used by ingress LSRs to determine the position of the EL label in		be used by ingress LSRs to determine the position of the EL label in
	the stack, and whether it's necessary to insert multiple ELs at		the stack, and whether it's necessary to insert multiple ELs at
	different positions in the label stack.		different positions in the label stack.
	2. Terminology		2. Terminology
	This memo makes use of the terms defined in [RFC6790] and [RFC4971].		This memo makes use of the terms defined in [RFC6790], [RFC4971] and
			[I-D.ietf-mpls-spring-entropy-label].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Advertising ERLD Using IS-IS		3. Advertising ELC Using IS-IS
	A new MSD-type of the Node MSD sub-TLV [RFC8491], called ERLD is
	defined to advertise the ERLD of a given router. As shown in
	Figure 2, it is formatted as described in [RFC8491] with a new MSD-
	Type code to be assigned by IANA (the type code of 2 is desired) and
	the Value field is set to the ERLD in the range between 0 to 255.
	The scope of the advertisement depends on the application. If a
	router has multiple line-cards with different capabilities of reading
	the maximum label stack depth, the router MUST advertise the smallest
	one.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSD-Type=TBD2 | ERLD |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: ERLD MSD-Type Format
	4. Advertising ELC Using IS-IS
	Even though ELC is a property of the node, in some cases it is		Even though ELC is a property of the node, in some cases it is
	advantageous to associate and advertise the ELC with a prefix. In a		advantageous to associate and advertise the ELC with a prefix. In a
	multi-area network, routers may not know the identity of the prefix		multi-area network, routers may not know the identity of the prefix
	originator in a remote area, or may not know the capabilities of such		originator in a remote area, or may not know the capabilities of such
	originator. Similarly in a multi-domain network, the identity of the		originator. Similarly in a multi-domain network, the identity of the
	prefix originator and its capabilities may not be known to the		prefix originator and its capabilities may not be known to the
	ingress LSR.		ingress LSR.
	One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"		One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 36 ¶
	originator in a remote area, or may not know the capabilities of such		originator in a remote area, or may not know the capabilities of such
	originator. Similarly in a multi-domain network, the identity of the		originator. Similarly in a multi-domain network, the identity of the
	prefix originator and its capabilities may not be known to the		prefix originator and its capabilities may not be known to the
	ingress LSR.		ingress LSR.
	One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"		One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"
	registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by		registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by
	the IANA for the ELC. If a router has multiple line cards, the		the IANA for the ELC. If a router has multiple line cards, the
	router MUST NOT announce the ELC for any prefixes that are locally		router MUST NOT announce the ELC for any prefixes that are locally
	attached unless all of its line-cards are capable of processing ELs.		attached unless all of its line-cards are capable of processing ELs.
	If a router supports ELs on all of its line-cards, it SHOULD set the		If a router supports ELs on all of its line-cards, it SHOULD set the
	ELC for every local host prefix it advertises in IS-IS.		ELC for every local host prefix it advertises in IS-IS.
	When a router leaks a prefix between two levels (upwards or
	downwards), it MUST preserve the ELC signaling for this prefix.
	0 1 2 3 4 5 6 7...		0 1 2 3 4 5 6 7...
	+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+...
	|X|R|N|E| ...		|X|R|N|E| ...
	+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+...
			Figure 1: Prefix Attribute Flags
			E-flag: ELC Flag (Bit 3)
			Set for local host prefix of the originating node
			if it supports ELC.
			When a router leaks a prefix between two levels (upwards or
			downwards), it MUST preserve the ELC signaling for this prefix.
	When redistributing a prefix between two IS-IS protocol instances or		When redistributing a prefix between two IS-IS protocol instances or
	redistributing from another protocol to an IS-IS protocol instance, a		redistributing from another protocol to an IS-IS protocol instance, a
	router SHOULD preserve the ELC signaling for that prefix. The exact		router SHOULD preserve the ELC signaling for that prefix. The exact
	mechanism used to exchange ELC between protocol instances running on		mechanism used to exchange ELC between protocol instances running on
	an ASBR is outside of the scope of this document and is		an ASBR is outside of the scope of this document and is
	implementation specific.		implementation specific.
	5. Acknowledgements		4. Acknowledgements
	The authors would like to thank Yimin Shen, George Swallow, Acee		The authors would like to thank Yimin Shen, George Swallow, Acee
	Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene		Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene
	Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their		Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their
	valuable comments.		valuable comments.
	6. BGP-LS Extension		5. Advertising ERLD Using IS-IS
			A new MSD-type of the Node MSD ((Maximum SID Depth) sub-TLV
			[RFC8491], called ERLD is defined to advertise the ERLD of a given
			router. As shown in Figure 2, it is formatted as described in
			[RFC8491] with a new MSD-Type code to be assigned by IANA (the type
			code of 2 is desired) and the Value field is set to the ERLD in the
			range between 0 to 255. The scope of the advertisement depends on
			the application. If a router has multiple line-cards with different
			capabilities of reading the maximum label stack depth, the router
			MUST advertise the smallest one.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MSD-Type=TBD2 | ERLD |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: ERLD MSD-Type Format
			When the ERLD MSD-Type is received in the Link MSD Sub-TLV, it MUST
			be ignored.
			6. Signaling ELC and ERLD in BGP-LS
	The IS-IS extensions defined in this document can be advertised via		The IS-IS extensions defined in this document can be advertised via
	BGP-LS [RFC7752] using existing BGP-LS TLVs.		BGP-LS [RFC7752] using existing BGP-LS TLVs.
	The ELC Flag included in the Prefix Attribute Flags sub-TLV, as		The ELC Flag included in the Prefix Attribute Flags sub-TLV, as
	defined in Section 4, is advertised using the Prefix Attribute Flags		defined in Section 3, is advertised using the Prefix Attribute Flags
	TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as		TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as
	defined in section 2.3.2 of		defined in section 2.3.2 of
	[I-D.ietf-idr-bgp-ls-segment-routing-ext].		[I-D.ietf-idr-bgp-ls-segment-routing-ext].
	The ERLD MSD-type introduced for IS-IS in Section 3 is advertised		The ERLD MSD-type introduced for IS-IS in Section 5 is advertised
	using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as		using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
	defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext].		defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd].
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate the E-bit (bit position 3 is desired)		IANA is requested to allocate the E-bit (bit position 3 is desired)
	from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.		from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.
	IANA is requested to allocate a MSD type (the type code of 2 is		IANA is requested to allocate a MSD type (the type code of 2 is
	desired) from the "IGP MSD Types" registry for ERLD.		desired) from the "IGP MSD Types" registry for ERLD.
	8. Security Considerations		8. Security Considerations
	The security considerations as described in [RFC4971] nd		The security considerations as described in [RFC4971] nd
	[I-D.ietf-mpls-spring-entropy-label] are applicable to this document.		[I-D.ietf-mpls-spring-entropy-label] are applicable to this document.
	Incorrectly setting the E flag (ELC capable) (during origination,		Incorrectly setting the E flag (ELC capable) (during origination,
	leaking or redistribution) may lead to black-holing of the traffic on		leaking or redistribution) may lead to black-holing of the traffic on
	the egress node.		the egress node.
	9. Normative References		Incorrectly setting of the ERLD value may lead to poor load-balancing
			of the traffic.
			9. References
			9.1. Normative References
	[I-D.ietf-idr-bgp-ls-segment-routing-ext]		[I-D.ietf-idr-bgp-ls-segment-routing-ext]
	Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,		Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
	and M. Chen, "BGP Link-State extensions for Segment		and M. Chen, "BGP Link-State extensions for Segment
	Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16		Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16
	(work in progress), June 2019.		(work in progress), June 2019.
	[I-D.ietf-isis-segment-routing-extensions]		[I-D.ietf-idr-bgp-ls-segment-routing-msd]
	Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,		Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,
	Gredler, H., and B. Decraene, "IS-IS Extensions for		and N. Triantafillis, "Signaling MSD (Maximum SID Depth)
	Segment Routing", draft-ietf-isis-segment-routing-		using Border Gateway Protocol Link-State", draft-ietf-idr-
	extensions-25 (work in progress), May 2019.		bgp-ls-segment-routing-msd-08 (work in progress),
			September 2019.
	[I-D.ietf-mpls-spring-entropy-label]		[I-D.ietf-mpls-spring-entropy-label]
	Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,		Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
	Shakir, R., and J. Tantsura, "Entropy label for SPRING		Shakir, R., and J. Tantsura, "Entropy label for SPRING
	tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in		tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in
	progress), July 2018.		progress), July 2018.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 47 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,		[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
	"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,		"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
	DOI 10.17487/RFC8491, November 2018,		DOI 10.17487/RFC8491, November 2018,
	<https://www.rfc-editor.org/info/rfc8491>.		<https://www.rfc-editor.org/info/rfc8491>.
			9.2. Informative References
			[I-D.ietf-isis-segment-routing-extensions]
			Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
			Gredler, H., and B. Decraene, "IS-IS Extensions for
			Segment Routing", draft-ietf-isis-segment-routing-
			extensions-25 (work in progress), May 2019.
	Authors' Addresses		Authors' Addresses
	Xiaohu Xu		Xiaohu Xu
	Alibaba Inc		Alibaba Inc
	Email: xiaohu.xxh@alibaba-inc.com		Email: xiaohu.xxh@alibaba-inc.com
	Sriganesh Kini		Sriganesh Kini
	Email: sriganeshkini@gmail.com		Email: sriganeshkini@gmail.com
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 31 ¶
	Peter Psenak		Peter Psenak
	Cisco		Cisco
	Email: ppsenak@cisco.com		Email: ppsenak@cisco.com
	Clarence Filsfils		Clarence Filsfils
	Cisco		Cisco
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Stephane Litkowski		Stephane Litkowski
	Orange		Cisco
	Email: stephane.litkowski@orange.com		Email: sslitkows@cisco.com
End of changes. 23 change blocks.
	50 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/