rfc9815v4.txt		rfc9815.txt
	skipping to change at line 95 ¶		skipping to change at line 95 ¶
	6.2. Dual-Stack Support		6.2. Dual-Stack Support
	6.3. SPF Calculation Based on BGP-LS-SPF NLRI		6.3. SPF Calculation Based on BGP-LS-SPF NLRI
	6.4. IPv4/IPv6 Unicast Address Family Interaction		6.4. IPv4/IPv6 Unicast Address Family Interaction
	6.5. NLRI Advertisement		6.5. NLRI Advertisement
	6.5.1. Link/Prefix Failure Convergence		6.5.1. Link/Prefix Failure Convergence
	6.5.2. Node Failure Convergence		6.5.2. Node Failure Convergence
	7. Error Handling		7. Error Handling
	7.1. Processing of BGP-LS-SPF TLVs		7.1. Processing of BGP-LS-SPF TLVs
	7.2. Processing of BGP-LS-SPF NLRIs		7.2. Processing of BGP-LS-SPF NLRIs
	7.3. Processing of BGP-LS Attributes		7.3. Processing of BGP-LS Attributes
	7.4. BGP-LS-SPF Link State NLRI Database Synchronization		7.4. BGP-LS-SPF Link State Database Synchronization
	8. IANA Considerations		8. IANA Considerations
	8.1. BGP-LS-SPF Allocation in the SAFI Values Registry		8.1. BGP-LS-SPF Allocation in the SAFI Values Registry
	8.2. BGP-LS-SPF Assignments in the BGP-LS NLRI and Attribute		8.2. BGP-LS-SPF Assignments in the BGP-LS NLRI and Attribute
	TLVs Registry		TLVs Registry
	8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Values		8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Values
	Registry		Registry
	8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Values		8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Values
	Registry		Registry
	8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Values		8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Values
	Registry		Registry
	skipping to change at line 193 ¶		skipping to change at line 193 ¶
	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.
	1.3. BGP Shortest Path First (SPF) Motivation		1.3. BGP Shortest Path First (SPF) Motivation
	Given that [RFC7938] already describes how BGP could be used as the		Given that [RFC7938] already describes how BGP could be used as the
	sole routing protocol in an MSDC, one might question the motivation		sole routing protocol in an MSDC, one might question the motivation
	for defining an alternative BGP deployment model when a mature		for defining an alternative BGP deployment model when a mature
	solution exists. For both alternatives, BGP offers the operational		solution exists. For both alternatives, BGP offers the operational
	benefits of a single routing protocol as opposed to the combination		benefits of a single routing protocol as opposed to the combination
	of IGP for the underlay and BGP as the overlay. However, BGP SPF		of an IGP for the underlay and BGP as the overlay. However, BGP SPF
	offers some unique advantages above and beyond standard BGP path-		offers some unique advantages above and beyond standard BGP path-
	vector routing. With BGP SPF, the simple single-hop peering model		vector routing. With BGP SPF, the simple single-hop peering model
	recommended in Section 5.2.1 of [RFC7938] is augmented with peering		recommended in Section 5.2.1 of [RFC7938] is augmented with peering
	models requiring fewer BGP sessions.		models requiring fewer BGP sessions.
	A primary advantage is that all BGP speakers in the BGP SPF routing		A primary advantage is that all BGP speakers in the BGP SPF routing
	domain have a complete view of the topology. This allows support for		domain have a complete view of the topology. This allows support for
	ECMP, IP fast-reroute (e.g., Loop-Free Alternatives (LFAs) [RFC5286],		ECMP, IP fast-reroute (e.g., Loop-Free Alternatives (LFAs) [RFC5286],
	Shared Risk Link Groups (SRLGs) [RFC4202], and other routing		Shared Risk Link Groups (SRLGs) [RFC4202], and other routing
	enhancements without advertisement of additional BGP paths [RFC7911]		enhancements without advertisement of additional BGP paths [RFC7911]
	skipping to change at line 280 ¶		skipping to change at line 280 ¶
	encodings that are no longer applicable. Unless explicitly specified		encodings that are no longer applicable. Unless explicitly specified
	in the context of BGP SPF, all optional path attributes SHOULD NOT be		in the context of BGP SPF, all optional path attributes SHOULD NOT be
	advertised. If received, all path attributes MUST be accepted,		advertised. If received, all path attributes MUST be accepted,
	validated, and propagated consistently with the BGP protocol		validated, and propagated consistently with the BGP protocol
	[RFC4271], even if not needed by BGP SPF.		[RFC4271], even if not needed by BGP SPF.
	Section 9.1 of [RFC4271] defines the Decision Process that is used to		Section 9.1 of [RFC4271] defines the Decision Process that is used to
	select routes for subsequent advertisement by applying the policies		select routes for subsequent advertisement by applying the policies
	in the local Policy Information Base (PIB) to the routes stored in		in the local Policy Information Base (PIB) to the routes stored in
	its Adj-RIBs-In. The output of the Decision Process is the set of		its Adj-RIBs-In. The output of the Decision Process is the set of
	routes that are announced by a BGP speaker to its peers. These		routes that is announced by a BGP speaker to its peers. These
	selected routes are stored by a BGP speaker in the speaker's Adj-		selected routes are stored by a BGP speaker in the speaker's Adj-
	RIBs-Out, according to policy.		RIBs-Out, according to policy.
	The BGP SPF extension fundamentally changes the Decision Process, as		The BGP SPF extension fundamentally changes the Decision Process, as
	described herein. Specifically:		described herein. Specifically:
	1. BGP advertisements are readvertised to neighbors immediately		1. BGP advertisements are readvertised to neighbors immediately
	without waiting or dependence on the route computation, as		without waiting or dependence on the route computation, as
	specified in phase 3 of the base BGP Decision Process. Multiple		specified in phase 3 of the base BGP Decision Process. Multiple
	peering models are supported, as specified in Section 4.		peering models are supported, as specified in Section 4.
	skipping to change at line 445 ¶		skipping to change at line 445 ¶
	SPF route calculation. All the other TLVs are considered as optional		SPF route calculation. All the other TLVs are considered as optional
	TLVs. Documents specifying usage of optional TLVs for BGP SPF MUST		TLVs. Documents specifying usage of optional TLVs for BGP SPF MUST
	address backward compatibility.		address backward compatibility.
	5.1.2. BGP-LS Attribute		5.1.2. BGP-LS Attribute
	The BGP-LS Attribute of the BGP-LS-SPF SAFI uses the exact same		The BGP-LS Attribute of the BGP-LS-SPF SAFI uses the exact same
	format as the BGP-LS AFI [RFC9552]. In other words, all the TLVs		format as the BGP-LS AFI [RFC9552]. In other words, all the TLVs
	used in the BGP-LS Attribute of the BGP-LS AFI are applicable and are		used in the BGP-LS Attribute of the BGP-LS AFI are applicable and are
	used for the BGP-LS Attribute of the BGP-LS-SPF SAFI. This attribute		used for the BGP-LS Attribute of the BGP-LS-SPF SAFI. This attribute
	is an optional, non-transitive BGP attribute that is used to carry		is an optional, non-transitive BGP attribute that is used to
	link, node, and prefix properties and attributes. The BGP-LS		advertise link, node, and prefix properties and attributes. The BGP-
	Attribute is a set of TLVs.		LS Attribute is a set of TLVs.
	All the TLVs defined for the BGP-LS Attribute [RFC9552] are		All the TLVs defined for the BGP-LS Attribute [RFC9552] are
	applicable and can be used with the BGP-LS-SPF SAFI to carry link,		applicable and can be used with the BGP-LS-SPF SAFI to advertise
	node, and prefix properties and attributes.		link, node, and prefix properties and attributes.
	The BGP-LS Attribute may potentially be quite large depending on the		The BGP-LS Attribute may potentially be quite large depending on the
	amount of link-state information associated with a single BGP-LS-SPF		amount of link-state information associated with a single BGP-LS-SPF
	NLRI. The BGP specification [RFC4271] mandates a maximum BGP message		NLRI. The BGP specification [RFC4271] mandates a maximum BGP message
	size of 4096 octets. It is RECOMMENDED that an implementation		size of 4096 octets. It is RECOMMENDED that an implementation
	support [RFC8654] in order to accommodate a greater amount of		support [RFC8654] in order to accommodate a greater amount of
	information within the BGP-LS Attribute. BGP speakers MUST ensure		information within the BGP-LS Attribute. BGP speakers MUST ensure
	that they limit the TLVs included in the BGP-LS Attribute to ensure		that they limit the TLVs included in the BGP-LS Attribute to ensure
	that a BGP UPDATE message for a single BGP-LS-SPF NLRI does not cross		that a BGP UPDATE message for a single BGP-LS-SPF NLRI does not cross
	the maximum limit for a BGP message. The determination of the types		the maximum limit for a BGP message. The determination of the types
	skipping to change at line 578 ¶		skipping to change at line 578 ¶
	presence of parallel unnumbered links.		presence of parallel unnumbered links.
	The link descriptors are described in Table 4 of [RFC9552].		The link descriptors are described in Table 4 of [RFC9552].
	Additionally, the Address Family (AF) Link Descriptor TLV is defined		Additionally, the Address Family (AF) Link Descriptor TLV is defined
	to determine whether an unnumbered link can be used in the IPv4 SPF,		to determine whether an unnumbered link can be used in the IPv4 SPF,
	the IPv6, or both (refer to Section 5.2.2.1).		the IPv6, or both (refer to Section 5.2.2.1).
	For a link to be used in SPF computation for a given address family,		For a link to be used in SPF computation for a given address family,
	i.e., IPv4 or IPv6, both routers connecting the link MUST have		i.e., IPv4 or IPv6, both routers connecting the link MUST have
	matching addresses (i.e., router interface addresses must be on the		matching addresses (i.e., router interface addresses must be on the
	same subnet for numbered interfaces, and the Link Local/Remote		same subnet for numbered interfaces, or the Link Local/Remote
	Identifiers (Section 6.3) must match for unnumbered interfaces).		Identifiers (Section 6.3) must match for unnumbered interfaces).
	The IGP Metric (TLV 1095) MUST be advertised. If a BGP speaker		The IGP Metric (TLV 1095) MUST be advertised. If a BGP speaker
	receives a Link NLRI without an IGP Metric attribute TLV, then it		receives a Link NLRI without an IGP Metric attribute TLV, then it
	MUST consider the received NLRI as malformed (refer to Section 7).		MUST consider the received NLRI as malformed and is handled as
	The BGP SPF metric length is 4 octets. A metric is associated with		described in Section 7.1. The BGP SPF metric length is 4 octets. A
	the output side of each router interface. This metric is		metric is associated with the output side of each router interface.
	configurable by the system administrator. The lower the metric, the		This metric is configurable by the system administrator. The lower
	more likely the interface is to be used to forward data traffic. One		the metric, the more likely the interface is to be used to forward
	possible default for the metric would be to give each interface a		data traffic. One possible default for the metric would be to give
	metric of 1 making it effectively a hop count.		each interface a metric of 1 making the SPF metric effectively a hop
			count.
	The usage of other link attribute TLVs is beyond the scope of this		The usage of other link attribute TLVs is beyond the scope of this
	document.		document.
	5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV		5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV
	For unnumbered links, the address family cannot be ascertained from		For unnumbered links, the address family cannot be ascertained from
	the endpoint link descriptors. Hence, the Address Family Link		the endpoint link descriptors. Hence, the Address Family Link
	Descriptor TLV SHOULD be included with the Link Local/Remote		Descriptor TLV SHOULD be included with the Link Local/Remote
	Identifiers TLV for unnumbered links, so that the link can be used in		Identifiers TLV for unnumbered links, so that the link can be used in
	skipping to change at line 775 ¶		skipping to change at line 776 ¶
	When incrementing the sequence number for each self-originated NLRI,		When incrementing the sequence number for each self-originated NLRI,
	the sequence number should be treated as an unsigned 64-bit value.		the sequence number should be treated as an unsigned 64-bit value.
	If the lower-order 32-bit value wraps, the higher-order 32-bit value		If the lower-order 32-bit value wraps, the higher-order 32-bit value
	should be incremented and saved in non-volatile storage. If a BGP		should be incremented and saved in non-volatile storage. If a BGP
	speaker completely loses its sequence number state (e.g., the BGP		speaker completely loses its sequence number state (e.g., the BGP
	speaker hardware is replaced or experiences a cold start), the BGP		speaker hardware is replaced or experiences a cold start), the BGP
	NLRI selection rules (see Section 6.1) ensure convergence, albeit not		NLRI selection rules (see Section 6.1) ensure convergence, albeit not
	immediately.		immediately.
	If the Sequence Number TLV is not received, then the corresponding		If the Sequence Number TLV is not received, then the corresponding
	NLRI is considered as malformed and MUST be handled as 'treat-as-		NLRI is considered as malformed and MUST be handled as described in
	withdraw'. An implementation SHOULD log an error for further		Section 7.1. An implementation SHOULD log an error for further
	analysis.		analysis.
	5.3. BGP-LS-SPF End of RIB (EoR) Marker		5.3. BGP-LS-SPF End of RIB (EoR) Marker
	The usage of the EoR marker [RFC4724] with the BGP-LS-SPF SAFI is		The usage of the EoR marker [RFC4724] with the BGP-LS-SPF SAFI is
	somewhat different than the other BGP SAFIs. Reception of the EoR		somewhat different than the other BGP SAFIs. Reception of the EoR
	marker MAY optionally be expected prior to advertising a Link NLRI		marker MAY optionally be expected prior to advertising a Link NLRI
	for a given peer.		for a given peer.
	5.4. BGP Next-Hop Information		5.4. BGP Next-Hop Information
	skipping to change at line 956 ¶		skipping to change at line 957 ¶
	prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node		prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node
	reachability. Implementations may choose to implement this with		reachability. Implementations may choose to implement this with
	separate RIBs for each address family and/or separate RIBs for		separate RIBs for each address family and/or separate RIBs for
	prefix and node reachability.		prefix and node reachability.
	Global Routing Information Base (GLOBAL-RIB): The RIB containing the		Global Routing Information Base (GLOBAL-RIB): The RIB containing the
	current routes that are installed in the router's forwarding		current routes that are installed in the router's forwarding
	plane. This is commonly referred to in networking parlance as		plane. This is commonly referred to in networking parlance as
	"the RIB".		"the RIB".
	Link State NLRI Database (LSNDB): A database of BGP-LS-SPF NLRIs		Link State Database (LSDB): A database of BGP-LS-SPF NLRIs that
	that facilitate access to all Node, Link, and Prefix NLRIs.		facilitate access to all Node, Link, and Prefix NLRIs.
	Candidate List (CAN-LIST): A list of candidate Node NLRIs used		Candidate List (CAN-LIST): A list of candidate Node NLRIs used
	during the BGP SPF calculation. The list is sorted by the cost to		during the BGP SPF calculation. The list is sorted by the cost to
	reach the Node NLRI, with the Node NLRI that has the lowest		reach the Node NLRI, with the Node NLRI that has the lowest
	reachability cost at the head of the list. This facilitates the		reachability cost at the head of the list. This facilitates the
	execution of the Dijkstra algorithm, where the shortest paths		execution of the Dijkstra algorithm, where the shortest paths
	between the local node and other nodes in the graph are computed.		between the local node and other nodes in the graph are computed.
	The CAN-LIST is typically implemented as a heap but other data		The CAN-LIST is typically implemented as a heap but other data
	structures have been used.		structures have been used.
	skipping to change at line 1159 ¶		skipping to change at line 1160 ¶
	6.4. IPv4/IPv6 Unicast Address Family Interaction		6.4. IPv4/IPv6 Unicast Address Family Interaction
	While the BGP-LS-SPF address family and the BGP unicast address		While the BGP-LS-SPF address family and the BGP unicast address
	families may install routes into the routing tables of the same		families may install routes into the routing tables of the same
	device, they operate independently (i.e., "ships-in-the-night" mode).		device, they operate independently (i.e., "ships-in-the-night" mode).
	There is no implicit route redistribution between the BGP-LS-SPF		There is no implicit route redistribution between the BGP-LS-SPF
	address family and the BGP unicast address families.		address family and the BGP unicast address families.
	It is RECOMMENDED that BGP-LS-SPF IPv4/IPv6 route computation and		It is RECOMMENDED that BGP-LS-SPF IPv4/IPv6 route computation and
	installation be given scheduling priority by default over other BGP		installation be given scheduling priority by default over other BGP
	address families as these address families are considered as underlay		address families as the BGP-LS-SPF SAFI is considered an underlay
	SAFIs.		SAFI.
	6.5. NLRI Advertisement		6.5. NLRI Advertisement
	6.5.1. Link/Prefix Failure Convergence		6.5.1. Link/Prefix Failure Convergence
	A local failure prevents a link from being used in the SPF		A local failure prevents a link from being used in the SPF
	calculation due to the IGP bidirectional connectivity requirement.		calculation due to the IGP bidirectional connectivity requirement.
	Consequently, local link failures SHOULD always be communicated as		Consequently, local link failures SHOULD always be communicated as
	quickly as possible and given priority over other categories of		quickly as possible and given priority over other categories of
	changes to ensure expeditious propagation and optimal convergence.		changes to ensure expeditious propagation and optimal convergence.
	According to standard BGP procedures, the link would continue to be		According to standard BGP procedures, the link would continue to be
	used until the last copy of the BGP-LS-SPF Link NLRI is withdrawn.		used until the last copy of the BGP-LS-SPF Link NLRI is withdrawn.
	In order to avoid this delay, the originator of the Link NLRI SHOULD		In order to avoid this delay, the originator of the Link NLRI SHOULD
	advertise a more recent version with an increased Sequence Number TLV		advertise a more recent version with an increased Sequence Number TLV
	for the BGP-LS-SPF Link NLRI including the SPF Status TLV (refer to		for the BGP-LS-SPF Link NLRI including the SPF Status TLV (refer to
	Section 5.2.2.2) indicating the link is down with respect to BGP SPF.		Section 5.2.2.2) indicating the link is down with respect to BGP SPF.
	The configurable LinkStatusDownAdvertise timer controls the interval		The configurable LinkStatusDownAdvertise timer controls the interval
	that the BGP-LS-LINK NLRI is advertised with SPF Status indicating		that the BGP-LS-SPF Link NLRI is advertised with SPF Status
	the link is down prior to withdrawal. If the BGP-LS-SPF Link NLRI is		indicating the link is down prior to withdrawal. If the BGP-LS-SPF
	advertised with the SPF Status TLV included in the BGP-LS Attribute,		Link NLRI is advertised with the SPF Status TLV included in the BGP-
	and the link becomes available in that period, the originator of the		LS Attribute, and the link becomes available in that period, the
	BGP-LS-SPF Link NLRI MUST advertise a more recent version of the BGP-		originator of the BGP-LS-SPF Link NLRI MUST advertise a more recent
	LS-SPF Link NLRI without the SPF Status TLV in the BGP-LS Link		version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the
	Attribute. The suggested default value for the		BGP-LS Link Attribute. The suggested default value for the
	LinkStatusDownAdvertise timer is 2 seconds.		LinkStatusDownAdvertise timer is 2 seconds.
	Similarly, when a prefix becomes unreachable, a more recent version		Similarly, when a prefix becomes unreachable, a more recent version
	of the BGP-LS-SPF Prefix NLRI SHOULD be advertised with the SPF		of the BGP-LS-SPF Prefix NLRI SHOULD be advertised with the SPF
	Status TLV (refer to Section 5.2.3.1) to indicate that the prefix is		Status TLV (refer to Section 5.2.3.1) to indicate that the prefix is
	unreachable in the BGP-LS Prefix Attributes, and the prefix will be		unreachable in the BGP-LS Prefix Attributes, and the prefix will be
	considered unreachable with respect to BGP SPF. The configurable		considered unreachable with respect to BGP SPF. The configurable
	PrefixStatusDownAdvertise timer controls the interval that the BGP-		PrefixStatusDownAdvertise timer controls the interval that the BGP-
	LS-Prefix NLRI is advertised with SPF Status indicating the prefix is		LS-Prefix NLRI is advertised with SPF Status indicating the prefix is
	unreachable prior to withdrawal. If the BGP-LS-SPF Prefix has been		unreachable prior to withdrawal. If the BGP-LS-SPF Prefix has been
	skipping to change at line 1209 ¶		skipping to change at line 1210 ¶
	the SPF Status TLV in the BGP-LS Prefix Attributes. The suggested		the SPF Status TLV in the BGP-LS Prefix Attributes. The suggested
	default value for the PrefixStatusDownAdvertise timer is 2 seconds.		default value for the PrefixStatusDownAdvertise timer is 2 seconds.
	6.5.2. Node Failure Convergence		6.5.2. Node Failure Convergence
	By default, all the NLRIs advertised by a node are withdrawn when a		By default, all the NLRIs advertised by a node are withdrawn when a
	session failure is detected [RFC4271]. If fast failure detection		session failure is detected [RFC4271]. If fast failure detection
	such as BFD [RFC5880] is utilized, and the node is on the fastest		such as BFD [RFC5880] is utilized, and the node is on the fastest
	converging path, the most recent versions of BGP-LS-SPF NLRI will be		converging path, the most recent versions of BGP-LS-SPF NLRI will be
	withdrawn. This may result in older versions of NLRIs received from		withdrawn. This may result in older versions of NLRIs received from
	one or more peers on a different path(s) in the LSNDB until they are		one or more peers on a different path(s) in the LSDB until they are
	withdrawn. These stale NLRIs will not delay convergence since the		withdrawn. These stale NLRIs will not delay convergence since the
	adjacent nodes detect the link failure and advertise a more recent		adjacent nodes detect the link failure and advertise a more recent
	NLRI indicating the link is down with respect to BGP SPF (refer to		NLRI indicating the link is down with respect to BGP SPF (refer to
	Section 6.5.1) and the bidirectional connectivity check fails during		Section 6.5.1) and the bidirectional connectivity check fails during
	the BGP SPF calculation (refer to Section 6.3).		the BGP SPF calculation (refer to Section 6.3).
	7. Error Handling		7. Error Handling
	This section describes error-handling actions, as described in		This section describes error-handling actions, as described in
	[RFC7606], that are specific to BGP-LS-SPF SAFI BGP UPDATE message		[RFC7606], that are specific to BGP-LS-SPF SAFI BGP UPDATE message
	skipping to change at line 1292 ¶		skipping to change at line 1293 ¶
	BGP speaker MUST handle such a malformed NLRI as 'treat-as-withdraw'		BGP speaker MUST handle such a malformed NLRI as 'treat-as-withdraw'
	[RFC7606].		[RFC7606].
	When a BGP speaker receives a BGP Update that does not contain any		When a BGP speaker receives a BGP Update that does not contain any
	BGP-LS Attributes, it is most likely an indication of 'Attribute		BGP-LS Attributes, it is most likely an indication of 'Attribute
	Discard' fault handling, and the BGP speaker SHOULD preserve and		Discard' fault handling, and the BGP speaker SHOULD preserve and
	propagate the BGP-LS-SPF NLRI as described in Section 8.2.2 of		propagate the BGP-LS-SPF NLRI as described in Section 8.2.2 of
	[RFC9552]. However, NLRIs without the BGP-LS Attribute MUST NOT be		[RFC9552]. However, NLRIs without the BGP-LS Attribute MUST NOT be
	used in the SPF calculation (Section 6.3). How this is accomplished		used in the SPF calculation (Section 6.3). How this is accomplished
	is an implementation matter, but one way would be for these NLRIs not		is an implementation matter, but one way would be for these NLRIs not
	to be returned in LSNDB lookups.		to be returned in LSDB lookups.
	7.2. Processing of BGP-LS-SPF NLRIs		7.2. Processing of BGP-LS-SPF NLRIs
	A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the		A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the
	syntactic validation checks of the BGP-LS-SPF NLRI listed in		syntactic validation checks of the BGP-LS-SPF NLRI listed in
	Section 8.2.2 of [RFC9552] to determine if it is malformed.		Section 8.2.2 of [RFC9552] to determine if it is malformed.
	7.3. Processing of BGP-LS Attributes		7.3. Processing of BGP-LS Attributes
	A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the		A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the
	syntactic validation checks of the BGP-LS Attribute listed in		syntactic validation checks of the BGP-LS Attribute listed in
	Section 8.2.2 of [RFC9552] to determine if it is malformed.		Section 8.2.2 of [RFC9552] to determine if it is malformed.
	An implementation SHOULD log an error for further analysis for		An implementation SHOULD log an error for further analysis for
	problems detected during syntax validation.		problems detected during syntax validation.
	7.4. BGP-LS-SPF Link State NLRI Database Synchronization		7.4. BGP-LS-SPF Link State Database Synchronization
	While uncommon, there may be situations where the LSNDBs of two BGP		While uncommon, there may be situations where the LSDBs of two BGP
	speakers support the BGP-LS-SPF SAFI lose synchronization. In these		speakers support the BGP-LS-SPF SAFI lose synchronization. In these
	situations, the BGP session MUST be reset unless other means of		situations, the BGP session MUST be reset unless other means of
	resynchronization are used (beyond the scope of this document). When		resynchronization are used (beyond the scope of this document). When
	the session is reset, the BGP speaker MUST send a NOTIFICATION		the session is reset, the BGP speaker MUST send a NOTIFICATION
	message with the BGP error code "Loss of LSDB Synchronization" as		message with the BGP error code "Loss of LSDB Synchronization" as
	described in Section 3 of [RFC4271]. The mechanisms to detect loss		described in Section 3 of [RFC4271]. The mechanisms to detect loss
	of synchronization are beyond the scope of this document.		of synchronization are beyond the scope of this document.
	8. IANA Considerations		8. IANA Considerations
End of changes. 15 change blocks.
	33 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48.