draft-ietf-lsvr-bgp-spf-51.original.xml		draft-ietf-lsvr-bgp-spf-51.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that
	most I-Ds might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-lsvr-bgp-spf-51"
	ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="e
	n" tocInclude="true"
	tocDepth="4" symRefs="true" sortRefs="true" version="3" consensus="true">
	<!-- xml2rfc v2v3 conversion 3.12.1 -->
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: full3667, noModification3667, noDerivatives3667
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->
	<!-- ***** FRONT MATTER ***** -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-lsvr-bgp-spf-51" number="0000" ipr="trust200902" obsoletes="" updates="" subm issionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" so rtRefs="true" version="3" consensus="true">
	<front>		<!--[rfced] The Abstract/Introduction mentions that this document
	<title abbrev="BGP Link-State SPF Routing">		provides extensions for use with BGP Link-State distribution and
	BGP Link-State Shortest Path First (SPF) Routing</title>		the SPF algorithm. Would you like to include "extensions" in the
	<!-- add 'role="editor"' below for the editors if appropriate -->		document title for consistency with the Abstract/Introduction?
	<!-- Another author who claims to be an editor -->		Original:
			BGP Link-State Shortest Path First (SPF) Routing
			Perhaps:
			Extensions for BGP Link-State Shortest Path First (SPF) Routing
			-->
	-&gt;		<front>
			<title abbrev="BGP Link-State SPF Routing">BGP Link-State Shortest Path Firs
			t (SPF) Routing</title>
			<seriesInfo name="RFC" value="0000"/>
	<author fullname="Keyur Patel" initials="K" surname="Patel">		<author fullname="Keyur Patel" initials="K" surname="Patel">
	<organization>Arrcus, Inc.</organization>		<organization>Arrcus, Inc.</organization>
	<address>		<address>
	<email>keyur@arrcus.com</email>		<email>keyur@arrcus.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Acee Lindem" initials="A" surname="Lindem">		<author fullname="Acee Lindem" initials="A" surname="Lindem">
	<organization>LabN Consulting, LLC</organization>		<organization>LabN Consulting, LLC</organization>
	<address>		<address>
	<postal>		<postal>
	<street>301 Midenhall Way</street>		<street>301 Midenhall Way</street>
	<city>Cary</city>		<city>Cary</city>
	<region>NC</region>		<region>NC</region>
	<code>27513</code>		<code>27513</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>acee.ietf@gmail.com</email>		<email>acee.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Shawn Zandi" initials="S" surname="Zandi">		<author fullname="Shawn Zandi" initials="S" surname="Zandi">
	<organization>LinkedIn</organization>		<organization>LinkedIn</organization>
	<address>		<address>
	<postal>		<postal>
	<street>222 2nd Street</street>		<street>222 2nd Street</street>
	<city>San Francisco</city>		<city>San Francisco</city>
	<region>CA</region>		<region>CA</region>
	<code>94105</code>		<code>94105</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>szandi@linkedin.com</email>		<email>szandi@linkedin.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Wim Henderickx" initials="W" surname="Henderickx">		<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
	<organization>Nokia</organization>		<organization>Nokia</organization>
	<address>		<address>
	<postal>		<postal>
	<street>copernicuslaan 50</street>		<street>copernicuslaan 50</street>
	<city>Antwerp</city>		<city>Antwerp</city>
	<code>2018</code>		<code>2018</code>
	<country>Belgium</country>		<country>Belgium</country>
	</postal>		</postal>
	<email>wim.henderickx@nokia.com</email>		<email>wim.henderickx@nokia.com</email>
	</address>		</address>
	</author>		</author>
	<date/>		<date month="June" year="2025"/>
	<!-- Meta-data Declarations -->
			<area>RTG</area>
			<workgroup>lsvr</workgroup>
	<area>Routing</area>
	<workgroup>Link State Vector Routing (LSVR) Working Group</workgroup>
	<keyword>IDR</keyword>		<keyword>IDR</keyword>
	<!-- Keywords will be incorporated into HTML output
	files in a meta tag but they have no effect on text or nroff
	output. If you submit your draft to the RFC Editor, the
	keywords will be used for the search engine. -->
	<abstract>		<abstract>
	<t>		<t>
	Many Massively Scaled Data Centers (MSDCs) have converged on simplified		Many Massively Scaled Data Centers (MSDCs) have converged on simplified
	L3 (Layer 3) routing. Furthermore, requirements for operational simplici ty		Layer 3 (L3) routing. Furthermore, requirements for operational simplici ty
	has led many of these MSDCs to converge on BGP as their single routing		has led many of these MSDCs to converge on BGP as their single routing
	protocol for both their fabric routing and their Data Center Interconnec		protocol for both fabric routing and Data Center Interconnect
	t		(DCI) routing. This document describes extensions to BGP for use with BG
	(DCI) routing. This document describes extensions to BGP to use BGP		P -
	Link-State distribution and the Shortest Path First (SPF) algorithm.		Link-State (BGP-LS) distribution and the Shortest Path First (SPF) algor
			ithm.
	In doing this, it allows		In doing this, it allows
	BGP to be efficiently used as both the underlay protocol and the overlay protocol in		BGP to be efficiently used as both the underlay protocol and the overlay protocol in
	MSDCs.		MSDCs.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	Many Massively Scaled Data Centers (MSDCs) have converged on simplified		Many Massively Scaled Data Centers (MSDCs) have converged on simplified
	L3 (Layer 3) routing. Furthermore, requirements for operational simplici ty		Layer 3 (L3) routing. Furthermore, requirements for operational simplici ty
	has led many of these MSDCs to converge on BGP <xref target="RFC4271" fo rmat="default"/>		has led many of these MSDCs to converge on BGP <xref target="RFC4271" fo rmat="default"/>
	as their single routing protocol for both their fabric routing and		as their single routing protocol for both fabric routing and
	their Data Center Interconnect (DCI) routing <xref target="RFC7938" form		Data Center Interconnect (DCI) routing <xref target="RFC7938" format="de
	at="default"/>.		fault"/>.
	This document describes an alternative solution which leverages		This document describes an alternative solution that leverages
	BGP-LS <xref target="RFC9552" format="default"/>		BGP-LS <xref target="RFC9552" format="default"/>
	and the Shortest Path First algorithm used by		and the Shortest Path First (SPF) algorithm used by
	Internal Gateway Protocols (IGPs).		Internal Gateway Protocols (IGPs).
	</t>		</t>
	<t>		<t>
	This document leverages both the BGP protocol <xref target="RFC4271" for mat="default"/> and		This document leverages both the BGP protocol <xref target="RFC4271" for mat="default"/> and
	the BGP-LS <xref target="RFC9552" format="default"/> extensions. The rel		BGP-LS extensions <xref target="RFC9552" format="default"/>. The relatio
	ationship, as well as		nship as well as
	the scope of changes is described respectively in <xref target="BGP-base		the scope of changes are described in Sections <xref target="BGP-base" f
	" format="default"/>		ormat="counter"/>
	and <xref target="BGP-LS" format="default"/>. The modifications to		and <xref target="BGP-LS" format="counter"/>, respectively. The modifica
			tions to
	<xref target="RFC4271" format="default"/>		<xref target="RFC4271" format="default"/>
	for BGP SPF described herein only apply to IPv4 and IPv6 as underlay uni cast		for BGP SPF described herein only apply to IPv4 and IPv6 as underlay uni cast
	Subsequent Address Families Identifiers (SAFIs).		Subsequent Address Family Identifiers (SAFIs).
	Operations for any other BGP SAFIs are outside the scope of this documen t.		Operations for any other BGP SAFIs are outside the scope of this documen t.
	</t>		</t>
	<t>		<t>
	This solution avails the benefits of both BGP and SPF-based IGPs.		This solution avails the benefits of both BGP and SPF-based IGPs.
	These include TCP-based flow-control, no periodic link-state refresh, an d		These include TCP-based flow-control, no periodic link-state refresh, an d
	completely incremental NLRI advertisement. These advantages can reduce t		completely incremental Network Layer Reachability Information (NLRI) adv
	he		ertisement.
	overhead in MSDCs where there is a high degree of Equal Cost Multi-Path		These advantages can reduce the
	(ECMP) load-balancing.		overhead in MSDCs where there is a high degree of Equal-Cost Multipath
			(ECMP) load balancing.
	Additionally, using an SPF-based computation can support fast convergenc e and		Additionally, using an SPF-based computation can support fast convergenc e and
	the computation of Loop-Free Alternatives (LFAs). The SPF LFA extensions defined		the computation of Loop-Free Alternatives (LFAs). The SPF LFA extensions defined
	in <xref target="RFC5286" format="default"/> can be similarly applied to BGP SPF calculations.		in <xref target="RFC5286" format="default"/> can be similarly applied to BGP SPF calculations.
			<!--[rfced] May we rephrase "are a matter of implementation detail" to
			"are specific to implementation" or "are specific to the
			implementation process" for clarity?
			Original:
			However, the details are a matter of implementation detail
			and out of scope for this document.
			Perhaps:
			However, the details are specific to implementation and are
			out of scope for this document.
			-->
	However, the details are a matter of implementation detail and out of sc ope for this		However, the details are a matter of implementation detail and out of sc ope for this
	document.		document.
	Furthermore, a BGP-based solution lends itself to multiple peering model s		Furthermore, a BGP-based solution lends itself to multiple peering model s
	including those incorporating route-reflectors <xref target="RFC4456" fo rmat="default"/>		including those incorporating route reflectors <xref target="RFC4456" fo rmat="default"/>
	or controllers.		or controllers.
	</t>		</t>
	<section anchor="terms" numbered="true" toc="default">		<section anchor="terms" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	This specification reuses terms defined in section 1.1 of		This specification reuses terms defined in <xref section="1.1" target=
	<xref target="RFC4271" format="default"/>.		"RFC4271" format="default"/>.
	</t>		</t>
	<t>Additionally, this document introduces the following terms:		<t>Additionally, this document introduces the following terms:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>BGP SPF Routing Domain:</dt>		<dt>BGP SPF Routing Domain:</dt>
	<dd> A set of BGP routers that are under a single		<dd> A set of BGP routers that are under a single
	administrative domain and exchange link-state information using the BG		administrative domain and that exchange link-state information using t
	P-LS-SPF SAFI		he BGP-LS-SPF SAFI
	and compute routes using BGP SPF as described herein.</dd>		and compute routes that use BGP SPF, as described herein.</dd>
	<dt>BGP-LS-SPF NLRI:</dt>		<dt>BGP-LS-SPF NLRI:</dt>
	<dd> This refers to BGP-LS Network Layer Reachability		<dd>The BGP-LS Network Layer Reachability
	Information (NLRI) that is being advertised in the BGP-LS-SPF SAFI (<x ref target="SAFI" format="default"/>)		Information (NLRI) that is being advertised in the BGP-LS-SPF SAFI (<x ref target="SAFI" format="default"/>)
	and is being used for BGP SPF route computation.</dd>		and is being used for BGP SPF route computation.</dd>
	<dt>Dijkstra Algorithm:</dt>		<dt>Dijkstra Algorithm:</dt>
	<dd>		<dd>
	An algorithm for computing the shortest path from a given node in a graph		An algorithm for computing the shortest path from a given node in a graph
	to every other node in the graph.		to every other node in the graph.
	</dd>		</dd>
	<dt>Prefix NLRI:</dt>		<dt>Prefix NLRI:</dt>
	<dd>		<dd>
	In the context of BGP SPF, this term refers to both or either the IP v4 Topology Prefix NLRI		In the context of BGP SPF, this term refers to the IPv4 Topology Pre fix NLRI
	and/or the IPv6 Topology Prefix NLRI.		and/or the IPv6 Topology Prefix NLRI.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP Shortest Path First (SPF) Motivation</name>		<name>BGP Shortest Path First (SPF) Motivation</name>
	<t>		<t>
	Given that <xref target="RFC7938" format="default"/> already describes how BGP could be used		Given that <xref target="RFC7938" format="default"/> already describes how BGP could be used
	as the sole routing protocol in an MSDC, one might question the motiva tion for		as the sole routing protocol in an MSDC, one might question the motiva tion for
	defining an alternative BGP deployment model when a mature solution ex ists.		defining an alternative BGP deployment model when a mature solution ex ists.
	For both alternatives, BGP offers the operational benefits of a single		For both alternatives, BGP offers the operational benefits of a single
	routing protocol as opposed to the combination of an IGP for the under		routing protocol as opposed to the combination of IGP for the underlay
	lay		and BGP as the overlay. However, BGP SPF offers some unique advantages
	and BGP as an overlay. However, BGP SPF offers some unique advantages		above
	above
	and beyond standard BGP path-vector routing. With BGP SPF, the		and beyond standard BGP path-vector routing. With BGP SPF, the
	simple single-hop peering model recommended in section 5.2.1 of <xref target="RFC7938"/>		simple single-hop peering model recommended in <xref section="5.2.1" t arget="RFC7938"/>
	is augmented with peering models requiring fewer BGP sessions.		is augmented with peering models requiring fewer BGP sessions.
	</t>		</t>
	<t>		<t>
	A primary advantage is that all BGP speakers in the BGP SPF routing do main		A primary advantage is that all BGP speakers in the BGP SPF routing do main
	have a complete view of the topology. This allows support for ECMP,		have a complete view of the topology. This allows support for ECMP,
	IP fast-reroute (e.g., Loop-Free Alternatives) <xref target="RFC5286" format="default"/>,		IP fast-reroute (e.g., Loop-Free Alternatives (LFAs) <xref target="RFC 5286" format="default"/>,
	Shared Risk Link Groups (SRLGs) <xref target="RFC4202"/>,		Shared Risk Link Groups (SRLGs) <xref target="RFC4202"/>,
	and other routing enhancements without advertisement of additional		and other routing enhancements without advertisement of additional
	BGP paths <xref target="RFC7911" format="default"/> or other extensio ns.		BGP paths <xref target="RFC7911" format="default"/> or other extensio ns.
	</t>		</t>
	<t>		<t>
	With the BGP SPF decision process as defined in		With the BGP SPF decision process as defined in
	<xref target="bgp-decision" format="default"/>, NLRI changes can be di sseminated throughout the BGP		<xref target="bgp-decision" format="default"/>, NLRI changes can be di sseminated throughout the BGP
	routing domain much more rapidly. The added advantage of BGP using TCP for reliable		routing domain much more rapidly. The added advantage of BGP using TCP for reliable
	transport leverages TCP's inherent flow-control and guaranteed in-orde r delivery.		transport leverages TCP's inherent flow-control and guaranteed in-orde r delivery.
	</t>		</t>
	<t>		<t>
	Another primary advantage is a potential reduction in NLRI advertise ment.		Another primary advantage is a potential reduction in NLRI advertise ment.
			<!--[rfced] In the RFC Series, "100s or 1000s" is typically spelled
			out. Would you like to spell it out here?
			Original:
			With standard BGP path-vector routing, a single link
			failure may impact 100s or 1000s of prefixes and result in the
			withdrawal or re-advertisement of the attendant NLRI.
			Perhaps:
			With standard BGP path-vector routing, a single link
			failure may impact hundreds or thousands of prefixes
			and result in the withdrawal or re-advertisement of
			the attendant NLRI.
			-->
	With standard BGP path-vector routing, a single link failure may imp act		With standard BGP path-vector routing, a single link failure may imp act
	100s or 1000s of prefixes and result in the withdrawal or re-adverti sement of		100s or 1000s of prefixes and result in the withdrawal or readvertis ement of
	the attendant NLRI. With BGP SPF, only the BGP speakers originating		the attendant NLRI. With BGP SPF, only the BGP speakers originating
	the link NLRI need to withdraw the corresponding BGP-LS-SPF Link NLR I. Additionally,		the link NLRI need to withdraw the corresponding BGP-LS-SPF Link NLR I. Additionally,
	the changed NLRI is advertised immediately as opposed to normal BGP where it		the changed NLRI is advertised immediately as opposed to normal BGP where it
	is only advertised after the best route selection. These advantages provide		is only advertised after the best route selection. These advantages provide
	NLRI dissemination throughout the BGP SPF routing domain with effici encies similar		NLRI dissemination throughout the BGP SPF routing domain with effici encies similar
	to link-state protocols.		to link-state protocols.
	</t>		</t>
	<t>		<t>
	With controller and route-reflector peering models, BGP SPF advertis ement		With controller and route-reflector peering models, BGP SPF advertis ement
	and distributed computation require a minimal number of sessions and		and distributed computation require a minimal number of sessions and
	copies of the NLRI since only the latest version of the NLRI from th e		copies of the NLRI as only the latest version of the NLRI from the
	originator is required (see <xref target="peering-models"/>).		originator is required (see <xref target="peering-models"/>).
	Given that verification of whether or not to advertise a link (with a		Given that verification of whether or not to advertise a link (with a
	BGP-LS-SPF Link NLRI) is done outside of BGP, each BGP		BGP-LS-SPF Link NLRI) is done outside of BGP, each BGP
	speaker only needs as many sessions and copies of the NLRI as requir ed for		speaker only needs as many sessions and copies of the NLRI as requir ed for
	redundancy. Additionally, a controller could inject topology (i.e., BGP-LS-SPF NLRI)		redundancy. Additionally, a controller could inject topology (i.e., BGP-LS-SPF NLRI)
	that is learned outside the BGP SPF routing domain.		that is learned outside the BGP SPF routing domain.
	</t>		</t>
	<t>		<t>
	Given BGP-LS NLRI is already defined		Given that BGP-LS NLRI is already defined
	<xref target="RFC9552" format="default"/>, this functionality		<xref target="RFC9552" format="default"/>, this functionality
	can be reused for BGP-LS-SPF NLRI.		can be reused for BGP-LS-SPF NLRI.
	</t>		</t>
	<t>		<t>
	Another advantage of BGP SPF is that both IPv6 and IPv4 can		Another advantage of BGP SPF is that both IPv6 and IPv4 can
	be supported using the BGP-LS-SPF SAFI with the same BGP-LS-SPF Link NLRIs. In many		be supported using the BGP-LS-SPF SAFI with the same BGP-LS-SPF Link NLRIs. In many
	MSDC fabrics, the IPv4 and IPv6 topologies are congruent (refer to		MSDC fabrics, the IPv4 and IPv6 topologies are congruent (refer to
	<xref target="Link-NLRI" format="default"/>).		<xref target="Link-NLRI" format="default"/>).
	Although beyond the scope of this document, BGP-LS-SPF NLRI multi-to pology extensions could		However, beyond the scope of this document, BGP-LS-SPF NLRI multi-to pology extensions could
	be defined to support separate IPv4, IPv6, unicast, and multicast to pologies		be defined to support separate IPv4, IPv6, unicast, and multicast to pologies
	while sharing the same NLRI.		while sharing the same NLRI.
	</t>		</t>
	<t>		<t>
			<!--[rfced] How may we rephrase "and realize all the above advantages"
			for clarity? Is the intended meaning that the BGF SPF topology
			"offers" the above advantages, as shown below?
			Original:
			Finally, the BGP SPF topology can be used as an underlay for other
			BGP SAFIs (using the existing model) and realize all the above
			advantages.
			Perhaps:
			Finally, the BGP SPF topology can be used as an underlay for other
			BGP SAFIs (using the existing model), and it offers all the above
			advantages.
			-->
	Finally, the BGP SPF topology can be used as an underlay for other B GP		Finally, the BGP SPF topology can be used as an underlay for other B GP
	SAFIs (using the existing model) and realize all the above		SAFIs (using the existing model) and realize all the above
	advantages.		advantages.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Document Overview</name>		<name>Document Overview</name>
	<t>		<t>
	The document begins with sections defining the precise relationship
	that BGP SPF has		<!--[rfced] FYI - We rephrased this sentence as shown below to avoid
	with both the base BGP protocol <xref target="RFC4271" format="defau		any confusion with "[RFC4271] (Section 2)" and "[RFC9552] (Section 3)".
	lt"/> (<xref target="BGP-base" format="default"/>) and the
	BGP Link-State (BGP-LS) extensions <xref target="RFC9552" format="d		Original:
	efault"/>		The document begins with sections defining the precise relationship
	(<xref target="BGP-LS" format="default"/>). The BGP peering models,		that BGP SPF has with both the base BGP protocol [RFC4271]
	as well as		(Section 2) and the BGP Link-State (BGP-LS) extensions [RFC9552]
			(Section 3).
			Current:
			This document begins with Section 2 defining the precise relationship
			that BGP SPF has with the base BGP protocol [RFC4271] and Section 3
			defining the BGP - Link-State (BGP-LS) extensions [RFC9552].
			-->
			This document begins with <xref target="BGP-base" format="default"/>
			defining the
			precise relationship that BGP SPF has
			with the base BGP protocol <xref target="RFC4271" format="default"/>
			and <xref target="BGP-LS" format="default"/> defining the
			BGP - Link-State (BGP-LS) extensions <xref target="RFC9552" format="
			default"/>.
			The BGP peering models as well as
	their respective trade-offs are then discussed in		their respective trade-offs are then discussed in
	<xref target="peering-models" format="default"/>. The remaining sect ions, which make up the bulk of the		<xref target="peering-models" format="default"/>. The remaining sect ions, which make up the bulk of the
	document, define the protocol enhancements necessary to support BGP SPF including BGP-LS Extensions		document, define the protocol enhancements necessary to support BGP SPF including BGP-LS extensions
	(<xref target="protocol-extend" format="default"/>), replacement of the base BGP decision process		(<xref target="protocol-extend" format="default"/>), replacement of the base BGP decision process
	with the SPF computation (<xref target="bgp-decision" format="defaul t"/>), and BGP SPF error		with the SPF computation (<xref target="bgp-decision" format="defaul t"/>), and BGP SPF error
	handling (<xref target="error-handling" format="default"/>).		handling (<xref target="error-handling" format="default"/>).
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Requirements Language</name>		<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"MAY", and "OPTIONAL" in this document are to be interpreted as		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119" format="default"/> <xref		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	target="RFC8174" format="default"/>		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, and only when, they appear in all capitals, as shown here.</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	</section>		</section>
	<!-- for Introductions section -->
	<section anchor="BGP-base" numbered="true" toc="default">		<section anchor="BGP-base" numbered="true" toc="default">
	<name>Base BGP Protocol Relationship</name>		<name>Base BGP Protocol Relationship</name>
	<t>		<t>
	With the exception of the decision process, the BGP SPF extensions leverage th e BGP		With the exception of the decision process, BGP SPF extensions leverage the BG P
	protocol <xref target="RFC4271" format="default"/> without change. This inclu des the BGP protocol		protocol <xref target="RFC4271" format="default"/> without change. This inclu des the BGP protocol
	Finite State Machine, BGP messages and their encodings, processing of BGP mess ages,		Finite State Machine, BGP messages and their encodings, the processing of BGP messages,
	BGP attributes and path attributes, BGP NLRI encodings, and any error handling		BGP attributes and path attributes, BGP NLRI encodings, and any error handling
	defined in <xref target="RFC4271" format="default"/>, <xref target="RFC4760" f ormat="default"/>,		defined in <xref target="RFC4271" format="default"/>, <xref target="RFC4760" f ormat="default"/>,
	and <xref target="RFC7606" format="default"/>.		and <xref target="RFC7606" format="default"/>.
	</t>		</t>
	<t>		<t>
	Due to the changes to the decision		Due to changes in the decision
	process, there are mechanisms and encodings that are no longer applicable.		process, there are mechanisms and encodings that are no longer applicable.
	Unless explicitly specified in the context of BGP SPF, all optional path		Unless explicitly specified in the context of BGP SPF, all optional path
	attributes SHOULD NOT be advertised. If received, all path attributes MUST		attributes <bcp14>SHOULD NOT</bcp14> be advertised. If received, all path att
	be accepted, validated, and propagated consistent with the BGP protocol		ributes <bcp14>MUST</bcp14>
			be accepted, validated, and propagated consistently with the BGP protocol
	<xref target="RFC4271"/>, even if not needed by BGP SPF.		<xref target="RFC4271"/>, even if not needed by BGP SPF.
	</t>		</t>
	<t>		<t>
	Section 9.1 of <xref target="RFC4271" format="default"/> defines the decision process that		<xref section="9.1" target="RFC4271" format="default"/> defines the decision p rocess that
	is used to select routes for subsequent advertisement		is used to select routes for subsequent advertisement
	by applying the policies in the local Policy Information Base (PIB) to the		by applying the policies in the local Policy Information Base (PIB) to the
	routes stored in its Adj-RIBs-In. The output of the Decision Process is the		routes stored in 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		set of routes that are announced by a BGP speaker to its peers. These
	selected routes are stored by a BGP speaker in the speaker's Adj-RIBs-Out		selected routes are stored by a BGP speaker in the speaker's Adj-RIBs-Out,
	according to policy.		according to policy.
	</t>		</t>
	<t>		<t>
	The BGP SPF extension fundamentally changes the decision process, as described		The BGP SPF extension fundamentally changes the decision process, as described
	herein. Specifically:		herein. Specifically:
	</t>		</t>
	<ol spacing="normal" type="1">		<ol spacing="normal" type="1">
	<li>		<li>
	BGP advertisements are readvertised to neighbors immediately without waiting		BGP advertisements are readvertised to neighbors immediately without waiting
	or dependence on the route computation as specified in phase 3 of the base B		or dependence on the route computation, as specified in phase 3 of the base
	GP		BGP
	decision process. Multiple peering models are supported as specified in		decision process. Multiple peering models are supported, as specified in
	<xref target="peering-models" format="default"/>.		<xref target="peering-models" format="default"/>.
	</li>		</li>
	<li>		<li>
			<!--[rfced] May we rephrase this sentence as follows so that it parses
			and is parallel with the third entry in the list?
			Original:
			Determining the degree of preference for BGP routes for the SPF
			calculation as described in phase 1 of the base BGP decision
			process is replaced with the mechanisms in Section 6.1.
			Perhaps:
			Phase 1 of the base BGP decision process, which determines the
			degreee of preferencce for BGP routes for the SPF calculation,
			is replaced with the mechanisms in Section 6.1.
			-->
	Determining the degree of preference for BGP routes for the SPF calculation as		Determining the degree of preference for BGP routes for the SPF calculation as
	described in phase 1 of the base BGP decision process is replaced with the mec hanisms		described in phase 1 of the base BGP decision process is replaced with the mec hanisms
	in <xref target="Phase-1" format="default"/>.		in <xref target="Phase-1" format="default"/>.
	</li>		</li>
	<li>		<li>
	Phase 2 of the base BGP protocol decision process is replaced with the		Phase 2 of the base BGP protocol decision process is replaced with the
	Shortest Path First (SPF) algorithm, also known as the Dijkstra algorithm.		SPF algorithm, also known as the Dijkstra algorithm.
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<!-- for BGP relationship section -->
	<section anchor="BGP-LS" numbered="true" toc="default">		<section anchor="BGP-LS" numbered="true" toc="default">
	<name>BGP Link-State (BGP-LS) Relationship</name>		<name>BGP - Link-State (BGP-LS) Relationship</name>
	<t>		<t>
	<xref target="RFC9552" format="default"/> describes a mechanism by		<xref target="RFC9552" format="default"/> describes a mechanism by
	which link-state and Traffic Engineering (TE) information can be collected fro m networks and shared with external		which link-state and Traffic Engineering (TE) information can be collected fro m networks and shared with external
	entities using BGP.		entities using BGP.
	This is achieved by defining NLRI advertised using the BGP-LS AFI. The BGP-LS extensions defined in		This is achieved by defining NLRIs that are advertised using the BGP-LS AFI. T he BGP-LS extensions defined in
	<xref target="RFC9552" format="default"/> make use of the decision process def ined in		<xref target="RFC9552" format="default"/> make use of the decision process def ined in
	<xref target="RFC4271" format="default"/>. Rather than reusing the BGP-LS SAF I, the BGP-LS-SPF SAFI		<xref target="RFC4271" format="default"/>. Rather than reusing the BGP-LS SAF I, the BGP-LS-SPF SAFI
	(<xref target="SAFI" format="default"/>) is introduced to ensure backward comp atibility		(<xref target="SAFI" format="default"/>) is introduced to ensure backward comp atibility
	for the BGP-LS SAFI usage.		for BGP-LS SAFI usage.
	</t>		</t>
	<t>		<t>
	The "BGP-LS NLRI and Attribute TLVs" registry <xref target="RFC9552"/> is shar ed between		The "BGP-LS NLRI and Attribute TLVs" registry <xref target="RFC9552"/> is shar ed between
	the BGP-LS SAFI and the BGP-LS-SPF SAFI.		the BGP-LS SAFI and the BGP-LS-SPF SAFI.
	However, the TLVs defined in this document may not be applicable to		However, the TLVs defined in this document may not be applicable to
	the BGP-LS SAFI. As specified in Section 5.1 of <xref target="RFC9552"/>, the		the BGP-LS SAFI. As specified in <xref section="5.1" target="RFC9552"/>, the
	presence		presence
	of unknown or unexpected TLVs is required to not result in the NLRI or		of unknown or unexpected TLVs is required so that the NLRI or
	the BGP-LS Attribute being considered		BGP-LS Attribute will not be considered
	malformed (section 5.2 of <xref target="RFC9552"/>). The list of BGP-LS TLVs		malformed (<xref section="5.2" target="RFC9552"/>). The list of BGP-LS TLVs a
	applicable		pplicable
	to the BGP-LS-SPF SAFI are described in		to the BGP-LS-SPF SAFI are described in
	<xref target="NLRI-Use"/>. By default, the usage of other BGP-LS TLVs or		<xref target="NLRI-Use"/>. By default, the usage of other BGP-LS TLVs or
	extensions are ignored for the BGP-LS-SPF SAFI. However, this doesn't preclude the usage		extensions are ignored for the BGP-LS-SPF SAFI. However, this doesn't preclude the usage
	specification of these TLVs for the BGP-LS-SPF SAFI in future documents.		specification of these TLVs for the BGP-LS-SPF SAFI in future documents.
	</t>		</t>
	</section>		</section>
	<!-- for BGP-LS relationship section -->
	<section anchor="peering-models" numbered="true" toc="default">		<section anchor="peering-models" numbered="true" toc="default">
	<name>BGP SPF Peering Models</name>		<name>BGP SPF Peering Models</name>
	<t>		<t>
	Depending on the topology, scaling, capabilities of the BGP speakers, and redu ndancy		Depending on the topology, scaling, capabilities of the BGP speakers, and redu ndancy
	requirements, various peering models are supported. The only requirement is th at all BGP		requirements, various peering models are supported. The only requirement is th at all BGP
	speakers in the BGP SPF routing domain adhere to this specification.		speakers in the BGP SPF routing domain adhere to this specification.
	</t>		</t>
	<t>		<t>
	The choice of the deployment model is up to the operator and their requirement s and policies.		The choice of the deployment model is up to the operator and their requirement s and policies.
	Deployment model choice is out of scope for this document and is discussed in		Deployment model choice is out of scope for this document and is discussed in
	<xref target="I-D.ietf-lsvr-applicability" format="default"/>. The sub-section s below		<xref target="I-D.ietf-lsvr-applicability" format="default"/>. The sub-section s below
	describe several BGP SPF deployment models. However, this doesn't preclude oth er		describe several BGP SPF deployment models. However, this doesn't preclude oth er
	deployment models.		deployment models.
	</t>		</t>
	<section anchor="single-hop-peering" numbered="true" toc="default">		<section anchor="single-hop-peering" numbered="true" toc="default">
	<name>BGP Single-Hop Peering on Network Node Connections</name>		<name>BGP Single-Hop Peering on Network Node Connections</name>
	<t>		<t>
	The simplest peering model is the one where		The simplest peering model is the one where
	EBGP single-hop sessions are established over direct point-to-point links		External BGP (EBGP) single-hop sessions are established over direct point-to-p
	interconnecting the nodes in the BGP SPF routing domain. Once the single-hop B		oint links
	GP session has been		interconnecting the nodes in the BGP SPF routing domain.
	established and the Multi-Protocol Extensions Capability with the BGP-LS-SPF A
	FI/SAFI has been exchanged		<!--[rfced] In RFC 4760, the term "Multiprotocol Extensions
	<xref target="RFC4760" format="default"/> for the corresponding session, then		capabilities" is used rather than "Multi-Protocol Extensions
	the link is considered up from		Capability". We have updated the text below to reflect
	a BGP SPF perspective and the corresponding BGP-LS-SPF Link NLRI is advertised		this. Note that there is another instance in Section 5.1.
	.		Please let us know if these changes are not correct.
			Original:
			Once the single-hop BGP session has been established and the
			Multi-Protocol Extensions Capability with the BGP-LS-SPF AFI/SAFI
			has been exchanged [RFC4760] for the corresponding session...
			Current:
			Once the single-hop BGP session has been established and the
			Multiprotocol Extensions capabilities have been exchanged with
			the BGP-LS-SPF AFI/SAFI [RFC4760] for the corresponding session...
			-->
			Once the single-hop BGP session has been
			established and the Multiprotocol Extensions capabilities have been exchanged
			with the BGP-LS-SPF AFI/SAFI
			<xref target="RFC4760" format="default"/> for the corresponding session, then
			the link is considered up and available from
			a BGP SPF perspective, and the corresponding BGP-LS-SPF Link NLRI is advertise
			d.
	</t>		</t>
	<t>		<t>
	An End-of-RIB (EoR) Marker (<xref target="BGP-LS-SPF-EOR"/>) for the BGP-LS-SP		An End-of-RIB (EoR) marker (<xref target="BGP-LS-SPF-EOR"/>) for the BGP-LS-SP
	F		F
	SAFI MAY be required from a peer prior to advertising the BGP-LS-SPF Link NLRI		SAFI <bcp14>MAY</bcp14> be required from a peer prior to advertising the BGP-L
	for the corresponding link to that peer. When required, the default		S-SPF Link NLRI
	wait indefinitely for the EoR Marker prior to advertising the BGP-LS-SPF Link		for the corresponding link to that peer.
	NLRI.
			<!--[rfced] The following sentence does not parse - are some words
			perhaps missing after "default"? Please let us know how we may
			rephrase for clarity.
			Original:
			When required, the default wait indefinitely for the EoR Marker prior
			to advertising the BGP-LS-SPF Link NLRI. Refer to Section 10.4.
			-->
			When required, the default
			wait indefinitely for the EoR marker prior to advertising the BGP-LS-SPF Link
			NLRI.
	Refer to <xref target="Adjacency-EoR-Required"/>.		Refer to <xref target="Adjacency-EoR-Required"/>.
	</t>		</t>
	<t>		<t>
	A failure to consistently configure the use of the EoR marker can		A failure to consistently configure the use of the EoR marker can
	result in transient micro-loops and dropped traffic due to incomplete		result in transient micro-loops and dropped traffic due to incomplete
	forwarding state.		forwarding state.
	</t>		</t>
	<t>		<t>
	If the session goes down, the corresponding Link NLRI are withdrawn. Topologic ally,		If the session goes down, the corresponding Link NLRIs are withdrawn. Topologi cally,
	this would be equivalent to the peering model in <xref target="RFC7938" format ="default"/> where there		this would be equivalent to the peering model in <xref target="RFC7938" format ="default"/> where there
	is a BGP session on every link in the data center switch fabric. The content of the Link NLRI		is a BGP session on every link in the data center switch fabric. The content of the Link NLRI
	is described in <xref target="Link-NLRI" format="default"/>.		is described in <xref target="Link-NLRI" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP Peering Between Directly-Connected Nodes</name>		<name>BGP Peering Between Directly Connected Nodes</name>
	<t>		<t>
	In this model, BGP speakers peer with all directly-connected		In this model, BGP speakers peer with all directly connected
	nodes but the sessions may be between loopback addresses (i.e.,		nodes but the sessions may be between loopback addresses (i.e.,
	two-hop sessions) and the direct connection		two-hop sessions), and the direct connection
	discovery and liveness detection for the interconnecting links are		discovery and liveness detection for the interconnecting links are
	independent of the BGP protocol. The BFD protocol <xref target="RFC5880" forma		independent of the BGP protocol. The Bidirectional Forwarding Detection (BFD)
	t="default"/>		protocol <xref target="RFC5880" format="default"/>
	is RECOMMENDED for liveness detection. Usage of other liveness connection mech		is <bcp14>RECOMMENDED</bcp14> for liveness detection. Usage of other liveness
	anisms		connection mechanisms
	is outside the scope of this document.		is outside the scope of this document.
	Consequently, there is a single BGP session even if there are multiple		Consequently, there is a single BGP session even if there are multiple
	direct connections between BGP speakers. The BGP-LS-SPF Link NLRI is advertise d		direct connections between BGP speakers. The BGP-LS-SPF Link NLRI is advertise d
	as long as a BGP session has been established, the BGP-LS-SPF AFI/SAFI		as long as a BGP session has been established, the BGP-LS-SPF AFI/SAFI
	capability has been exchanged <xref target="RFC4760" format="default"/>,		capability has been exchanged <xref target="RFC4760" format="default"/>,
	the link is operational as determined using liveness detection mechanisms,		the link is operational as determined using liveness detection mechanisms,
	and, optionally, the EoR Marker has been received as described in the		and, optionally, the EoR marker has been received as described in
	<xref target="BGP-LS-SPF-EOR"/>.		<xref target="BGP-LS-SPF-EOR"/>.
	This is much like the previous peering model only peering is between		This is much like the previous peering model, except peering is between
	loopback addresses and the interconnecting links can be unnumbered. However,		loopback addresses and the interconnecting links can be unnumbered. However,
	since there are BGP sessions between every directly-connected node in the		since there are BGP sessions between every directly connected node in the
	BGP SPF routing domain, there is a reduction in BGP sessions when there		BGP SPF routing domain, there is a reduction in BGP sessions when there
	are parallel links between nodes. Hence, this peering model is RECOMMENDED		are parallel links between nodes. Hence, this peering model is <bcp14>RECOMMEN DED</bcp14>
	over the single-hop peering model <xref target="single-hop-peering"/>.		over the single-hop peering model <xref target="single-hop-peering"/>.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP Peering in Route-Reflector or Controller Topology</name>		<name>BGP Peering in Route-Reflector or Controller Topology</name>
	<t>		<t>
	In this model, BGP speakers peer solely with one or more Route Reflectors		In this model, BGP speakers peer solely with one or more route reflectors
	<xref target="RFC4456" format="default"/> or controllers. As in the previous m odel, direct		<xref target="RFC4456" format="default"/> or controllers. As in the previous m odel, direct
	connection discovery and liveness detection for those links in the BGP		connection discovery and liveness detection for those links in the BGP
	SPF routing domain are done outside of the BGP protocol.		SPF routing domain are done outside of the BGP protocol.
	BGP-LS-SPF Link NLRI is advertised as long as the corresponding link is		BGP-LS-SPF Link NLRI is advertised as long as the corresponding link is
	considered up as per the chosen liveness detection mechanism (The BFD protocol		considered up and available as per the chosen liveness detection mechanism (th
	<xref target="RFC5880" format="default"/> is RECOMMENDED).		us, the BFD protocol
			<xref target="RFC5880" format="default"/> is <bcp14>RECOMMENDED</bcp14>).
	</t>		</t>
	<t>		<t>
	This peering model, known as sparse peering, allows for fewer BGP sessions		This peering model, known as "sparse peering", allows for fewer BGP sessions
	and, consequently, fewer instances of the same NLRI received from multiple pee rs.		and, consequently, fewer instances of the same NLRI received from multiple pee rs.
	Ideally, the route-reflectors or controller BGP sessions would be on directly- connected		Ideally, the route reflectors or controller BGP sessions would be on directly connected
	links to avoid dependence on another routing protocol for session connectivity . However,		links to avoid dependence on another routing protocol for session connectivity . However,
	multi-hop peering is not precluded. The number of BGP sessions is dependent		multi-hop peering is not precluded. The number of BGP sessions is dependent
	on the redundancy requirements and the stability of the BGP sessions.		on the redundancy requirements and the stability of the BGP sessions.
	</t>		</t>
	<t>		<t>
	The controller may use constraints to determine		The controller may use constraints to determine
	when to advertise BGP-LS-SPF NLRI for BGP-LS peers. For example, a controller		when to advertise BGP-LS-SPF NLRI for BGP-LS peers. For example, a controller
	may delay advertisement of a link between two peers the until EoR		may delay advertisement of a link between two peers the until the EoR
	marker <xref target="BGP-LS-SPF-EOR"/> has been		marker <xref target="BGP-LS-SPF-EOR"/> has been
	received from both BGP peers and the BGP-LS Link NLRI for the link(s) between the two nodes		received from both BGP peers and the BGP-LS Link NLRI for the link(s) between the two nodes
	have been received from both BGP peers.		has been received from both BGP peers.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<!--[rfced] May we update the title of Section 5 to reflect "Shortest
			Path Forward (SPF)" instead of "Shortest Path Routing (SPF)" for
			consistency? And may we remove the SPF expansion in the title of
			Section 5.1 since it was expanded in the title of Section 5?
			Original:
			5. BGP Shortest Path Routing (SPF) Protocol Extensions . . . 9
			5.1. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . 10
			Perhaps:
			5. BGP Shortest Path First (SPF) Protocol Extensions . . . . . 9
			5.1. BGP-LS SPF SAFI . . . . . . . . . . . . . . . . . . . . . 10
			-->
	<section anchor="protocol-extend" numbered="true" toc="default">		<section anchor="protocol-extend" numbered="true" toc="default">
	<name>BGP Shortest Path Routing (SPF) Protocol Extensions</name>		<name>BGP Shortest Path Routing (SPF) Protocol Extensions</name>
	<section anchor="SAFI" numbered="true" toc="default">		<section anchor="SAFI" numbered="true" toc="default">
	<name>BGP-LS Shortest Path Routing (SPF) SAFI</name>		<name>BGP-LS Shortest Path Routing (SPF) SAFI</name>
	<t>		<t>
	This document introduces the BGP-LS-SPF SAFI with a value of 80.		This document introduces the BGP-LS-SPF SAFI with a value of 80.
	The SPF-based decision process (Section 6) applies only to the		The SPF-based decision process (<xref target="bgp-decision"/>) applies only to
	BGP-LS-SPF SAFI and MUST NOT be used with other combinations of		the
	the BGP-LS AFI (16388). In order for two BGP speakers to		BGP-LS-SPF SAFI and <bcp14>MUST NOT</bcp14> be used with other combinations of
	exchange BGP-LS-SPF NLRI, they MUST exchange the Multiprotocol		the BGP-LS AFI (16388).
	Extensions Capability <xref target="RFC4760" format="default"/>		In order for two BGP speakers to
	to ensure that they are both capable of properly processing such		exchange BGP-LS-SPF NLRI, they <bcp14>MUST</bcp14> exchange Multiprotocol
			Extensions capabilities <xref target="RFC4760" format="default"/>
			to ensure that they are both capable of properly processing such an
	NLRI. This is done with AFI 16388 / SAFI 80. The BGP-LS-SPF SAFI		NLRI. This is done with AFI 16388 / SAFI 80. The BGP-LS-SPF SAFI
	is used to advertise IPv4 and IPv6 prefix information in a		is used to advertise IPv4 and IPv6 prefix information in a
	format facilitating an SPF-based decision process.		format facilitating an SPF-based decision process.
	</t>		</t>
	<section anchor="BGP-LS-TLV" numbered="true" toc="default">		<section anchor="BGP-LS-TLV" numbered="true" toc="default">
	<name>BGP-LS-SPF NLRI TLVs</name>		<name>BGP-LS-SPF NLRI TLVs</name>
	<t>		<t>
	All the TLVs defined for BGP-LS <xref target="RFC9552" format="default"/>		All the TLVs defined for BGP-LS <xref target="RFC9552" format="default"/>
	are applicable and can be used with the BGP-LS-SPF SAFI to describe links, nod es,		are applicable and can be used with the BGP-LS-SPF SAFI to describe links, nod es,
	and prefixes comprising BGP-SPF LSDB information.		and prefixes comprising BGP SPF Link-State Database (LSDB) information.
	</t>		</t>
	<t>		<t>
	The NLRI and comprising TLVs MUST be encoded as specified in		The NLRI and comprising TLVs <bcp14>MUST</bcp14> be encoded as specified in
	section 5.1 <xref target="RFC9552" format="default"/>. TLVs specified as		<xref section="5.1" target="RFC9552" format="default"/>. TLVs specified as
	mandatory in <xref target="RFC9552" format="default"/> are		mandatory in <xref target="RFC9552" format="default"/> are
	considered mandatory for the BGP-LS-SPF SAFI as		considered mandatory for the BGP-LS-SPF SAFI as
	well. If a mandatory TLV is not present, the NLRI MUST NOT be used in the		well. If a mandatory TLV is not present, the NLRI <bcp14>MUST NOT</bcp14> be u sed in the
	BGP SPF route calculation. All the other TLVs are considered as optional TLVs. Documents		BGP SPF route calculation. All the other TLVs are considered as optional TLVs. Documents
	specifying usage of optional TLV for BGP SPF MUST address backward compatibili ty.		specifying usage of optional TLVs for BGP SPF <bcp14>MUST</bcp14> address back ward compatibility.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS Attribute</name>		<name>BGP-LS Attribute</name>
	<t>		<t>
	The BGP-LS attribute of the BGP-LS-SPF SAFI uses exactly same format of the BG P-LS AFI		The BGP-LS attribute of the BGP-LS-SPF SAFI uses the exact same format as the BGP-LS AFI
	<xref target="RFC9552" format="default"/>. In		<xref target="RFC9552" format="default"/>. In
	other words, all the TLVs used in the BGP-LS attribute of the BGP-LS AFI are a pplicable		other words, all the TLVs used in the BGP-LS attribute of the BGP-LS AFI are a pplicable
	and used for the BGP-LS attribute of the BGP-LS-SPF SAFI. This attribute is an optional,		and are used for the BGP-LS attribute of the BGP-LS-SPF SAFI. This attribute i s an optional,
	non-transitive BGP attribute that is used to carry link, node, and prefix		non-transitive BGP attribute that is used to carry link, node, and prefix
	properties and attributes. The BGP-LS attribute is a set of TLVs.		properties and attributes. The BGP-LS attribute is a set of TLVs.
	</t>		</t>
	<t>		<t>
	All the TLVs defined for the BGP-LS Attribute <xref target="RFC9552" format=" default"/>		All the TLVs defined for the BGP-LS Attribute <xref target="RFC9552" format=" default"/>
	are applicable and can be used with the BGP-LS-SPF SAFI to carry link, node, a nd prefix		are applicable and can be used with the BGP-LS-SPF SAFI to carry link, node, a nd prefix
	properties and attributes.		properties and attributes.
	</t>		</t>
	<t>		<t>
	The BGP-LS attribute may potentially be quite large depending on		The BGP-LS attribute may potentially be quite large depending on
	the amount of link-state information associated with a single BGP-LS-SPF NLRI.		the amount of link-state information associated with a single BGP-LS-SPF NLRI.
	The BGP specification <xref target="RFC4271" format="default"/> mandates a max imum BGP		The BGP specification <xref target="RFC4271" format="default"/> mandates a max imum BGP
	message size of 4096 octets. It is RECOMMENDED that an		message size of 4096 octets. It is <bcp14>RECOMMENDED</bcp14> that an
	implementation support <xref target="RFC8654" format="default"/> in order to a ccommodate a greater		implementation support <xref target="RFC8654" format="default"/> in order to a ccommodate a greater
	amount of information within the BGP-LS Attribute. BGP speakers MUST		amount of information within the BGP-LS Attribute. BGP speakers <bcp14>MUST</ bcp14>
	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		ensure 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		not cross the maximum limit for a BGP message. The determination of
	the types of TLVs to be included by the BGP speaker		the types of TLVs to be included by the BGP speaker
	originating the attribute is outside the scope of this document.		originating the attribute is outside the scope of this document.
	If, due to the limits on the maximum size of an UPDATE message, a single		If, due to the limits on the maximum size of an UPDATE message, a single
	route doesn't fit into the message, the BGP speaker MUST NOT advertise the		route doesn't fit into the message, the BGP speaker <bcp14>MUST NOT</bcp14> ad
	route to its peer and MAY choose to log an error locally <xref target="RFC4271		vertise the
	"/>.		route to its peer and <bcp14>MAY</bcp14> choose to log an error locally <xref
			target="RFC4271"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="NLRI-Use" numbered="true" toc="default">		<section anchor="NLRI-Use" numbered="true" toc="default">
	<name>Extensions to BGP-LS</name>		<name>Extensions to BGP-LS</name>
	<t>		<t>
	<xref target="RFC9552" format="default"/> describes a mechanism		<xref target="RFC9552" format="default"/> describes a mechanism
	by which link-state and TE		by which link-state and TE
	information can be collected from IGPs and shared with external components		information can be collected from IGPs and shared with external components
	using the BGP protocol. It describes both the definition of the BGP-LS NLRI		using the BGP protocol. It describes both the definition of the BGP-LS NLRI
	skipping to change at line 547 ¶		skipping to change at line 640 ¶
	information and the definition of a BGP path attribute (BGP-LS		information and the definition of a BGP path attribute (BGP-LS
	attribute) that carries link, node, and prefix properties and		attribute) that carries link, node, and prefix properties and
	attributes, such as the link and prefix metric or auxiliary		attributes, such as the link and prefix metric or auxiliary
	Router-IDs of nodes, etc. This document extends the usage of BGP-LS NLRI for		Router-IDs of nodes, etc. This document extends the usage of BGP-LS NLRI for
	the purpose of BGP SPF calculation via advertisement in the BGP-LS-SPF SAFI.		the purpose of BGP SPF calculation via advertisement in the BGP-LS-SPF SAFI.
	</t>		</t>
	<t>		<t>
	The protocol identifier specified in the Protocol-ID field		The protocol identifier specified in the Protocol-ID field
	<xref target="RFC9552" format="default"/>		<xref target="RFC9552" format="default"/>
	represents the origin of the advertised NLRI. For Node NLRI and Link NLRI,		represents the origin of the advertised NLRI. For Node NLRI and Link NLRI,
	the specified Protocol-ID MUST be the direct protocol (4). Node or Link NLRI w ith a		the specified Protocol-ID <bcp14>MUST</bcp14> be the direct protocol (4). Node or Link NLRI with a
	Protocol-ID other than the direct protocol is considered malformed.		Protocol-ID other than the direct protocol is considered malformed.
	For Prefix NLRI, the specified Protocol-ID		For Prefix NLRI, the specified Protocol-ID
	MUST be the origin of the prefix. The local and remote node descriptors for al l NLRI MUST		<bcp14>MUST</bcp14> be the origin of the prefix. The Local and Remote Node Des criptors for all NLRI <bcp14>MUST</bcp14>
	include the BGP Router-ID (TLV 516) <xref target="RFC9086"/>		include the BGP Router-ID (TLV 516) <xref target="RFC9086"/>
	and the AS Number (TLV 512)		and the Autonomous System (TLV 512) number
	<xref target="RFC9552" format="default"/>.		<xref target="RFC9552" format="default"/>.
	The BGP Confederation Member (TLV 517)		The BGP Confederation Member (TLV 517)
	<xref target="RFC9086" format="default"/> is not applicable.		<xref target="RFC9086" format="default"/> is not applicable.
	</t>		</t>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Node NLRI Usage</name>		<name>Node NLRI Usage</name>
	<t>		<t>
	The Node NLRI MUST be advertised unconditionally by all routers in		The Node NLRI <bcp14>MUST</bcp14> be advertised unconditionally by all routers in
	the BGP SPF routing domain.		the BGP SPF routing domain.
	</t>		</t>
	<section anchor="node-status-tlv" numbered="true" toc="default">		<section anchor="node-status-tlv" numbered="true" toc="default">
	<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV</name>		<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV</name>
	<t>		<t>
	A BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Node NLRI is defined to in dicate the status of		A BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Node NLRI is defined to in dicate the status of
	the node with respect to the BGP SPF calculation. This is used to rapidly take a		the node with respect to the BGP SPF calculation. This is used to rapidly take a
	node out of service (refer to <xref target="node-failure" format="default"/>)		node out of service (refer to <xref target="node-failure" format="default"/>)
	or to indicate the node is not to be		or to indicate that the node is not to be
	used for transit (i.e., non-local) traffic (refer to <xref target="BGP-SPF" fo rmat="default"/>).		used for transit (i.e., non-local) traffic (refer to <xref target="BGP-SPF" fo rmat="default"/>).
	If the SPF Status TLV is not included with the Node NLRI, the node is consider ed to be up		If the SPF Status TLV is not included with the Node NLRI, the node is consider ed to be up
	and is available for transit traffic. A single TLV type is shared by the Node, Link, and		and is available for transit traffic. A single TLV type is shared by the Node, Link, and
	Prefix NLRI. The TLV type is 1184.		Prefix NLRI. The TLV type is 1184.
	</t>		</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1184) | Length (1 Octet) |		| Type (1184) | Length (1 Octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPF Status |		| SPF Status |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
			]]></artwork>
	SPF Status Values: 0 - Reserved		<table>
	1 - Node unreachable with respect to BGP SPF		<name>SPF Status Values</name>
	2 - Node does not support transit with respect		<thead>
	to BGP SPF		<tr><th>Value</th><th>Description</th></tr>
	3-254 - Undefined		</thead>
	255 - Reserved		<tbody>
			<tr><td>0</td><td>Reserved</td></tr>
			<tr><td>1</td><td>Node unreachable with respect to BGP SPF</td></tr>
			<tr><td>2</td><td>Node does not support transit with respect to BGP SPF</td>
			</tr>
			<tr><td>3-254</td><td>Unassigned</td></tr>
			<tr><td>255</td><td>Reserved</td></tr>
			</tbody>
			</table>
	]]></artwork>
	<t>		<t>
	If a BGP speaker received the Node NLRI but		If a BGP speaker received the Node NLRI but
	the SPF Status TLV is not received, then any previously received SPF status in formation is		the SPF Status TLV is not received, then any previously received SPF status in formation is
	considered as implicitly withdrawn and the NLRI is propagated to other BGP spe akers.		considered as implicitly withdrawn, and the NLRI is propagated to other BGP sp eakers.
	A BGP speaker receiving a BGP Update containing		A BGP speaker receiving a BGP Update containing
	an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="defau lt"/>		an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="defau lt"/>
	with an unknown value SHOULD be advertised to other		with an unknown value <bcp14>SHOULD</bcp14> be advertised to other
	BGP speakers and MUST ignore the Status TLV with an unknown value in		BGP speakers and <bcp14>MUST</bcp14> ignore the Status TLV with an unknown val
			ue in
	the SPF computation.		the SPF computation.
	An implementation MAY log this condition for further analysis.		An implementation <bcp14>MAY</bcp14> log this condition for further analysis.
	If the SPF Status TLV contains a reserved value (0 or 255) the TLV is consider		If the SPF Status TLV contains a reserved value (0 or 255), the TLV is conside
	ed malformed and		red malformed and
	is handled as described in <xref target="new-TLVs"/>.		is handled as described in <xref target="new-TLVs"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Link-NLRI" numbered="true" toc="default">		<section anchor="Link-NLRI" numbered="true" toc="default">
	<name>Link NLRI Usage</name>		<name>Link NLRI Usage</name>
	<t>		<t>
	The criteria for advertisement of Link NLRI are discussed in		The criteria for advertisement of Link NLRIs are discussed in
	<xref target="peering-models" format="default"/>.		<xref target="peering-models" format="default"/>.
	</t>		</t>
	<t>		<t>
	Link NLRI is advertised with unique local and remote node descriptors		Link NLRI is advertised with unique Local and Remote Node Descriptors
	dependent on the IP addressing. For IPv4 links, the		dependent on the IP addressing.
	link's local IPv4 (TLV 259) and remote IPv4 (TLV 260) addresses are used.
	For IPv6 links, the local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses		<!--[rfced] FYI - We updated the following text to reflect the TLV
	are used (Section 5.2.2 of <xref target="RFC9552"/>). IPv6 links without		names per RFC 9552.
			Original:
			For IPv4 links, the link's local IPv4 (TLV 259) and remote IPv4
			(TLV 260) addresses are used. For IPv6 links, the local IPv6
			(TLV 261) and remote IPv6 (TLV 262) addresses are used (Section
			5.2.2 of [RFC9552]).
			Current:
			For IPv4 links, the link's local IPv4 interface address (TLV 259)
			and remote IPv4 neighbor address (TLV 260) are used. For IPv6
			links, the local IPv6 interface address (TLV 261) and remote IPv6
			neighbor address (TLV 262) are used (Section 5.2.2 of [RFC9552]).
			-->
			For IPv4 links, the
			link's local IPv4 interface address (TLV 259) and remote IPv4 neighbor address
			(TLV 260) are used.
			For IPv6 links, the local IPv6 interface address (TLV 261) and remote IPv6 nei
			ghbor address (TLV 262)
			are used (<xref section="5.2.2" target="RFC9552"/>). IPv6 links without
	global IPv6 addresses are considered unnumbered links and are handled as		global IPv6 addresses are considered unnumbered links and are handled as
	described below.		described below.
	For links supporting having both IPv4 and IPv6 addresses, both sets		For links supporting both IPv4 and IPv6 addresses, both sets
	of descriptors MAY be included in the same Link NLRI.		of descriptors <bcp14>MAY</bcp14> be included in the same Link NLRI.
	</t>		</t>
	<t>		<t>
	For unnumbered links, the Link Local/Remote Identifiers (TLV 258)		For unnumbered links, the Link Local/Remote Identifiers (TLV 258)
	are used. The Link Remote Identifier isn't normally exchanged in BGP		are used. The Link Remote Identifier isn't normally exchanged in BGP,
	and discovering the Link Remote Identifier is beyond the scope of this		and discovering the Link Remote Identifier is beyond the scope of this
	document. If the Link Remote Identifier is unknown, a Link Remote Identifier o f		document. If the Link Remote Identifier is unknown, a Link Remote Identifier o f
	0 MUST be advertised. When 0 is advertised and there are parallel unnumbered l inks		0 <bcp14>MUST</bcp14> be advertised. When 0 is advertised and there are parall el unnumbered links
	between a pair of BGP speakers, there may be transient intervals where the		between a pair of BGP speakers, there may be transient intervals where the
	BGP speakers don't agree on which of the parallel unnumbered links are operati onal.		BGP speakers don't agree on which of the parallel unnumbered links are operati onal.
	For this reason, it is RECOMMENDED that the Link Remote Identifiers be		For this reason, it is <bcp14>RECOMMENDED</bcp14> that the Link Remote Identif iers be
	known (e.g., discovered using alternate mechanisms or configured) in the prese nce		known (e.g., discovered using alternate mechanisms or configured) in the prese nce
	of parallel unnumbered links.		of parallel unnumbered links.
	</t>		</t>
	<t>		<t>
	The link descriptors are		The link descriptors are
	described in table 4 of <xref target="RFC9552" format="default"/>.		described in Table 4 of <xref target="RFC9552" format="default"/>.
	Additionally, the Address Family Link Descriptor TLV is defined to determine w hether an		Additionally, the Address Family Link Descriptor TLV is defined to determine w hether an
	unnumbered link can be used in the IPv4 SPF, the IPv6, or both (refer to		unnumbered link can be used in the IPv4 SPF, the IPv6, or both (refer to
	<xref target="af-link-descriptor-tlv"/>).		<xref target="af-link-descriptor-tlv"/>).
	</t>		</t>
	<t>		<t>
	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 matching addres		i.e., IPv4 or IPv6, both routers connecting the link <bcp14>MUST</bcp14> have
	ses (i.e.,		matching addresses (i.e.,
	router interface addresses must be on the same subnet for numbered interfaces		router interface addresses must be on the same subnet for numbered interfaces,
	and the		and the
	local/remote link identifiers (<xref target="BGP-SPF"/>) must match for unnumb ered		local/remote link identifiers (<xref target="BGP-SPF"/>) must match for unnumb ered
	interfaces).		interfaces).
	</t>		</t>
	<t>		<t>
	The IGP metric attribute TLV (TLV 1095) MUST be advertised. If a BGP speaker		The IGP Metric (TLV 1095) <bcp14>MUST</bcp14> be advertised. If a BGP speaker
	receives a Link NLRI without an IGP metric attribute TLV, then it MUST conside		receives a Link NLRI without an IGP Metric attribute TLV, then it <bcp14>MUST<
	r		/bcp14> consider
	the received NLRI as a malformed (refer to <xref target="error-handling"/>).		the received NLRI as malformed (refer to <xref target="error-handling"/>).
	The BGP SPF metric length is 4 octets. A metric is associated with the output side of each		The BGP SPF metric length is 4 octets. A metric is associated with the output side of each
	router interface. This metric is configurable by the system administrator. T he		router interface. This metric is configurable by the system administrator. T he
	lower the metric, the more likely the interface is to be used to forward data traffic.		lower the metric, the more likely the interface is to be used to forward data traffic.
	One possible default for metric would be to give each interface a metric of 1		One possible default for the metric would be to give each interface a metric of 1
	making it effectively a hop count.		making it effectively a hop count.
	</t>		</t>
	<t>		<t>
	The usage of other link attribute TLVs is beyond the scope of this document.		The usage of other link attribute TLVs is beyond the scope of this document.
	</t>		</t>
	<section anchor="af-link-descriptor-tlv" numbered="true" toc="default">		<section anchor="af-link-descriptor-tlv" numbered="true" toc="default">
	<name>BGP-LS Link NLRI Address Family Link Descriptor TLV</name>		<name>BGP-LS Link NLRI Address Family Link Descriptor TLV</name>
	<t>		<t>
			<!--[rfced] Section 5.2.2.1. For consistency, should instances of
			"Address Family Link Descriptor" include "TLV" (i.e., "Address
			Family Link Descriptor TLV") in the following paragraph (as the
			latter part of the sentence (not shown) includes it)?
			Original:
			For unnumbered links, the address family cannot be ascertained from
			the endpoint link descriptors. Hence, the Address Family (AF) Link
			Descriptor SHOULD be included with the Link Local/Remote Identifiers
			TLV for unnumbered links, so that the link can be used in the
			respective address family SPF. If the Address Family Link Descriptor
			is not present for an unnumbered link, the link will not be used in
			the SPF computation for either address family. If the Address Family
			Link Descriptor is present for a numbered link, the link descriptor
			will be ignored.
			-->
	For unnumbered links, the address family cannot be ascertained from the		For unnumbered links, the address family cannot be ascertained from the
	endpoint link descriptors. Hence, the Address Family (AF) Link Descriptor SH OULD		endpoint link descriptors. Hence, the Address Family Link Descriptor <bcp14> SHOULD</bcp14>
	be included with the Link Local/Remote Identifiers TLV for unnumbered links,		be included with the Link Local/Remote Identifiers TLV for unnumbered links,
	so that the link can be used in the respective address family SPF. If the		so that the link can be used in the respective address family SPF. If the
	Address Family Link		Address Family Link
	Descriptor is not present for an unnumbered link, the link will not be		Descriptor is not present for an unnumbered link, the link will not be
	used in the SPF computation for either address family. If the Address Family Link		used in the SPF computation for either address family. If the Address Family Link
	Descriptor is present for a numbered link, the link descriptor		Descriptor is present for a numbered link, the link descriptor
	will be ignored. If the Address Family Link Descriptor TLV contains an		will be ignored. If the Address Family Link Descriptor TLV contains an
	undefined value (3-254), the link descriptor will be ignored.		undefined value (3-254), the link descriptor will be ignored.
	If the Address Family Link Descriptor TLV contains a		If the Address Family Link Descriptor TLV contains a
	reserved value (0 or 255) the TLV is considered malformed and		reserved value (0 or 255), the TLV is considered malformed and
	is handled as described in <xref target="new-TLVs"/>.		is handled as described in <xref target="new-TLVs"/>.
	</t>		</t>
	<t>		<t>
	Note that an unnumbered link can be used for both the IPv4 and IPv6		Note that an unnumbered link can be used for both the IPv4 and IPv6
	SPF computation by advertising separate Address Family Link Descriptor		SPF computation by advertising separate Address Family Link Descriptor
	TLVs for IPv4 and IPv6.		TLVs for IPv4 and IPv6.
	</t>		</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1185) | Length (1 Octet) |		| Type (1185) | Length (1 Octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address Family|		| Address Family|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
			]]></artwork>
	Address Family Values: 0 - Reserved		<table>
	1 - IPv4 Address Family		<name>Address Family Values</name>
	2 - IPv6 Address Family		<thead>
	3-254 - Undefined		<tr><th>Value</th><th>Description</th></tr>
	255 - Reserved		</thead>
			<tbody>
			<tr><td>0</td><td>Reserved</td></tr>
			<tr><td>1</td><td>IPv4 Address Family</td></tr>
			<tr><td>2</td><td>IPv6 Address Family</td></tr>
			<tr><td>3-254</td><td>Undefined</td></tr>
			<tr><td>255</td><td>Reserved</td></tr>
			</tbody>
			</table>
	]]></artwork>
	</section>		</section>
	<section anchor="link-status-tlv" numbered="true" toc="default">		<section anchor="link-status-tlv" numbered="true" toc="default">
	<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV</name>		<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV</name>
	<t>		<t>
	This BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined to		The BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined to
	indicate the status of the link with respect to the BGP SPF calculation. Thi s is used to expedite		indicate the status of the link with respect to the BGP SPF calculation. Thi s is used to expedite
	convergence for link failures as discussed in <xref target="failure-converge " format="default"/>. If the		convergence for link failures as discussed in <xref target="failure-converge " format="default"/>. If the
	SPF Status TLV is not included with the Link NLRI, the link is considered		SPF Status TLV is not included with the Link NLRI, the link is considered
	up and available. The SPF status is acted upon with the execution of the		up and available. The SPF status is acted upon with the execution of the
	next SPF calculation <xref target="BGP-SPF" format="default"/>.		next SPF calculation (<xref target="BGP-SPF" format="default"/>).
	A single TLV type is shared by the Node, Link, and Prefix NLRI.		A single TLV type is shared by the Node, Link, and Prefix NLRI.
	The TLV type is 1184.		The TLV type is 1184.
	</t>		</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1184) | Length (1 Octet) |		| Type (1184) | Length (1 Octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPF Status |		| SPF Status |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
			]]></artwork>
	BGP Status Values: 0 - Reserved		<table>
	1 - Link Unreachable with respect to BGP SPF		<name>BGP Status Values</name>
	2-254 - Undefined		<thead>
	255 - Reserved		<tr><th>Value</th><th>Description</th></tr>
			</thead>
	]]></artwork>		<tbody>
			<tr><td>0</td><td>Reserved</td></tr>
			<tr><td>1</td><td>Link unreachable with respect to BGP SPF</td></tr>
			<tr><td>2-254</td><td>Unassigned</td></tr>
			<tr><td>255</td><td>Reserved</td></tr>
			</tbody>
			</table>
	<t>		<t>
	If a BGP speaker received the Link NLRI but		If a BGP speaker received the Link NLRI but
	the SPF Status TLV is not received, then any previously received SPF status information is		the SPF Status TLV is not received, then any previously received SPF status information is
	considered as implicitly withdrawn and the NLRI is propagated to other BGP s peakers.		considered as implicitly withdrawn, and the NLRI is propagated to other BGP speakers.
	A BGP speaker receiving a BGP Update containing		A BGP speaker receiving a BGP Update containing
	an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="def ault"/>		an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="def ault"/>
	with an unknown value SHOULD be advertised to other		with an unknown value <bcp14>SHOULD</bcp14> be advertised to other
	BGP speakers and MUST ignore the Status TLV with an unknown value in		BGP speakers and <bcp14>MUST</bcp14> ignore the SPF Status TLV with an unkno
			wn value in
	the SPF computation.		the SPF computation.
	An implementation MAY log this information for further analysis.		An implementation <bcp14>MAY</bcp14> log this information for further analys
	If the SPF Status TLV contains a reserved value (0 or 255) the TLV is consid		is.
	ered malformed and		If the SPF Status TLV contains a reserved value (0 or 255), the TLV is consi
			dered malformed and
	is handled as described in <xref target="new-TLVs"/>.		is handled as described in <xref target="new-TLVs"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Prefix-NLRI" numbered="true" toc="default">		<section anchor="Prefix-NLRI" numbered="true" toc="default">
	<name>IPv4/IPv6 Prefix NLRI Usage</name>		<name>IPv4/IPv6 Prefix NLRI Usage</name>
	<t>		<t>
	IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor and		A IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor and
	the prefix and length. The Prefix Descriptors field includes the IP Reachabi		the prefix and length. The Prefix Descriptor field includes IP Reachability
	lity		Information (TLV 265) as described in <xref target="RFC9552" format="default
	Information TLV (TLV 265) as described in <xref target="RFC9552" format="def		"/>.
	ault"/>.		The Prefix Metric (TLV 1155) <bcp14>MUST</bcp14> be advertised to be conside
	The Prefix Metric TLV (TLV 1155) MUST be advertised to be considered for rou		red for route calculation. The IGP Route Tag (TLV 1153) <bcp14>MAY</bcp14> be ad
	te calculation.		vertised. The usage of other BGP-LS
	The IGP Route Tag TLV (TLV 1153) MAY be advertised. The usage of other BGP-L
	S
	attribute TLVs is beyond the scope of this document.		attribute TLVs is beyond the scope of this document.
	</t>		</t>
	<section anchor="prefix-status-tlv" numbered="true" toc="default">		<section anchor="prefix-status-tlv" numbered="true" toc="default">
	<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV</name>		<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV</name>
	<t>		<t>
	A BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Prefix NLRI is defined to indicate the status of		A BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Prefix NLRI is defined to indicate the status of
	the prefix with respect to the BGP SPF calculation. This is used to expedi te		the prefix with respect to the BGP SPF calculation. This is used to expedi te
	convergence for prefix unreachability as discussed in <xref target="failur e-converge" format="default"/>.		convergence for prefix unreachability, as discussed in <xref target="failu re-converge" format="default"/>.
	If the SPF Status TLV is not included with the Prefix NLRI, the prefix is considered		If the SPF Status TLV is not included with the Prefix NLRI, the prefix is considered
	reachable.		reachable.
	A single TLV type is shared by the Node, Link, and Prefix NLRI.		A single TLV type is shared by the Node, Link, and Prefix NLRI.
	The TLV type is 1184.		The TLV type is 1184.
	</t>		</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1184) | Length (1 Octet) |		| Type (1184) | Length (1 Octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPF Status |		| SPF Status |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	BGP Status Values: 0 - Reserved
	1 - Prefix Unreachable with respect to SPF
	2-254 - Undefined
	255 - Reserved
	]]></artwork>		]]></artwork>
			<!--[rfced] We updated the description for BGP status value "1" (in
			Section 5.2.3.1) for consistency with IANA's "BGP-LS-SPF Prefix
			NLRI Attribute SPF Status TLV Status" registry
			<https://www.iana.org/assignments/bgp-spf/>, as shown below.
			We also placed the information in a table to match the formatting of
			similar text in Section 5.2.2.2. Tables 3 and 4 are both titled
			"BGP Status Values". Would you like to update one of the titles to
			differentiate the tables?
			Original:
			BGP Status Values:
			0 - Reserved
			1 - Prefix Unreachable with respect to SPF
			2-254 - Undefined
			255 - Reserved
			Current:
			+=======+============================================+
			| Value | Description |
			+=======+============================================+
			| 0 | Reserved |
			+ - - - + - - - - - - - - - - - - - - - - - - - - - +
			| 1 | Prefix unreachable with respect to BGP SPF |
			+ - - - + - - - - - - - - - - - - - - - - - - - - - -+
			| 2-254 | Unassigned |
			+ - - - + - - - - - - - - - - - - - - - - - - - - - -+
			| 255 | Reserved |
			+ - - - + - - - - - - - - - - - - - - - - - - - - - -+
			Table 4: BGP Status Values
			-->
			<table>
			<name>BGP Status Values</name>
			<thead>
			<tr><th>Value</th><th>Description</th></tr>
			</thead>
			<tbody>
			<tr><td>0</td><td>Reserved</td></tr>
			<tr><td>1</td><td>Prefix unreachable with respect to BGP SPF</td></tr>
			<tr><td>2-254</td><td>Unassigned</td></tr>
			<tr><td>255</td><td>Reserved</td></tr>
			</tbody>
			</table>
	<t>		<t>
	If a BGP speaker received the Prefix NLRI but		If a BGP speaker received the Prefix NLRI but
	the SPF Status TLV is not received, then any previously received SPF statu s information is		the SPF Status TLV is not received, then any previously received SPF statu s information is
	considered as implicitly withdrawn and the NLRI is propagated to other BGP speakers.		considered as implicitly withdrawn, and the NLRI is propagated to other BG P speakers.
	A BGP speaker receiving a BGP Update containing		A BGP speaker receiving a BGP Update containing
	an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="d efault"/>		an SPF Status TLV in the BGP-LS attribute <xref target="RFC9552" format="d efault"/>
	with an unknown value SHOULD be advertised to other		with an unknown value <bcp14>SHOULD</bcp14> be advertised to other
	BGP speakers and MUST ignore the Status TLV with an unknown value in		BGP speakers and <bcp14>MUST</bcp14> ignore the Status TLV with an unknown
			value in
	the SPF computation.		the SPF computation.
	An implementation MAY log this information for further analysis.		An implementation <bcp14>MAY</bcp14> log this information for further anal
	If the SPF Status TLV contains a reserved value (0 or 255) the TLV is cons		ysis.
	idered malformed and		If the SPF Status TLV contains a reserved value (0 or 255), the TLV is con
			sidered malformed and
	is handled as described in <xref target="new-TLVs"/>.		is handled as described in <xref target="new-TLVs"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sequence-number-tlv" numbered="true" toc="default">		<section anchor="sequence-number-tlv" numbered="true" toc="default">
	<name>BGP-LS Attribute Sequence Number TLV</name>		<name>BGP-LS Attribute Sequence Number TLV</name>
	<t>		<t>
	A BGP-LS Attribute Sequence Number TLV of the BGP-LS-SPF NLRI types is defin ed to assure the most		A BGP-LS Attribute Sequence Number TLV of the BGP-LS-SPF NLRI types is defin ed to assure the most
	recent version of a given NLRI is used in the SPF computation. The Sequence Number TLV is		recent version of a given NLRI is used in the SPF computation. The Sequence Number TLV is
	mandatory for BGP-LS-SPF NLRI.		mandatory for BGP-LS-SPF NLRI.
	skipping to change at line 817 ¶		skipping to change at line 1009 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (1181) | Length (8 Octets) |		| Type (1181) | Length (8 Octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number (High-Order 32 Bits) |		| Sequence Number (High-Order 32 Bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number (Low-Order 32 Bits) |		| Sequence Number (Low-Order 32 Bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<t>		<t>
	Sequence Number:		Sequence Number:
	The 64-bit strictly-increasing sequence number MUST be incremented for every		The 64-bit strictly increasing sequence number <bcp14>MUST</bcp14> be increm ented for every
	self-originated version of a BGP-LS-SPF NLRI. BGP speakers implementing this specification		self-originated version of a BGP-LS-SPF NLRI. BGP speakers implementing this specification
	MUST use available mechanisms to preserve the sequence number's strictly inc reasing property		<bcp14>MUST</bcp14> use available mechanisms to preserve the sequence number 's strictly increasing property
	for the deployed life of the BGP speaker (including cold restarts).		for the deployed life of the BGP speaker (including cold restarts).
	One mechanism for accomplishing this would be to use the high-order 32 bits of the		One mechanism for accomplishing this would be to use the high-order 32 bits of the
	sequence number as a wrap/boot count that is incremented any time the BGP ro uter		sequence number as a wrap/boot count that is incremented any time the BGP ro uter
	loses its sequence number state or the low-order 32 bits wrap.		loses its sequence number state or the low-order 32 bits wrap.
	</t>		</t>
	<t>		<t>
	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		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 should		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 speaker completel y		be incremented and saved in non-volatile storage. If a BGP speaker completel y
	loses its sequence number state (e.g., the BGP speaker hardware		loses its sequence number state (e.g., the BGP speaker hardware
	is replaced or experiences a cold-start), the BGP NLRI selection rules		is replaced or experiences a cold start), the BGP NLRI selection rules
	(see <xref target="Phase-1" format="default"/>) ensure convergence, albeit n ot immediately.		(see <xref target="Phase-1" format="default"/>) ensure convergence, albeit n ot immediately.
	</t>		</t>
	<t>		<t>
	If the Sequence Number TLV		If the Sequence Number TLV
	is not received, then the corresponding NLRI is considered as malformed and		is not received, then the corresponding NLRI is considered as malformed and
	MUST be handled as 'Treat-as-withdraw'. An implementation SHOULD log an erro r for		<bcp14>MUST</bcp14> be handled as 'treat-as-withdraw'. An implementation <bc p14>SHOULD</bcp14> log an error for
	further analysis.		further analysis.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="BGP-LS-SPF-EOR" numbered="true" toc="default">		<section anchor="BGP-LS-SPF-EOR" numbered="true" toc="default">
	<name>BGP-LS-SPF End of RIB (EoR) Marker</name>		<name>BGP-LS-SPF End of RIB (EoR) Marker</name>
	<t>		<t>
	The usage of the End-of-RIB (EoR) Marker <xref target="RFC4724"/> with the BG P-LS-SPF		The usage of the EoR marker <xref target="RFC4724"/> with the BGP-LS-SPF
	SAFI is somewhat different than the other BGP SAFIs. Reception of the EoR		SAFI is somewhat different than the other BGP SAFIs. Reception of the EoR
	marker MAY optionally be expected prior to advertising an LINK-NLRI for a giv en peer.		marker <bcp14>MAY</bcp14> optionally be expected prior to advertising a Link NLRI for a given peer.
	</t>		</t>
	</section>		</section>
	<section anchor="NEXT-HOP" numbered="true" toc="default">		<section anchor="NEXT-HOP" numbered="true" toc="default">
	<name>BGP Next-Hop Information</name>		<name>BGP Next-Hop Information</name>
	<t>		<t>
	The rules for setting the BGP Next-Hop in the MP_REACH_NLRI attribute <xref target="RFC4760"/>		The rules for setting the BGP Next-Hop in the MP_REACH_NLRI attribute <xref target="RFC4760"/>
	for the BGP-LS-SPF SAFI follow the rules in section 5.5 of <xref target="RFC 9552" format="default"/>.		for the BGP-LS-SPF SAFI follow the rules in <xref section="5.5" target="RFC9 552" format="default"/>.
	All BGP peers that support SPF extensions will locally compute the Local-RIB Next-Hop		All BGP peers that support SPF extensions will locally compute the Local-RIB Next-Hop
	as a result of the SPF process. Hence, the use of the MP_REACH_NLRI Next-Hop as a tiebreaker in the		as a result of the SPF process. Hence, the use of the MP_REACH_NLRI Next-Hop as a tiebreaker in the
	standard BGP path decision processing is not applicable.		standard BGP path decision processing is not applicable.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="bgp-decision" numbered="true" toc="default">		<section anchor="bgp-decision" numbered="true" toc="default">
	<name>Decision Process with SPF Algorithm</name>		<name>Decision Process with the SPF Algorithm</name>
	<t>		<t>
	The Decision Process described in <xref target="RFC4271" format="default"/> takes place in		The Decision Process described in <xref target="RFC4271" format="default"/> takes place in
	three distinct phases. The Phase 1 decision function of the Decision Process is		three distinct phases. The Phase 1 decision function of the Decision Process is
	responsible for calculating the degree		responsible for calculating the degree
	of preference for each route received from a BGP speaker's peer. The Phase 2 decision		of preference for each route received from a BGP speaker's peer. The Phase 2 decision
	function is invoked on completion of the Phase 1 decision function and is re sponsible		function is invoked on completion of the Phase 1 decision function and is re sponsible
	for choosing the best route out of all those available for each		for choosing the best route out of all those available for each
	distinct destination, and for installing each chosen route into the Local-RI B.		distinct destination and for installing each chosen route into the Local-RIB .
	The combination of the Phase 1 and 2 decision functions is characterized as		The combination of the Phase 1 and 2 decision functions is characterized as
	a Path Vector algorithm.		a Path Vector algorithm.
	</t>		</t>
	<t>		<t>
	The SPF-based Decision process replaces the BGP Decision process described i n		The SPF-based Decision Process replaces the BGP Decision Process described i n
	<xref target="RFC4271" format="default"/>.		<xref target="RFC4271" format="default"/>.
	Since BGP-LS-SPF NLRI always contains the local node descriptor as described in		Since BGP-LS-SPF NLRI always contains the Local Node Descriptor as described in
	<xref target="NLRI-Use" format="default"/>, each NLRI is uniquely originated by a single		<xref target="NLRI-Use" format="default"/>, each NLRI is uniquely originated by a single
	BGP speaker in the BGP SPF routing domain (the BGP node matching the NLRI's Node		BGP speaker in the BGP SPF routing domain (the BGP node matching the NLRI's Node
	Descriptors). Instances of the same NLRI originated by multiple BGP speakers would be		Descriptors). Instances of the same NLRI originated by multiple BGP speakers would be
	indicative of a configuration error or a masquerading attack		indicative of a configuration error or a masquerading attack
	(refer to <xref target="Security" format="default"/>).		(refer to <xref target="Security" format="default"/>).
	These selected Node NLRI and their Link/Prefix NLRI are used to build a dire cted		These selected Node NLRIs and their Link/Prefix NLRIs are used to build a di rected
	graph during the SPF computation as described below. The best routes for BGP prefixes		graph during the SPF computation as described below. The best routes for BGP prefixes
	are installed in the RIB as a result of the SPF process.		are installed in the RIB as a result of the SPF process.
	</t>		</t>
	<t>		<t>
	When BGP-LS-SPF NLRI is received, all that is required is to determine		When BGP-LS-SPF NLRI is received, all that is required is to determine
	whether it is the most recent by examining the Node-ID and sequence number as described		whether it is the most recent by examining the Node-ID and sequence number as described
	in <xref target="Phase-1" format="default"/>. If the received NLRI has changed , it is advertised		in <xref target="Phase-1" format="default"/>. If the received NLRI has changed , it is advertised
	to other BGP-LS-SPF peers. If the attributes have changed (other than the sequ ence number),		to other BGP-LS-SPF peers. If the attributes have changed (other than the sequ ence number),
	a BGP SPF calculation is triggered. However, a changed NLRI MAY be advertised immediately		a BGP SPF calculation is triggered. However, a changed NLRI <bcp14>MAY</bcp14> be advertised immediately
	to other peers and prior to any SPF calculation. Note that the BGP		to other peers and prior to any SPF calculation. Note that the BGP
	MinASOriginationIntervalTimer <xref target="RFC4271" format="default"/> timer is not applicable		MinASOriginationIntervalTimer <xref target="RFC4271" format="default"/> timer is not applicable
	to the BGP-LS-SPF SAFI. The MinRouteAdvertisementIntervalTimer is applicable w ith a suggested default		to the BGP-LS-SPF SAFI. The MinRouteAdvertisementIntervalTimer is applicable w ith a suggested default
	of 5 seconds consistent with Internal BGP (IBGP) (refer to section 10 of <xref		of 5 seconds consistent with Internal BGP (IBGP) (refer to <xref section="10"
	target="RFC4271"/>).		target="RFC4271"/>).
			<!--[rfced] We note that "SPF Back-Off algorithm" is called the "SPF
			Back-Off Delay algorithm" in RFC 8405. We updated the text below
			for consistency. Please let us know of any objections.
			Original:
			The scheduling of the SPF calculation, as described in Section 6.3, is an
			implementation and/or configuration matter. Scheduling MAY be dampened
			consistent with the SPF back-off algorithm specified in [RFC8405].
			Current:
			The scheduling of the SPF calculation, as described in Section 6.3, is an
			implementation and/or configuration matter. Scheduling MAY be dampened
			consistent with the SPF Back-Off Delay algorithm specified in [RFC8405].
			-->
	The scheduling of the SPF calculation, as described in		The scheduling of the SPF calculation, as described in
	<xref target="BGP-SPF" format="default"/>, is an implementation and/or configu ration matter.		<xref target="BGP-SPF" format="default"/>, is an implementation and/or configu ration matter.
	Scheduling MAY be dampened consistent with the SPF back-off algorithm		Scheduling <bcp14>MAY</bcp14> be dampened consistent with the SPF Back-Off Del ay algorithm
	specified in <xref target="RFC8405" format="default"/>.		specified in <xref target="RFC8405" format="default"/>.
	</t>		</t>
	<t>		<t>
	The Phase 3 decision function		The Phase 3 decision function
	of the Decision Process <xref target="RFC4271" format="default"/> is also simp		of the Decision Process <xref target="RFC4271" format="default"/> is also simp
	lified since under		lified because under
	normal SPF operation, a BGP speaker MUST advertise the changed NLRIs		normal SPF operation, a BGP speaker <bcp14>MUST</bcp14> advertise the changed
			NLRIs
	to all BGP peers with the BGP-LS-SPF AFI/SAFI and install the changed routes i n		to all BGP peers with the BGP-LS-SPF AFI/SAFI and install the changed routes i n
	the GLOBAL-RIB. The only exception are unchanged		the GLOBAL-RIB. The only exceptions are unchanged
	NLRIs or stale NLRIs, i.e., NLRI received with a less recent (numerically smal		NLRIs or stale NLRIs, i.e., an NLRI received with a less recent (numerically s
	ler)		maller)
	sequence number.		sequence number.
	</t>		</t>
	<section anchor="Phase-1" numbered="true" toc="default">		<section anchor="Phase-1" numbered="true" toc="default">
	<name>BGP SPF NLRI Selection</name>		<name>BGP SPF NLRI Selection</name>
	<t>		<t>
	For all BGP-LS-SPF NLRIs, the selection rules for phase 1 of the BGP		For all BGP-LS-SPF NLRIs, the selection rules for Phase 1 of the BGP
	decision process, section 9.1.1 <xref target="RFC4271" format="default"/>, no		decision process (see <xref section="9.1.1" target="RFC4271" format="default"
	longer apply.		/>) no longer apply.
	</t>		</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	NLRI self-originated from directly-connected BGP SPF peers are preferred.		NLRIs self-originated from directly connected BGP SPF peers are preferred.
	This condition can be determined by comparing the BGP Identifiers in		This condition can be determined by comparing the BGP Identifiers in
	the received Local Node Descriptor and the BGP OPEN message for an active		the received Local Node Descriptor and the BGP OPEN message for an active
	BGP session. This rule assures that stale NLRI is updated even if a BGP SPF ro		BGP session. This rule assures that a stale NLRI is updated even if a BGP SPF
	uter		router
	loses its sequence number state due to a cold-start. Note that once the BGP se		loses its sequence number state due to a cold start. Note that once the BGP se
	ssion		ssion
	goes down, the NLRI received is no longer considered as being from a directly		goes down, the NLRI received is no longer considered as being from a directly
	connected BGP SPF peer.		connected BGP SPF peer.
	</li>		</li>
	<li>		<li>
	Consistent with base BGP <xref target="RFC4271"/>, NLRI received from a peer w ill always		Consistent with base BGP <xref target="RFC4271"/>, an NLRI received from a pee r will always
	replace the same NLRI received from that peer. Coupled with rule #1, this will ensure that		replace the same NLRI received from that peer. Coupled with rule #1, this will ensure that
	any stale NLRI in the BGP SPF routing domain will be updated.		any stale NLRI in the BGP SPF routing domain will be updated.
	</li>		</li>
	<li>		<li>
	The NLRI with the most recent Sequence Number TLV, i.e., highest sequence numb er is selected.		The NLRI with the most recent Sequence Number TLV, i.e., the highest sequence number is selected.
	</li>		</li>
	<li>		<li>
	The NLRI received from the BGP speaker with the numerically larger BGP		The NLRI received from the BGP speaker with the numerically larger BGP
	Identifier is preferred.		Identifier is preferred.
	</li>		</li>
	</ol>		</ol>
	<t>		<t>
	When a BGP speaker completely loses its sequence number state, e.g., due to a cold start, or		When a BGP speaker completely loses its sequence number state, e.g., due to a cold start, or
	in the unlikely possibility that 64-bit sequence number wraps, the BGP routing		in the unlikely possibility that a 64-bit sequence number wraps, the BGP routi
	domain will		ng domain will
	still converge. This is due to the fact that BGP speakers adjacent to the rout		still converge.
	er
	always accept self-originated NLRI from the associated speaker as more recent		<!--[rfced] How may we clarify "as more recent" in the following
	(rule #1). When a		text. Have BGP speakers been accepting the self-originated NLRIs
			recently (rather than "always"), as shown below?
			Original:
			This is due to the fact that BGP speakers adjacent to the router
			always accept self-originated NLRI from the associated speaker as
			more recent (rule #1).
			Perhaps:
			This is due to the fact that BGP speakers adjacent to the router
			have been recently accepting self-originated NLRIs from the
			associated speaker (per rule #1).
			-->
			This is due to the fact that BGP speakers adjacent to the router
			always accept self-originated NLRIs from the associated speaker as more recent
			(rule #1). When a
	BGP speaker reestablishes a connection with its peers, any existing sessions a re taken		BGP speaker reestablishes a connection with its peers, any existing sessions a re taken
	down and stale NLRI are replaced. The adjacent BGP speakers update their NLRI		down and stale NLRIs are replaced. The adjacent BGP speakers update their NLRI
	advertisements and advertise to their neighbors until the BGP routing domain h as converged.		advertisements and advertise to their neighbors until the BGP routing domain h as converged.
	</t>		</t>
	<t>		<t>
	The modified SPF Decision Process performs an SPF calculation rooted at the lo cal BGP		The modified SPF Decision Process performs an SPF calculation rooted at the lo cal BGP
	speaker using the metrics from the Link Attribute IGP Metric TLV (1095) and		speaker using the metrics from the Link Attribute IGP Metric (TLV 1095) and
	the Prefix Attribute Prefix Metric TLV (1155) <xref target="RFC9552" format="d		the Prefix Attribute Prefix Metric (TLV 1155) <xref target="RFC9552" format="d
	efault"/>.		efault"/>.
	These metrics are considered consistently across the BGP SPF domain.		These metrics are considered consistently across the BGP SPF domain.
	As a result, any other BGP attributes that		As a result, any other BGP attributes that
	would influence the BGP decision process defined in <xref target="RFC4271" for mat="default"/> including		would influence the BGP decision process defined in <xref target="RFC4271" for mat="default"/> including
	ORIGIN, MULTI_EXIT_DISC, and		ORIGIN, MULTI_EXIT_DISC, and
	LOCAL_PREF attributes are ignored by the SPF algorithm. The Next Hop in the MP _REACH_NLRI attribute		LOCAL_PREF attributes are ignored by the SPF algorithm. The Next Hop in the MP _REACH_NLRI attribute
	<xref target="RFC4760"/> is discussed in <xref target="NEXT-HOP" format="defau lt"/>.		<xref target="RFC4760"/> is discussed in <xref target="NEXT-HOP" format="defau lt"/>.
	The AS_PATH and AS4_PATH <xref target="RFC6793" format="default"/> attributes		The AS_PATH and AS4_PATH attributes <xref target="RFC6793" format="default"/>
	are preserved and used for loop detection <xref target="RFC4271" format="defau lt"/>. They are ignored		are preserved and used for loop detection <xref target="RFC4271" format="defau lt"/>. They are ignored
	during the SPF computation for BGP-LS-SPF NLRIs.		during the SPF computation for BGP-LS-SPF NLRIs.
	</t>		</t>
	<section anchor="Self-Origin" numbered="true" toc="default">		<section anchor="Self-Origin" numbered="true" toc="default">
	<name>BGP Self-Originated NLRI</name>		<name>BGP Self-Originated NLRI</name>
	<t>		<t>
	Node, Link, or Prefix NLRI with Node Descriptors matching the local BGP speake		Nodes, Links, or Prefix NLRIs with Node Descriptors matching the local BGP spe
	r are		aker are
	considered self-originated. When self-originated NLRI is received and it doesn		considered self-originated. When a self-originated NLRI is received and it doe
	't match the		sn't match the
	local node's NLRI content (including sequence number), special processing is r		local node's NLRI content (including the sequence number), special processing
	equired.		is required.
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	If self-originated NLRI is received and the sequence number is more recent ( i.e., greater than		If a self-originated NLRI is received and the sequence number is more recent (i.e., greater than
	the local node's sequence number for the NLRI), the NLRI sequence number is advanced to		the local node's sequence number for the NLRI), the NLRI sequence number is advanced to
	one greater than the received sequence number and the NLRI is readvertised t o all peers.		one greater than the received sequence number, and the NLRI is readvertised to all peers.
	</li>		</li>
	<li>		<li>
	If self-originated NLRI is received and the sequence number is the same as t he local node's		If a self-originated NLRI is received and the sequence number is the same as the local node's
	sequence number but the attributes differ, the NLRI sequence number is advan ced to		sequence number but the attributes differ, the NLRI sequence number is advan ced to
	one greater than the received sequence number and the NLRI is readvertised t o all peers.		one greater than the received sequence number, and the NLRI is readvertised to all peers.
	</li>		</li>
	<!--		<!--
	<li>		<li>
	If self-originated Link or Prefix NLRI is received and the Link or Prefix NL RI is no longer		If self-originated Link or Prefix NLRI is received and the Link or Prefix NL RI is no longer
	being advertised by the local node, the NLRI is considered stale and is with drawn using the		being advertised by the local node, the NLRI is considered stale and is with drawn using the
	standard BGP Update message Withdrawn Routes encodings <xref target="RFC4760 "/>.		standard BGP Update message Withdrawn Routes encodings <xref target="RFC4760 "/>.
	</li>		</li>
	-->		-->
	</ul>		</ul>
	<t>		<t>
	skipping to change at line 1006 ¶		skipping to change at line 1231 ¶
	(refer to <xref target="Security" format="default"/>).		(refer to <xref target="Security" format="default"/>).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="dual-stack" numbered="true" toc="default">		<section anchor="dual-stack" numbered="true" toc="default">
	<name>Dual Stack Support</name>		<name>Dual Stack Support</name>
	<t>		<t>
	The SPF-based decision process operates on Node, Link, and Prefix NLRIs that s upport		The SPF-based decision process operates on Node, Link, and Prefix NLRIs that s upport
	both IPv4 and IPv6 addresses. Whether to run a single SPF computation or multi ple		both IPv4 and IPv6 addresses. Whether to run a single SPF computation or multi ple
	SPF computations for separate AFs is an implementation and/or policy matter. N ormally, IPv4		SPF computations for separate AFs is an implementation and/or policy matter. N ormally, IPv4
	next-hops are calculated for IPv4 prefixes and IPv6 next-hops are calculated f or IPv6		next-hops are calculated for IPv4 prefixes, and IPv6 next-hops are calculated for IPv6
	prefixes.		prefixes.
	</t>		</t>
	</section>		</section>
	<section anchor="BGP-SPF" numbered="true" toc="default">		<section anchor="BGP-SPF" numbered="true" toc="default">
	<name>SPF Calculation based on BGP-LS-SPF NLRI</name>		<name>SPF Calculation Based on BGP-LS-SPF NLRI</name>
	<t>		<t>
	This section details the BGP-LS-SPF local routing information base (RIB) calcu		This section details the BGP-LS-SPF local Routing Information Base (RIB) calcu
	lation.		lation.
	The router uses BGP-LS-SPF Node, Link, and Prefix NLRI to compute routes using		The router uses BGP-LS-SPF Node, Link, and Prefix NLRIs to compute routes usin
	the		g the
	following algorithm. This calculation yields the set of routes associated		following algorithm. This calculation yields the set of routes associated
	with the BGP SPF Routing Domain. A router calculates the shortest-path tree u sing itself		with the BGP SPF Routing Domain. A router calculates the shortest-path tree u sing itself
	as the root. Optimizations to the BGP-LS-SPF algorithm are possible but MUST y		as the root. Optimizations to the BGP-LS-SPF algorithm are possible but <bcp14
	ield		>MUST</bcp14> yield
	the same set of routes. The algorithm below supports Equal Cost Multi-Path (EC		the same set of routes. The algorithm below supports ECMP
	MP)		routes. Weighted Unequal-Cost Multipath (UCMP) routes are out of scope.
	routes. Weighted Unequal Cost Multi-Path routes are out of scope.
	</t>		</t>
	<t>		<t>
	The following abstract data structures are defined in order to specify the alg orithm.		The following abstract data structures are defined in order to specify the alg orithm.
	</t>		</t>
	<ul spacing="normal">		<dl spacing="normal" newline="false">
	<li>		<dt>Local Route Information Base (Local-RIB):</dt><dd>A routing table
	Local Route Information Base (Local-RIB) - This routing table contains reacha		that contains reachability information (i.e., next hops) for all prefixes (bo
	bility information		th
	(i.e., next hops) for all prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF		IPv4 and IPv6) as well as BGP-LS-SPF node reachability.
	node
	reachability. Implementations may choose to implement this with separate RIBs		<!--[rfced] Please clarify "Prefix versus Node reachability" in the
	for each		last sentence. Does "versus" mean "or" in this context?
	address family and/or Prefix versus Node reachability.
	</li>		Also, we see "BGP-LS-SPF node reachability" in the first sentence.
	<li>		Should "node" be "Node" for consistency with "Node reachability"
	Global Routing Information Base (GLOBAL-RIB) - This is the Routing Informatio		(e.g., "BGP-LS-SPF Node reachability")?
	n Base (RIB)
	containing the current routes that are installed in the router's forwarding p		Original:
	lane.		Local Route Information Base (Local-RIB) - This routing table
	This is commonly referred to in networking parlance as "the RIB".		contains reachability information (i.e., next hops) for all
	</li>		prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node
	<li>		reachability. Implementations may choose to implement this with
	Link State NLRI Database (LSNDB) - Database of BGP-LS-SPF NLRI that facilitat		separate RIBs for each address family and/or Prefix versus Node
	es access to		reachability.
	all Node, Link, and Prefix NLRI.
	</li>		Perhaps:
	<li>		Local Route Information Base (Local-RIB): A routing table that
	Candidate List (CAN-LIST) - This is a list of candidate Node NLRIs used during		contains reachability information (i.e., next hops) for all
	the BGP SPF		prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF Node
	calculation. The list is sorted by		reachability. Implementations may choose to implement this with
	the cost to reach the Node NLRI with the Node NLRI with the lowest reachabilit		separate RIBs for each address family and/or Prefix or Node
	y cost at		reachability.
	the head of the list. This facilitates execution of the Dijkstra algorithm		-->
	where the shortest paths between the local node and other nodes in graph are c
	omputed.		Implementations may
	The CAN-LIST is typically implemented as a heap but other data structures have		choose to implement this with separate RIBs for each address family and/or
	been used.		Prefix versus Node reachability.</dd>
	</li>
	</ul>		<dt>Global Routing Information Base (GLOBAL-RIB):</dt><dd>The
	<t>The algorithm consists of the steps below:		RIB containing the current routes that are
	</t>		installed in the router's forwarding plane. This is commonly referred to
			in networking parlance as "the RIB".</dd>
			<dt>Link-State NLRI Database (LSNDB):</dt><dd>A database of BGP-LS-SPF NLRIs
			that facilitate access to all Node, Link, and Prefix NLRIs.</dd>
			<dt>Candidate List (CAN-LIST):</dt><dd>A list of candidate Node
			NLRIs used 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 reachability c
			ost
			at the head of the list. This facilitates the execution of the Dijkstra
			algorithm, where the shortest paths between the local node and other nodes
			in the graph are computed. The CAN-LIST is typically implemented as a heap b
			ut
			other data structures have been used.</dd>
			</dl>
			<t>The Dijkstra algorithm consists of the steps below:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	The current Local-RIB is invalidated, and the CAN-LIST is initialized to be em pty.		The current Local-RIB is invalidated, and the CAN-LIST is initialized to be em pty.
	The Local-RIB is rebuilt during the course of the SPF computation. The existi ng routing entries		The Local-RIB is rebuilt during the course of the SPF computation. The existi ng routing entries
	are preserved for comparison to determine changes that need to be made to the GLOBAL-RIB in		are preserved for comparison to determine changes that need to be made to the GLOBAL-RIB in
	step 6. These routes are referred to as stale routes.		Step 6. These routes are referred to as "stale routes".
	</li>		</li>
	<li>		<li>
	The cost of the Local-RIB Node route entry for the computing router is set to 0.		The cost of the Local-RIB Node route entry for the computing router is set to 0.
	The computing router's Node NLRI is added to the CAN-LIST (which was previous ly initialized		The computing router's Node NLRI is added to the CAN-LIST (which was previous ly initialized
	to be empty in step 1). The next-hop list is set to the internal loopback nex t-hop.		to be empty in Step 1). The next-hop list is set to the internal loopback nex t-hop.
	</li>		</li>
	<li>		<li>
	The Node NLRI with the lowest cost is removed from the CAN-LIST for processing .		The Node NLRI with the lowest cost is removed from the CAN-LIST for processing .
	If the BGP-LS Node attribute includes an SPF Status TLV		If the BGP-LS Node attribute includes an SPF Status TLV
	(refer to <xref target="node-status-tlv" format="default"/>)		(refer to <xref target="node-status-tlv" format="default"/>)
	indicating the node is unreachable, the Node NLRI is ignored and the next lowe st cost		indicating the node is unreachable, the Node NLRI is ignored and the next lowe st-cost
	Node NLRI is selected from the CAN-LIST. The		Node NLRI is selected from the CAN-LIST. The
	Node corresponding to this NLRI is referred to as the Current-Node. If the CAN		Node corresponding to this NLRI is referred to as the "Current-Node". If the C
	-LIST		AN-LIST
	list is empty, the SPF calculation has completed and the algorithm proceeds to		list is empty, the SPF calculation has completed and the algorithm proceeds to
	step 6.		Step 6.
	</li>		</li>
	<li>		<li>
	<t>		<t>
	All the Prefix NLRI with the same Local Node Descriptors as the Current-Node		All the Prefix NLRIs with the same Local Node Descriptors as the Current-Nod
	are considered		e are considered
	for installation. The next-hop(s) for these Prefix NLRI are inherited from t		for installation. The next-hop(s) for these Prefix NLRIs are inherited from
	he Current-Node.		the Current-Node.
	If the Current-Node is for the local BGP Router, the next-hop for the prefix is a direct		If the Current-Node is for the local BGP Router, the next-hop for the prefix is a direct
	next-hop. The cost for each prefix is the metric advertised in the Prefix A ttribute		next-hop. The cost for each prefix is the metric advertised in the Prefix A ttribute
	Prefix Metric TLV (1155) added to the cost to reach the Current-Node. The fo		Prefix Metric (TLV 1155) added to the cost to reach the Current-Node. The fo
	llowing		llowing
	is done for each Prefix NLRI (referred to as the Current-Prefix):		is done for each Prefix NLRI (referred to as the "Current-Prefix"):
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	If the BGP-LS Prefix attribute includes an SPF Status TLV indicating the pre fix is		If the BGP-LS Prefix attribute includes an SPF Status TLV indicating the pre fix is
	unreachable, the Current-Prefix is considered unreachable and the next Prefi x		unreachable, the Current-Prefix is considered unreachable, and the next Pref ix
	NLRI is examined in Step 4.		NLRI is examined in Step 4.
	</li>		</li>
			<!--[rfced] Please clarify what "less than" refers to - is it the
			metric's cost, length, or other?
			Original:
			If the Current-Prefix's corresponding prefix is in the Local-RIB
			and the Local-RIB metric is less than the Current-Prefix's metric,
			the Current-Prefix does not contribute to the route and the next
			Prefix NLRI is examined in Step 4.
			-->
	<li>		<li>
	If the Current-Prefix's corresponding prefix is in the Local-RIB and the		If the Current-Prefix's corresponding prefix is in the Local-RIB and the
	Local-RIB metric is less than the Current-Prefix's metric,		Local-RIB metric is less than the Current-Prefix's metric,
	the Current-Prefix does not contribute to the route and the next Prefix NLRI is		the Current-Prefix does not contribute to the route, and the next Prefix NLR I is
	examined in Step 4.		examined in Step 4.
	</li>		</li>
			<!--[rfced] Please clarify "and the metric being updated". Is the
			intended meaning perhaps "the metric is updated" (option A) or
			that the next-hops are installed as the "Local-RIB route and
			updated metric's next-hops" (option B)?
			Original:
			If the Current-Prefix's corresponding prefix is not in the
			Local-RIB, the prefix is installed with the Current-Node's
			next-hops installed as the Local-RIB route's next-hops and
			the metric being updated.
			Perhaps A:
			If the Current-Prefix's corresponding prefix is not in the
			Local-RIB, the prefix is installed with the Current-Node's
			next-hops installed as the Local-RIB route's next-hops, and
			the metric is updated.
			Perhaps B:
			If the Current-Prefix's corresponding prefix is not in the
			Local-RIB, the prefix is installed with the Current-Node's
			next-hops installed as the Local-RIB route and updated
			metric's next-hops.
			-->
	<li>		<li>
	If the Current-Prefix's corresponding prefix is not in the Local-RIB,		If the Current-Prefix's corresponding prefix is not in the Local-RIB,
	the prefix is installed with the Current-Node's next-hops		the prefix is installed with the Current-Node's next-hops
	installed as the Local-RIB route's next-hops and the metric being updated. I f the		installed as the Local-RIB route's next-hops and the metric being updated. I f the
	IGP Route Tag TLV (1153) is		IGP Route Tag (TLV 1153) is
	included in the Current-Prefix's NLRI Attribute, the tag(s) are installed in		included in the Current-Prefix's NLRI Attribute, the tag(s) is installed in
	the		the
	current Local-RIB route's tag(s).		current Local-RIB route's tag(s).
	</li>		</li>
	<li>		<li>
	If the Current-Prefix's corresponding prefix is in the Local-RIB and the cos t is less		If the Current-Prefix's corresponding prefix is in the Local-RIB and the cos t is less
	than the Local-RIB route's metric, the prefix is installed with the Current-		than the Local-RIB route's metric, the prefix is installed with the Current-
	Node's next-hops		Node's next-hops, which
	replacing the Local-RIB route's next-hops and the metric being updated and a		replace the Local-RIB route's next-hops and the metric being updated, and an
	ny route tags		y route tags
	removed. If the IGP Route Tag TLV (1153) is		are removed. If the IGP Route Tag (TLV 1153) is
	included in the Current-Prefix's NLRI Attribute, the tag(s) are installed in		included in the Current-Prefix's NLRI Attribute, the tag(s) is installed in
	the		the
	current Local-RIB route's tag(s).		current Local-RIB route's tag(s).
	</li>		</li>
	<li>		<li>
	If the Current-Prefix's corresponding prefix is in the Local-RIB and the cos t		If the Current-Prefix's corresponding prefix is in the Local-RIB and the cos t
	is the same as the Local-RIB route's metric, the Current-Node's next-hops ar e merged		is the same as the Local-RIB route's metric, the Current-Node's next-hops ar e merged
	with Local-RIB route's next-hops.		with the Local-RIB route's next-hops.
	The algorithm below supports Equal Cost Multi-Path (ECMP) routes.		The algorithm below supports ECMP routes.
	Some platforms or implementations may have limits on the number of		Some platforms or implementations may have limits on the number of
	ECMP routes that can be supported. The setting or identification		ECMP routes that can be supported. The setting or identification
	of any limitations is outside the scope if this document.		of any limitations is outside the scope if this document.
	Weighted Unequal Cost Multi-Path routes are out of scope as well.		Weighted UCMP routes are out of scope as well.
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	<t>		<t>
	All the Link NLRI with the same Node Identifiers as the Current-Node are con		All the Link NLRIs with the same Node Identifiers as the Current-Node are co
	sidered		nsidered
	for installation. Each link is examined and is referred to in the following		for installation. Each link is examined and referred to as the "Current-Link
	text		" in the following text. The cost of the Current-Link is the advertised IGP Metr
	as the Current-Link. The cost of the Current-Link is the advertised IGP Metr		ic (TLV 1095)
	ic TLV (1095)
	from the Link NLRI BGP-LS attribute added to the cost to reach the Current-N ode.		from the Link NLRI BGP-LS attribute added to the cost to reach the Current-N ode.
	If the Current-Node is for the local BGP Router,		If the Current-Node is for the local BGP Router,
	the next-hop for the link is a direct next-hop pointing to the corresponding local		the next-hop for the link is a direct next-hop pointing to the corresponding local
	interface. For any other Current-Node, the next-hop(s) for the Current-Link are inherited		interface. For any other Current-Node, the next-hop(s) for the Current-Link is inherited
	from the Current-Node. The following is done for each link:		from the Current-Node. The following is done for each link:
	</t>		</t>
	<ol spacing="normal" type="a">		<ol spacing="normal" type="a">
	<li>		<li>
	If the Current-Link's NLRI attribute includes an SPF Status TLV indicating the link is		If the Current-Link's NLRI attribute includes an SPF Status TLV indicating the link is
	down, the BGP-LS-SPF Link NLRI is considered down and the next link		down, the BGP-LS-SPF Link NLRI is considered down, and the next link
	for the Current-Node is examined in Step 5.		for the Current-Node is examined in Step 5.
	</li>		</li>
	<li>		<li>
	If the Current-Node NLRI attributes includes the SPF Status TLV		If the Current-Node NLRI attributes include the SPF Status TLV
	(refer to <xref target="node-status-tlv" format="default"/>) and the status		(refer to <xref target="node-status-tlv" format="default"/>) and the status
	indicates that the Node doesn't support transit, the next link for the Current -Node is		indicates that the Node doesn't support transit, the next link for the Current -Node is
	processed in Step 5.		processed in Step 5.
	</li>		</li>
	<li>		<li>
	<t>		<t>
	The Current-Link's Remote Node NLRI is accessed (i.e., the Node NLRI		The Current-Link's Remote Node NLRI is accessed (i.e., the Node NLRI
	with the same Node identifiers as the Current-Link's Remote Node Descriptors		with the same Node Identifiers as the Current-Link's Remote Node Descriptors
	). If it exists,		). If it exists,
	it is referred to as the Remote-Node and the algorithm proceeds as follows:		it is referred to as the "Remote-Node" and the algorithm proceeds as follows
			:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	If the Remote-Node's NLRI attribute includes an SPF Status TLV indicating th e node is		If the Remote-Node's NLRI attribute includes an SPF Status TLV indicating th e node is
	unreachable, the next link for the Current-Node is examined in Step 5.		unreachable, the next link for the Current-Node is examined in Step 5.
	</li>		</li>
	<li>		<li>
	<t>		<t>
	All the Link NLRI corresponding the Remote-Node are searched for a Link		All the Link NLRIs corresponding to the Remote-Node are searched for a Link
	NLRI pointing to the Current-Node. Each Remote-Node's Link NLRI (referred to a s the		NLRI pointing to the Current-Node. Each Remote-Node's Link NLRI (referred to a s the
	Remote-Link) is examined for Remote Node Descriptors matching the Current-Node and		Remote-Link) is examined for Remote Node Descriptors matching the Current-Node and
	Link Descriptors matching the Current-Link.		Link Descriptors matching the Current-Link.
	</t>		</t>
	<ul spacing = "normal">		<ul spacing = "normal">
	<li>		<li>
	For IPv4/IPv6 numbered Link Descriptors to match during the IPv4 SPF compu		For IPv4/IPv6 numbered Link Decriptors to match during the IPv4 SPF comput
	tation, the		ation, the
	Current-Link's IP4/IPv6 interface address link descriptor MUST match the R		Current-Link's IP4/IPv6 interface address link descriptor <bcp14>MUST</bcp
	emote-Link		14> match the Remote-Link
	IPv4/IPv6 neighbor address link descriptor and the Current-Link's IPv4/IPv		IPv4/IPv6 neighbor address link descriptor, and the Current-Link's IPv4/IP
	6 neighbor		v6 neighbor
	address MUST match the Remote-Link's IPv4/IPv6 interface address.		address <bcp14>MUST</bcp14> match the Remote-Link's IPv4/IPv6 interface ad
			dress.
	</li>		</li>
	<li>		<li>
	For unnumbered links to match during the IPv4 or IPv6 SPF computation,		For unnumbered links to match during the IPv4 or IPv6 SPF computation,
	Current-Link and Remote-Link's Address Family Link Descriptor TLV must mat ch		the Current-Link and Remote-Link's Address Family Link Descriptor TLV must match
	the address family of the IPv4 or IPv6 SPF computation,		the address family of the IPv4 or IPv6 SPF computation,
	the Current-Link's Remote Identifier MUST match the Remote-Link's Local		the Current-Link's Remote Identifier <bcp14>MUST</bcp14> match the Remote-
	Identifier and the Current-Link's Remote Identifier MUST match the		Link's Local
			Identifier, and the Current-Link's Remote Identifier <bcp14>MUST</bcp14> m
			atch the
	Remote-Link's Local Identifier.		Remote-Link's Local Identifier.
			<!--[rfced] Section 6.3. We note the following variations - are these
			terms different? Please let us know if/how we may update these
			for consistency.
			Link Local/Remote Identifiers (TLV 258)
			Current or Remote Link's Local Identifier
			Current-Link's Remote Identifier
			Link Remote Identifier
			Link's Remote Identifier
			Remote Link Identifiers
			As an example, how may we update this sentence for consistency? Should
			reference to TLV 258 be "Link Local/Remote Identifiers" per RFC 9552?
			Original:
			Since the Link's Remote Identifier may not be known, a value of 0
			is considered a wildcard and will match any Current or Remote
			Link's Local Identifier (see TLV 258 [RFC9552]).
			Perhaps:
			Since the Link Remote Identifier may not be known, a value of 0
			is considered a wildcard and will match any Link Local/Remote
			Identifiers (see TLV 258 [RFC9552]).
			-->
	Since the Link's Remote Identifier may not be known, a value of 0		Since the Link's Remote Identifier may not be known, a value of 0
	is considered a wildcard and will match any Current or Remote Link's Local		is considered a wildcard and will match any Current or Remote Link's Local
	Identifier (see TLV 258 <xref target="RFC9552" format="default"/>).		Identifier (see TLV 258 <xref target="RFC9552" format="default"/>).
	Address Family Link Descriptor TLVs for multiple address families may be		Address Family Link Descriptor TLVs for multiple address families may be
	advertised so that an unnumbered link can be used in the SPF computation f or		advertised so that an unnumbered link can be used in the SPF computation f or
	multiple address families.		multiple address families.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	If these conditions are satisfied for one of the Remote-Node's links,		If these conditions are satisfied for one of the Remote-Node's links,
	the bi-directional connectivity		the bidirectional connectivity
	check succeeds and the Remote-Node may be processed further. The		check succeeds and the Remote-Node may be processed further. The
	Remote-Node's Link NLRI providing bi-directional connectivity		Remote-Node's Link NLRI providing bidirectional connectivity
	is referred to as the Remote-Link. If no Remote-Link is found, the next		is referred to as the Remote-Link. If no Remote-Link is found, the next
	link for the Current-Node is examined in Step 5.		link for the Current-Node is examined in Step 5.
	</t>		</t>
	</li>		</li>
	<li>		<li>
	If the Remote-Link NLRI attribute includes an SPF Status TLV indicating		If the Remote-Link NLRI attribute includes an SPF Status TLV indicating
	the link is down, the Remote-Link NLRI is considered down and the next link		the link is down, the Remote-Link NLRI is considered down, and the next link
	for the Current-Node is examined in Step 5.		for the Current-Node is examined in Step 5.
	</li>		</li>
	<li>		<li>
	If the Remote-Node is not on the CAN-LIST, it is inserted based		If the Remote-Node is not on the CAN-LIST, it is inserted based
	on the cost. The Remote Node's cost is the cost of Current-Node added		on the cost. The Remote Node's cost is the cost of the Current-Node added
	the Current-Link's IGP Metric TLV (1095). The next-hop(s) for the Remote-Node		to the Current-Link's IGP Metric (TLV 1095). The next-hop(s) for the Remote-No
	are inherited from the Current-Link.		de
			is inherited from the Current-Link.
	</li>		</li>
	<li>		<li>
	If the Remote-Node NLRI is already on the CAN-LIST with a higher cost, it		If the Remote-Node NLRI is already on the CAN-LIST with a higher cost, it
	must be removed and reinserted with the Remote-Node cost based on the		must be removed and reinserted with the Remote-Node cost based on the
	Current-Link (as calculated in the previous step). The		Current-Link (as calculated in the previous step). The
	next-hop(s) for the Remote-Node are inherited from the Current-Link.		next-hop(s) for the Remote-Node is inherited from the Current-Link.
	</li>		</li>
	<li>		<li>
	If the Remote-Node NLRI is already on the CAN-LIST with the same cost, it need		If the Remote-Node NLRI is already on the CAN-LIST with the same cost, it need
	not be reinserted on the CAN-LIST. However, the Current-Link's next-hop(s)		not be reinserted on the CAN-LIST. However, the Current-Link's next-hop(s)
	must be merged into the current set of next-hops for the Remote-Node.		must be merged into the current set of next-hops for the Remote-Node.
	</li>		</li>
	<li>		<li>
	If the Remote-Node NLRI is already on the CAN-LIST with a lower cost, it need		If the Remote-Node NLRI is already on the CAN-LIST with a lower cost, it need
	not be reinserted on the CAN-LIST.		not be reinserted on the CAN-LIST.
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	Return to step 3 to process the next lowest cost Node NLRI on the CAN-LIST.		Return to Step 3 to process the next lowest-cost Node NLRI on the CAN-LIST.
	</li>		</li>
	</ol>		</ol>
	</li>		</li>
	<li>		<li>
	<t>		<t>
	The Local-RIB is examined and changes (adds, deletes, modifications) are ins talled into		The Local-RIB is examined and changes (adds, deletes, and modifications) are installed into
	the GLOBAL-RIB. For each route in the Local-RIB:		the GLOBAL-RIB. For each route in the Local-RIB:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	If the route was added during the current BGP SPF computation, install the r oute into		If the route was added during the current BGP SPF computation, install the r oute into
	the GLOBAL-RIB.		the GLOBAL-RIB.
	</li>		</li>
	<li>		<li>
	If the route modified during the current BGP SPF computation (e.g., metric, ta gs,		If the route was modified during the current BGP SPF computation (e.g., metric , tags,
	or next-hops), update the route in the GLOBAL-RIB.		or next-hops), update the route in the GLOBAL-RIB.
	</li>		</li>
	<li>		<li>
	If the route was not installed during the current BGP SPF computation, remove the route		If the route was not installed during the current BGP SPF computation, remove the route
	from the GLOBAL-RIB.		from the GLOBAL-RIB.
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>IPv4/IPv6 Unicast Address Family Interaction</name>		<name>IPv4/IPv6 Unicast Address Family Interaction</name>
	<t>		<t>
	While the BGP-LS-SPF address family and the BGP unicast address families may i nstall routes		While the BGP-LS-SPF address family and the BGP unicast address families may i nstall routes
	into the same device routing tables, they operate independently (i.e., "Ships- in-the-Night" mode).		into the routing tables of the same device, they operate independently (i.e., "ships-in-the-night" mode).
	There is no implicit route redistribution between the BGP-LS-SPF address famil y and the BGP		There is no implicit route redistribution between the BGP-LS-SPF address famil y and the BGP
	unicast address families.		unicast address families.
	</t>		</t>
	<t>		<t>
	It is RECOMMENDED that BGP-LS-SPF IPv4/IPv6 route computation and		It is <bcp14>RECOMMENDED</bcp14> that BGP-LS-SPF IPv4/IPv6 route computation a nd
	installation be given scheduling priority by default over other BGP address fa milies		installation be given scheduling priority by default over other BGP address fa milies
	as these address families are considered as underlay SAFIs.		as these address families are considered as underlay SAFIs.
	</t>		</t>
	</section>		</section>
	<section anchor="NLRI-Advertise" numbered="true" toc="default">		<section anchor="NLRI-Advertise" numbered="true" toc="default">
	<name>NLRI Advertisement</name>		<name>NLRI Advertisement</name>
	<section anchor="failure-converge" numbered="true" toc="default">		<section anchor="failure-converge" numbered="true" toc="default">
	<name>Link/Prefix Failure Convergence</name>		<name>Link/Prefix Failure Convergence</name>
	<t>		<t>
	A local failure prevents a link from being used in the SPF calculation		A local failure prevents a link from being used in the SPF calculation
	due to the IGP bi-directional connectivity requirement. Consequently, local li		due to the IGP bidirectional connectivity requirement. Consequently, local lin
	nk		k
	failures SHOULD always be communicated as quickly as possible and given priori		failures <bcp14>SHOULD</bcp14> always be communicated as quickly as possible a
	ty		nd given priority
	over other categories of changes to ensure expeditious propagation		over other categories of changes to ensure expeditious propagation
	and optimal convergence.		and optimal convergence.
	</t>		</t>
	<t>		<t>
	According to standard BGP procedures, the link would continue		According to standard BGP procedures, the link would continue
	to be used until the last copy of the BGP-LS-SPF Link NLRI is		to be 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 SHOUL D		withdrawn. In order to avoid this delay, the originator of the Link NLRI <bcp1 4>SHOULD</bcp14>
	advertise a more recent version with an increased Sequence Number TLV for		advertise a more recent version with an increased Sequence Number TLV for
	the BGP-LS-SPF Link NLRI including the SPF Status TLV		the BGP-LS-SPF Link NLRI including the SPF Status TLV
	(refer to <xref target="link-status-tlv" format="default"/>) indicating the li nk		(refer to <xref target="link-status-tlv" format="default"/>) indicating the li nk
	is down with respect to BGP SPF.		is down with respect to BGP SPF.
			<!--[rfced] The following sentences do not parse, for example, "that
			the BGP-LS-LINK NLRI is advertised with SPF Status". How may we
			rephrase this text for clarity?
			Also, should "BGP-LS-LINK NLRI" be updated as "BGP-LS-SPF Link NLRI"
			in the first sentence and "BGP-LS-Prefix NLRI" be updated as
			"BGP-LS-SPF Prefix NLRI" in the second sentence for consistency?
			Original:
			The configurable LinkStatusDownAdvertise timer controls the interval
			that the BGP-LS-LINK NLRI is advertised with SPF Status indicating
			the link is down prior to withdrawal.
			The configurable PrefixStatusDownAdvertise timer controls the
			interval that the BGP-LS-Prefix NLRI is advertised with SPF
			Status indicating the prefix is unreachable prior to withdrawal.
			Perhaps:
			The configurable PrefixStatusDownAdvertise timer controls the
			interval when a BGP-LS-SPF Link NLRI has been advertised with the
			SPF Status TLV and indicates that the prefix is unreachable prior
			to withdrawal.
			The configurable PrefixStatusDownAdvertise timer controls the
			interval when a BGP-LS-SPF Prefix NLRI is advertised with the
			SPF Status TLV and indicates that the prefix is unreachable prior
			to withdrawal.
			-->
	The configurable LinkStatusDownAdvertise timer		The configurable LinkStatusDownAdvertise timer
	controls the interval that the BGP-LS-LINK NLRI is advertised with SPF Status indicating		controls the interval that the BGP-LS-LINK NLRI is advertised with SPF Status indicating
	the link is down prior to withdrawal.		the link is down prior to withdrawal.
	If BGP-LS-SPF Link NLRI has been advertised with the SPF Status		If a BGP-LS-SPF Link NLRI has been advertised with the SPF Status
	TLV and the link becomes available		TLV and the link becomes available
	in that period, the originator of the BGP-LS-SPF LINK NLRI MUST advertise a mo		in that period, the originator of the BGP-LS-SPF Link NLRI <bcp14>MUST</bcp14>
	re recent		advertise a more recent
	version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the BGP-LS L		version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the BGP-LS A
	ink Attributes.		ttributes.
	The suggested default value for the LinkStatusDownAdvertise timer is 2 seconds .		The suggested default value for the LinkStatusDownAdvertise timer is 2 seconds .
	</t>		</t>
	<t>		<t>
	Similarly, when a prefix becomes unreachable, a more recent version of the BGP -LS-SPF		Similarly, when a prefix becomes unreachable, a more recent version of the BGP -LS-SPF
	Prefix NLRI SHOULD be advertised with the SPF Status TLV		Prefix NLRI <bcp14>SHOULD</bcp14> be advertised with the SPF Status TLV
	(refer to <xref target="prefix-status-tlv" format="default"/>)		(refer to <xref target="prefix-status-tlv" format="default"/>)
	indicating the prefix is unreachable in the BGP-LS Prefix Attributes and the p refix will be		to indicate that the prefix is unreachable in the BGP-LS Prefix Attributes, an d the prefix will be
	considered unreachable with respect to BGP SPF.		considered unreachable with respect to BGP SPF.
	The configurable PrefixStatusDownAdvertise timer		The configurable PrefixStatusDownAdvertise timer
	controls the interval that the BGP-LS-Prefix NLRI is advertised with SPF Statu s indicating		controls the interval that the BGP-LS-Prefix NLRI is advertised with SPF Statu s indicating
	the prefix is unreachable prior to withdrawal.		the prefix is unreachable prior to withdrawal.
	If the BGP-LS-SPF Prefix has been advertised with the SPF Status TLV and the p refix		If the BGP-LS-SPF Prefix has been advertised with the SPF Status TLV and the p refix
	becomes reachable in that period, the originator of the BGP-LS-SPF Prefix NLRI		becomes reachable in that period, the originator of the BGP-LS-SPF Prefix NLRI
	MUST advertise a more recent version of the BGP-LS-SPF Prefix NLRI without the		<bcp14>MUST</bcp14> advertise a more recent version of the BGP-LS-SPF Prefix N LRI without the
	SPF Status TLV in the BGP-LS Prefix Attributes.		SPF Status TLV in the BGP-LS Prefix Attributes.
	The suggested default value for the PrefixStatusDownAdvertise timer is 2 secon ds.		The suggested default value for the PrefixStatusDownAdvertise timer is 2 secon ds.
	</t>		</t>
	</section>		</section>
	<section anchor="node-failure" numbered="true" toc="default">		<section anchor="node-failure" numbered="true" toc="default">
	<name>Node Failure Convergence</name>		<name>Node Failure Convergence</name>
	<t>		<t>
	By default, all the NLRI advertised by a node are withdrawn when a session		By default, all the NLRIs advertised by a node are withdrawn when a session
	failure is detected <xref target="RFC4271"/>. If fast failure detection such a s BFD		failure is detected <xref target="RFC4271"/>. If fast failure detection such a s BFD
	<xref target="RFC5880"/> is utilized, and the node is		<xref target="RFC5880"/> is utilized, and the node is
	on the fastest converging path, the most recent versions of BGP-LS-SPF NLRI wi ll be		on the fastest converging path, the most recent versions of BGP-LS-SPF NLRI wi ll be
	withdrawn. This may result in older versions of NLRI received from peer(s) on		withdrawn. This may result in older versions of NLRIs received from one or mor
	different path(s) being in the LSNDB until they are withdrawn.		e peers on
	These stale NLRI will not delay convergence since the adjacent nodes detect th		a different path(s) in the LSNDB until they are withdrawn.
	e		These stale NLRIs will not delay convergence since the adjacent nodes detect t
			he
	link failure and advertise a more recent NLRI indicating the link is down with respect to		link failure and advertise a more recent NLRI indicating the link is down with respect to
	BGP SPF (refer to <xref target="failure-converge" format="default"/>) and the		BGP SPF (refer to <xref target="failure-converge" format="default"/>) and the
	bi-directional connectivity check fails during the BGP SPF calculation		bidirectional connectivity check fails during the BGP SPF calculation
	(refer to <xref target="BGP-SPF" format="default"/>).		(refer to <xref target="BGP-SPF" format="default"/>).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="error-handling" numbered="true" toc="default">		<section anchor="error-handling" numbered="true" toc="default">
	<name>Error Handling</name>		<name>Error Handling</name>
	<t>		<t>
	This section describes the Error Handling actions, as described in		This section describes error-handling actions, as described in
	<xref target="RFC7606" format="default"/>, that are specific to SAFI BGP-LS-SP		<xref target="RFC7606" format="default"/>, that are specific to BGP-LS-SPF SAF
	F BGP Update		I BGP Update
	message processing.		message processing.
	</t>		</t>
	<section anchor="new-TLVs" numbered="true" toc="default">		<section anchor="new-TLVs" numbered="true" toc="default">
	<name>Processing of BGP-LS-SPF TLVs</name>		<name>Processing of BGP-LS-SPF TLVs</name>
	<t>		<t>
	When a BGP speaker receives a BGP Update containing a malformed Node NLRI		When a BGP speaker receives a BGP Update containing a malformed Node NLRI
	SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,		SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,
	the corresponding Node NLRI is		the corresponding Node NLRI is
	considered as malformed and MUST be handled as 'Treat-as-withdraw'. An		considered malformed and <bcp14>MUST</bcp14> be handled as 'treat-as-withdraw'
	implementation SHOULD log an error (subject to rate-limiting) for further anal		. An
	ysis.		implementation <bcp14>SHOULD</bcp14> log an error (subject to rate limiting) f
			or further analysis.
	</t>		</t>
	<t>		<t>
	When a BGP speaker receives a BGP Update containing a malformed Link NLRI		When a BGP speaker receives a BGP Update containing a malformed Link NLRI
	SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,		SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,
	the corresponding Link NLRI is		the corresponding Link NLRI is
	considered as malformed and MUST be handled as 'Treat-as-withdraw'. An		considered malformed and <bcp14>MUST</bcp14> be handled as 'treat-as-withdraw'
	implementation SHOULD log an error (subject to rate-limiting) for further anal		. An
	ysis.		implementation <bcp14>SHOULD</bcp14> log an error (subject to rate limiting) f
			or further analysis.
	</t>		</t>
	<t>		<t>
	When a BGP speaker receives a BGP Update containing a malformed Address Family		When a BGP speaker receives a BGP Update containing a malformed Address Family
	Link Descriptor TLV in the BGP-LS Attribute <xref target="RFC9552" format="def ault"/>,		Link Descriptor TLV in the BGP-LS Attribute <xref target="RFC9552" format="def ault"/>,
	the corresponding Link NLRI is		the corresponding Link NLRI is
	considered as malformed and MUST be handled as 'Treat-as-withdraw'. An		considered malformed and <bcp14>MUST</bcp14> be handled as 'treat-as-withdraw'
	implementation SHOULD log an error (subject to rate-limiting) for further anal		. An
	ysis.		implementation <bcp14>SHOULD</bcp14> log an error (subject to rate limiting) f
			or further analysis.
	</t>		</t>
	<t>		<t>
	When a BGP speaker receives a BGP Update containing a malformed Prefix NLRI		When a BGP speaker receives a BGP Update containing a malformed Prefix NLRI
	SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,		SPF Status TLV in the BGP-LS Attribute <xref target="RFC9552" format="default" />,
	the corresponding Prefix NLRI is		the corresponding Prefix NLRI is
	considered as malformed and MUST be handled as 'Treat-as-withdraw'. An		considered malformed and <bcp14>MUST</bcp14> be handled as 'treat-as-withdraw'
	implementation SHOULD log an error (subject to rate-limiting) for further anal		. An
	ysis.		implementation <bcp14>SHOULD</bcp14> log an error (subject to rate limiting) f
			or further analysis.
	</t>		</t>
	<t>		<t>
	When a BGP speaker receives a BGP Update containing any malformed BGP-LS Attri		When a BGP speaker receives a BGP Update containing a malformed BGP-LS Attribu
	bute TE		te TE
	and IGP Metric TLV, the corresponding NLRI is considered as malformed		and IGP Metric TLV, the corresponding NLRI is considered malformed
	and MUST be handled as 'Treat-as-withdraw' <xref target="RFC7606" format="defa		and <bcp14>MUST</bcp14> be handled as 'treat-as-withdraw' <xref target="RFC760
	ult"/>.		6" format="default"/>.
	An implementation SHOULD log an error (subject to rate-limiting) for further a		An implementation <bcp14>SHOULD</bcp14> log an error (subject to rate limiting
	nalysis.		) for further analysis.
	</t>		</t>
	<t>		<t>
	The BGP-LS Attribute consists of Node attribute TLVs, Link attribute TLVs, and		The BGP-LS Attribute consists of Node attribute TLVs, Link attribute TLVs, and
	the Prefix		Prefix
	attribute TLVs. Node attribute TLVs and their error handling rules are either		attribute TLVs. Node attribute TLVs and their error-handling rules are either
	defined in		defined in
	<xref target="RFC9552" format="default"/>		<xref target="RFC9552" format="default"/>
	or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.		or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.
	If a BGP speaker receives a BGP-LS Attribute which is considered malformed bas		If a BGP speaker receives a BGP-LS Attribute that is considered malformed base
	ed on these		d on these
	error handling rules, then it MUST consider the received NLRI as malformed and		error-handling rules, then it <bcp14>MUST</bcp14> consider the received NLRI a
	the receiving		s malformed, and the receiving
	BGP speaker MUST handle such malformed NLRI as 'Treat-as-withdraw' <xref targe		BGP speaker <bcp14>MUST</bcp14> handle such a malformed NLRI as 'treat-as-with
	t="RFC7606" format="default"/>.		draw' <xref target="RFC7606" format="default"/>.
	</t>		</t>
	<t>		<t>
	Node Descriptor TLVs and their error handling rules are defined in		Node Descriptor TLVs and their error-handling rules are defined in
	section 5.2.1 of <xref target="RFC9552" format="default"/>.		<xref section="5.2.1" target="RFC9552" format="default"/>.
	Node Attribute TLVs and their error handling rules are either defined in		Node Attribute TLVs and their error-handling rules are either defined in
	<xref target="RFC9552" format="default"/>		<xref target="RFC9552" format="default"/>
	or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.		or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.
	</t>		</t>
	<t>		<t>
	Link Descriptor TLVs and their error handling rules are defined in		Link Descriptor TLVs and their error-handling rules are defined in
	section 5.2.2 of <xref target="RFC9552" format="default"/>.		<xref section="5.2.2" target="RFC9552" format="default"/>.
	Link Attribute TLVs and their error handling rules are either defined in		Link Attribute TLVs and their error-handling rules are either defined in
	<xref target="RFC9552" format="default"/>		<xref target="RFC9552" format="default"/>
	or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.		or derived from <xref target="RFC5305" format="default"/> and <xref target="RF C6119" format="default"/>.
	</t>		</t>
	<t>		<t>
	Prefix Descriptor TLVs and their error handling rules are defined in		Prefix Descriptor TLVs and their error-handling rules are defined in
	section 5.2.3 of <xref target="RFC9552" format="default"/>.		<xref section="5.2.3" target="RFC9552" format="default"/>.
	Prefix Attribute TLVs and their error handling rules are either defined in		Prefix Attribute TLVs and their error-handling rules are either defined in
	<xref target="RFC9552" format="default"/>		<xref target="RFC9552" format="default"/>
	or derived from <xref target="RFC5130" format="default"/> and		or derived from <xref target="RFC5130" format="default"/> and
	<xref target="RFC2328" format="default"/>.		<xref target="RFC2328" format="default"/>.
	</t>		</t>
	<t>		<t>
	If a BGP speaker receives NLRI with a Node Descriptor TLV, Link Descriptor TLV , or Prefix Descriptor		If a BGP speaker receives NLRI with a Node Descriptor TLV, Link Descriptor TLV , or Prefix Descriptor
	TLV that is considered malformed based on error handling rules defined in the above references,		TLV that is considered malformed based on error handling rules defined in the above references,
	then it MUST consider the received NLRI as malformed and the receiving		then it <bcp14>MUST</bcp14> consider the received NLRI as malformed, and the r
	BGP speaker MUST handle such malformed NLRI as 'Treat-as-withdraw' <xref targe		eceiving
	t="RFC7606" format="default"/>.		BGP speaker <bcp14>MUST</bcp14> handle such a malformed NLRI as 'treat-as-with
			draw' <xref target="RFC7606" format="default"/>.
	</t>		</t>
	<t>		<t>
	When a BGP speaker receives a BGP Update that does not contain any BGP-LS Attr		When a BGP speaker receives a BGP Update that does not contain any BGP-LS Attr
	ibute,		ibutes,
	it is most likely an indication of 'Attribute Discard' fault handling and the		it is most likely an indication of 'Attribute Discard' fault handling, and the
	BGP speaker SHOULD preserve and propagate the BGP-LS-SPF NLRI as described in		BGP speaker <bcp14>SHOULD</bcp14> preserve and propagate the BGP-LS-SPF NLRI a
	Section 8.2.2 of <xref target="RFC9552"/>. However, NLRI without the BGP-LS at		s described in
	tribute		<xref section="8.2.2" target="RFC9552"/>. However, NLRIs without the BGP-LS at
	MUST NOT be used in the SPF Calculation <xref target="BGP-SPF"/>. How this is		tribute
	accomplished		<bcp14>MUST NOT</bcp14> be used in the SPF calculation (<xref target="BGP-SPF"
	is an implementation matter but one way would be for these NLRI not to returne		/>). How this is accomplished
	d in		is an implementation matter, but one way would be for these NLRIs not to be re
			turned in
	LSNDB lookups.		LSNDB lookups.
	</t>		</t>
	</section>		</section>
	<section anchor="bgpspf-nlri" numbered="true" toc="default">		<section anchor="bgpspf-nlri" numbered="true" toc="default">
	<name>Processing of BGP-LS-SPF NLRIs</name>		<name>Processing of BGP-LS-SPF NLRIs</name>
	<t>		<t>
	A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the syntactic valida		A BGP speaker supporting the BGP-LS-SPF SAFI <bcp14>MUST</bcp14> perform the s
	tion checks of the		yntactic validation checks of the
	BGP-LS-SPF NLRI listed in Section 8.2.2 of		BGP-LS-SPF NLRI listed in <xref section="8.2.2" target="RFC9552" format="defau
	<xref target="RFC9552" format="default"/> to determine if		lt"/> to determine if
	it is malformed.		it is malformed.
	</t>		</t>
	</section>		</section>
	<section anchor="bgpspf-attribute" numbered="true" toc="default">		<section anchor="bgpspf-attribute" numbered="true" toc="default">
	<name>Processing of BGP-LS Attribute</name>		<name>Processing of BGP-LS Attributes</name>
	<t>		<t>
	A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the syntactic validat		A BGP speaker supporting the BGP-LS-SPF SAFI <bcp14>MUST</bcp14> perform the sy
	ion checks of the		ntactic validation checks of the
	BGP-LS Attribute listed in Section 8.2.2 of		BGP-LS Attribute listed in <xref section="8.2.2" target="RFC9552" format="defau
	<xref target="RFC9552" format="default"/> to determine if		lt"/> to determine if
	it is malformed.		it is malformed.
	</t>		</t>
	<t>		<t>
	An implementation SHOULD log an error for further analysis for problems		An implementation <bcp14>SHOULD</bcp14> log an error for further analysis for problems
	detected during syntax validation.		detected during syntax validation.
	</t>		</t>
	</section>		</section>
	<section anchor="bgp-sync" numbered="true" toc="default">		<section anchor="bgp-sync" numbered="true" toc="default">
	<name>BGP-LS-SPF Link State NLRI Database Synchronization</name>		<name>BGP-LS-SPF Link-State NLRI Database Synchronization</name>
	<t>		<t>
	While uncommon, there may be situations where the LSNDBs of two		While uncommon, there may be situations where the LSNDBs of two
	BGP speakers supporting the BGP-LS-SPF SAFI lose synchronization.		BGP speakers support the BGP-LS-SPF SAFI lose synchronization.
	In these situations, the BGP		In these situations, the BGP
	session MUST be reset unless other means of resynchronization are used		session <bcp14>MUST</bcp14> be reset unless other means of resynchronization are used
	(beyond the scope of this document).		(beyond the scope of this document).
	When the session is reset, the BGP speaker MUST send a NOTIFICATION		When the session is reset, the BGP speaker <bcp14>MUST</bcp14> send a NOTIFI CATION
	message with the BGP error code "Loss of LSDB Synchronization" as described		message with the BGP error code "Loss of LSDB Synchronization" as described
	in section 3 of <xref target="RFC4271"/>. The mechanisms to detect loss of		in <xref section="3" target="RFC4271"/>. The mechanisms to detect loss of
	synchronization are beyond the scope of this document.		synchronization are beyond the scope of this document.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="IANA" numbered="true" toc="default">		<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS-SPF Allocation in SAFI Parameters Registry</name>		<name>BGP-LS-SPF Allocation in the SAFI Values Registry</name>
	<t>		<t>
	IANA has assigned value 80 for BGP-LS-SPF from the First Come First		IANA has assigned value 80 for BGP-LS-SPF from the First Come First
	Served range in the "Subsequent Address Family Identifiers (SAFI)		Served range <xref target="RFC8126"/> and listed this document as a reference
	Parameters" registry. IANA is requested to update the registration		in the "SAFI Values" registry within the "Subsequent Address Family Identifiers
	to reference only to this document.		(SAFI) Parameters" registry group.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS-SPF Assignments to BGP-LS NLRI and Attribute TLV Registry</name>		<name>BGP-LS-SPF Assignments in the BGP-LS NLRI and Attribute TLVs Registry</n ame>
	<t>		<t>
	IANA has assigned six TLVs for BGP-LS-SPF NLRI in the "BGP-LS NLRI and Attribu te		IANA has assigned six TLVs for BGP-LS-SPF NLRI in the "BGP-LS NLRI and Attribu te
	TLV" registry.		TLVs" registry. Supported TLV types include Sequence Number, SPF Status, and A
	Supported TLV types include the SPF Status TLV type, Address Family Link		ddress Family Link
	Descriptor TLV type, and Sequence Number TLV type. Deprecated TLV types		Descriptor. Deprecated TLV types include SPF Capability, IPv4 Link Prefix Len
	include the SPF Capability TLV type, IPv4 Link Prefix Length TLV type, and IPv		gth, and IPv6
	6		Link Prefix Length.
	Link Prefix Length TLV type.
	</t>		</t>
			<!--[rfced] FYI - We placed the information in Table 5 in ascending
			order to match the "BGP-LS NLRI and Attribute TLVs" registry at
			<https://www.iana.org/assignments/bgp-ls-parameters/>
			-->
	<table anchor="tab.iana-attr" align="center">		<table anchor="tab.iana-attr" align="center">
	<name>NLRI Attribute TLVs</name>		<name>NLRI Attribute TLVs</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">TLV Code Point</th>		<th align="left">TLV Code Point</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">1185</td>
	<td align="left">Address Family Link Descriptor</td>
	<td align="left"><xref target="af-link-descriptor-tlv"/>, RFCXXXX ([this documen
	t]).</td>
	</tr>
	<tr>
	<td align="left">1181</td>		<td align="left">1181</td>
	<td align="left">Sequence Number</td>		<td align="left">Sequence Number</td>
	<td align="left">RFCXXXX ([this document]), <xref target="sequence-number-tlv"/> </td>		<td align="left"><xref target="sequence-number-tlv"/> of RFC XXXX</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">1184</td>		<td align="left">1184</td>
	<td align="left">SPF Status</td>		<td align="left">SPF Status</td>
	<td align="left"><xref target="node-status-tlv"/>, RFCXXXX ([this document]),		<td align="left">Sections <xref target="node-status-tlv" format="counter"/>,
	<xref target="link-status-tlv"/> and <xref target="prefix-status-tlv"/></td>		<xref target="link-status-tlv" format="counter"/>, and <xref target="prefix-stat
			us-tlv" format="counter"/> of RFC XXXX</td>
			</tr>
			<tr>
			<td align="left">1185</td>
			<td align="left">Address Family Link Descriptor</td>
			<td align="left"><xref target="af-link-descriptor-tlv"/> of RFC XXXX</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>		<t>
	The early allocation assignments for the TLV types SPF Capability (1180),		The early allocation assignments for the TLV types SPF Capability (1180),
	IPv4 Link Prefix Length (1182), and IPv6 Link Prefix Length (1183) are no long er required		IPv4 Link Prefix Length (1182), and IPv6 Link Prefix Length (1183) are no long er required
	and are to be deprecated.		and have been deprecated.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status Registry</name>		<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status Registry</name>
	<t>		<t>
	IANA is requested to create the "BGP-LS-SPF Node NLRI Attribute SPF		IANA has created the "BGP-LS-SPF Node NLRI Attribute SPF
	Status TLV Status" Registry for status values in a new BGP SPF group.		Status TLV Status" registry for status values within the "BGP Shortest Path
			First (BGP SPF)" registry group.
	Initial values for this registry are provided below. Future assignments		Initial values for this registry are provided below. Future assignments
	are to be made using the Expert Review registration policy <xref target="RFC 8126"/>		are to be made using the Expert Review registration policy <xref target="RFC 8126"/>
	with guidance for Designated Experts as per section 7.2 of <xref target="RFC 9552"/>.		with guidance for designated experts as per <xref section="7.2" target="RFC9 552"/>.
	</t>		</t>
	<table anchor="tab.iana-node-status" align="center">		<table anchor="tab.iana-node-status" align="center">
	<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status Registry Assignmen ts</name>		<name>BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status Registry Assignmen ts</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Values</th>		<th align="left">Values</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	skipping to change at line 1549 ¶		skipping to change at line 1889 ¶
	<tr>		<tr>
	<td align="left">255</td>		<td align="left">255</td>
	<td align="left">Reserved</td>		<td align="left">Reserved</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status Registry</name>		<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status Registry</name>
	<t>		<t>
	IANA is requested to create the "BGP-LS-SPF Link NLRI Attribute SPF		IANA has created the "BGP-LS-SPF Link NLRI Attribute SPF
	Status TLV Status" Registry for status values in a new BGP SPF group.		Status TLV Status" registry for status values within the BGP Shortest Path F
			irst (BGP SPF)" registry group.
	Initial values for this registry are provided below. Future assignments		Initial values for this registry are provided below. Future assignments
	are to be made using the IETF Review registration policy <xref target="RFC81 26"/>.		are to be made using the IETF Review registration policy <xref target="RFC81 26"/>.
	</t>		</t>
	<table anchor="tab.iana-link-status" align="center">		<table anchor="tab.iana-link-status" align="center">
	<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status Registry Assignmen ts</name>		<name>BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status Registry Assignmen ts</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Value</th>		<th align="left">Value</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	</tr>		</tr>
	skipping to change at line 1585 ¶		skipping to change at line 1925 ¶
	<tr>		<tr>
	<td align="left">255</td>		<td align="left">255</td>
	<td align="left">Reserved</td>		<td align="left">Reserved</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status Registry</name>		<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status Registry</name>
	<t>		<t>
	IANA is requested to create the "BGP-LS-SPF Prefix NLRI Attribute SPF		IANA has created the "BGP-LS-SPF Prefix NLRI Attribute SPF
	Status TLV Status" Registry for status values in a new BGP SPF group.		Status TLV Status" registry for status values within the "BGP Shortest Path
			First (BGP SPF)" registry group.
	Initial values for this registry are provided below. Future assignments		Initial values for this registry are provided below. Future assignments
	are to be made using the IETF Review registration policy <xref target="RFC81 26"/>.		are to be made using the IETF Review registration policy <xref target="RFC81 26"/>.
	</t>		</t>
	<table anchor="tab.iana-prefix-status" align="center">		<table anchor="tab.iana-prefix-status" align="center">
	<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status Registry Assignm ents</name>		<name>BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status Registry Assignm ents</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Value</th>		<th align="left">Value</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	</tr>		</tr>
	skipping to change at line 1619 ¶		skipping to change at line 1959 ¶
	<td align="left">Unassigned</td>		<td align="left">Unassigned</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">255</td>		<td align="left">255</td>
	<td align="left">Reserved</td>		<td align="left">Reserved</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BGP Error (Notification) Code Assignment</name>		<name>Assignment in the BGP Error (Notification) Codes Registry</name>
	<t>		<t>
	IANA is requested to assign a TBD code for "Loss of LSDB Synchronization" in		IANA has assigned value 9 for Loss of LSDB Synchronization in the
	the		"BGP Error (Notification) Codes" registry within the
	BGP Error (Notification) Codes" registry in the
	"Border Gateway Protocol (BGP) Parameters" registry group.		"Border Gateway Protocol (BGP) Parameters" registry group.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document defines a BGP SAFI, i.e., the BGP-LS-SPF SAFI. This document		This document defines a BGP SAFI, i.e., the BGP-LS-SPF SAFI. This document
	does not change the underlying security issues inherent in the BGP protocol		does not change the underlying security issues inherent in the BGP protocol
	<xref target="RFC4271" format="default"/>. The Security Considerations		<xref target="RFC4271" format="default"/>. The security considerations
	discussed in <xref target="RFC4271" format="default"/> apply to the BGP SPF fu nctionality as well.		discussed in <xref target="RFC4271" format="default"/> apply to the BGP SPF fu nctionality as well.
	The analysis of the security issues for BGP mentioned		The analysis of the security issues for BGP mentioned
	in <xref target="RFC4272" format="default"/> and <xref target="RFC6952" format ="default"/> also applies to this document.		in <xref target="RFC4272" format="default"/> and <xref target="RFC6952" format ="default"/> also applies to this document.
	The threats and security considerations are the similar to the BGP IPv4 Unicas t SAFI and		The threats and security considerations are similar to the BGP IPv4 Unicast SA FI and
	IPv6 Unicast SAFI when utilized in similar deployments, e.g., <xref target="RF C7938"/>.		IPv6 Unicast SAFI when utilized in similar deployments, e.g., <xref target="RF C7938"/>.
	The analysis of Generic Threats to Routing Protocols done in <xref target="RFC 4593" format="default"/>		The analysis of generic threats to routing protocols in <xref target="RFC4593" format="default"/>
	is also worth noting.		is also worth noting.
	</t>		</t>
	<t>		<t>
	As the modifications described in this document for		As the modifications for
	BGP SPF apply to IPv4 Unicast and IPv6 Unicast as underlay SAFIs in a single		BGP SPF described in this document apply to IPv4 Unicast and IPv6 Unicast as u
			nderlay SAFIs in a single
	BGP SPF Routing Domain, the BGP		BGP SPF Routing Domain, the BGP
	security solutions described in <xref target="RFC6811" format="default"/> and <xref target="RFC8205" format="default"/>		security solutions described in <xref target="RFC6811" format="default"/> and <xref target="RFC8205" format="default"/>
	are out of scope as they are meant to apply for inter-domain BGP where		are out of scope as they are meant to apply for inter-domain BGP, where
	multiple BGP Routing Domains are typically involved. The BGP-LS-SPF SAFI NLRI		multiple BGP Routing Domains are typically involved. The BGP-LS-SPF SAFI NLRIs
	described		described
	in this document are typically advertised between External BGP (EBGP) or		in this document are typically advertised between EBGP or
	Internal BGP (IBGP) speakers under a single administrative domain.		IBGP speakers under a single administrative domain.
	</t>		</t>
	<t>		<t>
			<!--[rfced] We having trouble parsing this sentence. Does the
			processing of the BGP SPF and BGP-LS-SPF SAFI cause the encoding
			to be inherited from BGP-LS (option A)? Or do BGP-LS-SPF SAFIs
			and processed BGP SPFs inherit the encoding (option B)? Please
			clarify.
			Original:
			The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding
			from BGP-LS [RFC9552], and consequently, inherit the security
			considerations for BGP-LS associated with encoding.
			Perhaps A:
			When BGP SPF and BGP-LS-SPF SAFI are processed, they inherit
			encoding from BGP-LS [RFC9552] and, consequently, inherit the
			security considerations for the BGP-LS associated with encoding.
			Perhaps B:
			BGP-LS-SPF SAFIs and processed BGP SPFs inherit the encoding
			from BGP-LS [RFC9552] and, consequently, inherit the security
			considerations for BGP-LS associated with encoding.
			-->
	The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding from BGP-L S		The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding from BGP-L S
	<xref target="RFC9552" format="default"/>, and consequently, inherit		<xref target="RFC9552" format="default"/>, and consequently, inherit
	the security considerations for BGP-LS associated with encoding. Additionally,		the security considerations for BGP-LS associated with encoding. Additionally,
	given that the BGP SPF processing		given that BGP SPF processing
	is used to install IPv4 and IPv6 Unicast routes, the BGP SPF processing is vul		is used to install IPv4 and IPv6 unicast routes, the BGP SPF processing is vul
	nerable to		nerable to
	attacks to the routing control plane that aren't applicable to BGP-LS. One not able		attacks to the routing control plane that aren't applicable to BGP-LS. One not able
	Denial-of-Service attack, would be to include malformed BGP attributes in a re plicated		Denial-of-Service attack would be to include malformed BGP attributes in a rep licated
	BGP Update, causing the receiving peer to treat the advertised BGP-LS-SPF to a		BGP Update, causing the receiving peer to treat the advertised BGP-LS-SPF to a
	withdrawal <xref target="RFC7606" format="default"/>.		withdrawal <xref target="RFC7606" format="default"/>.
	</t>		</t>
	<t>		<t>
	In order to mitigate the risk of peering with BGP speakers masquerading		In order to mitigate the risk of peering with BGP speakers masquerading
	as legitimate authorized BGP speakers, it is RECOMMENDED that		as legitimate authorized BGP speakers, it is <bcp14>RECOMMENDED</bcp14> that
	the TCP Authentication Option (TCP-AO) <xref target="RFC5925" format="default" /> be used to		the TCP Authentication Option (TCP-AO) <xref target="RFC5925" format="default" /> be used to
	authenticate BGP sessions. If an authorized BGP peer is compromised, that		authenticate BGP sessions. If an authorized BGP peer is compromised, that
	BGP peer could advertise modified Node, Link, or Prefix NLRI which result		BGP peer could advertise a modified Node, Link, or Prefix NLRI that results
	in misrouting, repeating origination of NLRI, and/or excessive SPF		in misrouting, repeating origination of NLRI, and/or excessive SPF
	calculations. When a BGP speaker detects that its self-originated NLRI		calculations. When a BGP speaker detects that its self-originated NLRI
	is being originated by another BGP speaker, an appropriate error SHOULD		is being originated by another BGP speaker, an appropriate error <bcp14>SHOULD </bcp14>
	be logged so that the operator can take corrective action. This exposure is si milar		be logged so that the operator can take corrective action. This exposure is si milar
	to other BGP AFI/SAFIs.		to other BGP AFI/SAFIs.
	</t>		</t>
	</section>		</section>
	<section anchor="Management" numbered="true" toc="default">		<section anchor="Management" numbered="true" toc="default">
	<name>Management Considerations</name>		<name>Management Considerations</name>
	<t>		<t>
	This section includes unique management considerations for the BGP-LS-SPF addr ess family.		This section includes unique management considerations for the BGP-LS-SPF addr ess family.
	</t>		</t>
	<section anchor="Config" numbered="true" toc="default">		<section anchor="Config" numbered="true" toc="default">
	<name>Configuration</name>		<name>Configuration</name>
	<t>		<t>
	All routers in BGP SPF Routing Domain are under a single administrative domain		All routers in the BGP SPF Routing Domain are under a single administrative do main
	allowing for consistent configuration.		allowing for consistent configuration.
	</t>		</t>
	</section>		</section>
	<section anchor="link-metric-config" numbered="true" toc="default">		<section anchor="link-metric-config" numbered="true" toc="default">
	<name>Link Metric Configuration</name>		<name>Link Metric Configuration</name>
	<t>		<t>
	For loopback prefixes, it is RECOMMENDED that the metric be 0.		For loopback prefixes, it is <bcp14>RECOMMENDED</bcp14> that the metric be 0 .
	For non-loopback prefixes, the setting of the		For non-loopback prefixes, the setting of the
	metric is a local matter and beyond the scope of this document.		metric is a local matter and beyond the scope of this document.
	</t>		</t>
	<t>		<t>
			<!--[rfced] How may we update this sentence for clarity?
			Original:
			Algorithms such as setting the metric inversely to the link speed as
			supported in some IGP implementations MAY be supported.
			Perhaps:
			Algorithms that set the metric inversely to the link speed
			in some IGP implementations MAY be supported.
			-->
	Algorithms such as setting the metric inversely to the link speed as		Algorithms such as setting the metric inversely to the link speed as
	supported in some IGP implementations MAY be supported. However, the		supported in some IGP implementations <bcp14>MAY</bcp14> be supported. Howev er, the
	details of how the metric is computed are beyond the scope of this document.		details of how the metric is computed are beyond the scope of this document.
	</t>		</t>
	<t>		<t>
	Within a BGP SPF Routing Domain, the IGP metrics for all advertised links SHO ULD be configured or		Within a BGP SPF Routing Domain, the IGP metrics for all advertised links <bc p14>SHOULD</bcp14> be configured or
	defaulted consistently. For example, if a default metric is used for one rout er's links, then a		defaulted consistently. For example, if a default metric is used for one rout er's links, then a
	similar metric should be used for all router's links. Similarly, if the link metric is		similar metric should be used for all router's links. Similarly, if the link metric is
	derived from using the inverse of the link bandwidth on one router, then this		derived from using the inverse of the link bandwidth on one router, then this
	SHOULD		<bcp14>SHOULD</bcp14>
	be done for all routers and the same reference bandwidth SHOULD be used to de		be done for all routers, and the same reference bandwidth <bcp14>SHOULD</bcp1
	rive the		4> be used to derive the
	inversely proportional metric. Failure to do so will result in incorrect rout ing based on		inversely proportional metric. Failure to do so will result in incorrect rout ing based on
	link metric.		the link metric.
	</t>		</t>
	</section>		</section>
	<section anchor="neighbor-config" numbered="true" toc="default">		<section anchor="neighbor-config" numbered="true" toc="default">
	<name>Unnumbered Link Configuration</name>		<name>Unnumbered Link Configuration</name>
	<t>		<t>
	When parallel unnumbered links between BGP-SPF routers are included in the B		When parallel unnumbered links between BGP and SPF routers are included in t
	GP SPF routing		he BGP SPF routing
	domain and the Remote Link Identifiers aren't readily discovered, it is RECO		domain and the Remote Link Identifiers aren't readily discovered, it is <bcp
	MMENDED that these		14>RECOMMENDED</bcp14> that
	the Remote Link Identifiers be configured so that precise NLRI Link matching		the Remote Link Identifiers be configured so that precise Link NLRI matching
	can be done.		can be done.
	</t>		</t>
	</section>		</section>
	<section anchor="Adjacency-EoR-Required" numbered="true" toc="default">		<section anchor="Adjacency-EoR-Required" numbered="true" toc="default">
	<name>Adjacency End-of-RIB (EOR) Marker Requirement</name>		<name>Adjacency End-of-RIB (EOR) Marker Requirement</name>
	<t>		<t>
	Depending on the peering model, topology, and convergence requirements, an		Depending on the peering model, topology, and convergence requirements, an
	End-of-RIB (EoR) Marker <xref target="BGP-LS-SPF-EOR"/> for the BGP-LS-SPF		EoR marker (<xref target="BGP-LS-SPF-EOR"/>) for the BGP-LS-SPF
	SAFI MAY be required from the peer prior to advertising a BGP-LS Link NLRI		SAFI <bcp14>MAY</bcp14> be required from the peer prior to advertising a BGP-L
	for the peer. If configuration is supported, this MUST be configurable at		S Link NLRI
	the BGP SPF instance level and MUST be configured consistently throughout		for the peer. If configuration is supported, this <bcp14>MUST</bcp14> be confi
			gurable at
			the BGP SPF instance level and <bcp14>MUST</bcp14> be configured consistently
			throughout
	the BGP SPF routing domain.		the BGP SPF routing domain.
	</t>		</t>
	<t>		<t>
	When this configuration is provided, the default MUST be to wait		When this configuration is provided, the default <bcp14>MUST</bcp14> be to wai
	indefinitely prior to advertising a BGP-LS link NLRI. Configuration of		t
			indefinitely prior to advertising a BGP-LS Link NLRI. Configuration of
	a timer specifying the maximum time to wait prior to advertisement		a timer specifying the maximum time to wait prior to advertisement
	MAY be provided.		<bcp14>MAY</bcp14> be provided.
	</t>		</t>
	</section>		</section>
	<section anchor="spf-backoff-config" numbered="true" toc="default">		<section anchor="spf-backoff-config" numbered="true" toc="default">
	<name>backoff-config</name>		<name>backoff-config</name>
	<t>		<t>
	In addition to configuration of the BGP-LS-SPF address family, implementations		In addition to the configuration of the BGP-LS-SPF address family, implementat
	SHOULD		ions <bcp14>SHOULD</bcp14>
	support the "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State		support "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGP
	IGPs"		s"
	<xref target="RFC8405" format="default"/>. If supported, configuration of the INITIAL_SPF_DELAY, SHORT_SPF_DELAY,		<xref target="RFC8405" format="default"/>. If supported, configuration of the INITIAL_SPF_DELAY, SHORT_SPF_DELAY,
	LONG_SPF_DELAY, TIME_TO_LEARN, and HOLDDOWN_INTERVAL MUST be supported <xref t		LONG_SPF_DELAY, TIME_TO_LEARN, and HOLDDOWN_INTERVAL <bcp14>MUST</bcp14> be su
	arget="RFC8405" format="default"/>.		pported <xref target="RFC8405" format="default"/>.
	Section 6 of <xref target="RFC8405" format="default"/> recommends consistent c		<xref section="6" target="RFC8405" format="default"/> recommends consistent co
	onfiguration of these values		nfiguration of these values
	throughout the IGP routing domain and this also applies to the BGP SPF Routing		throughout the IGP routing domain, and this also applies to the BGP SPF Routin
	Domain.		g Domain.
	</t>		</t>
	</section>		</section>
	<section anchor="bgp-ls-spf-readvertisement-delay" numbered="true" toc="default" >		<section anchor="bgp-ls-spf-readvertisement-delay" numbered="true" toc="default" >
	<name>BGP-LS-SPF NLRI Readvertisement Delay</name>		<name>BGP-LS-SPF NLRI Readvertisement Delay</name>
	<t>		<t>
	The configuration parameter specifies the delay for readvertising a more recen t		The configuration parameter that specifies the delay for readvertising a more recent
	instance of a self-originated NLRI when received more than once in succession		instance of a self-originated NLRI when received more than once in succession
	is BGP_LS_SPF_SELF_READVERTISEMENT_DELAY. The default is 5 seconds.		is BGP_LS_SPF_SELF_READVERTISEMENT_DELAY. The default is 5 seconds.
	</t>		</t>
	</section>		</section>
	<section anchor="Operation" numbered="true" toc="default">		<section anchor="Operation" numbered="true" toc="default">
	<name>Operational Data</name>		<name>Operational Data</name>
	<t>		<t>
	In order to troubleshoot SPF issues, implementations SHOULD support an SPF log including		In order to troubleshoot SPF issues, implementations <bcp14>SHOULD</bcp14> sup port an SPF log including
	entries for previous SPF computations. Each SPF log entry would include the BG P-LS-SPF NLRI SPF		entries for previous SPF computations. Each SPF log entry would include the BG P-LS-SPF NLRI SPF
	triggering the SPF, SPF scheduled time, SPF start time and SPF end time.		triggering the SPF, SPF scheduled time, SPF start time, and SPF end time.
	Since the size of the log is finite, implementations		Since the size of the log is finite, implementations
	SHOULD also maintain counters for the total number of SPF computations and the		<bcp14>SHOULD</bcp14> also maintain counters for the total number of SPF compu
	total number of SPF triggering events. Additionally, to troubleshoot SPF sched		tations and the
	uling and		total number of SPF triggering events. Additionally, troubleshooting should be
	back-off <xref target="RFC8405" format="default"/>, the current SPF back-off s		available for SPF scheduling and
	tate, remaining time-to-learn,		back-off <xref target="RFC8405" format="default"/>, the current SPF back-off s
	remaining hold-down interval, last trigger event time, last SPF time, and next		tate, the remaining time-to-learn,
	SPF time should be		the remaining hold-down interval, the last trigger event time, the last SPF ti
	available.		me, and the next SPF time.
	</t>		</t>
	</section>		</section>
	<section anchor="bgp-ls-spf-isolation" numbered="true" toc="default">		<section anchor="bgp-ls-spf-isolation" numbered="true" toc="default">
	<name>BGP-LS-SPF Address Family Session Isolation</name>		<name>BGP-LS-SPF Address Family Session Isolation</name>
	<t>		<t>
	In common deployment scenarios, the unicast routes installed during		In common deployment scenarios, the unicast routes installed during
	BGP-LS-SPF AFI/SAFI SPF computation serve as the		BGP-LS-SPF AFI/SAFI SPF computation serve as the
	underlay for other BGP AFI/SAFIs.		underlay for other BGP AFI/SAFIs.
	To avoid errors encountered in other AFI/SAFIs from impacting		To avoid errors encountered in other AFI/SAFIs from impacting
	the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms such as		the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms such as
	separate BGP instances or separate BGP sessions (e.g., using different		separate BGP instances or separate BGP sessions (e.g., using different
	addresses for peering) for BGP SPF Link-State information distribution		addresses for peering) for BGP SPF Link-State distribution information
	SHOULD be used.		<bcp14>SHOULD</bcp14> be used.
	</t>
	</section>
	</section>
	<section anchor="implementation" numbered="true" toc="default">
	<name>Implementation Status</name>
	<t>
	Note RFC Editor: Please remove this section and the associated references
	prior to publication.
	</t>
	<t>
	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of
	this Internet-Draft and is based on a proposal described in
	<xref target="RFC7942" format="default"/>. The description of implementations
	in this section is
	intended to assist the IETF in its decision processes in
	progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the
	IETF. Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a
	catalog of available implementations or their features. Readers
	are advised to note that other implementations may exist.
	</t>
	<t>
	According to RFC 7942, "this will allow reviewers and working
	groups to assign due consideration to documents that have the
	benefit of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented
	protocols more mature. It is up to the individual working groups
	to use this information as they see fit".
	</t>
	<t>
	The document <xref target="I-D.psarkar-lsvr-bgp-spf-impl" format="default"/>
	contains an implementation report documenting implementations of
	BGP Link-State Short Path First (SPF) routing, i.e., this specification.
	</t>		</t>
	</section>		</section>
	<section anchor="Acknowledgements" numbered="true" toc="default">		<section anchor="Acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>		<t>The authors would like to thank <contact fullname="Sue Hares"/>,
	The authors would like to thank Sue Hares, Jorge Rabadan, Boris Hassanov, Dan		<contact fullname="Jorge Rabadan"/>, <contact fullname="Boris Hassanov"/>,
	Frost,		<contact fullname="Dan Frost"/>, <contact fullname="Matt Anderson"/>,
	Matt Anderson, Fred Baker, Lukas Krattiger, Yingzhen Qu, and Haibo Wang for th		<contact fullname="Fred Baker"/>, <contact fullname="Lukas Krattiger"/>,
	eir		<contact fullname="Yingzhen Qu"/>, and <contact fullname="Haibo Wang"/> for
	review and comments. Thanks to Pushpasis Sarkar for discussions on preventing		their reviews and comments. Thanks to <contact fullname="Pushpasis Sarkar"/>
	a		for discussions on preventing a BGP SPF Router from being used for non-local
	BGP SPF Router from being used for non-local traffic (i.e., transit traffic).		traffic (i.e., transit traffic).</t>
	</t>		<t>The authors extend a special thanks to <contact fullname="Eric Rosen"/> for
	<t>		fruitful discussions on BGP-LS-SPF convergence as compared to IGPs.</t>
	The authors extend special thanks to Eric Rosen for fruitful discussions on
	BGP-LS-SPF convergence as compared to IGPs.		<!--[rfced] FYI - To avoid the repetition of "The authors would like
	</t>		to thank" in the Acknowledgements, we updated the text as
	<t>		follows:
	The authors would like extend thanks Alvaro Retana for multiple AD reviews
	and discussions.		Original:
	</t>		The authors would like extend thanks Alvaro Retana for
	<t>		multiple AD reviews and discussions.
	The authors would to thank Ketan Talaulikar for an extensive shepherd review.
	</t>		The authors would to thank Ketan Talaulikar for an extensive
	<t>		shepherd review.
	The authors would like to thank Adrian Farrel, Li Zhang, and Jie Dong for WG l
	ast		The authors would like to thank Adrian Farrel, Li Zhang, and Jie Dong
	call review comments.		for WG last call review comments.
	</t>
	<t>		The authors would to like to thank Jim Guichard for his AD review
	The authors would to like to thank Jim Guichard for his AD review and discussi		and discussion.
	on.
	</t>		The authors would to like to thank David Dong for his IANA review.
	<t>
	The authors would to like to thank David Dong for his IANA review.		The authors would to like to thank Joel Halpern for his GENART review.
	</t>
	<t>		The authors would to like to thank Erik Kline, Eric Vyncke, Mahesh
	The authors would to like to thank Joel Halpern for his GENART review.		Jethanandani, and Roman Danyliw for IESG review comments.
	</t>
	<t>		The authors would to like to thank John Scudder for his detailed
	The authors would to like to thank Erik Kline, Eric Vyncke, Mahesh		IESG review and specifically for helping align the document with
	Jethanandani, and Roman Danyliw for IESG review comments.		BGP documents.
	</t>
	<t>		Current:
	The authors would to like to thank John Scudder for his detailed IESG		The authors would also like to thank the following people:
	review and specifically for helping align the document with BGP documents.
	</t>		* Alvaro Retana for multiple AD reviews and discussions.
			* Ketan Talaulikar for an extensive shepherd review.
			* Adrian Farrel, Li Zhang, and Jie Dong for WG Last Call review
			comments.
			* Jim Guichard for his AD review and discussion.
			* David Dong for his IANA review.
			* Joel Halpern for his GENART review.
			* Erik Kline, Eric Vyncke, Mahesh Jethanandani, and Roman Danyliw
			for IESG review comments.
			* John Scudder for his detailed IESG review and specifically for
			helping align the document with BGP documents.
			-->
			<t>The authors would also like to thank the following people:</t>
			<ul empty="false">
			<li><t><contact fullname="Alvaro Retana"/> for multiple AD
			reviews and discussions.</t></li>
			<li><t><contact fullname="Ketan Talaulikar"/> for an
			extensive shepherd review.</t></li>
			<li><t><contact fullname="Adrian Farrel"/>,
			<contact fullname="Li Zhang"/>, and <contact fullname="Jie Dong"/> for WG
			Last Call review comments.</t></li>
			<li><t><contact fullname="Jim Guichard"/> for his AD review and
			discussion.</t></li>
			<li><t><contact fullname="David Dong"/> for his IANA review.</t></li>
			<li><t><contact fullname="Joel Halpern"/> for his GENART review.</t></li>
			<li><t><contact fullname="Erik Kline"/>,
			<contact fullname="Eric Vyncke"/>, <contact fullname="Mahesh
			Jethanandani"/>, and <contact fullname="Roman Danyliw"/> for IESG review
			comments.</t></li>
			<li><t><contact fullname="John Scudder"/> for his detailed IESG
			review and specifically for helping align the document with BGP documents.</t>
			</li>
			</ul>
	</section>		</section>
	<section anchor="Contributors" numbered="true" toc="default">		<section anchor="Contributors" numbered="true" toc="default">
	<name>Contributors</name>		<name>Contributors</name>
	<t>		<t>The following people contributed substantially to the content of this documen
	In addition to the authors listed on the front page, the following		t and should be considered
	co-authors have contributed to the document.		coauthors:</t>
	</t>
	<artwork align="left" name="" type="" alt=""><![CDATA[
	Derek Yeung
	Arrcus, Inc.
	derek@arrcus.com
	Gunter Van De Velde		<contact fullname="Derek Yeung">
	Nokia		<organization>Arrcus, Inc.</organization>
	gunter.van_de_velde@nokia.com		<address>
			<email>derek@arrcus.com</email>
			</address>
			</contact>
	Abhay Roy		<contact fullname="Gunter Van De Velde">
	Arrcus, Inc.		<organization>Nokia</organization>
	abhay@arrcus.com		<address>
			<email>gunter.van_de_velde@nokia.com</email>
			</address>
			</contact>
	Venu Venugopal		<contact fullname="Abhay Roy">
	Cisco Systems		<organization>Arrcus, Inc.</organization>
	venuv@cisco.com		<address>
			<email>abhay@arrcus.com</email>
			</address>
			</contact>
	Chaitanya Yadlapalli		<contact fullname="Venu Venugopal">
	AT&T		<organization>Cisco Systems</organization>
	cy098d@att.com		<address>
	]]></artwork>		<email>venuv@cisco.com</email>
			</address>
			</contact>
			<contact fullname="Chaitanya Yadlapalli">
			<organization>AT&amp;T</organization>
			<address>
			<email>cy098d@att.com</email>
			</address>
			</contact>
			</section>
	</section>		</section>
	</middle>		</middle>
	<!-- *****BACK MATTER ***** -->
	<back>		<back>
	<references><name>References</name>		<references><name>References</name>
	<references><name>Normative References</name>		<references><name>Normative References</name>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2328.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4202.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4271.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4760.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5305.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5130.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5130.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5880.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5925.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6793.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6793.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6811.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6119.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7606.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8126.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8205.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8405.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8405.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8654.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8654.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9086.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml"
	/>		/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9552.xml"		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"
	/>		/>
	</references>		</references>
	<references><name>Informational References</name>		<references><name>Informative References</name>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4272.xml"		<!-- Note: Removed references to [RFC7942] and [I-D.psarkar-lsvr-bgp-spf-impl] p
	/>		er authors' note. -->
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4456.xml"
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4593.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4724.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4593.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5286.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4724.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6952.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7911.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7938.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7942.xml"		/>
	/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7938.xml"
			/>
			<!-- draft-ietf-lsvr-applicability-22. IESG State: RFC Ed Queue as of 06/06/25 -
			C529 companion doc. -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsv r-applicability.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsv r-applicability.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.psarkar-
	lsvr-bgp-spf-impl.xml"/>		<!-- [rfced] Some author comments are present in the XML. Please
			confirm that no updates related to these comments are
			outstanding. Note that the comments will be deleted prior to
			publication.
			-->
			<!-- [rfced] Terminology
			1) Throughout the text, the following terminology appears to be used
			inconsistently. Please review these occurrences and let us know
			if/how they may be made consistent.
			BGP Router vs. BGP router
			BGP SPF Router vs. BGP SPF router vs. BGP-SPF router
			BGP SPF Routing Domain vs. BGP SPF routing domain
			BGP-LS Attribute vs. BGP-LS attribute
			[Note: uppercase used in RFC 9552]
			BGP-LS Prefix Attribute vs. BGP-LS Prefix attribute
			BGP-LS-LINK NLRI vs. BGP-LS Link NLRI
			BGP-LS-SPF NLRI vs. BGP-LS-SPF Link NLRI
			[Note: are these terms different or the same?]
			BGP-LS-SPF Node NLRI vs. BGP-LS-SPF NLRI
			[Note: are these terms different or the same?]
			Decision Process vs. decision process
			[Note: uppercase used in RFC 4271]
			Remote Identifier vs. Remote Link Identifier
			[Note: are these terms different or the same?]
			Remote Node NLRI vs. Remote-Node NLRI
			UPDATE message vs. Update message vs. update message
			[Note: should this be "UPDATE message" per RFC 7606?]
			2) FYI - We updated the following terms to reflect the forms on the right
			for consistency. Please let us know of any objections.
			AS Number (TLV 512) -> Autonomous System (TLV 512) (per RFC 9552)
			back-off algorithm -> Back-Off algorithm (per RFC 8405)
			Error Handling -> error handling
			BGP update -> BGP Update
			BGP-LS Link Attributes -> BGP-LS Attributes (1 instance)
			BGP-LS-SPF LINK NLRI -> BGP-LS-SPF Link NLRI
			EoR Marker -> EoR marker (per RFC 4724)
			IGP metric attribute TLV (TLV 1095) -> IGP Metric (TLV 1095) (per RFC 9552)
			local and remote node descriptors -> Local and Remote Node Descriptors
			local node descriptor -> Local Node Descriptor
			local/remote link identifiers -> Local/Remote Link Identifiers XX
			NLRI Link -> Link NLRI
			Node identifiers -> Node Identifiers
			phase 1 -> Phase 1
			Route Reflector -> route reflector (per RFC 4456)
			SAFI BGP-LS-SPF BGP Update -> BGP-LS-SPF SAFI BGP Update
			set 1 -> Step 1
			Ships-in-the-Night -> ships-in-the-night (per other RFCs)
			SPF back-off -> SPF Back-Off (per RFC 8405)
			Treat-as-withdraw -> treat-as-withdraw (per RFC 7606)
			Unequal Cost Multi-Path -> Unequal-Cost Multipath
			Unicast -> unicast
			3) In this document, we see one occurence of "BGP-LS-SPF Attribute TLV",
			and it is not used in any other RFCs. Is this form correct or should it
			perhaps be "BGP-LS-SPF attribute" or other?
			Original:
			The BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined
			to indicate the status of the link with respect to the BGP SPF
			calculation.
			4) In this document, we see one occurence of "BGP-LS Node attribute".
			Should this be "BGP-LS attribute" or other for consistency?
			Original:
			If the BGP-LS Node attribute includes an SPF Status TLV
			(refer to Section 5.2.1.1) indicating the node is
			unreachable, the Node NLRI is ignored and the next lowest
			cost Node NLRI is selected from the CAN-LIST.
			5) Should "local/remote link identifiers" perhaps be "Link
			Local/Remote Identifiers" for consistency?
			Original:
			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
			matching addresses (i.e., router interface addresses must be on the
			same subnet for numbered interfaces and the local/remote link
			identifiers (Section 6.3) must match for unnumbered interfaces).
			Perhaps:
			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
			matching addresses (i.e., router interface addresses must be on the
			same subnet for numbered interfaces, and the Link Local/Remote
			Identifiers (Section 6.3) must match for unnumbered interfaces).
			6) We note inconsistencies with "next hop". How may we update this term
			for consistency?
			Next-Hop vs. Next Hop vs. next-hop vs. next hop
			Some instances in the document:
			BGP Next-Hop
			Current-Node's next-hops
			Local-RIB Next-Hop
			Local-RIB route's next-hops
			MP_REACH_NLRI Next-Hop
			The Next Hop in the MP_REACH_NLRI attribute
			(i.e., next hops)
			the next-hop for...
			Perhaps:
			BGP Next-Hop (per RFC 9552)
			Local-RIB Next-Hop
			MP_REACH_NLRI Next-Hop
			When used in general: lowercase open form and hyphenated
			when preceding a noun (e.g., "The next-hop list is set
			to the internal loopback next hop").
			-->
			<!-- [rfced] Abbreviations
			1) FYI - We have added expansions for the following abbreviations
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			Autonomous System (AS)
			Bidirectional Forwarding Detection (BFD)
			Network Layer Reachability Information (NLRI)
			Unequal-Cost Multipath (UCMP)
			2) We note "LSDB" and "LSNDB". Are these different databases or
			should they be updated for consistency?
			Link-State Database (LSDB) (per RFC 9552)
			Link-State NLRI Database (LSNDB)
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice.
			-->
	</references>		</references>
	</references>		</references>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 281 change blocks.
	777 lines changed or deleted		1357 lines changed or added
This html diff was produced by rfcdiff 1.48.