rfc9815v1.txt   rfc9815.txt 
Internet Engineering Task Force (IETF) K. Patel Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 9815 Arrcus, Inc. Request for Comments: 9815 A. Lindem
Category: Standards Track A. Lindem Category: Standards Track Arrcus, Inc.
ISSN: 2070-1721 LabN Consulting, LLC ISSN: 2070-1721 S. Zandi
S. Zandi
LinkedIn
W. Henderickx W. Henderickx
Nokia Nokia
July 2025 July 2025
BGP Link-State Shortest Path First (SPF) Routing BGP Link State (BGP-LS) Shortest Path First (SPF) Routing
Abstract Abstract
Many Massively Scaled Data Centers (MSDCs) have converged on Many Massively Scaled Data Centers (MSDCs) have converged on
simplified Layer 3 (L3) routing. Furthermore, requirements for simplified Layer 3 (L3) routing. Furthermore, requirements for
operational simplicity have led many of these MSDCs to converge on operational simplicity have led many of these MSDCs to converge on
BGP as their single routing protocol for both fabric routing and Data BGP as their single routing protocol for both fabric routing and Data
Center Interconnect (DCI) routing. This document describes Center Interconnect (DCI) routing. This document describes
extensions to BGP for use with BGP - Link State (BGP-LS) distribution extensions to BGP for use with BGP Link State (BGP-LS) distribution
and the Shortest Path First (SPF) algorithm. In doing this, it and the Shortest Path First (SPF) algorithm. In doing this, it
allows BGP to be efficiently used as both the underlay protocol and allows BGP to be efficiently used as both the underlay protocol and
the overlay protocol in MSDCs. the overlay protocol in MSDCs.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
skipping to change at line 59 skipping to change at line 58
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
1.2. BGP Shortest Path First (SPF) Motivation 1.2. Requirements Language
1.3. Document Overview 1.3. BGP Shortest Path First (SPF) Motivation
1.4. Requirements Language 1.4. Document Overview
2. Base BGP Protocol Relationship 2. Base BGP Protocol Relationship
3. BGP - Link State (BGP-LS) Relationship 3. BGP Link State (BGP-LS) Relationship
4. BGP SPF Peering Models 4. BGP SPF Peering Models
4.1. BGP Single-Hop Peering on Network Node Connections 4.1. BGP Single-Hop Peering on Network Node Connections
4.2. BGP Peering Between Directly Connected Nodes 4.2. BGP Peering Between Directly Connected Nodes
4.3. BGP Peering in Route-Reflector or Controller Topology 4.3. BGP Peering in Route-Reflector or Controller Topology
5. BGP Shortest Path Routing (SPF) Protocol Extensions 5. BGP Shortest Path First (SPF) Routing Protocol Extensions
5.1. BGP-LS Shortest Path Routing (SPF) SAFI 5.1. BGP-LS-SPF SAFI
5.1.1. BGP-LS-SPF NLRI TLVs 5.1.1. BGP-LS-SPF NLRI TLVs
5.1.2. BGP-LS Attribute 5.1.2. BGP-LS Attribute
5.2. Extensions to BGP-LS 5.2. Extensions to BGP-LS
5.2.1. Node NLRI Usage 5.2.1. Node NLRI Usage
5.2.1.1. BGP-LS-SPF Node NLRI Attribute SPF Status TLV 5.2.1.1. BGP-LS-SPF Node NLRI Attribute SPF Status TLV
5.2.2. Link NLRI Usage 5.2.2. Link NLRI Usage
5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV 5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV
5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV 5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV
5.2.3. IPv4/IPv6 Prefix NLRI Usage 5.2.3. IPv4/IPv6 Prefix NLRI Usage
5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV 5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV
skipping to change at line 96 skipping to change at line 95
6.2. Dual-Stack Support 6.2. Dual-Stack Support
6.3. SPF Calculation Based on BGP-LS-SPF NLRI 6.3. SPF Calculation Based on BGP-LS-SPF NLRI
6.4. IPv4/IPv6 Unicast Address Family Interaction 6.4. IPv4/IPv6 Unicast Address Family Interaction
6.5. NLRI Advertisement 6.5. NLRI Advertisement
6.5.1. Link/Prefix Failure Convergence 6.5.1. Link/Prefix Failure Convergence
6.5.2. Node Failure Convergence 6.5.2. Node Failure Convergence
7. Error Handling 7. Error Handling
7.1. Processing of BGP-LS-SPF TLVs 7.1. Processing of BGP-LS-SPF TLVs
7.2. Processing of BGP-LS-SPF NLRIs 7.2. Processing of BGP-LS-SPF NLRIs
7.3. Processing of BGP-LS Attributes 7.3. Processing of BGP-LS Attributes
7.4. BGP-LS-SPF Link State NLRI Database Synchronization 7.4. BGP-LS-SPF Link State Database Synchronization
8. IANA Considerations 8. IANA Considerations
8.1. BGP-LS-SPF Allocation in the SAFI Values Registry 8.1. BGP-LS-SPF Allocation in the SAFI Values Registry
8.2. BGP-LS-SPF Assignments in the BGP-LS NLRI and Attribute 8.2. BGP-LS-SPF Assignments in the BGP-LS NLRI and Attribute
TLVs Registry TLVs Registry
8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status 8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Values
Registry Registry
8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status 8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Values
Registry Registry
8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status 8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Values
Registry Registry
8.6. Assignment in the BGP Error (Notification) Codes Registry 8.6. Assignment in the BGP Error (Notification) Codes Registry
9. Security Considerations 9. Security Considerations
10. Management Considerations 10. Management Considerations
10.1. Configuration 10.1. Configuration
10.2. Link Metric Configuration 10.2. Link Metric Configuration
10.3. Unnumbered Link Configuration 10.3. Unnumbered Link Configuration
10.4. Adjacency End-of-RIB (EOR) Marker Requirement 10.4. Adjacency End-of-RIB (EOR) Marker Requirement
10.5. backoff-config 10.5. backoff-config
10.6. BGP-LS-SPF NLRI Readvertisement Delay 10.6. BGP-LS-SPF NLRI Readvertisement Delay
skipping to change at line 153 skipping to change at line 152
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, These include TCP-based flow-control, no periodic link-state refresh,
and completely incremental Network Layer Reachability Information and completely incremental Network Layer Reachability Information
(NLRI) advertisement. These advantages can reduce the overhead in (NLRI) advertisement. These advantages can reduce the overhead in
MSDCs where there is a high degree of Equal-Cost Multipath (ECMP) MSDCs where there is a high degree of Equal-Cost Multipath (ECMP)
load balancing. Additionally, using an SPF-based computation can load balancing. Additionally, using an SPF-based computation can
support fast convergence and the computation of Loop-Free support fast convergence and the computation of Loop-Free
Alternatives (LFAs). The SPF LFA extensions defined in [RFC5286] can Alternatives (LFAs). The SPF LFA extensions defined in [RFC5286] can
be similarly applied to BGP SPF calculations. However, the details be similarly applied to BGP SPF calculations. However, the details
are a matter of implementation detail and out of scope for this are specific to implementation and are out of scope for this
document. Furthermore, a BGP-based solution lends itself to multiple document. Furthermore, a BGP-based solution lends itself to multiple
peering models including those incorporating route reflectors peering models including those incorporating route reflectors
[RFC4456] or controllers. [RFC4456] or controllers.
1.1. Terminology 1.1. Terminology
This specification reuses terms defined in Section 1.1 of [RFC4271]. This specification reuses terms defined in Section 1.1 of [RFC4271].
Additionally, this document introduces the following terms: Additionally, this document introduces the following terms:
skipping to change at line 179 skipping to change at line 178
BGP-LS-SPF NLRI: The BGP-LS Network Layer Reachability Information BGP-LS-SPF NLRI: The BGP-LS Network Layer Reachability Information
(NLRI) that is being advertised in the BGP-LS-SPF SAFI (NLRI) that is being advertised in the BGP-LS-SPF SAFI
(Section 5.1) and is being used for BGP SPF route computation. (Section 5.1) and is being used for BGP SPF route computation.
Dijkstra Algorithm: An algorithm for computing the shortest path Dijkstra Algorithm: An algorithm for computing the shortest path
from a given node in a graph to every other node in the graph. from a given node in a graph to every other node in the graph.
Prefix NLRI: In the context of BGP SPF, this term refers to the IPv4 Prefix NLRI: In the context of BGP SPF, this term refers to the IPv4
Topology Prefix NLRI and/or the IPv6 Topology Prefix NLRI. Topology Prefix NLRI and/or the IPv6 Topology Prefix NLRI.
1.2. BGP Shortest Path First (SPF) Motivation 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. BGP Shortest Path First (SPF) Motivation
Given that [RFC7938] already describes how BGP could be used as the Given that [RFC7938] already describes how BGP could be used as the
sole routing protocol in an MSDC, one might question the motivation sole routing protocol in an MSDC, one might question the motivation
for defining an alternative BGP deployment model when a mature for defining an alternative BGP deployment model when a mature
solution exists. For both alternatives, BGP offers the operational solution exists. For both alternatives, BGP offers the operational
benefits of a single routing protocol as opposed to the combination benefits of a single routing protocol as opposed to the combination
of IGP for the underlay and BGP as the overlay. However, BGP SPF of an IGP for the underlay and BGP as the overlay. However, BGP SPF
offers some unique advantages above and beyond standard BGP path- offers some unique advantages above and beyond standard BGP path-
vector routing. With BGP SPF, the simple single-hop peering model vector routing. With BGP SPF, the simple single-hop peering model
recommended in Section 5.2.1 of [RFC7938] is augmented with peering recommended in Section 5.2.1 of [RFC7938] is augmented with peering
models requiring fewer BGP sessions. models requiring fewer BGP sessions.
A primary advantage is that all BGP speakers in the BGP SPF routing A primary advantage is that all BGP speakers in the BGP SPF routing
domain have a complete view of the topology. This allows support for domain have a complete view of the topology. This allows support for
ECMP, IP fast-reroute (e.g., Loop-Free Alternatives (LFAs) [RFC5286], ECMP, IP fast-reroute (e.g., Loop-Free Alternatives (LFAs) [RFC5286],
Shared Risk Link Groups (SRLGs) [RFC4202], and other routing Shared Risk Link Groups (SRLGs) [RFC4202], and other routing
enhancements without advertisement of additional BGP paths [RFC7911] enhancements without advertisement of additional BGP paths [RFC7911]
or other extensions. or other extensions.
With the BGP SPF decision process as defined in Section 6, NLRI With the BGP SPF Decision Process as defined in Section 6, NLRI
changes can be disseminated throughout the BGP routing domain much changes can be disseminated throughout the BGP routing domain much
more rapidly. The added advantage of BGP using TCP for reliable more rapidly. The added advantage of BGP using TCP for reliable
transport leverages TCP's inherent flow-control and guaranteed in- transport leverages TCP's inherent flow-control and guaranteed in-
order delivery. order delivery.
Another primary advantage is a potential reduction in NLRI Another primary advantage is a potential reduction in NLRI
advertisement. With standard BGP path-vector routing, a single link advertisement. With standard BGP path-vector routing, a single link
failure may impact 100s or 1000s of prefixes and result in the failure may impact hundreds or thousands of prefixes and result in
withdrawal or readvertisement of the attendant NLRI. With BGP SPF, the withdrawal or readvertisement of the attendant NLRI. With BGP
only the BGP speakers originating the Link NLRI need to withdraw the SPF, only the BGP speakers originating the Link NLRI need to withdraw
corresponding BGP-LS-SPF Link NLRI. Additionally, the changed NLRI the corresponding BGP-LS-SPF Link NLRI. Additionally, the changed
is advertised immediately as opposed to normal BGP where it is only NLRI is advertised immediately as opposed to normal BGP where it is
advertised after the best route selection. These advantages provide only advertised after the best route selection. These advantages
NLRI dissemination throughout the BGP SPF routing domain with provide NLRI dissemination throughout the BGP SPF routing domain with
efficiencies similar to link-state protocols. efficiencies similar to link-state protocols.
With controller and route-reflector peering models, BGP SPF With controller and route-reflector peering models, BGP SPF
advertisement and distributed computation require a minimal number of advertisement and distributed computation require a minimal number of
sessions and copies of the NLRI as only the latest version of the sessions and copies of the NLRI as only the latest version of the
NLRI from the originator is required (see Section 4). Given that NLRI from the originator is required (see Section 4). Given that
verification of whether or not to advertise a link (with a BGP-LS-SPF verification of whether or not to advertise a link (with a BGP-LS-SPF
Link NLRI) is done outside of BGP, each BGP speaker only needs as Link NLRI) is done outside of BGP, each BGP speaker only needs as
many sessions and copies of the NLRI as required for redundancy. many sessions and copies of the NLRI as required for redundancy.
Additionally, a controller could inject topology (i.e., BGP-LS-SPF Additionally, a controller could inject topology (i.e., BGP-LS-SPF
skipping to change at line 238 skipping to change at line 245
Another advantage of BGP SPF is that both IPv6 and IPv4 can be 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 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 NLRIs. In many MSDC fabrics, the IPv4 and IPv6 topologies are
congruent (refer to Section 5.2.2). However, beyond the scope of congruent (refer to Section 5.2.2). However, beyond the scope of
this document, BGP-LS-SPF NLRI multi-topology extensions could be this document, BGP-LS-SPF NLRI multi-topology extensions could be
defined to support separate IPv4, IPv6, unicast, and multicast defined to support separate IPv4, IPv6, unicast, and multicast
topologies while sharing the same NLRI. topologies while sharing the same NLRI.
Finally, the BGP SPF topology can be used as an underlay for other Finally, the BGP SPF topology can be used as an underlay for other
BGP SAFIs (using the existing model) and realize all the above BGP SAFIs (using the existing model) and obtain all the above
advantages. advantages.
1.3. Document Overview 1.4. Document Overview
This document begins with Section 2 defining the precise relationship This document begins with Section 2 defining the precise relationship
that BGP SPF has with the base BGP protocol [RFC4271] and Section 3 that BGP SPF has with the base BGP protocol [RFC4271] and Section 3
defining the BGP - Link State (BGP-LS) extensions [RFC9552]. The BGP defining the BGP Link State (BGP-LS) extensions [RFC9552]. The BGP
peering models as well as their respective trade-offs are then peering models as well as their respective trade-offs are then
discussed in Section 4. The remaining sections, which make up the discussed in Section 4. The remaining sections, which make up the
bulk of the document, define the protocol enhancements necessary to bulk of the document, define the protocol enhancements necessary to
support BGP SPF including BGP-LS extensions (Section 5), replacement support BGP SPF including BGP-LS extensions (Section 5), replacement
of the base BGP decision process with the SPF computation of the base BGP Decision Process with the SPF computation
(Section 6), and BGP SPF error handling (Section 7). (Section 6), and BGP SPF error handling (Section 7).
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Base BGP Protocol Relationship 2. Base BGP Protocol Relationship
With the exception of the decision process, BGP SPF extensions With the exception of the Decision Process, BGP SPF extensions
leverage the BGP protocol [RFC4271] without change. This includes leverage the BGP protocol [RFC4271] without change. This includes
the BGP protocol Finite State Machine, BGP messages and their the BGP protocol Finite State Machine, BGP messages and their
encodings, the processing of BGP messages, BGP attributes and path encodings, the processing of BGP messages, BGP attributes and path
attributes, BGP NLRI encodings, and any error handling defined in attributes, BGP NLRI encodings, and any error handling defined in
[RFC4271], [RFC4760], and [RFC7606]. [RFC4271], [RFC4760], and [RFC7606].
Due to changes in the decision process, there are mechanisms and Due to changes in the Decision Process, there are mechanisms and
encodings that are no longer applicable. Unless explicitly specified encodings that are no longer applicable. Unless explicitly specified
in the context of BGP SPF, all optional path attributes SHOULD NOT be in the context of BGP SPF, all optional path attributes SHOULD NOT be
advertised. If received, all path attributes MUST be accepted, advertised. If received, all path attributes MUST be accepted,
validated, and propagated consistently with the BGP protocol validated, and propagated consistently with the BGP protocol
[RFC4271], even if not needed by BGP SPF. [RFC4271], even if not needed by BGP SPF.
Section 9.1 of [RFC4271] defines the decision process that is used to Section 9.1 of [RFC4271] defines the Decision Process that is used to
select routes for subsequent advertisement by applying the policies select routes for subsequent advertisement by applying the policies
in the local Policy Information Base (PIB) to the routes stored in in the local Policy Information Base (PIB) to the routes stored in
its Adj-RIBs-In. The output of the Decision Process is the set of its Adj-RIBs-In. The output of the Decision Process is the set of
routes that are announced by a BGP speaker to its peers. These routes that is announced by a BGP speaker to its peers. These
selected routes are stored by a BGP speaker in the speaker's Adj- selected routes are stored by a BGP speaker in the speaker's Adj-
RIBs-Out, according to policy. RIBs-Out, according to policy.
The BGP SPF extension fundamentally changes the decision process, as The BGP SPF extension fundamentally changes the Decision Process, as
described herein. Specifically: described herein. Specifically:
1. BGP advertisements are readvertised to neighbors immediately 1. BGP advertisements are readvertised to neighbors immediately
without waiting or dependence on the route computation, as without waiting or dependence on the route computation, as
specified in phase 3 of the base BGP decision process. Multiple specified in phase 3 of the base BGP Decision Process. Multiple
peering models are supported, as specified in Section 4. peering models are supported, as specified in Section 4.
2. Determining the degree of preference for BGP routes for the SPF 2. Determining the degree of preference for BGP routes, as described
calculation as described in phase 1 of the base BGP decision in phase 1 of the base BGP Decision Process, is replaced with the
process is replaced with the mechanisms in Section 6.1. mechanisms in Section 6.1 for the SPF calculation.
3. Phase 2 of the base BGP protocol decision process is replaced 3. Phase 2 of the base BGP protocol Decision Process is replaced
with the SPF algorithm, also known as the Dijkstra algorithm. with the SPF algorithm, also known as the Dijkstra algorithm.
3. BGP - Link State (BGP-LS) Relationship 3. BGP Link State (BGP-LS) Relationship
[RFC9552] describes a mechanism by which link-state and Traffic [RFC9552] describes a mechanism by which link-state and Traffic
Engineering (TE) information can be collected from networks and Engineering (TE) information can be collected from networks and
shared with external entities using BGP. This is achieved by shared with external entities using BGP. This is achieved by
defining NLRIs that are advertised using the BGP-LS AFI. The BGP-LS defining NLRIs that are advertised using the BGP-LS AFI. The BGP-LS
extensions defined in [RFC9552] make use of the decision process extensions defined in [RFC9552] make use of the Decision Process
defined in [RFC4271]. Rather than reusing the BGP-LS SAFI, the BGP- defined in [RFC4271]. Rather than reusing the BGP-LS SAFI, the BGP-
LS-SPF SAFI (Section 5.1) is introduced to ensure backward LS-SPF SAFI (Section 5.1) is introduced to ensure backward
compatibility for BGP-LS SAFI usage. compatibility for BGP-LS SAFI usage.
The "BGP-LS NLRI and Attribute TLVs" registry [RFC9552] is shared The "BGP-LS NLRI and Attribute TLVs" registry [RFC9552] is shared
between the BGP-LS SAFI and the BGP-LS-SPF SAFI. However, the TLVs between the BGP-LS SAFI and the BGP-LS-SPF SAFI. However, the TLVs
defined in this document may not be applicable to the BGP-LS SAFI. defined in this document may not be applicable to the BGP-LS SAFI.
As specified in Section 5.1 of [RFC9552], the presence of unknown or As specified in Section 5.1 of [RFC9552], the presence of unknown or
unexpected TLVs is required so that the NLRI or BGP-LS Attribute will unexpected TLVs is required so that the NLRI or BGP-LS Attribute will
not be considered malformed (Section 5.2 of [RFC9552]). The list of not be considered malformed (Section 5.2 of [RFC9552]). The list of
skipping to change at line 342 skipping to change at line 341
for this document and is discussed in [RFC9816]. The subsections for this document and is discussed in [RFC9816]. The subsections
below describe several BGP SPF deployment models. However, this below describe several BGP SPF deployment models. However, this
doesn't preclude other deployment models. doesn't preclude other deployment models.
4.1. BGP Single-Hop Peering on Network Node Connections 4.1. BGP Single-Hop Peering on Network Node Connections
The simplest peering model is the one where External BGP (EBGP) The simplest peering model is the one where External BGP (EBGP)
single-hop sessions are established over direct point-to-point links single-hop sessions are established over direct point-to-point links
interconnecting the nodes in the BGP SPF routing domain. Once the interconnecting the nodes in the BGP SPF routing domain. Once the
single-hop BGP session has been established and the Multiprotocol single-hop BGP session has been established and the Multiprotocol
Extensions capabilities have been exchanged with the BGP-LS-SPF AFI/ Extensions Capability with the BGP-LS-SPF AFI/SAFI [RFC4760] has been
SAFI [RFC4760] for the corresponding session, then the link is exchanged for the corresponding session, then the link is considered
considered up and available from a BGP SPF perspective, and the up and available from a BGP SPF perspective, and the corresponding
corresponding BGP-LS-SPF Link NLRI is advertised. BGP-LS-SPF Link NLRI is advertised.
An End-of-RIB (EoR) marker (Section 5.3) for the BGP-LS-SPF SAFI MAY An End-of-RIB (EoR) marker (Section 5.3) for the BGP-LS-SPF SAFI MAY
be required from a peer prior to advertising the BGP-LS-SPF Link NLRI be required from a peer prior to advertising the BGP-LS-SPF Link NLRI
for the corresponding link to that peer. When required, the default for the corresponding link to that peer. When required, the default
wait indefinitely for the EoR marker prior to advertising the BGP-LS- is to wait indefinitely for the EoR marker prior to advertising the
SPF Link NLRI. Refer to Section 10.4. BGP-LS-SPF Link NLRI. Refer to Section 10.4.
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.
If the session goes down, the corresponding Link NLRIs are withdrawn. If the session goes down, the corresponding Link NLRIs are withdrawn.
Topologically, this would be equivalent to the peering model in Topologically, this would be equivalent to the peering model in
[RFC7938] where there is a BGP session on every link in the data [RFC7938] where there is a BGP session on every link in the data
center switch fabric. The content of the Link NLRI is described in center switch fabric. The content of the Link NLRI is described in
Section 5.2.2. Section 5.2.2.
skipping to change at line 412 skipping to change at line 411
dependent on the redundancy requirements and the stability of the BGP dependent on the redundancy requirements and the stability of the BGP
sessions. sessions.
The controller may use constraints to determine when to advertise The controller may use constraints to determine when to advertise
BGP-LS-SPF NLRI for BGP-LS peers. For example, a controller may BGP-LS-SPF NLRI for BGP-LS peers. For example, a controller may
delay advertisement of a link between two peers the until the EoR delay advertisement of a link between two peers the until the EoR
marker Section 5.3 has been received from both BGP peers and the BGP- marker Section 5.3 has been received from both BGP peers and the BGP-
LS Link NLRI for the link(s) between the two nodes has been received LS Link NLRI for the link(s) between the two nodes has been received
from both BGP peers. from both BGP peers.
5. BGP Shortest Path Routing (SPF) Protocol Extensions 5. BGP Shortest Path First (SPF) Routing Protocol Extensions
5.1. BGP-LS Shortest Path Routing (SPF) SAFI 5.1. BGP-LS-SPF SAFI
This document introduces the BGP-LS-SPF SAFI with a value of 80. The This document introduces the BGP-LS-SPF SAFI with a value of 80. The
SPF-based decision process (Section 6) applies only to the BGP-LS-SPF SPF-based Decision Process (Section 6) applies only to the BGP-LS-SPF
SAFI and MUST NOT be used with other combinations of the BGP-LS AFI SAFI and MUST NOT be used with other combinations of the BGP-LS AFI
(16388). In order for two BGP speakers to exchange BGP-LS-SPF NLRI, (16388). In order for two BGP speakers to exchange BGP-LS-SPF NLRI,
they MUST exchange Multiprotocol Extensions capabilities [RFC4760] to they MUST exchange the Multiprotocol Extensions Capability [RFC4760]
ensure that they are both capable of properly processing such an 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 is 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 format used to advertise IPv4 and IPv6 prefix information in a format
facilitating an SPF-based decision process. facilitating an SPF-based Decision Process.
5.1.1. BGP-LS-SPF NLRI TLVs 5.1.1. BGP-LS-SPF NLRI TLVs
All the TLVs defined for BGP-LS [RFC9552] are applicable and can be All the TLVs defined for BGP-LS [RFC9552] are applicable and can be
used with the BGP-LS-SPF SAFI to describe links, nodes, and prefixes used with the BGP-LS-SPF SAFI to describe links, nodes, and prefixes
comprising BGP SPF Link State Database (LSDB) information. comprising BGP SPF Link State Database (LSDB) information.
The NLRI and comprising TLVs MUST be encoded as specified in The NLRI and comprising TLVs MUST be encoded as specified in
Section 5.1 of [RFC9552]. TLVs specified as mandatory in [RFC9552] Section 5.1 of [RFC9552]. TLVs specified as mandatory in [RFC9552]
are considered mandatory for the BGP-LS-SPF SAFI as well. If a are 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 BGP mandatory TLV is not present, the NLRI MUST NOT be used in the BGP
SPF route calculation. All the other TLVs are considered as optional SPF route calculation. All the other TLVs are considered as optional
TLVs. Documents specifying usage of optional TLVs for BGP SPF MUST TLVs. Documents specifying usage of optional TLVs for BGP SPF MUST
address backward compatibility. address backward compatibility.
5.1.2. BGP-LS Attribute 5.1.2. BGP-LS Attribute
The BGP-LS attribute of the BGP-LS-SPF SAFI uses the exact same The BGP-LS Attribute of the BGP-LS-SPF SAFI uses the exact same
format as the BGP-LS AFI [RFC9552]. In other words, all the TLVs format as the BGP-LS AFI [RFC9552]. In other words, all the TLVs
used in the BGP-LS attribute of the BGP-LS AFI are applicable and are used in the BGP-LS Attribute of the BGP-LS AFI are applicable and are
used for the BGP-LS attribute of the BGP-LS-SPF SAFI. This attribute used for the BGP-LS Attribute of the BGP-LS-SPF SAFI. This attribute
is an optional, non-transitive BGP attribute that is used to carry is an optional, non-transitive BGP attribute that is used to
link, node, and prefix properties and attributes. The BGP-LS advertise link, node, and prefix properties and attributes. The BGP-
attribute is a set of TLVs. LS Attribute is a set of TLVs.
All the TLVs defined for the BGP-LS Attribute [RFC9552] are All the TLVs defined for the BGP-LS Attribute [RFC9552] are
applicable and can be used with the BGP-LS-SPF SAFI to carry link, applicable and can be used with the BGP-LS-SPF SAFI to advertise
node, and prefix properties and attributes. link, node, and prefix properties and attributes.
The BGP-LS attribute may potentially be quite large depending on the The BGP-LS Attribute may potentially be quite large depending on the
amount of link-state information associated with a single BGP-LS-SPF amount of link-state information associated with a single BGP-LS-SPF
NLRI. The BGP specification [RFC4271] mandates a maximum BGP message NLRI. The BGP specification [RFC4271] mandates a maximum BGP message
size of 4096 octets. It is RECOMMENDED that an implementation size of 4096 octets. It is RECOMMENDED that an implementation
support [RFC8654] in order to accommodate a greater amount of support [RFC8654] in order to accommodate a greater amount of
information within the BGP-LS Attribute. BGP speakers MUST ensure information within the BGP-LS Attribute. BGP speakers MUST ensure
that they limit the TLVs included in the BGP-LS Attribute to ensure that they limit the TLVs included in the BGP-LS Attribute to ensure
that a BGP update message for a single BGP-LS-SPF NLRI does not cross that a BGP UPDATE message for a single BGP-LS-SPF NLRI does not cross
the maximum limit for a BGP message. The determination of the types the maximum limit for a BGP message. The determination of the types
of TLVs to be included by the BGP speaker originating the attribute of TLVs to be included by the BGP speaker originating the attribute
is outside the scope of this document. If, due to the limits on the is outside the scope of this document. If, due to the limits on the
maximum size of an UPDATE message, a single route doesn't fit into maximum size of an UPDATE message, a single route doesn't fit into
the message, the BGP speaker MUST NOT advertise the route to its peer the message, the BGP speaker MUST NOT advertise the route to its peer
and MAY choose to log an error locally [RFC4271]. and MAY choose to log an error locally [RFC4271].
5.2. Extensions to BGP-LS 5.2. Extensions to BGP-LS
[RFC9552] describes a mechanism by which link-state and TE [RFC9552] describes a mechanism by which link-state and TE
information can be collected from IGPs and shared with external information can be collected from IGPs and shared with external
components using the BGP protocol. It describes both the definition components using the BGP protocol. It describes both the definition
of the BGP-LS NLRI that advertise links, nodes, and prefixes of the BGP-LS NLRI that advertise links, nodes, and prefixes
comprising IGP link-state information and the definition of a BGP comprising IGP link-state information and the definition of a BGP
path attribute (BGP-LS attribute) that carries link, node, and prefix path attribute (BGP-LS Attribute) that carries link, node, and prefix
properties and attributes, such as the link and prefix metric or properties and attributes, such as the link and prefix metric or
auxiliary Router-IDs of nodes, etc. This document extends the usage auxiliary Router-IDs of nodes, etc. This document extends the usage
of BGP-LS NLRI for the purpose of BGP SPF calculation via of BGP-LS NLRI for the purpose of BGP SPF calculation via
advertisement in the BGP-LS-SPF SAFI. advertisement in the BGP-LS-SPF SAFI.
The protocol identifier specified in the Protocol-ID field [RFC9552] The protocol identifier specified in the Protocol-ID field [RFC9552]
represents the origin of the advertised NLRI. For Node NLRI and Link represents the origin of the advertised NLRI. For Node NLRI and Link
NLRI, the specified Protocol-ID MUST be the direct protocol (4). NLRI, the specified Protocol-ID MUST be the direct protocol (4).
Node or Link NLRI with a Protocol-ID other than the direct protocol Node or Link NLRI with a Protocol-ID other than the direct protocol
is considered malformed. For Prefix NLRI, the specified Protocol-ID is considered malformed. For Prefix NLRI, the specified Protocol-ID
skipping to change at line 531 skipping to change at line 530
+-------+-------------------------------------------------------+ +-------+-------------------------------------------------------+
| 1 | Node unreachable with respect to BGP SPF | | 1 | Node unreachable with respect to BGP SPF |
+-------+-------------------------------------------------------+ +-------+-------------------------------------------------------+
| 2 | Node does not support transit with respect to BGP SPF | | 2 | Node does not support transit with respect to BGP SPF |
+-------+-------------------------------------------------------+ +-------+-------------------------------------------------------+
| 3-254 | Unassigned | | 3-254 | Unassigned |
+-------+-------------------------------------------------------+ +-------+-------------------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+-------------------------------------------------------+ +-------+-------------------------------------------------------+
Table 1: SPF Status Values Table 1: Node NLRI Attribute Status Values
If a BGP speaker received the Node NLRI but the SPF Status TLV is not If a BGP speaker received the Node NLRI but the SPF Status TLV is not
received, then any previously received SPF status information is received, then any previously received SPF status information is
considered as implicitly withdrawn, and the NLRI is propagated to considered as implicitly withdrawn, and the NLRI is propagated to
other BGP speakers. A BGP speaker receiving a BGP Update containing other BGP speakers. A BGP speaker receiving a BGP Update containing
an SPF Status TLV in the BGP-LS attribute [RFC9552] with an unknown an SPF Status TLV in the BGP-LS Attribute [RFC9552] with an unknown
value SHOULD be advertised to other BGP speakers and MUST ignore the value SHOULD be advertised to other BGP speakers and MUST ignore the
Status TLV with an unknown value in the SPF computation. An Status TLV with an unknown value in the SPF computation. An
implementation MAY log this condition for further analysis. If the implementation MAY log this condition for further analysis. If the
SPF Status TLV contains a reserved value (0 or 255), the TLV is SPF Status TLV contains a reserved value (0 or 255), the TLV is
considered malformed and is handled as described in Section 7.1. considered malformed and is handled as described in Section 7.1.
5.2.2. Link NLRI Usage 5.2.2. Link NLRI Usage
The criteria for advertisement of Link NLRIs are discussed in The criteria for advertisement of Link NLRIs are discussed in
Section 4. Section 4.
skipping to change at line 579 skipping to change at line 578
presence of parallel unnumbered links. presence of parallel unnumbered links.
The link descriptors are described in Table 4 of [RFC9552]. The link descriptors are described in Table 4 of [RFC9552].
Additionally, the Address Family (AF) Link Descriptor TLV is defined Additionally, the Address Family (AF) Link Descriptor TLV is defined
to determine whether an unnumbered link can be used in the IPv4 SPF, to determine whether an unnumbered link can be used in the IPv4 SPF,
the IPv6, or both (refer to Section 5.2.2.1). the IPv6, or both (refer to Section 5.2.2.1).
For a link to be used in SPF computation for a given address family, For a link to be used in SPF computation for a given address family,
i.e., IPv4 or IPv6, both routers connecting the link MUST have i.e., IPv4 or IPv6, both routers connecting the link MUST have
matching addresses (i.e., router interface addresses must be on the matching addresses (i.e., router interface addresses must be on the
same subnet for numbered interfaces, and the local/remote link same subnet for numbered interfaces, or the Link Local/Remote
identifiers (Section 6.3) must match for unnumbered interfaces). Identifiers (Section 6.3) must match for unnumbered interfaces).
The IGP Metric (TLV 1095) MUST be advertised. If a BGP speaker The IGP Metric (TLV 1095) MUST be advertised. If a BGP speaker
receives a Link NLRI without an IGP Metric attribute TLV, then it receives a Link NLRI without an IGP Metric attribute TLV, then it
MUST consider the received NLRI as malformed (refer to Section 7). MUST consider the received NLRI as malformed and is handled as
The BGP SPF metric length is 4 octets. A metric is associated with described in Section 7.1. The BGP SPF metric length is 4 octets. A
the output side of each router interface. This metric is metric is associated with the output side of each router interface.
configurable by the system administrator. The lower the metric, the This metric is configurable by the system administrator. The lower
more likely the interface is to be used to forward data traffic. One the metric, the more likely the interface is to be used to forward
possible default for the metric would be to give each interface a data traffic. One possible default for the metric would be to give
metric of 1 making it effectively a hop count. each interface a metric of 1 making the SPF metric effectively a hop
count.
The usage of other link attribute TLVs is beyond the scope of this The usage of other link attribute TLVs is beyond the scope of this
document. document.
5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV 5.2.2.1. BGP-LS Link NLRI Address Family Link Descriptor TLV
For unnumbered links, the address family cannot be ascertained from For unnumbered links, the address family cannot be ascertained from
the endpoint link descriptors. Hence, the Address Family Link the endpoint link descriptors. Hence, the Address Family Link
Descriptor SHOULD be included with the Link Local/Remote Identifiers Descriptor TLV SHOULD be included with the Link Local/Remote
TLV for unnumbered links, so that the link can be used in the Identifiers TLV for unnumbered links, so that the link can be used in
respective address family SPF. If the Address Family Link Descriptor the respective address family SPF. If the Address Family Link
is not present for an unnumbered link, the link will not be used in Descriptor TLV is not present for an unnumbered link, the link will
the SPF computation for either address family. If the Address Family not be used in the SPF computation for either address family. If the
Link Descriptor is present for a numbered link, the link descriptor Address Family Link Descriptor TLV is present for a numbered link,
will be ignored. If the Address Family Link Descriptor TLV contains the link descriptor will be ignored. If the Address Family Link
an undefined value (3-254), the link descriptor will be ignored. If Descriptor TLV contains an undefined value (3-254), the link
the Address Family Link Descriptor TLV contains a reserved value (0 descriptor will be ignored. If the Address Family Link Descriptor
or 255), the TLV is considered malformed and is handled as described TLV contains a reserved value (0 or 255), the TLV is considered
in Section 7.1. malformed and is handled as described in Section 7.1.
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 SPF computation by advertising separate Address Family Link
Descriptor TLVs for IPv4 and IPv6. Descriptor TLVs for IPv4 and IPv6.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 641 skipping to change at line 641
+-------+---------------------+ +-------+---------------------+
| 3-254 | Undefined | | 3-254 | Undefined |
+-------+---------------------+ +-------+---------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+---------------------+ +-------+---------------------+
Table 2: Address Family Values Table 2: Address Family Values
5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV 5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV
The BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined The BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Link NLRI is
to indicate the status of the link with respect to the BGP SPF defined to indicate the status of the link with respect to the BGP
calculation. This is used to expedite convergence for link failures SPF calculation. This is used to expedite convergence for link
as discussed in Section 6.5.1. If the SPF Status TLV is not included failures as discussed in Section 6.5.1. If the SPF Status TLV is not
with the Link NLRI, the link is considered up and available. The SPF included with the Link NLRI, the link is considered up and available.
status is acted upon with the execution of the next SPF calculation The SPF status is acted upon with the execution of the next SPF
(Section 6.3). A single TLV type is shared by the Node, Link, and calculation (Section 6.3). A single TLV type is shared by the Node,
Prefix NLRI. The TLV type is 1184. Link, and Prefix NLRI. The TLV type is 1184.
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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+=======+==========================================+ +=======+==========================================+
skipping to change at line 670 skipping to change at line 670
+=======+==========================================+ +=======+==========================================+
| 0 | Reserved | | 0 | Reserved |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 1 | Link unreachable with respect to BGP SPF | | 1 | Link unreachable with respect to BGP SPF |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 2-254 | Unassigned | | 2-254 | Unassigned |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+------------------------------------------+ +-------+------------------------------------------+
Table 3: BGP Status Values Table 3: Link NLRI Attribute Status Values
If a BGP speaker received the Link NLRI but the SPF Status TLV is not If a BGP speaker received the Link NLRI but the SPF Status TLV is not
received, then any previously received SPF status information is received, then any previously received SPF status information is
considered as implicitly withdrawn, and the NLRI is propagated to considered as implicitly withdrawn, and the NLRI is propagated to
other BGP speakers. A BGP speaker receiving a BGP Update containing other BGP speakers. A BGP speaker receiving a BGP Update containing
an SPF Status TLV in the BGP-LS attribute [RFC9552] with an unknown an SPF Status TLV in the BGP-LS Attribute [RFC9552] with an unknown
value SHOULD be advertised to other BGP speakers and MUST ignore the value SHOULD be advertised to other BGP speakers and MUST ignore the
SPF Status TLV with an unknown value in the SPF computation. An SPF Status TLV with an unknown value in the SPF computation. An
implementation MAY log this information for further analysis. If the implementation MAY log this information for further analysis. If the
SPF Status TLV contains a reserved value (0 or 255), the TLV is SPF Status TLV contains a reserved value (0 or 255), the TLV is
considered malformed and is handled as described in Section 7.1. considered malformed and is handled as described in Section 7.1.
5.2.3. IPv4/IPv6 Prefix NLRI Usage 5.2.3. IPv4/IPv6 Prefix NLRI Usage
An IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor An IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor
and the prefix and length. The Prefix Descriptor field includes IP and the prefix and length. The Prefix Descriptor field includes IP
Reachability Information (TLV 265) as described in [RFC9552]. The Reachability Information (TLV 265) as described in [RFC9552]. The
Prefix Metric (TLV 1155) MUST be advertised to be considered for Prefix Metric (TLV 1155) MUST be advertised to be considered for
route calculation. The IGP Route Tag (TLV 1153) MAY be advertised. route calculation. The IGP Route Tag (TLV 1153) MAY be advertised.
The usage of other BGP-LS attribute TLVs is beyond the scope of this The usage of other BGP-LS Attribute TLVs is beyond the scope of this
document. document.
5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV 5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV
A BGP-LS Attribute SPF Status TLV of the BGP-LS-SPF Prefix NLRI is 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 defined to indicate the status of the prefix with respect to the BGP
SPF calculation. This is used to expedite convergence for prefix SPF calculation. This is used to expedite convergence for prefix
unreachability, as discussed in Section 6.5.1. If the SPF Status TLV unreachability, as discussed in Section 6.5.1. If the SPF Status TLV
is not included with the Prefix NLRI, the prefix is considered is not included with the Prefix NLRI, the prefix is considered
reachable. A single TLV type is shared by the Node, Link, and Prefix reachable. A single TLV type is shared by the Node, Link, and Prefix
skipping to change at line 723 skipping to change at line 723
+=======+============================================+ +=======+============================================+
| 0 | Reserved | | 0 | Reserved |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 1 | Prefix unreachable with respect to BGP SPF | | 1 | Prefix unreachable with respect to BGP SPF |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 2-254 | Unassigned | | 2-254 | Unassigned |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
Table 4: BGP Status Values Table 4: Prefix NLRI Attribute Status Values
If a BGP speaker received the Prefix NLRI but the SPF Status TLV is If a BGP speaker received the Prefix NLRI but the SPF Status TLV is
not received, then any previously received SPF status information is not received, then any previously received SPF status information is
considered as implicitly withdrawn, and the NLRI is propagated to considered as implicitly withdrawn, and the NLRI is propagated to
other BGP speakers. A BGP speaker receiving a BGP Update containing other BGP speakers. A BGP speaker receiving a BGP Update containing
an SPF Status TLV in the BGP-LS attribute [RFC9552] with an unknown an SPF Status TLV in the BGP-LS Attribute [RFC9552] with an unknown
value SHOULD be advertised to other BGP speakers and MUST ignore the value SHOULD be advertised to other BGP speakers and MUST ignore the
Status TLV with an unknown value in the SPF computation. An Status TLV with an unknown value in the SPF computation. An
implementation MAY log this information for further analysis. If the implementation MAY log this information for further analysis. If the
SPF Status TLV contains a reserved value (0 or 255), the TLV is SPF Status TLV contains a reserved value (0 or 255), the TLV is
considered malformed and is handled as described in Section 7.1. considered malformed and is handled as described in Section 7.1.
5.2.4. BGP-LS Attribute Sequence Number TLV 5.2.4. BGP-LS Attribute Sequence Number TLV
A BGP-LS Attribute Sequence Number TLV of the BGP-LS-SPF NLRI types A BGP-LS Attribute Sequence Number TLV of the BGP-LS-SPF NLRI types
is defined to assure the most recent version of a given NLRI is used is defined to assure the most recent version of a given NLRI is used
skipping to change at line 776 skipping to change at line 776
When incrementing the sequence number for each self-originated NLRI, When incrementing the sequence number for each self-originated NLRI,
the sequence number should be treated as an unsigned 64-bit value. the sequence number should be treated as an unsigned 64-bit value.
If the lower-order 32-bit value wraps, the higher-order 32-bit value If the lower-order 32-bit value wraps, the higher-order 32-bit value
should be incremented and saved in non-volatile storage. If a BGP should be incremented and saved in non-volatile storage. If a BGP
speaker completely loses its sequence number state (e.g., the BGP speaker completely loses its sequence number state (e.g., the BGP
speaker hardware is replaced or experiences a cold start), the BGP speaker hardware is replaced or experiences a cold start), the BGP
NLRI selection rules (see Section 6.1) ensure convergence, albeit not NLRI selection rules (see Section 6.1) ensure convergence, albeit not
immediately. immediately.
If the Sequence Number TLV is not received, then the corresponding If the Sequence Number TLV is not received, then the corresponding
NLRI is considered as malformed and MUST be handled as 'treat-as- NLRI is considered as malformed and MUST be handled as described in
withdraw'. An implementation SHOULD log an error for further Section 7.1. An implementation SHOULD log an error for further
analysis. analysis.
5.3. BGP-LS-SPF End of RIB (EoR) Marker 5.3. BGP-LS-SPF End of RIB (EoR) Marker
The usage of the EoR marker [RFC4724] with the BGP-LS-SPF SAFI is The usage of the EoR marker [RFC4724] with the BGP-LS-SPF SAFI is
somewhat different than the other BGP SAFIs. Reception of the EoR somewhat different than the other BGP SAFIs. Reception of the EoR
marker MAY optionally be expected prior to advertising a Link NLRI marker MAY optionally be expected prior to advertising a Link NLRI
for a given peer. for a given peer.
5.4. BGP Next-Hop Information 5.4. BGP Next-Hop Information
skipping to change at line 846 skipping to change at line 846
The Phase 3 decision function of the Decision Process [RFC4271] is The Phase 3 decision function of the Decision Process [RFC4271] is
also simplified because under normal SPF operation, a BGP speaker also simplified because under normal SPF operation, a BGP speaker
MUST advertise the changed NLRIs to all BGP peers with the BGP-LS-SPF MUST advertise the changed NLRIs to all BGP peers with the BGP-LS-SPF
AFI/SAFI and install the changed routes in the GLOBAL-RIB. The only AFI/SAFI and install the changed routes in the GLOBAL-RIB. The only
exceptions are unchanged NLRIs or stale NLRIs, i.e., an NLRI received exceptions are unchanged NLRIs or stale NLRIs, i.e., an NLRI received
with a less recent (numerically smaller) sequence number. with a less recent (numerically smaller) sequence number.
6.1. BGP SPF NLRI Selection 6.1. BGP SPF NLRI Selection
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 (see Section 9.1.1 of [RFC4271]) no longer apply. Decision Process (see Section 9.1.1 of [RFC4271]) no longer apply.
1. NLRIs self-originated from directly connected BGP SPF peers are 1. NLRIs self-originated from directly connected BGP SPF peers are
preferred. This condition can be determined by comparing the BGP preferred. This condition can be determined by comparing the BGP
Identifiers in the received Local Node Descriptor and the BGP Identifiers in the received Local Node Descriptor and the BGP
OPEN message for an active BGP session. This rule assures that a OPEN message for an active BGP session. This rule assures that a
stale NLRI is updated even if a BGP SPF router loses its sequence stale NLRI is updated even if a BGP SPF router loses its sequence
number state due to a cold start. Note that once the BGP session number state due to a cold start. Note that once the BGP session
goes down, the NLRI received is no longer considered as being goes down, the NLRI received is no longer considered as being
from a directly connected BGP SPF peer. from a directly connected BGP SPF peer.
skipping to change at line 884 skipping to change at line 884
with its peers, any existing sessions are taken down and stale NLRIs with its peers, any existing sessions are taken down and stale NLRIs
are replaced. The adjacent BGP speakers update their NLRI are replaced. The adjacent BGP speakers update their NLRI
advertisements and advertise to their neighbors until the BGP routing advertisements and advertise to their neighbors until the BGP routing
domain has converged. domain has converged.
The modified SPF Decision Process performs an SPF calculation rooted The modified SPF Decision Process performs an SPF calculation rooted
at the local BGP speaker using the metrics from the Link Attribute at the local BGP speaker using the metrics from the Link Attribute
IGP Metric (TLV 1095) and the Prefix Attribute Prefix Metric (TLV IGP Metric (TLV 1095) and the Prefix Attribute Prefix Metric (TLV
1155) [RFC9552]. These metrics are considered consistently across 1155) [RFC9552]. These metrics are considered consistently across
the BGP SPF domain. As a result, any other BGP attributes that would the BGP SPF domain. As a result, any other BGP attributes that would
influence the BGP decision process defined in [RFC4271] including influence the BGP Decision Process defined in [RFC4271] including
ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the
SPF algorithm. The Next Hop in the MP_REACH_NLRI attribute [RFC4760] SPF algorithm. The Next Hop in the MP_REACH_NLRI attribute [RFC4760]
is discussed in Section 5.4. The AS_PATH and AS4_PATH attributes is discussed in Section 5.4. The AS_PATH and AS4_PATH attributes
[RFC6793] are preserved and used for loop detection [RFC4271]. They [RFC6793] are preserved and used for loop detection [RFC4271]. They
are ignored during the SPF computation for BGP-LS-SPF NLRIs. are ignored during the SPF computation for BGP-LS-SPF NLRIs.
6.1.1. BGP Self-Originated NLRI 6.1.1. BGP Self-Originated NLRI
Nodes, Links, or Prefix NLRIs with Node Descriptors matching the Nodes, Links, or Prefix NLRIs with Node Descriptors matching the
local BGP speaker are considered self-originated. When a self- local BGP speaker are considered self-originated. When a self-
skipping to change at line 923 skipping to change at line 923
instance is considered to be a stale instance that was advertised by instance is considered to be a stale instance that was advertised by
the local node prior to a restart where the NLRI state was lost. the local node prior to a restart where the NLRI state was lost.
However, if subsequent newer self-originated NLRI is received for the However, if subsequent newer self-originated NLRI is received for the
same Node, Link, or Prefix NLRI, the readvertisement or withdrawal is same Node, Link, or Prefix NLRI, the readvertisement or withdrawal is
delayed by BGP_LS_SPF_SELF_READVERTISEMENT_DELAY (default 5) seconds delayed by BGP_LS_SPF_SELF_READVERTISEMENT_DELAY (default 5) seconds
since it is likely being advertised by a misconfigured or rogue BGP since it is likely being advertised by a misconfigured or rogue BGP
speaker (refer to Section 9). speaker (refer to Section 9).
6.2. Dual-Stack Support 6.2. Dual-Stack Support
The SPF-based decision process operates on Node, Link, and Prefix The SPF-based Decision Process operates on Node, Link, and Prefix
NLRIs that support both IPv4 and IPv6 addresses. Whether to run a NLRIs that support both IPv4 and IPv6 addresses. Whether to run a
single SPF computation or multiple SPF computations for separate AFs single SPF computation or multiple SPF computations for separate AFs
is an implementation and/or policy matter. Normally, IPv4 next-hops is an implementation and/or policy matter. Normally, IPv4 next-hops
are calculated for IPv4 prefixes, and IPv6 next-hops are calculated are calculated for IPv4 prefixes, and IPv6 next-hops are calculated
for IPv6 prefixes. for IPv6 prefixes.
6.3. SPF Calculation Based on BGP-LS-SPF NLRI 6.3. SPF Calculation Based on BGP-LS-SPF NLRI
This section details the BGP-LS-SPF local Routing Information Base This section details the BGP-LS-SPF local Routing Information Base
(RIB) calculation. The router uses BGP-LS-SPF Node, Link, and Prefix (RIB) calculation. The router uses BGP-LS-SPF Node, Link, and Prefix
skipping to change at line 946 skipping to change at line 946
routing domain. A router calculates the shortest-path tree using routing domain. A router calculates the shortest-path tree using
itself as the root. Optimizations to the BGP-LS-SPF algorithm are itself as the root. Optimizations to the BGP-LS-SPF algorithm are
possible but MUST yield the same set of routes. The algorithm below possible but MUST yield the same set of routes. The algorithm below
supports ECMP routes. Weighted Unequal-Cost Multipath (UCMP) routes supports ECMP routes. Weighted Unequal-Cost Multipath (UCMP) routes
are out of scope. are out of scope.
The following abstract data structures are defined in order to The following abstract data structures are defined in order to
specify the algorithm. specify the algorithm.
Local Route Information Base (Local-RIB): A routing table that Local Route Information Base (Local-RIB): A routing table that
contains reachability information (i.e., next hops) for all contains reachability information (i.e., next-hops) for all
prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node
reachability. Implementations may choose to implement this with reachability. Implementations may choose to implement this with
separate RIBs for each address family and/or Prefix versus Node separate RIBs for each address family and/or separate RIBs for
reachability. prefix and node reachability.
Global Routing Information Base (GLOBAL-RIB): The RIB containing the Global Routing Information Base (GLOBAL-RIB): The RIB containing the
current routes that are installed in the router's forwarding current routes that are installed in the router's forwarding
plane. This is commonly referred to in networking parlance as plane. This is commonly referred to in networking parlance as
"the RIB". "the RIB".
Link State NLRI Database (LSNDB): A database of BGP-LS-SPF NLRIs Link State Database (LSDB): A database of BGP-LS-SPF NLRIs that
that facilitate access to all Node, Link, and Prefix NLRIs. facilitate access to all Node, Link, and Prefix NLRIs.
Candidate List (CAN-LIST): A list of candidate Node NLRIs used Candidate List (CAN-LIST): A list of candidate Node NLRIs used
during the BGP SPF calculation. The list is sorted by the cost to during the BGP SPF calculation. The list is sorted by the cost to
reach the Node NLRI, with the Node NLRI that has the lowest reach the Node NLRI, with the Node NLRI that has the lowest
reachability cost at the head of the list. This facilitates the reachability cost at the head of the list. This facilitates the
execution of the Dijkstra algorithm, where the shortest paths execution of the Dijkstra algorithm, where the shortest paths
between the local node and other nodes in the graph are computed. between the local node and other nodes in the graph are computed.
The CAN-LIST is typically implemented as a heap but other data The CAN-LIST is typically implemented as a heap but other data
structures have been used. structures have been used.
skipping to change at line 985 skipping to change at line 985
made to the GLOBAL-RIB in Step 6. These routes are referred to made to the GLOBAL-RIB in Step 6. These routes are referred to
as "stale routes". as "stale routes".
2. The cost of the Local-RIB Node route entry for the computing 2. 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 router is set to 0. The computing router's Node NLRI is added to
the CAN-LIST (which was previously initialized to be empty in the CAN-LIST (which was previously initialized to be empty in
Step 1). The next-hop list is set to the internal loopback next- Step 1). The next-hop list is set to the internal loopback next-
hop. hop.
3. The Node NLRI with the lowest cost is removed from the CAN-LIST 3. The Node NLRI with the lowest cost is removed from the CAN-LIST
for processing. If the BGP-LS Node attribute includes an SPF for processing. If the BGP-LS Attribute includes an SPF Status
Status TLV (refer to Section 5.2.1.1) indicating the node is TLV (refer to Section 5.2.1.1) indicating the node is
unreachable, the Node NLRI is ignored and the next lowest-cost unreachable, the Node NLRI is ignored and the next lowest-cost
Node NLRI is selected from the CAN-LIST. The Node corresponding Node NLRI is selected from the CAN-LIST. The Node corresponding
to this NLRI is referred to as the "Current-Node". If the CAN- to this NLRI is referred to as the "Current-Node". If the CAN-
LIST list is empty, the SPF calculation has completed and the LIST list is empty, the SPF calculation has completed and the
algorithm proceeds to Step 6. algorithm proceeds to Step 6.
4. All the Prefix NLRIs with the same Local Node Descriptors as the 4. All the Prefix NLRIs with the same Local Node Descriptors as the
Current-Node are considered for installation. The next-hop(s) Current-Node are considered for installation. The next-hop(s)
for these Prefix NLRIs are inherited from the Current-Node. If for these Prefix NLRIs are inherited from the Current-Node. If
the Current-Node is for the local BGP Router, the next-hop for 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 the prefix is a direct next-hop. The cost for each prefix is the
metric advertised in the Prefix Attribute Prefix Metric (TLV metric advertised in the Prefix Attribute Prefix Metric (TLV
1155) added to the cost to reach the Current-Node. The following 1155) added to the cost to reach the Current-Node. The following
is done for each Prefix NLRI (referred to as the "Current- is done for each Prefix NLRI (referred to as the "Current-
Prefix"): Prefix"):
* If the BGP-LS Prefix attribute includes an SPF Status TLV * If the BGP-LS Prefix Attribute includes an SPF Status TLV
indicating the prefix is unreachable, the Current-Prefix is indicating the prefix is unreachable, the Current-Prefix is
considered unreachable, and the next Prefix NLRI is examined considered unreachable, and the next Prefix NLRI is examined
in Step 4. in Step 4.
* If the Current-Prefix's corresponding prefix is in the Local- * If the Current-Prefix's corresponding prefix is in the Local-
RIB and the Local-RIB metric is less than the Current-Prefix's RIB and the Local-RIB metric is less than the Current-Prefix's
metric, the Current-Prefix does not contribute to the route, metric, the Current-Prefix does not contribute to the route,
and the next Prefix NLRI is examined in Step 4. and the next Prefix NLRI is examined in Step 4.
* If the Current-Prefix's corresponding prefix is not in the * If the Current-Prefix's corresponding prefix is not in the
Local-RIB, the prefix is installed with the Current-Node's Local-RIB, the prefix is installed with the Current-Node's
next-hops installed as the Local-RIB route's next-hops and the next-hops installed as the Local-RIB route's next-hops. The
metric being updated. If the IGP Route Tag (TLV 1153) is Local-RIB route metric is set to the sum of the cost for
included in the Current-Prefix's NLRI Attribute, the tag(s) is Current-Node and the Current-Prefix's metric. If the IGP
installed in the current Local-RIB route's tag(s). Route Tag (TLV 1153) is included in the Current-Prefix's NLRI
Attribute, the tag(s) is installed in the current Local-RIB
route's tag(s).
* If the Current-Prefix's corresponding prefix is in the Local- * If the Current-Prefix's corresponding prefix is in the Local-
RIB and the cost is less than the Local-RIB route's metric, RIB and the cost is less than the Local-RIB route's metric,
the prefix is installed with the Current-Node's next-hops, the prefix is installed with the Current-Node's next-hops,
which replace the Local-RIB route's next-hops and the metric which replace the Local-RIB route's next-hops and the metric
being updated, and any route tags are removed. If the IGP being updated, and any route tags are removed. If the IGP
Route Tag (TLV 1153) is included in the Current-Prefix's NLRI Route Tag (TLV 1153) is included in the Current-Prefix's NLRI
Attribute, the tag(s) is installed in the current Local-RIB Attribute, the tag(s) is installed in the current Local-RIB
route's tag(s). route's tag(s).
skipping to change at line 1044 skipping to change at line 1046
number of ECMP routes that can be supported. The setting or number of ECMP routes that can be supported. The setting or
identification of any limitations is outside the scope if this identification of any limitations is outside the scope if this
document. Weighted UCMP routes are out of scope as well. document. Weighted UCMP routes are out of scope as well.
5. All the Link NLRIs with the same Node Identifiers as the Current- 5. All the Link NLRIs with the same Node Identifiers as the Current-
Node are considered for installation. Each link is examined and Node are considered for installation. Each link is examined and
referred to as the "Current-Link" in the following text. The referred to as the "Current-Link" in the following text. The
cost of the Current-Link is the advertised IGP Metric (TLV 1095) cost of the Current-Link is the advertised IGP Metric (TLV 1095)
from the Link NLRI BGP-LS attribute added to the cost to reach from the Link NLRI BGP-LS attribute added to the cost to reach
the Current-Node. If the Current-Node is for the local BGP the Current-Node. If the Current-Node is for the local BGP
Router, the next-hop for the link is a direct next-hop pointing router, the next-hop for the link is a direct next-hop pointing
to the corresponding local interface. For any other Current- to the corresponding local interface. For any other Current-
Node, the next-hop(s) for the Current-Link is inherited from the Node, the next-hop(s) for the Current-Link is inherited from the
Current-Node. The following is done for each link: Current-Node. The following is done for each link:
a. If the Current-Link's NLRI attribute includes an SPF Status a. If the Current-Link's NLRI attribute includes an SPF Status
TLV indicating the link is down, the BGP-LS-SPF Link NLRI is TLV indicating the link is down, the BGP-LS-SPF Link NLRI is
considered down, and the next link for the Current-Node is considered down, and the next link for the Current-Node is
examined in Step 5. examined in Step 5.
b. If the Current-Node NLRI attributes include the SPF Status b. If the Current-Node NLRI attributes include the SPF Status
skipping to change at line 1158 skipping to change at line 1160
6.4. IPv4/IPv6 Unicast Address Family Interaction 6.4. IPv4/IPv6 Unicast Address Family Interaction
While the BGP-LS-SPF address family and the BGP unicast address While the BGP-LS-SPF address family and the BGP unicast address
families may install routes into the routing tables of the same families may install routes into the routing tables of the same
device, they operate independently (i.e., "ships-in-the-night" mode). device, they operate independently (i.e., "ships-in-the-night" mode).
There is no implicit route redistribution between the BGP-LS-SPF There is no implicit route redistribution between the BGP-LS-SPF
address family and the BGP unicast address families. address family and the BGP unicast address families.
It is RECOMMENDED that BGP-LS-SPF IPv4/IPv6 route computation and It is RECOMMENDED that BGP-LS-SPF IPv4/IPv6 route computation and
installation be given scheduling priority by default over other BGP installation be given scheduling priority by default over other BGP
address families as these address families are considered as underlay address families as the BGP-LS-SPF SAFI is considered an underlay
SAFIs. SAFI.
6.5. NLRI Advertisement 6.5. NLRI Advertisement
6.5.1. Link/Prefix Failure Convergence 6.5.1. Link/Prefix Failure Convergence
A local failure prevents a link from being used in the SPF A local failure prevents a link from being used in the SPF
calculation due to the IGP bidirectional connectivity requirement. calculation due to the IGP bidirectional connectivity requirement.
Consequently, local link failures SHOULD always be communicated as Consequently, local link failures SHOULD always be communicated as
quickly as possible and given priority over other categories of quickly as possible and given priority over other categories of
changes to ensure expeditious propagation and optimal convergence. changes to ensure expeditious propagation and optimal convergence.
According to standard BGP procedures, the link would continue to be According to standard BGP procedures, the link would continue to be
used until the last copy of the BGP-LS-SPF Link NLRI is withdrawn. used until the last copy of the BGP-LS-SPF Link NLRI is withdrawn.
In order to avoid this delay, the originator of the Link NLRI SHOULD In order to avoid this delay, the originator of the Link NLRI SHOULD
advertise a more recent version with an increased Sequence Number TLV advertise a more recent version with an increased Sequence Number TLV
for the BGP-LS-SPF Link NLRI including the SPF Status TLV (refer to for the BGP-LS-SPF Link NLRI including the SPF Status TLV (refer to
Section 5.2.2.2) indicating the link is down with respect to BGP SPF. Section 5.2.2.2) indicating the link is down with respect to BGP SPF.
The configurable LinkStatusDownAdvertise timer controls the interval The configurable LinkStatusDownAdvertise timer controls the interval
that the BGP-LS-LINK NLRI is advertised with SPF Status indicating that the BGP-LS-SPF Link NLRI is advertised with SPF Status
the link is down prior to withdrawal. If a BGP-LS-SPF Link NLRI has indicating the link is down prior to withdrawal. If the BGP-LS-SPF
been advertised with the SPF Status TLV and the link becomes Link NLRI is advertised with the SPF Status TLV included in the BGP-
available in that period, the originator of the BGP-LS-SPF Link NLRI LS Attribute, and the link becomes available in that period, the
MUST advertise a more recent version of the BGP-LS-SPF Link NLRI originator of the BGP-LS-SPF Link NLRI MUST advertise a more recent
without the SPF Status TLV in the BGP-LS Link Attributes. The version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the
suggested default value for the LinkStatusDownAdvertise timer is 2 BGP-LS Link Attribute. The suggested default value for the
seconds. LinkStatusDownAdvertise timer is 2 seconds.
Similarly, when a prefix becomes unreachable, a more recent version Similarly, when a prefix becomes unreachable, a more recent version
of the BGP-LS-SPF Prefix NLRI SHOULD be advertised with the SPF of the BGP-LS-SPF Prefix NLRI SHOULD be advertised with the SPF
Status TLV (refer to Section 5.2.3.1) to indicate that the prefix is Status TLV (refer to Section 5.2.3.1) to indicate that the prefix is
unreachable in the BGP-LS Prefix Attributes, and the prefix will be unreachable in the BGP-LS Prefix Attributes, and the prefix will be
considered unreachable with respect to BGP SPF. The configurable considered unreachable with respect to BGP SPF. The configurable
PrefixStatusDownAdvertise timer controls the interval that the BGP- PrefixStatusDownAdvertise timer controls the interval that the BGP-
LS-Prefix NLRI is advertised with SPF Status indicating the prefix is LS-Prefix NLRI is advertised with SPF Status indicating the prefix is
unreachable prior to withdrawal. If the BGP-LS-SPF Prefix has been unreachable prior to withdrawal. If the BGP-LS-SPF Prefix has been
advertised with the SPF Status TLV and the prefix becomes reachable advertised with the SPF Status TLV and the prefix becomes reachable
skipping to change at line 1208 skipping to change at line 1210
the SPF Status TLV in the BGP-LS Prefix Attributes. The suggested the SPF Status TLV in the BGP-LS Prefix Attributes. The suggested
default value for the PrefixStatusDownAdvertise timer is 2 seconds. default value for the PrefixStatusDownAdvertise timer is 2 seconds.
6.5.2. Node Failure Convergence 6.5.2. Node Failure Convergence
By default, all the NLRIs advertised by a node are withdrawn when a By default, all the NLRIs advertised by a node are withdrawn when a
session failure is detected [RFC4271]. If fast failure detection session failure is detected [RFC4271]. If fast failure detection
such as BFD [RFC5880] is utilized, and the node is on the fastest such as BFD [RFC5880] is utilized, and the node is on the fastest
converging path, the most recent versions of BGP-LS-SPF NLRI will be converging path, the most recent versions of BGP-LS-SPF NLRI will be
withdrawn. This may result in older versions of NLRIs received from withdrawn. This may result in older versions of NLRIs received from
one or more peers on a different path(s) in the LSNDB until they are one or more peers on a different path(s) in the LSDB until they are
withdrawn. These stale NLRIs will not delay convergence since the withdrawn. These stale NLRIs will not delay convergence since the
adjacent nodes detect the link failure and advertise a more recent adjacent nodes detect the link failure and advertise a more recent
NLRI indicating the link is down with respect to BGP SPF (refer to NLRI indicating the link is down with respect to BGP SPF (refer to
Section 6.5.1) and the bidirectional connectivity check fails during Section 6.5.1) and the bidirectional connectivity check fails during
the BGP SPF calculation (refer to Section 6.3). the BGP SPF calculation (refer to Section 6.3).
7. Error Handling 7. Error Handling
This section describes error-handling actions, as described in This section describes error-handling actions, as described in
[RFC7606], that are specific to BGP-LS-SPF SAFI BGP Update message [RFC7606], that are specific to BGP-LS-SPF SAFI BGP UPDATE message
processing. processing.
7.1. Processing of BGP-LS-SPF TLVs 7.1. Processing of BGP-LS-SPF TLVs
When a BGP speaker receives a BGP Update containing a malformed Node When a BGP speaker receives a BGP Update containing a malformed Node
NLRI SPF Status TLV in the BGP-LS Attribute [RFC9552], the NLRI SPF Status TLV in the BGP-LS Attribute [RFC9552], the
corresponding Node NLRI is considered malformed and MUST be handled corresponding Node NLRI is considered malformed and MUST be handled
as 'treat-as-withdraw'. An implementation SHOULD log an error as 'treat-as-withdraw'. An implementation SHOULD log an error
(subject to rate limiting) for further analysis. (subject to rate limiting) for further analysis.
skipping to change at line 1288 skipping to change at line 1290
Descriptor TLV, or Prefix Descriptor TLV that is considered malformed Descriptor TLV, or Prefix Descriptor TLV that is considered malformed
based on error handling rules defined in the above references, then based on error handling rules defined in the above references, then
it MUST consider the received NLRI as malformed, and the receiving it MUST consider the received NLRI as malformed, and the receiving
BGP speaker MUST handle such a malformed NLRI as 'treat-as-withdraw' BGP speaker MUST handle such a malformed NLRI as 'treat-as-withdraw'
[RFC7606]. [RFC7606].
When a BGP speaker receives a BGP Update that does not contain any When a BGP speaker receives a BGP Update that does not contain any
BGP-LS Attributes, it is most likely an indication of 'Attribute BGP-LS Attributes, it is most likely an indication of 'Attribute
Discard' fault handling, and the BGP speaker SHOULD preserve and Discard' fault handling, and the BGP speaker SHOULD preserve and
propagate the BGP-LS-SPF NLRI as described in Section 8.2.2 of propagate the BGP-LS-SPF NLRI as described in Section 8.2.2 of
[RFC9552]. However, NLRIs without the BGP-LS attribute MUST NOT be [RFC9552]. However, NLRIs without the BGP-LS Attribute MUST NOT be
used in the SPF calculation (Section 6.3). How this is accomplished used in the SPF calculation (Section 6.3). How this is accomplished
is an implementation matter, but one way would be for these NLRIs not is an implementation matter, but one way would be for these NLRIs not
to be returned in LSNDB lookups. to be returned in LSDB lookups.
7.2. Processing of BGP-LS-SPF NLRIs 7.2. Processing of BGP-LS-SPF NLRIs
A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the
syntactic validation checks of the BGP-LS-SPF NLRI listed in syntactic validation checks of the BGP-LS-SPF NLRI listed in
Section 8.2.2 of [RFC9552] to determine if it is malformed. Section 8.2.2 of [RFC9552] to determine if it is malformed.
7.3. Processing of BGP-LS Attributes 7.3. Processing of BGP-LS Attributes
A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the A BGP speaker supporting the BGP-LS-SPF SAFI MUST perform the
syntactic validation checks of the BGP-LS Attribute listed in syntactic validation checks of the BGP-LS Attribute listed in
Section 8.2.2 of [RFC9552] to determine if it is malformed. Section 8.2.2 of [RFC9552] to determine if it is malformed.
An implementation SHOULD log an error for further analysis for An implementation SHOULD log an error for further analysis for
problems detected during syntax validation. problems detected during syntax validation.
7.4. BGP-LS-SPF Link State NLRI Database Synchronization 7.4. BGP-LS-SPF Link State Database Synchronization
While uncommon, there may be situations where the LSNDBs of two BGP While uncommon, there may be situations where the LSDBs of two BGP
speakers support the BGP-LS-SPF SAFI lose synchronization. In these speakers support the BGP-LS-SPF SAFI lose synchronization. In these
situations, the BGP session MUST be reset unless other means of situations, the BGP session MUST be reset unless other means of
resynchronization are used (beyond the scope of this document). When resynchronization are used (beyond the scope of this document). When
the session is reset, the BGP speaker MUST send a NOTIFICATION the session is reset, the BGP speaker MUST send a NOTIFICATION
message with the BGP error code "Loss of LSDB Synchronization" as message with the BGP error code "Loss of LSDB Synchronization" as
described in Section 3 of [RFC4271]. The mechanisms to detect loss described in Section 3 of [RFC4271]. The mechanisms to detect loss
of synchronization are beyond the scope of this document. of synchronization are beyond the scope of this document.
8. IANA Considerations 8. IANA Considerations
skipping to change at line 1355 skipping to change at line 1357
| 1185 | Address Family | Section 5.2.2.1 of RFC | | 1185 | Address Family | Section 5.2.2.1 of RFC |
| | Link Descriptor | 9815 | | | Link Descriptor | 9815 |
+----------------+-----------------+----------------------------+ +----------------+-----------------+----------------------------+
Table 5: NLRI Attribute TLVs Table 5: NLRI Attribute TLVs
The early allocation assignments for the TLV types SPF Capability The early allocation assignments for the TLV types SPF Capability
(1180), IPv4 Link Prefix Length (1182), and IPv6 Link Prefix Length (1180), IPv4 Link Prefix Length (1182), and IPv6 Link Prefix Length
(1183) are no longer required and have been deprecated. (1183) are no longer required and have been deprecated.
8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status Registry 8.3. BGP-LS-SPF Node NLRI Attribute SPF Status TLV Values Registry
IANA has created the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV IANA has created the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV
Status" registry for status values within the "BGP Shortest Path Values" registry for status values within the "BGP Shortest Path
First (BGP SPF)" registry group. Initial values for this registry First (BGP SPF)" registry group. Initial values for this registry
are provided below. Future assignments are to be made using the are provided below. Future assignments are to be made using the
Expert Review registration policy [RFC8126] with guidance for Expert Review registration policy [RFC8126] with guidance for
designated experts as per Section 7.2 of [RFC9552]. designated experts as per Section 7.2 of [RFC9552].
+========+==========================================+ +========+==========================================+
| Values | Description | | Values | Description |
+========+==========================================+ +========+==========================================+
| 0 | Reserved | | 0 | Reserved |
+--------+------------------------------------------+ +--------+------------------------------------------+
skipping to change at line 1380 skipping to change at line 1382
+--------+------------------------------------------+ +--------+------------------------------------------+
| 2 | Node does not support transit traffic | | 2 | Node does not support transit traffic |
| | with respect to BGP SPF | | | with respect to BGP SPF |
+--------+------------------------------------------+ +--------+------------------------------------------+
| 3-254 | Unassigned | | 3-254 | Unassigned |
+--------+------------------------------------------+ +--------+------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+--------+------------------------------------------+ +--------+------------------------------------------+
Table 6: BGP-LS-SPF Node NLRI Attribute SPF Table 6: BGP-LS-SPF Node NLRI Attribute SPF
Status TLV Status Registry Assignments Status TLV Values Registry Assignments
8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status Registry 8.4. BGP-LS-SPF Link NLRI Attribute SPF Status TLV Values Registry
IANA has created the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV IANA has created the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV
Status" registry for status values within the BGP Shortest Path First Values" registry for status values within the BGP Shortest Path First
(BGP SPF)" registry group. Initial values for this registry are (BGP SPF)" registry group. Initial values for this registry are
provided below. Future assignments are to be made using the IETF provided below. Future assignments are to be made using the IETF
Review registration policy [RFC8126]. Review registration policy [RFC8126].
+=======+==========================================+ +=======+==========================================+
| Value | Description | | Value | Description |
+=======+==========================================+ +=======+==========================================+
| 0 | Reserved | | 0 | Reserved |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 1 | Link unreachable with respect to BGP SPF | | 1 | Link unreachable with respect to BGP SPF |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 2-254 | Unassigned | | 2-254 | Unassigned |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+------------------------------------------+ +-------+------------------------------------------+
Table 7: BGP-LS-SPF Link NLRI Attribute SPF Table 7: BGP-LS-SPF Link NLRI Attribute SPF
Status TLV Status Registry Assignments Status TLV Values Registry Assignments
8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status Registry 8.5. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Values Registry
IANA has created the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV IANA has created the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV
Status" registry for status values within the "BGP Shortest Path Values" registry for status values within the "BGP Shortest Path
First (BGP SPF)" registry group. Initial values for this registry First (BGP SPF)" registry group. Initial values for this registry
are provided below. Future assignments are to be made using the IETF are provided below. Future assignments are to be made using the IETF
Review registration policy [RFC8126]. Review registration policy [RFC8126].
+=======+============================================+ +=======+============================================+
| Value | Description | | Value | Description |
+=======+============================================+ +=======+============================================+
| 0 | Reserved | | 0 | Reserved |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 1 | Prefix unreachable with respect to BGP SPF | | 1 | Prefix unreachable with respect to BGP SPF |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 2-254 | Unassigned | | 2-254 | Unassigned |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
| 255 | Reserved | | 255 | Reserved |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
Table 8: BGP-LS-SPF Prefix NLRI Attribute SPF Table 8: BGP-LS-SPF Prefix NLRI Attribute SPF
Status TLV Status Registry Assignments Status TLV Values Registry Assignments
8.6. Assignment in the BGP Error (Notification) Codes Registry 8.6. Assignment in the BGP Error (Notification) Codes Registry
IANA has assigned value 9 for Loss of LSDB Synchronization in the IANA has assigned value 9 for Loss of LSDB Synchronization in the
"BGP Error (Notification) Codes" registry within the "Border Gateway "BGP Error (Notification) Codes" registry within the "Border Gateway
Protocol (BGP) Parameters" registry group. Protocol (BGP) Parameters" registry group.
9. Security Considerations 9. Security Considerations
This document defines a BGP SAFI, i.e., the BGP-LS-SPF SAFI. This This document defines a BGP SAFI, i.e., the BGP-LS-SPF SAFI. This
skipping to change at line 1456 skipping to change at line 1458
As the modifications for BGP SPF described in this document apply to As the modifications for BGP SPF described in this document apply to
IPv4 unicast and IPv6 unicast as underlay SAFIs in a single BGP SPF IPv4 unicast and IPv6 unicast as underlay SAFIs in a single BGP SPF
routing domain, the BGP security solutions described in [RFC6811] and routing domain, the BGP security solutions described in [RFC6811] and
[RFC8205] are out of scope as they are meant to apply for inter- [RFC8205] are out of scope as they are meant to apply for inter-
domain BGP, where multiple BGP routing domains are typically domain BGP, where multiple BGP routing domains are typically
involved. The BGP-LS-SPF SAFI NLRIs described in this document are involved. The BGP-LS-SPF SAFI NLRIs described in this document are
typically advertised between EBGP or IBGP speakers under a single typically advertised between EBGP or IBGP speakers under a single
administrative domain. administrative domain.
The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding The BGP-LS-SPF SAFI and associated BGP SPF processing inherit the
from BGP-LS [RFC9552], and consequently, inherit the security encodings from BGP-LS [RFC9552], and consequently, inherit the
considerations for BGP-LS associated with encoding. Additionally, security considerations for BGP-LS associated with these encodings.
given that BGP SPF processing is used to install IPv4 and IPv6 Additionally, given that BGP SPF processing is used to install IPv4
unicast routes, the BGP SPF processing is vulnerable to attacks to and IPv6 unicast routes, the BGP SPF processing is vulnerable to
the routing control plane that aren't applicable to BGP-LS. One attacks to the routing control plane that aren't applicable to BGP-
notable Denial-of-Service attack would be to include malformed BGP LS. One notable Denial-of-Service attack would be to include
attributes in a replicated BGP Update, causing the receiving peer to malformed BGP attributes in a replicated BGP Update, causing the
treat the advertised BGP-LS-SPF to a withdrawal [RFC7606]. receiving peer to treat the advertised BGP-LS-SPF to a withdrawal
[RFC7606].
In order to mitigate the risk of peering with BGP speakers In order to mitigate the risk of peering with BGP speakers
masquerading as legitimate authorized BGP speakers, it is RECOMMENDED masquerading as legitimate authorized BGP speakers, it is RECOMMENDED
that the TCP Authentication Option (TCP-AO) [RFC5925] be used to that the TCP Authentication Option (TCP-AO) [RFC5925] be used to
authenticate BGP sessions. If an authorized BGP peer is compromised, authenticate BGP sessions. If an authorized BGP peer is compromised,
that BGP peer could advertise a modified Node, Link, or Prefix NLRI that BGP peer could advertise a modified Node, Link, or Prefix NLRI
that results in misrouting, repeating origination of NLRI, and/or that results in misrouting, repeating origination of NLRI, and/or
excessive SPF calculations. When a BGP speaker detects that its excessive SPF calculations. When a BGP speaker detects that its
self-originated NLRI is being originated by another BGP speaker, an self-originated NLRI is being originated by another BGP speaker, an
appropriate error SHOULD be logged so that the operator can take appropriate error SHOULD be logged so that the operator can take
skipping to change at line 1493 skipping to change at line 1496
All routers in the BGP SPF routing domain are under a single All routers in the BGP SPF routing domain are under a single
administrative domain allowing for consistent configuration. administrative domain allowing for consistent configuration.
10.2. Link Metric Configuration 10.2. Link Metric Configuration
For loopback prefixes, it is RECOMMENDED that the metric be 0. For For loopback prefixes, it is RECOMMENDED that the metric be 0. For
non-loopback prefixes, the setting of the metric is a local matter non-loopback prefixes, the setting of the metric is a local matter
and beyond the scope of this document. and beyond the scope of this document.
Algorithms such as setting the metric inversely to the link speed as Algorithms that set the metric inversely to the link speed in some
supported in some IGP implementations MAY be supported. However, the IGP implementations MAY be supported. However, the details of how
details of how the metric is computed are beyond the scope of this the metric is computed are beyond the scope of this document.
document.
Within a BGP SPF routing domain, the IGP metrics for all advertised Within a BGP SPF routing domain, the IGP metrics for all advertised
links SHOULD be configured or defaulted consistently. For example, links SHOULD be configured or defaulted consistently. For example,
if a default metric is used for one router's links, then a similar if a default metric is used for one router's links, then a similar
metric should be used for all router's links. Similarly, if the link 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 metric is derived from using the inverse of the link bandwidth on one
router, then this SHOULD be done for all routers, and the same router, then this SHOULD be done for all routers, and the same
reference bandwidth SHOULD be used to derive the inversely reference bandwidth SHOULD be used to derive the inversely
proportional metric. Failure to do so will result in incorrect proportional metric. Failure to do so will result in incorrect
routing based on the link metric. routing based on the link metric.
skipping to change at line 1565 skipping to change at line 1567
for the total number of SPF computations and the total number of SPF for the total number of SPF computations and the total number of SPF
triggering events. Additionally, troubleshooting should be available triggering events. Additionally, troubleshooting should be available
for SPF scheduling and back-off [RFC8405], the current SPF back-off for SPF scheduling and back-off [RFC8405], the current SPF back-off
state, the remaining time-to-learn, the remaining hold-down interval, state, the remaining time-to-learn, the remaining hold-down interval,
the last trigger event time, the last SPF time, and the next SPF the last trigger event time, the last SPF time, and the next SPF
time. time.
10.8. BGP-LS-SPF Address Family Session Isolation 10.8. BGP-LS-SPF Address Family Session Isolation
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 underlay for other the BGP-LS-SPF AFI/SAFI computation serve as the underlay for other
BGP AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from BGP AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from
impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms
such as separate BGP instances or separate BGP sessions (e.g., using such as separate BGP instances or separate BGP sessions (e.g., using
different addresses for peering) for BGP SPF Link-State information different addresses for peering) for BGP-LS-SPF information
distribution SHOULD be used. distribution SHOULD be used.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at line 1712 skipping to change at line 1714
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>. <https://www.rfc-editor.org/info/rfc7911>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC9816] Patel, K., Lindem, A., Zandi, S., Dawra, G., and J. Dong, [RFC9816] Patel, K., Lindem, A., Zandi, S., Dawra, G., and J. Dong,
"Usage and Applicability of BGP Link-State Shortest Path "Usage and Applicability of BGP Link State (BGP-LS)
Routing (BGP-SPF) in Data Centers", RFC 9816, Shortest Path First (SPF) Routing in Data Centers",
DOI 10.17487/RFC9816, July 2025, RFC 9816, DOI 10.17487/RFC9816, July 2025,
<https://www.rfc-editor.org/info/rfc9816>. <https://www.rfc-editor.org/info/rfc9816>.
Acknowledgements Acknowledgements
The authors would like to thank Sue Hares, Jorge Rabadan, Boris The authors would like to thank Sue Hares, Jorge Rabadan, Boris
Hassanov, Dan Frost, Matt Anderson, Fred Baker, Lukas Krattiger, Hassanov, Dan Frost, Matt Anderson, Fred Baker, Lukas Krattiger,
Yingzhen Qu, and Haibo Wang for their reviews and comments. Thanks Yingzhen Qu, and Haibo Wang for their reviews and comments. Thanks
to Pushpasis Sarkar for discussions on preventing a BGP SPF Router to Pushpasis Sarkar for discussions on preventing a BGP SPF router
from being used for non-local traffic (i.e., transit traffic). from being used for non-local traffic (i.e., transit traffic).
The authors extend a special thanks to Eric Rosen for fruitful The authors extend a special thanks to Eric Rosen for fruitful
discussions on BGP-LS-SPF convergence as compared to IGPs. discussions on BGP-LS-SPF convergence as compared to IGPs.
The authors would also like to thank the following people: The authors would also like to thank the following people:
* Alvaro Retana for multiple AD reviews and discussions. * Alvaro Retana for multiple AD reviews and discussions.
* Ketan Talaulikar for an extensive shepherd review. * Ketan Talaulikar for an extensive shepherd review.
skipping to change at line 1781 skipping to change at line 1783
AT&T AT&T
Email: cy098d@att.com Email: cy098d@att.com
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Acee Lindem Acee Lindem
LabN Consulting, LLC Arrcus, Inc.
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
United States of America United States of America
Email: acee.ietf@gmail.com Email: acee.ietf@gmail.com
Shawn Zandi Shawn Zandi
LinkedIn Email: shafagh@shafagh.com
222 2nd Street
San Francisco, CA 94105
United States of America
Email: szandi@linkedin.com
Wim Henderickx Wim Henderickx
Nokia Nokia
copernicuslaan 50 copernicuslaan 50
2018 Antwerp 2018 Antwerp
Belgium Belgium
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
 End of changes. 91 change blocks. 
179 lines changed or deleted 177 lines changed or added

This html diff was produced by rfcdiff 1.48.