draft-ietf-ospf-ospfv2-hbit-11.txt		draft-ietf-ospf-ospfv2-hbit-12.txt
	OSPF K. Patel		OSPF K. Patel
	Internet-Draft Arrcus		Internet-Draft Arrcus
	Updates: 6987 (if approved) P. Pillay-Esnault		Updates: 6987 (if approved) P. Pillay-Esnault
	Intended status: Standards Track PPE Consulting		Intended status: Standards Track PPE Consulting
	Expires: May 19, 2020 M. Bhardwaj		Expires: June 20, 2020 M. Bhardwaj
	S. Bayraktar		S. Bayraktar
	Cisco Systems		Cisco Systems
	November 16, 2019		December 18, 2019
	Host Router Support for OSPFv2		Host Router Support for OSPFv2
	draft-ietf-ospf-ospfv2-hbit-11		draft-ietf-ospf-ospfv2-hbit-12
	Abstract		Abstract
	The Open Shortest Path First Version 2 (OSPFv2) does not have a		The Open Shortest Path First Version 2 (OSPFv2) protocol does not
	mechanism for a node to repel transit traffic if it is on the		have a mechanism for a node to repel transit traffic if it is on the
	shortest path. This document defines a bit (Host-bit) that enables a		shortest path. This document defines a bit (Host-bit) that enables a
	router to advertise that it is a non-transit router. It also		router to advertise that it is a non-transit router. It also
	describes the changes needed to support the H-bit in the domain. In		describes the changes needed to support the H-bit in the domain. In
	addition, this document updates RFC 6987 to advertise type-2 External		addition, this document updates RFC 6987 to advertise type-2 External
	and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a		and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
	high cost in order to repel traffic effectively.		high cost in order to repel traffic effectively.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	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 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 May 19, 2020.		This Internet-Draft will expire on June 20, 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The OSPFv2 specifies a Shortest Path First (SPF) algorithm that		The OSPFv2 protocol specifies a Shortest Path First (SPF) algorithm
	identifies transit vertices based on their adjacencies. Therefore,		that identifies transit vertices based on their adjacencies.
	OSPFv2 does not have a mechanism to prevent traffic transiting a		Therefore, OSPFv2 does not have a mechanism to prevent traffic
	participating node if it is a transit vertex in the only existing or		transiting a participating node if it is a transit vertex in the only
	shortest path to the destination. The use of metrics to make the		existing or shortest path to the destination. The use of metrics to
	node undesirable can help to repel traffic only if an alternative		make the node undesirable can help to repel traffic only if an
	better route exists.		alternative better route exists.
	This functionality is particularly useful for a number of use cases:		A mechanism to move traffic away from the shortest path is
			particularly useful for a number of use cases:
	1. To gracefully isolate a router to avoid blackhole scenarios when		1. To gracefully isolate a router to avoid blackhole scenarios when
	there is a reload and possible long reconvergence times.		there is a reload and possible long reconvergence times.
	2. Closet Switches are usually not used for transit traffic but need		2. Closet Switches are usually not used for transit traffic but need
	to participate in the topology.		to participate in the topology.
	3. Overloaded routers could use such a capability to temporarily		3. Overloaded routers could use such a capability to temporarily
	repel traffic until they stabilize.		repel traffic until they stabilize.
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	AS-external-LSAs if the H-bit is set. Some use cases, such as an		AS-external-LSAs if the H-bit is set. Some use cases, such as an
	overloaded router or a router being gracefully isolated, may benefit		overloaded router or a router being gracefully isolated, may benefit
	from continued advertisement of non-local prefixes. In these cases,		from continued advertisement of non-local prefixes. In these cases,
	the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to		the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to
	repel traffic.(see Section 6 of this document).		repel traffic.(see Section 6 of this document).
	4. SPF Modifications		4. SPF Modifications
	The SPF calculation described in section 16.1 [RFC2328] will be		The SPF calculation described in section 16.1 [RFC2328] will be
	modified to ensure that the routers originating router-LSAs with the		modified to ensure that the routers originating router-LSAs with the
	H-bit set will not be used for transit traffic. Step 2 is modified		H-bit set will not be used for transit traffic. The Step 2 is
	as follows:		modified to include a check on H-bit as shown below. (Please note
			all the sub-procedures of Step 2 remain unchanged and not included in
			the excerpt below.)
	2) Call the vertex just added to the		2) Call the vertex just added to the
	tree vertex V. Examine the LSA		tree vertex V. Examine the LSA
	associated with vertex V. This is		associated with vertex V. This is
	a lookup in the Area A's link state		a lookup in the Area A's link state
	database based on the Vertex ID. If		database based on the Vertex ID. If
	this is a router-LSA, and the H-bit		this is a router-LSA, and the H-bit
	of the router-LSA is set, and		of the router-LSA is set, and
	vertex V is not the root, then the		vertex V is not the root, then the
	router should not be used for transit		router should not be used for transit
	and step (3) should be executed		and step (3) should be executed
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 40 ¶
	7 Host Router Support capability		7 Host Router Support capability
	Table 1: OSPF Router Information LSA Capabilities		Table 1: OSPF Router Information LSA Capabilities
	Auto Discovery via announcement of the Host Router Support Capability		Auto Discovery via announcement of the Host Router Support Capability
	ensures that the H-bit functionality and its associated SPF changes		ensures that the H-bit functionality and its associated SPF changes
	MUST only take effect if all the routers in a given OSPF area support		MUST only take effect if all the routers in a given OSPF area support
	this functionality.		this functionality.
	In normal operation, there is no guarantee that the RI LSA will reach		In normal operation, it is possible that the RI LSA will fail to
	all routers in an area in a timely manner, which may result in		reach all routers in an area in a timely manner. For example, if a
	forwarding loops in partial deployments. For example, if a new		new router without H-bit support joins an area that previously had
	router joins an area, which previously had only H-bit capable routers		only H-bit capable routers with H-bit set then it may take some time
	with H-bit set then it may take some time for the RI to propagate to		for the RI to propagate to all routers. While it is propagating, the
	all routers.		routers in the area will gradually detect the presence of a router
			not supporting the capability and revert back to normal SPF
			calculation. During the propagation time, the area as a whole is
			unsure of the status of the new router, and that can cause temporary
			transient loops.
	The following recommendations will mitigate transient routing loops:		The following recommendations will mitigate transient routing loops:
	o Implementations are RECOMMENDED to provide a configuration		o Implementations are RECOMMENDED to provide a configuration
	parameter to manually override enforcement of the H-bit		parameter to manually override enforcement of the H-bit
	functionality in partial deployments where the topology guarantees		functionality in partial deployments where the topology guarantees
	that OSPFv2 routers not supporting the H-bit do not compute routes		that OSPFv2 routers not supporting the H-bit do not compute routes
	resulting in routing loops.		resulting in routing loops.
	o All routers, with the H-bit set, MUST advertise all of the		o All routers with the H-bit set MUST advertise all of the router's
	router's non-stub links with a metric equal to MaxLinkMetric		non-stub links with a metric equal to MaxLinkMetric [RFC6987] in
	[RFC6987] in its LSAs in order to avoid OSPFv2 (unless last		its LSAs in order to avoid OSPFv2 (unless last resort) routers not
	resort) routers not supporting the H-bit from attempting to use it		supporting the H-bit from attempting to use it for transit
	for transit traffic.		traffic.
	o All routers supporting H-Bit MUST check all the RI LSAs of nodes		o All routers supporting the H-Bit MUST check the RI LSAs of all
	in the area before actively running the modified SPF to account		nodes in the area to verify that all nodes support the H-Bit
	for the H-bit in order to verify that all routers are in routing		before actively using the H-Bit feature. If any router does not
	capability. If any router does not advertise the Host Router		advertise the Host Router Support capability then the SPF
	Support capability then the SPF Modifications (Section 4) MUST NOT		Modifications (Section 4) MUST NOT be used in the area.
	be used in the area.
	6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics		6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics
	When calculating the path to an OSPF AS-External-LSA or NSSA-LSA		When calculating the path to a prefix in an OSPF AS-External-LSA or
	[RFC3101] with a Type-2 metric, the advertised Type-2 metric is taken		NSSA-LSA [RFC3101] with a Type-2 metric, the advertised Type-2 metric
	as more significant than the OSPF intra-area or inter-area path.		is taken as more significant than the OSPF intra-area or inter-area
	Hence, advertising the links with MaxLinkMetric as specified in		path. Hence, advertising the links with MaxLinkMetric as specified
	[RFC6987] does not discourage transit traffic when calculating AS		in [RFC6987] does not discourage transit traffic when calculating AS
	external or NSSA routes with Type-2 metrics.		external or NSSA routes with Type-2 metrics.
	Consequently, [RFC6987] is updated so that the Type-2 metric in any		Consequently, [RFC6987] is updated so that the Type-2 metric in any
	self-originated AS-External-LSAs or NSSA-LSAs is advertised as		self-originated AS-External-LSAs or NSSA-LSAs is advertised as
	LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric		LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric
	MUST be set to LSInfinity.		MUST be set to LSInfinity.
	7. IANA Considerations		7. IANA Considerations
	This document requests the IANA to assign the 0x80 value to the Host-		This document requests the IANA to assign the 0x80 value to the Host-
End of changes. 12 change blocks.
	39 lines changed or deleted		44 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/