draft-ietf-ospf-mpls-elc-14.txt		draft-ietf-ospf-mpls-elc-15.txt
	LSR Working Group X. Xu		LSR 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: November 29, 2020		Expires: December 3, 2020
	P. Psenak		P. Psenak
	C. Filsfils		C. Filsfils
	S. Litkowski		S. Litkowski
	Cisco Systems, Inc.		Cisco Systems, Inc.
	M. Bocci		M. Bocci
	Nokia		Nokia
	May 28, 2020		June 1, 2020
	Signaling Entropy Label Capability and Entropy Readable Label Depth		Signaling Entropy Label Capability and Entropy Readable Label Depth
	Using OSPF		Using OSPF
	draft-ietf-ospf-mpls-elc-14		draft-ietf-ospf-mpls-elc-15
	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 the Entropy Label Capability (ELC), on that LSP. In addition, it		as the Entropy Label Capability (ELC), on that LSP. 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 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 November 29, 2020.		This Internet-Draft will expire on December 3, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 ELC Using OSPF . . . . . . . . . . . . . . . . . 3		3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3
	3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 4		3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 3
	3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4		3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4
	4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4		4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4
	5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 5		5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10.1. Normative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	originator. Similarly, in a multi domain network, the identity of		originator. Similarly, in a multi domain network, the identity of
	the prefix originator and its capabilities may not be known to the		the prefix originator and its capabilities may not be known to the
	ingress LSR.		ingress LSR.
	If a router has multiple interfaces, the router MUST NOT announce ELC		If a router has multiple interfaces, the router MUST NOT announce ELC
	unless all of its interfaces are capable of processing ELs.		unless all of its interfaces are capable of processing ELs.
	If the router supports ELs on all of its interfaces, it SHOULD		If the router supports ELs on all of its interfaces, it SHOULD
	advertise the ELC with every local host prefix it advertises in OSPF.		advertise the ELC with every local host prefix it advertises in OSPF.
			3.1. Advertising ELC Using OSPFv2
			[RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise
			additional attributes associated with a prefix. The OSPFv2 Extended
			Prefix TLV includes a one-octet Flags field. A new flag in the Flags
			field is used to signal the ELC for the prefix:
			0x20 - E-Flag (ELC Flag): Set by the advertising router to
			indicate that the prefix originator is capable of processing ELs.
	The ELC signaling MUST be preserved when an OSPF Area Border Router		The ELC signaling MUST be preserved when an OSPF Area Border Router
	(ABR) distributes information between areas. To do so, an ABR MUST		(ABR) distributes information between areas. To do so, an ABR MUST
	originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including		originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including
	the received ELC setting.		the received ELC setting.
	When an OSPF Autonomous System Boundary Router (ASBR) redistributes a		When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
	prefix from another instance of OSPF or from some other protocol, it		prefix from another instance of OSPF or from some other protocol, it
	SHOULD preserve the ELC signaling for the prefix if it exists. To do		SHOULD preserve the ELC signaling for the prefix if it exists. To do
	so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684]		so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684]
	including the ELC setting of the redistributed prefix. The flooding		including the ELC setting of the redistributed prefix. The flooding
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 14 ¶
	originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including		originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including
	the received ELC setting.		the received ELC setting.
	When an OSPF Autonomous System Boundary Router (ASBR) redistributes a		When an OSPF Autonomous System Boundary Router (ASBR) redistributes a
	prefix from another instance of OSPF or from some other protocol, it		prefix from another instance of OSPF or from some other protocol, it
	SHOULD preserve the ELC signaling for the prefix if it exists. To do		SHOULD preserve the ELC signaling for the prefix if it exists. To do
	so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684]		so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684]
	including the ELC setting of the redistributed prefix. The flooding		including the ELC setting of the redistributed prefix. The flooding
	scope of the Extended Prefix Opaque LSA MUST match the flooding scope		scope of the Extended Prefix Opaque LSA MUST match the flooding scope
	of the LSA that an ASBR originates as a result of the redistribution.		of the LSA that an ASBR originates as a result of the redistribution.
	The exact mechanism used to exchange ELC between protocol instances		The exact mechanism used to exchange ELC between protocol instances
	on an ASBR is outside of the scope of this document.		on an ASBR is outside of the scope of this document.
	3.1. Advertising ELC Using OSPFv2
	[RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise
	additional attributes associated with a prefix. The OSPFv2 Extended
	Prefix TLV includes a one-octet Flags field. A new flag in the Flags
	field is used to signal the ELC for the prefix:
	0x20 - E-Flag (ELC Flag): Set by the advertising router to
	indicate that the prefix originator is capable of processing ELs.
	3.2. Advertising ELC Using OSPFv3		3.2. Advertising ELC Using OSPFv3
	[RFC5340] defines the OSPFv3 PrefixOptions field to indicate		[RFC5340] defines the OSPFv3 PrefixOptions field to indicate
	capabilities associated with a prefix. A new bit in the OSPFv3		capabilities associated with a prefix. A new bit in the OSPFv3
	PrefixOptions is used to signal the ELC for the prefix:		PrefixOptions is used to signal the ELC for the prefix:
	0x40 - E-Flag (ELC Flag): Set by the advertising router to		0x40 - E-Flag (ELC Flag): Set by the advertising router to
	indicate that the prefix originator is capable of processing ELs.		indicate that the prefix originator is capable of processing ELs.
	The ELC signaling MUST be preserved when an OSPFv3 Area Border		The ELC signaling MUST be preserved when an OSPFv3 Area Border
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,		Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,
	and N. Triantafillis, "Signaling MSD (Maximum SID Depth)		and N. Triantafillis, "Signaling MSD (Maximum SID Depth)
	using Border Gateway Protocol - Link State", draft-ietf-		using Border Gateway Protocol - Link State", draft-ietf-
	idr-bgp-ls-segment-routing-msd-18 (work in progress), May		idr-bgp-ls-segment-routing-msd-18 (work in progress), May
	2020.		2020.
	[I-D.ietf-isis-mpls-elc]		[I-D.ietf-isis-mpls-elc]
	Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,		Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
	and M. Bocci, "Signaling Entropy Label Capability and		and M. Bocci, "Signaling Entropy Label Capability and
	Entropy Readable Label Depth Using IS-IS", draft-ietf-		Entropy Readable Label Depth Using IS-IS", draft-ietf-
	isis-mpls-elc-12 (work in progress), April 2020.		isis-mpls-elc-13 (work in progress), May 2020.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,		for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
	<https://www.rfc-editor.org/info/rfc5340>.		<https://www.rfc-editor.org/info/rfc5340>.
End of changes. 9 change blocks.
	17 lines changed or deleted		16 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/