draft-ietf-isis-reverse-metric-12-review.txt		draft-ietf-isis-reverse-metric-12-review-2.txt
	Networking Working Group N. Shen		Networking Working Group N. Shen
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track S. Amante		Intended status: Standards Track S. Amante
	Expires: March 28, 2019 Apple, Inc.		Expires: March 31, 2019 Apple, Inc.
	M. Abrahamsson		M. Abrahamsson
	T-Systems Nordic		T-Systems Nordic
	September 24, 2018		September 27, 2018
	IS-IS Routing with Reverse Metric		IS-IS Routing with Reverse Metric
	draft-ietf-isis-reverse-metric-12		draft-ietf-isis-reverse-metric-12
	Abstract		Abstract
	This document describes a mechanism to allow IS-IS routing to quickly		This document describes a mechanism to allow IS-IS routing to quickly
	and accurately shift traffic away from either a point-to-point or		and accurately shift traffic away from either a point-to-point or
	multi-access LAN interface during network maintenance or other		multi-access LAN interface during network maintenance or other
	operational events. This is accomplished by signaling adjacent IS-IS		operational events. This is accomplished by signaling adjacent IS-IS
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 March 28, 2019.		This Internet-Draft will expire on March 31, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9		3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12		Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12
	Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12		Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12
	Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13		Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The IS-IS [ISO10589] routing protocol has been widely used in		The IS-IS [ISO10589] routing protocol has been widely used in
	Internet Service Provider IP/MPLS networks. Operational experience		Internet Service Provider IP/MPLS networks. Operational experience
	with the protocol, combined with ever increasing requirements for		with the protocol, combined with ever increasing requirements for
	lossless operations have demonstrated some operational issues. This		lossless operations have demonstrated some operational issues. This
	document describes the issues and a mechanism for mitigating them.		document describes the issues and a mechanism for mitigating them.
	1.1. Node and Link Isolation		1.1. Node and Link Isolation
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Flags | Metric		| Type | Length | Flags | Metric
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Metric (Continue) | sub-TLV Len |Optional sub-TLV		Metric (Continue) | sub-TLV Len |Optional sub-TLV
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Reverse Metric TLV		Figure 1: Reverse Metric TLV
	The Value part of the Reverse Metric TLV is composed of a 3 octet		The Value part of the Reverse Metric TLV is composed of a 3 octet
	field containing an IS-IS Metric Value, a 1 octet field of Flags, and		field containing an IS-IS Metric Value, a 1 octet field of Flags, and
	a 1 octet Traffic Engineering (TE) sub-TLV length field representing		a 1 octet Reverse Metric sub-TLV length field representing the length
	the length of a variable number of sub-TLVs. If the "sub-TLV len" is		of a variable number of sub-TLVs. If the "sub-TLV len" is non-zero,
	non-zero, then the Value field MUST also contain one or more Extended		then the Value field MUST also contain one or more sub-TLVs.
	IS Reachability sub-TLVs [RFC5305].
	The Reverse Metric TLV may be optionally present in any IS-IS Hello		The Reverse Metric TLV MAY be optionally present in any IS-IS Hello
	PDU. A sender MUST only transmit a single Reverse Metric TLV in a		PDU. A sender MUST only transmit a single Reverse Metric TLV in a
	IS-IS Hello PDU. If a received IS-IS Hello PDU contains more than		IS-IS Hello PDU. If a received IS-IS Hello PDU contains more than
	one Reverse Metric TLV, an implementation MUST ignore all the Reverse		one Reverse Metric TLV, an implementation MUST ignore all the Reverse
	Metric TLVs. If an IS-IS node received of IS-IS Reverse Metric TLV		Metric TLVs.
	in the PDU other than the IS-IS Hello PDU, this TLV MUST be ignored.
	TYPE: 16		TYPE: 16
	LENGTH: variable (5 - 255 octets)		LENGTH: variable (5 - 255 octets)
	VALUE:		VALUE:
	Flags (1 octet)		Flags (1 octet)
	Metric (3 octets)		Metric (3 octets)
	sub-TLV length (1 octet)		sub-TLV length (1 octet)
	sub-TLV data (0 - 250 octets)		sub-TLV data (0 - 250 octets)
	skipping to change at page 6, line 15		skipping to change at page 6, line 14
	transmitted in an IIH PDU on a point-to-point link, and MUST be		transmitted in an IIH PDU on a point-to-point link, and MUST be
	ignored when received on a point-to-point link.		ignored when received on a point-to-point link.
	U bit (0x02): The "Unreachable" bit specifies that the metric		U bit (0x02): The "Unreachable" bit specifies that the metric
	calculated by addition of the reverse metric value to the "default		calculated by addition of the reverse metric value to the "default
	metric" is limited to (2^24-1). This "U" bit applies to both the		metric" is limited to (2^24-1). This "U" bit applies to both the
	default metric in the Extended IS Reachability TLV and the Traffic		default metric in the Extended IS Reachability TLV and the Traffic
	Engineering Default Metric sub-TLV of the link. This is only		Engineering Default Metric sub-TLV of the link. This is only
	relevant to the IS-IS "wide" metric mode.		relevant to the IS-IS "wide" metric mode.
			The Reserved bits of Flags field MUST be set to zero and MUST be
			ignored when received.
	The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router		The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router
	wishes to signal to its neighbor to raise its Traffic Engineering		wishes to signal additional information to its neighbor. In this
	(TE) Metric over the link. The Sub-TLV Type 18, the "Traffic		document, the Reverse Metric Traffic Engineering Metric sub-TLV, with
	Engineering Default Metric" sub-TLV [RFC5305], is defined to be		Type 18, is defined. This Traffic Engineering Metric contains a
	included in the Reverse Metric TLV. Upon receiving this Traffic		24-bit unsigned integer. This sub-TLV is optional, and MUST appear
	Engineering METRIC sub-TLV in a Reverse Metric TLV, a node SHOULD add		once at most in the Reverse Metric TLV, otherwise the entire Reverse
	the received Traffic Engineering Default Metric offset value to its		Metric TLV MUST be ignore on the receive. Upon receiving this
	existing, configured Traffic Engineering Default Metric within its		Traffic Engineering METRIC sub-TLV in a Reverse Metric TLV, a node
	Extended IS Reachability TLV. Use of other sub-TLVs is outside the		SHOULD add the received Traffic Engineering Metric offset value to
	scope of this document. The "sub-TLV Len" value MUST be set to zero		its existing, configured Traffic Engineering Default Metric within
	when an IS-IS router does not have Traffic Engineering sub-TLVs that		its Extended IS Reachability TLV. The use of other sub-TLVs is
	it wishes to send to its IS-IS neighbor.		outside the scope of this document. The "sub-TLV Len" value MUST be
			set to zero when an IS-IS router does not have Traffic Engineering
			sub-TLVs that it wishes to send to its IS-IS neighbor.
	3. Elements of Procedure		3. Elements of Procedure
	3.1. Processing Changes to Default Metric		3.1. Processing Changes to Default Metric
	It is important to use the same IS-IS metric type on both ends of the		It is important to use the same IS-IS metric type on both ends of the
	link and in the entire IS-IS area or level. On the receiving side of		link and in the entire IS-IS area or level. On the receiving side of
	the 'reverse-metric' TLV, the accumulated value of configured metric		the 'reverse-metric' TLV, the accumulated value of configured metric
	and the reverse-metric needs to be limited to 63 in "narrow" metric		and the reverse-metric needs to be limited to 63 in "narrow" metric
	mode and to (2^24 - 2) in "wide" metric mode. This applies to both		mode and to (2^24 - 2) in "wide" metric mode. This applies to both
	skipping to change at page 9, line 40		skipping to change at page 9, line 42
	link. It is RECOMMENDED also that the CSPF does the immediate CSPF		link. It is RECOMMENDED also that the CSPF does the immediate CSPF
	re-calculation when the Traffic Engineering metric is raised to (2^24		re-calculation when the Traffic Engineering metric is raised to (2^24
	- 2) to be the last resort link.		- 2) to be the last resort link.
	It is RECOMMENDED that implementations provide a capability to		It is RECOMMENDED that implementations provide a capability to
	disable any changes by Reverse Metric mechanism through neighbor's		disable any changes by Reverse Metric mechanism through neighbor's
	Hello PDUs. It can be to a node's individual interface Default		Hello PDUs. It can be to a node's individual interface Default
	Metric or Traffic Engineering parameters based upon receiving a		Metric or Traffic Engineering parameters based upon receiving a
	properly formatted Reverse Metric TLVs.		properly formatted Reverse Metric TLVs.
			It is RECOMMENDED that the network operators disable the capability
			when this Reverse Metric feature or mechanism is not being used in
			the network where in the case an IS-IS implementation has this
			mechanism enabled by default.
	4. Security Considerations		4. Security Considerations
	The enhancement in this document makes it possible for one IS-IS		The enhancement in this document makes it possible for one IS-IS
	router to manipulate the IS-IS Default Metric and, optionally,		router to manipulate the IS-IS Default Metric and, optionally,
	Traffic Engineering parameters of adjacent IS-IS neighbors. Although		Traffic Engineering parameters of adjacent IS-IS neighbors. Although
	IS-IS routers within a single Autonomous System nearly always are		IS-IS routers within a single Autonomous System nearly always are
	under the control of a single administrative authority, it is highly		under the control of a single administrative authority, it is highly
	RECOMMENDED that operators configure authentication of IS-IS PDUs to		RECOMMENDED that operators configure authentication of IS-IS PDUs to
	mitigate use of the Reverse Metric TLV as a potential attack vector,		mitigate use of the Reverse Metric TLV as a potential attack vector,
	particularly on multi-access LANs.		particularly on multi-access LANs.
End of changes. 10 change blocks.
	22 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/