Proposed Update to BGP Link-State SPF NLRI Selection Rules
draft-dong-lsvr-bgp-spf-selection-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jie Dong , chenjinqiang , Sheng Fang , Jiawei Li | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dong-lsvr-bgp-spf-selection-05
Link State Vector Routing Working Group J. Dong
Internet-Draft J. Chen
Intended status: Standards Track Huawei Technologies
Expires: 6 May 2027 S. Fang
Individual
J. Li
China Satellite Network Innovation Research Institute
2 November 2026
Proposed Update to BGP Link-State SPF NLRI Selection Rules
draft-dong-lsvr-bgp-spf-selection-05
Abstract
For network scenarios such as Massively Scaled Data Centers (MSDCs),
BGP is extended for Link-State (LS) distribution and the Shortest
Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages
the mechanisms of both BGP protocol and BGP-LS protocol extensions,
with new selection rules defined for BGP-LS-SPF NLRI. This document
proposes some updates to the BGP-LS-SPF NLRI selection rules, so as
to improve the route updates and convergence, while consistent SPF
computation result can still be achieved. This document updates the
NLRI selection rules in I-D.ietf-lsvr-bgp-spf.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dong, et al. Expires 6 May 2027 [Page 1]
Internet-Draft BGP-SPF Selection Rules November 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Network Scenarios Which Triggered This Update . . . . . . . . 3
2.1. Unnecessary Redundant Advertisement . . . . . . . . . . . 3
2.2. Parallal BGP-LS-SPF Peers . . . . . . . . . . . . . . . . 3
2.3. Stale NLRI Propagation After Cold Restart . . . . . . . . 4
3. Update to BGP-LS-SPF Selection Rules . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
For network scenarios such as Massively Scaled Data Centers (MSDCs),
BGP is extended for Link-State (LS) distribution and the Shortest
Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages
the mechanisms of both BGP protocol and BGP-LS protocol extensions.
For 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.
The selection rules for BGP-LS-SPF NLRI are defined in section 6.1 of
[RFC9815].
In some network scenarios, the selection rules defined in [RFC9815]
for BGP-LS-SPF NLRI may not be enough to provide optimized route
advertisement and convergence. This document proposes some updates
to the BGP-LS-SPF NLRI selection rules, so as to improve the route
convergence while consistent SPF computation result can still be
achieved.
This document firstly describes the network scenarios in which the
existing NLRI selection rules are considered not enough. Then it
provides suggested updates to the BGP-LS-SPF NLRI selection rules.
Dong, et al. Expires 6 May 2027 [Page 2]
Internet-Draft BGP-SPF Selection Rules November 2026
2. Network Scenarios Which Triggered This Update
2.1. Unnecessary Redundant Advertisement
According to the rules in [RFC9815], for the BGP-LS-SPF NLRIs with
the same sequence number, the NLRI received from the numerically
larger BGP ID is preferred. While in some cases, this may cause
unnecessary redundant advertisement of the same NLRI.
+----+ new +----+ +----+ +----+
| R6 +-------+ R1 +---------+ R2 +-------+ R5 |
+----+ peer +-+--+ +-+--+ +----+
| |
| |
| |
| |
| |
+-+--+ +-+--+
| R3 +---------+ R4 |
+----+ +----+
Figure 1. Example of Duplicated Updates
As shown in the example in Figure 1, a new BGP session is established
between R1 and R6, and R1 advertise the link NLRI of R1-R6 to its
neighboring nodes (R2 and R3). R2 firstly receives the link NLRI
R1-R6 from R1 directly, and advertise it further to its neighbors (R4
and R5). R4 receives the link NLRI of R1-R6 with the same sequence
number from both R3 and R2, and according to the NLRI selection
rules, R4 would prefer the NLRI received from R3 according to the
rule of numerically larger BGP ID, then R4 advertises this link NLRI
of R1-R6 to R2. R2 would also prefer the NLRI received from R4
according to the rule of numerically larger BGP ID, and further
advertises this link NLRI to R5, which is a redundant advertisement
of its previous advertisement of the same link NLRI.
2.2. Parallal BGP-LS-SPF Peers
In some scenarios, BGP single-hop peering model is used between
directly connected BGP nodes. When two or more parallel links exists
between the BGP nodes, multiple BGP sessions are established between
the peering nodes, and each session will be used for the distribution
of BGP-LS-SPF NLRIs.
Dong, et al. Expires 6 May 2027 [Page 3]
Internet-Draft BGP-SPF Selection Rules November 2026
parallel BGP sessions
+----+ +----+ +----+ +----+
| | | +---------+ | | |
| R3 +-------+ R1 +---------+ R2 +-------+ R4 |
+----+ +-+--+ +-+--+ +----+
Figure 2. Example of Parallal BGP Sessions
As shown in the example of Figure 2, there are two parallel links
between R1 and R2, and a separate BGP session is established on each
link. Based on the existing BGP-LS-SPF NLRI selection rules, from
R2's perspective, for the same NLRI with the same sequence number,
either the route received from peer R1.1, or the route received from
peer R1.2 may be selected as the best. No matter what tie-breaking
rule is used, depending on the order of the routes received from R1,
R2 may need to advertise duplicated NLRIs to R4.
2.3. Stale NLRI Propagation After Cold Restart
Consider a network where a BGP-LS-SPF speaker (Rx) is connected to a
direct peer (R1), and the network also includes routers R2 through R6
in a partial mesh topology as shown in Figure 3.
parallel BGP sessions
+----+ +----+ +----+ +----+
| | | | | | | |
| Rx +-------+ R1 +-------+ R2 +-------+ R5 |
+----+ +-+--+ +-+--+ +-+--+
Cold | | |
Restart | | |
+-+--+ +----+ +-+--+
| | | | | |
| R3 +-------+ R4 +-------+ R6 |
+----+ +----+ +----+
Figure 3. Example of Router Cold Restart
Initially, all nodes have received and stored Rx's self-originated
NLRI with sequence number (SN) 100. Then the following sequence of
events occurs:
Rx undergoes a cold restart, causing its NLRI sequence number to
reset to 1. Upon restart, Rx sends its self-originated NLRI-Rx with
SN=1 to its direct peer, R1.
R1, as the direct peer of Rx, selects NLRI-Rx (SN=1) as the best path
and advertises it to its peers, R2 and R3.
Dong, et al. Expires 6 May 2027 [Page 4]
Internet-Draft BGP-SPF Selection Rules November 2026
R2 holds the stale NLRI-Rx (SN=100) received from R4, it prefers the
NLRI with higher sequence number (SN=100) and advertises this stale
NLRI-Rx (N=100) back to R1.
R3 only receives NLRI-Rx from R1, which is updated by NLRI-Rx (SN=1)
sent by R1. Thus R3 selects the newer NLRI-Rx (SN=1) and advertises
it to R4.
Similarly, R4 only receives NLRI-Rx from R3, it selects NLRI-Rx
(SN=1) received from R3, and advertises it to its peers, R2 and R6.
R2 now receives NLRI-Rx (SN=1) from R4. Since both of R2's upstream
peers advertise NLRI-Rx (SN=1), R2 selects NLRI-Rx (SN=1) from R4 as
the best route, and advertises it to R1 and R5.
R6 selects NLRI-Rx (SN=1) and advertises it to R5.
R5, which holds the stale NLRI-Rx (SN=100) from R6, prefers and
advertises the stale NLRI Rx (SN=100) to R2, before it receives the
update of NLRI-Rx (SN=1) from R6.
After receiving the update of NLRI-Rx (SN=1) from R6, R5 finally
selects NLRI-Rx@SN:1 and advertises it to R2.
As shown in the above process, routers R2 and R5 do not select the
latest NLRI-Rx (SN=1) upon first receipt, due to the presence of
stale NLRI with a higher sequence number (SN=100) in their Loc-RIB.
As a result, R2 and R5 may advertise additional stale NLRI-Rx
(SN=100) to their BGP peers before eventually converging onto the
latest version (SN=1). This behavior causes redundant NLRI
advertisement and delays route convergence. In this case, the cycle
of stale NLRI advertisement could have been reduced, if R1 at the
first place prefers the stale NLRI with SN=100 and sends it to Rx, as
that would make Rx to increase the sequence number to SN=101, which
would be prefered by all the BGP-SPF routers.
3. Update to BGP-LS-SPF Selection Rules
As the BGP-LS-SPF NLRIs are used to distribute the link-state
information, which are then used for SPF computation, BGP attributes
which are used in BGP best path selection (e.g. AS_PATH) for BGP
address families other than BGP-LS are not considered in the
computation of BGP-LS-SPF. The consistency of BGP-LS-SPF computation
result only relies on the sequence number associated with the BGP-LS-
SPF NLRIs. For network scenarios where optimized route convergence
is more desirable, additional route selection and advertisement due
to the changes in BGP attributes which are not used in BGP-SPF
computation, although may help to achieve deterministic NLRI
Dong, et al. Expires 6 May 2027 [Page 5]
Internet-Draft BGP-SPF Selection Rules November 2026
selection, are considered unnecessary.
For such scenarios, this document proposes to update the selection
rules for BGP-LS-SPF NLRI by adding the below rule 3 (b) and 4 (b)
afer the rule 3 and rule 4 in section 6.1 of [RFC9815] respectively.
The updated NLRI selection rules are as follows:
1. NLRIs self-originated from directly connected BGP SPF peers
are preferred. This condition can be determined by comparing the
BGP Identifiers in the received Local Node Descriptor and the BGP
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
number state due to a cold start. Note that once the BGP session
goes down, the NLRI received is no longer considered as being from
a directly connected BGP SPF peer. An implementation MAY provide
a knob to disable rule 1, if it is assumed the convergence can be
improved by making the originating BGP SPF router to generate an
update of its NLRI with a larger sequence number.
2. Consistent with base BGP [RFC4271], an NLRI received from a
peer will always replace the same NLRI received from that peer.
Coupled with rule #1, this will ensure that any stale NLRI in the
BGP SPF routing domain will be updated.
3. The NLRI with the most recent Sequence Number TLV, i.e., the
highest sequence number is selected.
3 (b). The NLRI received from a BGP-LS-SPF peer with the same
sequence number as the one of the current selected NLRI SHOULD not
be selected.
4.The NLRI received from the BGP speaker with the numerically
larger BGP Identifier is preferred.
4 (b). The NLRI received from the BGP speaker with the
numerically smallest peer address is preferred.
The update of rule 1 helps to reduce unnecessary route update and
imrove route convergence in scenarios as described in section 2.3.
Rule 3 (b) helps to solve the duplicated advertisement problem as
described in section 2.1 and 2.2. Rule 4 (b) helps to ensure that if
multiple routes draw in tie in preceding rules, deterministic route
selection result can be achieved.
4. IANA Considerations
This document makes no request of IANA.
Dong, et al. Expires 6 May 2027 [Page 6]
Internet-Draft BGP-SPF Selection Rules November 2026
5. Security Considerations
The mechanism described in this document provide updates to the NLRI
selection rules for BGP-LS-SPF. It does not introduce any additional
security considerations than those described in [RFC4271] and
[RFC4272].
6. Acknowledgements
The authors would like to thank Haibo Wang, Jun Ge, Li Zhang and
Yifan Wang for the valuable discussion and suggestions.
7. References
7.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC9815] Patel, K., Lindem, A., Zandi, S., and W. Henderickx, "BGP
Link State (BGP-LS) Shortest Path First (SPF) Routing",
RFC 9815, DOI 10.17487/RFC9815, July 2025,
<https://www.rfc-editor.org/info/rfc9815>.
7.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
Authors' Addresses
Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
Jinqiang Chen
Huawei Technologies
China
Email: chenjinqiang@huawei.com
Dong, et al. Expires 6 May 2027 [Page 7]
Internet-Draft BGP-SPF Selection Rules November 2026
Sheng Fang
Individual
China
Email: fang_sheng@163.com
JIawei Li
China Satellite Network Innovation Research Institute
China
Email: lijw3@chinasatnet.com.cn
Dong, et al. Expires 6 May 2027 [Page 8]