rfc9929v1.txt		rfc9929.txt
	skipping to change at line 111 ¶		skipping to change at line 111 ¶
	The growth of networks running a link-state routing protocol results		The growth of networks running a link-state routing protocol results
	in the addition of more state, which leads to scalability and		in the addition of more state, which leads to scalability and
	convergence challenges. The organization of networks into levels/		convergence challenges. The organization of networks into levels/
	areas and IGP domains helps limit the scope of link-state information		areas and IGP domains helps limit the scope of link-state information
	within certain boundaries. However, the state related to prefix		within certain boundaries. However, the state related to prefix
	reachability often requires propagation across a multi-area/level		reachability often requires propagation across a multi-area/level
	and/or multi-domain IGP network. IGP summarization is a network		and/or multi-domain IGP network. IGP summarization is a network
	engineering technique for combining multiple smaller, contiguous IP		engineering technique for combining multiple smaller, contiguous IP
	networks into a single, larger summary route. Techniques such as		networks into a single, larger summary route. Techniques such as
	summarization have been used traditionally to address the scaling		summarization have been used to address the scaling challenges
	challenges associated with advertising prefix state outside of the		associated with advertising prefix state outside of the local area/
	local area/domain. However, this results in suppression of the		domain. However, this results in suppression of the individual
	individual prefix state that is useful for triggering fast-		prefix state that is useful for triggering fast-convergence
	convergence mechanisms outside of the IGPs -- e.g., Border Gateway		mechanisms outside of the IGPs -- e.g., Border Gateway Protocol (BGP)
	Protocol (BGP) Prefix-Independent Convergence (PIC) [BGP-PIC].		Prefix-Independent Convergence (PIC) [BGP-PIC].
	Similarly, when a router needs to be taken out of service for		Similarly, when a router needs to be taken out of service for
	maintenance, the traffic is drained from the node before taking it		maintenance, the traffic is drained from the node before taking it
	down. This is typically achieved by setting the OVERLOAD bit		down. This is typically achieved by setting the OVERLOAD bit
	together with using a high metric for all prefixes advertised by the		together with using a high metric for all prefixes advertised by the
	node in IS-IS. In OSPFv2 using the cost of MaxLinkMetric for all		node in IS-IS. The mechanisms available for that purpose are (in
	non-stub links in the router-LSA [RFC6987], or H-bit [RFC8770], and		OSPFv2) using the cost of MaxLinkMetric for all non-stub links in the
	R-bit for OSPFv3 [RFC5340] are mechanisms available for that purpose.		router-LSA [RFC6987] or using the H-bit [RFC8770], or (in OSPFv3
			[RFC5340]) using the R-bit.
	When prefixes from such nodes are summarized by an Area Border Router		When prefixes from such nodes are summarized by an Area Border Router
	(ABR) or Autonomous System Boundary Router (ASBR), nodes outside of		(ABR) or Autonomous System Boundary Router (ASBR), nodes outside of
	the area or domain are unaware of these summarized prefixes becoming		the area or domain are unaware of these summarized prefixes becoming
	unreachable. This document proposes protocol extensions to carry		unreachable. This document proposes protocol extensions to carry
	information about such prefixes in a backward-compatible manner.		information about such prefixes in a backward-compatible manner.
	This document does not define how to advertise a prefix that is not		This document does not define how to advertise a prefix that is not
	reachable for routing. That has been defined for IS-IS in [RFC5305]		reachable for routing. That has been defined for IS-IS in [RFC5305]
	and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].		and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].
	skipping to change at line 175 ¶		skipping to change at line 176 ¶
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Generation of the UPA		2. Generation of the UPA
	UPA MAY be generated by an ABR or ASBR for a prefix that is		UPA MAY be generated by an ABR or ASBR for a prefix that is
	summarized by the summary prefix originated by an ABR or ASBR in the		summarized by the summary prefix originated by an ABR or ASBR in the
	following cases:		following cases:
	1. Reachability of a prefix that was reachable earlier was lost.		1. A prefix that was reachable earlier becomes unreachable.
	2. For any of the planned maintenance cases:		2. For any of the planned maintenance cases:
	* if the node originating the prefix is signaling the overload		* the node originating the prefix is signaling the overload
	state in IS-IS, or H-bit in OSPFv2 [RFC8770], or R-bit in		state in IS-IS, or the H-bit in OSPFv2 [RFC8770], or the R-bit
	OSPFv3 [RFC5340].		in OSPFv3 [RFC5340].
	* the metric to reach the prefix from an ABR or ASBR crosses the		* the metric to reach the prefix from an ABR or ASBR crosses the
	configured threshold.		configured threshold.
	Generation as well as propagation of the UPA at an ABR or ASBR is		Generation as well as propagation of the UPA at an ABR or ASBR is
	optional and SHOULD be controlled by a configuration knob. It SHOULD		optional and SHOULD be controlled by a configuration knob. It SHOULD
	be disabled by default.		be disabled by default.
	Implementations MAY limit the UPA generation as well as propagation		Implementations MAY limit the UPA generation as well as propagation
	to specific prefixes, e.g. host prefixes, Segment Routing over IPv6		to specific prefixes, e.g. host prefixes, Segment Routing over IPv6
	skipping to change at line 210 ¶		skipping to change at line 211 ¶
	reason for which the UPA was generated ceases, e.g., prefix		reason for which the UPA was generated ceases, e.g., prefix
	reachability was restored or its metric has changed such that it is		reachability was restored or its metric has changed such that it is
	below a configured threshold value.		below a configured threshold value.
	Even if the reasons persist, UPA advertisements SHOULD be withdrawn		Even if the reasons persist, UPA advertisements SHOULD be withdrawn
	after some amount of time, that would provide sufficient time for UPA		after some amount of time, that would provide sufficient time for UPA
	to be flooded network-wide and acted upon by receiving nodes, but		to be flooded network-wide and acted upon by receiving nodes, but
	limits the presence of UPA in the network. The time the UPA is kept		limits the presence of UPA in the network. The time the UPA is kept
	in the network SHOULD also reflect the intended use case for which		in the network SHOULD also reflect the intended use case for which
	the UPA was advertised. Not withdrawing the UPA would result in		the UPA was advertised. Not withdrawing the UPA would result in
	stale information being kept in the link state database of all		stale information being kept in the link state databases of all
	routers in the area.		routers in the area.
	Implementations SHOULD provide a configuration option to specify the		Implementations SHOULD provide a configuration option to specify the
	UPA lifetime at the originating ABR or ASBR.		UPA lifetime at the originating ABR or ASBR.
	As UPA advertisements in IS-IS are advertised in existing Link State		As UPA advertisements in IS-IS are advertised in existing Link State
	PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is		PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is
	RECOMMENDED that, when possible, UPAs are advertised in LSPs		RECOMMENDED that, when possible, UPAs are advertised in LSPs
	dedicated to this type of advertisement. This will minimize the		dedicated to this type of advertisement. This will minimize the
	number of LSPs that need to be updated when UPAs are advertised and		number of LSPs that need to be updated when UPAs are advertised and
	skipping to change at line 271 ¶		skipping to change at line 272 ¶
	Existing nodes in a network that do not support UPA will not use UPAs		Existing nodes in a network that do not support UPA will not use UPAs
	during the route calculation but will continue to flood them within		during the route calculation but will continue to flood them within
	the area. This allows flooding of such advertisements to occur		the area. This allows flooding of such advertisements to occur
	without the need to upgrade all nodes in a network to support this		without the need to upgrade all nodes in a network to support this
	specification.		specification.
	Those ABRs or ASBRs that are responsible for propagating UPA		Those ABRs or ASBRs that are responsible for propagating UPA
	advertisements into other areas or domains are also expected to		advertisements into other areas or domains are also expected to
	recognize UPA advertisements.		recognize UPA advertisements.
	As per the definitions referenced in the preceding section, any		As per the definitions referenced in Section 3, any prefix
	prefix advertisement with a metric value greater than 0xFE000000 can		advertisement with a metric value greater than 0xFE000000 can be used
	be used for purposes other than normal routing calculations. Such a		for purposes other than normal routing calculations. Such a metric
	metric MUST be used when advertising UPA in IS-IS.		MUST be used when advertising UPA in IS-IS.
	[RFC7370] introduced the "IS-IS Sub-TLVs for TLVs Advertising Prefix		[RFC7370] introduced the "IS-IS Sub-TLVs for TLVs Advertising Prefix
	Reachability" registry, which lists TLVs for advertising different		Reachability" registry, which lists TLVs for advertising different
	types of prefix reachability. (The list at the time of publication		types of prefix reachability. (The list at the time of publication
	of this document is below.) UPA in IS-IS is supported for prefixes		of this document is below.) UPA in IS-IS is supported for prefixes
	advertised in all such TLVs identified by that registry, for example:		advertised in all such TLVs identified by that registry, for example:
	* SRv6 Locator [RFC9352]		* SRv6 Locator [RFC9352]
	* Extended IP reachability [RFC5305]		* Extended IP reachability [RFC5305]
	skipping to change at line 299 ¶		skipping to change at line 300 ¶
	* MT IPv6 IP Reach [RFC5120]		* MT IPv6 IP Reach [RFC5120]
	* IPv4 Algorithm Prefix Reachability TLV [RFC9502]		* IPv4 Algorithm Prefix Reachability TLV [RFC9502]
	* IPv6 Algorithm Prefix Reachability TLV [RFC9502]		* IPv6 Algorithm Prefix Reachability TLV [RFC9502]
	3.2. Signaling UPA in IS-IS		3.2. Signaling UPA in IS-IS
	In IS-IS, a prefix can be advertised with a metric higher than		In IS-IS, a prefix can be advertised with a metric higher than
	0xFE000000, for various reasons. Even though in all cases the		0xFE000000, for various reasons. While IS-IS specifies the treatment
	treatment of such metric is specified for IS-IS, having an explicit		of such metrics, explicit signaling is required to distinguish UPA
	way to signal that the prefix was advertised in order to signal UPA		from other high-metric advertisements.
	is required to distinguish it from other cases where the prefix with
	such a metric is advertised.
	Two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags		Two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags
	[RFC7794] are defined:		[RFC7794] are defined:
	U-Flag: Unreachable Prefix Flag (bit 5). When set, it indicates		U-Flag: Unreachable Prefix Flag (bit 5). When set, it indicates
	that the prefix is unreachable.		that the prefix is unreachable.
	UP-Flag: Unreachable Planned Prefix Flag (bit 6). When set, this		UP-Flag: Unreachable Planned Prefix Flag (bit 6). When set, this
	flag indicates that the prefix is unreachable due to a planned		flag indicates that the prefix is unreachable due to a planned
	event (e.g., planned maintenance).		event (e.g., planned maintenance).
	skipping to change at line 404 ¶		skipping to change at line 403 ¶
	If an ABR or ASBR advertises UPA in an advertisement of an inter-area		If an ABR or ASBR advertises UPA in an advertisement of an inter-area
	or external prefix inside OSPFv2 or OSPFv3, then it MUST set the age		or external prefix inside OSPFv2 or OSPFv3, then it MUST set the age
	to a value lower than MaxAge and set the metric to LSInfinity.		to a value lower than MaxAge and set the metric to LSInfinity.
	UPA flooding inside the area follows the existing standard procedures		UPA flooding inside the area follows the existing standard procedures
	defined by OSPFv2 [RFC2328] and OSPFv3 [RFC5340].		defined by OSPFv2 [RFC2328] and OSPFv3 [RFC5340].
	4.2. Signaling UPA in OSPF		4.2. Signaling UPA in OSPF
	In OSPFv2 a prefix can be advertised with metric LSInfinity, or in		A prefix can be advertised (in OSPFv2) with the LSInfinity metric or
	OSPFv3 with the NU-bit set in PrefixOptions, for various reasons.		(in OSPFv3) with the NU-bit set in PrefixOptions, for various
	Even though in all cases the treatment of such a metric, or NU-bit,		reasons. While OSPFv2 and OSPFv3 specify the treatment of the
	is specified for OSPFv2 and OSPFv3, having an explicit way to signal		LSInfinity metric and the NU-bit, explicit signaling is required to
	that the prefix was advertised in order to signal UPA is required to		distinguish UPA from other scenarios using the LSInfinity metric or
	distinguish it from other cases where the prefix with such a metric		NU-bit.
	is advertised.
	OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in		OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in
	[RFC9792] for advertising additional prefix attribute flags in OSPFv2		[RFC9792] for advertising additional prefix attribute flags in OSPFv2
	and OSPFv3.		and OSPFv3.
	Two new bits in the Prefix Attribute Flags Sub-TLV are defined:		Two new bits in the Prefix Attribute Flags Sub-TLV are defined:
	U-Flag: Unreachable Prefix Flag (bit 0). When set, it indicates		U-Flag: Unreachable Prefix Flag (bit 0). When set, it indicates
	that the prefix is unreachable.		that the prefix is unreachable.
	skipping to change at line 436 ¶		skipping to change at line 434 ¶
	U-flag.		U-flag.
	The receiving node MUST ignore the UP-flag in the advertisement if		The receiving node MUST ignore the UP-flag in the advertisement if
	the U-flag is not set.		the U-flag is not set.
	4.2.1. Signaling UPA in OSPFv2		4.2.1. Signaling UPA in OSPFv2
	The OSPFv2 Prefix Extended Flags Sub-TLV [RFC9792] is a sub-TLV of		The OSPFv2 Prefix Extended Flags Sub-TLV [RFC9792] is a sub-TLV of
	the OSPFv2 Extended Prefix TLV [RFC7684].		the OSPFv2 Extended Prefix TLV [RFC7684].
	The prefix that is advertised with U-Flag MUST have the metric set to		The prefix that is advertised with U-Flag or UP-Flag MUST have the
	a value LSInfinity. If the prefix metric is not equal to LSInfinity,		metric set to a value LSInfinity. If the prefix metric is not equal
	both of these flags MUST be ignored. For default algorithm 0		to LSInfinity, both of these flags MUST be ignored. Therefore, for
	prefixes with U-Flag it is therefore REQUIRED to advertise the		the prefixes in default algorithm 0 that are advertised with U-Flag,
	unreachable prefix in the base OSPFv2 LSA - e.g., OSPFv2 Summary-LSA		or Up-Flag, it is REQUIRED to advertise the unreachable prefix in the
	[RFC2328], or AS-external-LSAs [RFC2328], or NSSA AS-external LSA		base OSPFv2 LSA, e.g., e.g., OSPFv2 Summary-LSA [RFC2328], or AS-
	[RFC3101].		external-LSAs [RFC2328], or NSSA AS-external LSA [RFC3101].
	4.2.2. Signaling UPA in OSPFv3		4.2.2. Signaling UPA in OSPFv3
	OSPFv3 Prefix Extended Flags Sub-TLV is defined as a sub-TLV of the		OSPFv3 Prefix Extended Flags Sub-TLV is defined as a sub-TLV of the
	following OSPFv3 TLVs that are defined in [RFC8362]:		following OSPFv3 TLVs that are defined in [RFC8362]:
	* Intra-Area Prefix TLV		* Intra-Area-Prefix TLV
	* Inter-Area Prefix TLV		* Inter-Area-Prefix TLV
	* External Prefix TLV		* External-Prefix TLV
	The prefix that is advertised with U-Flag or UP-flag MUST have the		The prefix that is advertised with U-Flag or UP-flag MUST have the
	metric set to a value LSInfinity. For default algorithm 0 prefixes,		metric set to a value LSInfinity. For default algorithm 0 prefixes,
	the LSInfinity MUST be set in the parent TLV. For IP Algorithm		the LSInfinity MUST be set in the parent TLV. For IP Algorithm
	Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm		Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm
	Prefix Reachability sub-TLV. If the prefix metric is not equal to		Prefix Reachability sub-TLV. If the prefix metric is not equal to
	LSInfinity, both of these flags MUST be ignored.		LSInfinity, both of these flags MUST be ignored.
	The prefix that is advertised with U-Flag or UP-Flag MUST have the		The prefix that is advertised with U-Flag or UP-Flag MUST have the
	NU-bit set in the PrefixOptions of the parent TLV. If the NU-bit in		NU-bit set in the PrefixOptions of the parent TLV. If the NU-bit in
End of changes. 12 change blocks.
	40 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48.