| Internet-Draft | Area-Scoped BGP-LS-SPF | November 2026 |
| Du, et al. | Expires 6 May 2027 | [Page] |
BGP Link-State Shortest Path First (BGP-LS-SPF) routing, defined in RFC 9815, uses BGP to distribute link-state information and the SPF algorithm to compute routes. In large-scale networks with frequent topology changes, distributing detailed link-state information across the entire network may introduce significant control-plane overhead and frequent route recomputation.¶
This document proposes an area-scoped routing mechanism for BGP-LS-SPF. The mechanism divides a network into multiple routing areas, limits the distribution of detailed topology information, and maintains inter-area reachability through boundary routers. It aims to improve routing scalability and stability while supporting distributed route computation.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
BGP-LS-SPF routing [RFC9815] combines BGP-based link-state distribution with SPF route computation. It allows routers to exchange Node, Link, and Prefix information and independently compute routes based on the received topology information.¶
In large-scale networks, distributing detailed topology information to all participating routers may lead to significant control-plane overhead. When links or nodes change frequently, routing updates may propagate across the entire network and trigger repeated route computation, even when the changes affect only a small part of the topology.¶
Existing routing architectures use different approaches to improve scalability, including hierarchical routing, topology aggregation, and controlled routing information distribution. However, BGP-LS-SPF, as defined in RFC 9815, primarily operates within a single SPF routing domain.¶
This document proposes an area-scoped routing mechanism that extends BGP-LS-SPF to support multiple routing areas. Each area maintains detailed local topology information, while boundary routers control the propagation of routing information between areas. The mechanism allows routers to compute routes using local topology information and the reachability information received from other areas.¶
The objective is to reduce unnecessary link-state distribution and route recomputation while maintaining network-wide reachability.¶
In a single BGP-LS-SPF routing domain, routers use distributed link-state information to build a topology database and perform SPF computation.¶
In a flat routing domain, participating routers have similar routing and forwarding roles without relying on a fixed hierarchy of core and non-core nodes.¶
As network size increases, the amount of link-state information maintained by each router may increase accordingly. Frequent link-state changes can also cause repeated routing updates and route computation across the network.¶
However, not all topology changes need to be known by every router. For example, a link failure within one part of a network may change local forwarding paths without affecting reachability to destinations in other parts of the network.¶
This motivates a routing mechanism that can limit the propagation of detailed topology changes while maintaining reachability across the network.¶
The main requirements are:¶
Limit detailed link-state information distribution to the relevant routing area.¶
Maintain reachability between different areas without requiring a complete network-wide topology database.¶
Allow routers to compute routes independently using available local and inter-area information.¶
Prevent routing loops during inter-area routing information exchange.¶
Reduce the impact of local topology changes on routing operations in other areas.¶
This document proposes an area-scoped routing mechanism based on BGP-LS-SPF [RFC9815]. The mechanism divides a routing network into multiple areas and introduces area-based control of routing information distribution.¶
Within each area, routers maintain detailed local topology information and perform SPF computation. Boundary routers control the exchange of routing information between areas, limiting the propagation of internal topology changes while maintaining reachability to destinations in other areas.¶
The proposed mechanism extends the routing information distribution behavior of BGP-LS-SPF. It retains the use of Node, Link, and Prefix NLRIs, but applies different propagation rules according to the type of information and the area boundaries.¶
+----------------+ +----------------+ +----------------+
| Area A | | Area B | | Area C |
| Local Node/Link| | Local Node/Link| | Local Node/Link|
| state and SPF | | state and SPF | | state and SPF |
| [BA]-----+---+ [BB] [BC]---+---+ [BD] |
+----------------+ +----------------+ +----------------+
Area A <--- Prefix reachability ---> Area B
Area B <--- Prefix reachability ---> Area C
BA, BB, BC, BD: boundary routers
Detailed intra-area topology is not distributed end-to-end.
The architecture shown above separates detailed intra-area link-state information from inter-area prefix reachability. Each area can make local forwarding decisions based on its own topology, while boundary routers provide the information needed to reach prefixes outside that area.¶
The routing network is divided into multiple logical areas. Each router is assigned an Area Identifier (Area ID), which identifies the area to which it belongs.¶
Routers exchange area information with their neighbors. A router that has a neighbor belonging to a different area is identified as a boundary router. Other routers operate as intra-area routers.¶
Intra-area routers maintain routing information and perform route computation within their own area. Boundary routers additionally control the propagation of routing information across area boundaries.¶
The boundary-router role is determined by inter-area adjacency and does not require a router to be pre-designated as a dedicated boundary node.¶
The mechanism does not require a specific area partitioning method. Area assignment may be determined according to network topology, scale, or operational requirements.¶
Area identification is a logical routing function and is distinct from an Autonomous System number. This initial version assumes a router belongs to one area for its local SPF computation; support for membership in multiple areas and the exact signaling of Area IDs require further specification.¶
The proposed mechanism applies different distribution rules to Node, Link, and Prefix information carried by BGP-LS-SPF.¶
This separation allows each area to maintain its own detailed topology while sharing the information needed to reach destinations in other areas.¶
Boundary routers apply area-based distribution rules in addition to the existing BGP-LS-SPF information propagation procedures. As a result, local topology changes can be contained within the affected area unless they affect information required by other areas.¶
For example, a change to an internal link in Area B is distributed among routers in Area B, but its detailed Link NLRI is not forwarded into Areas A and C. A change to a link between Area B and Area C may need to be visible to both adjacent areas because it affects their boundary connectivity.¶
The distinction is between detailed topology needed for local SPF computation and reachability information required to forward traffic toward other areas. Scope control is applied at the boundary rather than requiring every router to maintain the same network-wide link-state database.¶
Since routers do not maintain the complete topology of remote areas, inter-area reachability cannot rely on detailed end-to-end topology information.¶
The proposed mechanism uses boundary routers to connect the local topology with reachability information received from other areas.¶
When a boundary router receives Prefix information from another area, it processes the information so that routers in the local area can compute a path toward the corresponding destination using their available topology information.¶
This processing provides a local representation of remote destination reachability through the relevant area boundary. It allows routers to use local SPF computation to select paths toward destinations outside the area without requiring the complete topology of the remote areas.¶
At a conceptual level, boundary processing consists of the following operations:¶
Receive inter-area prefix reachability from an adjacent area and check whether the advertisement is eligible for further processing, including the area-level loop check.¶
Associate the remote prefix with a locally reachable boundary so that the local SPF topology can resolve a forwarding path toward that boundary.¶
Make the resulting reachability available to routers within the local area and, where appropriate, advertise it toward another adjacent area.¶
Update or withdraw the corresponding inter-area information when a change in boundary connectivity affects the advertised reachability.¶
For instance, when a prefix originated in Area C is learned through Area B, Area A can receive a representation of that prefix associated with its boundary toward Area B. Routers in Area A then compute the path to the boundary using their Area A topology, rather than attempting to perform SPF over the nodes and links in Area C.¶
Boundary routers also propagate the necessary reachability information to other areas, allowing destinations to remain reachable across multiple area boundaries.¶
The mechanism therefore separates detailed topology distribution from inter-area destination reachability. The specific representation of remote prefixes and associated routing metrics will be defined in subsequent versions.¶
When Prefix information is propagated across multiple areas, the routing system needs to prevent repeated circulation of routing information between areas.¶
The proposed mechanism introduces area-level path information that records the sequence of areas traversed by an inter-area advertisement.¶
A boundary router examines this information when processing received inter-area routing updates. If the area path indicates that an advertisement would return through an area already traversed, the router prevents further propagation along that path.¶
This provides a mechanism for detecting loops in the propagation of inter-area routing information without requiring routers to maintain the detailed topology of all areas.¶
As an illustration, if an advertisement follows the area sequence C, B, A, a subsequent attempt to send the same advertisement back into Area B would be rejected because B is already present in the path. Such checks limit circulation of the inter-area advertisement.¶
Area-path checking addresses loops in control-information propagation. Ensuring loop-free packet forwarding when multiple boundary routers, alternate inter-area paths, or independently calculated metrics are present additionally depends on the route-selection and reachability-representation procedures, which remain to be specified.¶
The encoding and processing rules for area-level path information will be specified in subsequent versions.¶
Each router performs SPF computation using the topology information available in its local area.¶
The local topology database contains detailed information about routers and links within the area, together with the boundary connectivity and reachability information needed for inter-area forwarding.¶
For destinations within the local area, routes are computed using the local topology. For destinations outside the area, routers use the available inter-area reachability information to determine a path toward the relevant boundary.¶
When an internal link or node changes, the corresponding topology update is distributed within the affected area. Routers in that area can update their forwarding paths without requiring the detailed topology change to be propagated to every router in the network.¶
If the topology change affects connectivity or reachability advertised to other areas, the relevant inter-area information is updated accordingly.¶
The decision to send an inter-area update is based on whether the externally advertised reachability has changed, not solely on whether an internal Link NLRI has changed. This distinction is intended to keep local topology churn from forcing unrelated areas to repeat SPF computation.¶
Changes to a boundary link or to the availability of an egress boundary can affect the inter-area information. In that case, the responsible boundary router updates the relevant reachability and other areas may recompute routes for the affected destinations. This version does not define a new failure-recovery timer or a specific metric-composition rule.¶
This approach reduces the scope of routing updates and SPF recomputation while maintaining distributed route computation and reachability across the network.¶
Consider three routing areas connected in sequence, as shown below. Each area has its own detailed Node and Link information, and boundary routers exchange the Prefix reachability needed for communication between areas.¶
+--------------+ +--------------+ +--------------+ | Area A | | Area B | | Area C | | A1---A2 | | B1---B2 | | C1---C2 | | | | | | | | | | | | | | A3---BA------+---+BB---BC-------+---+-BD---C3---P | +--------------+ +--------------+ +--------------+ BA--BB: A/B boundary link; BC--BD: B/C boundary link P: destination prefix attached to router C3
Prefix P is attached to C3 in Area C. Routers in Area C know the local attachment and use their Area C topology to reach C3. The detailed C1--C2 and BD--C3 topology is not required by routers in Area A.¶
The boundary toward Area B advertises the reachability of P. Within Area B, P is represented as reachable through the boundary facing Area C. Routers in Area B can use local SPF information to reach that boundary. Area B can then propagate the corresponding inter-area reachability toward Area A.¶
Within Area A, P is associated with the reachable boundary BA. For example, A1 computes a path toward BA using its own area topology; BA forwards the traffic across the A/B boundary, and the forwarding decision is subsequently resolved using the topology and reachability information available in Area B and Area C.¶
The exact representation of P at each boundary, the method used to compose route metrics, and the treatment of multiple candidate boundaries are not specified in this version. These are necessary protocol details for subsequent work.¶
Suppose the internal link B1--B2 in Area B fails while the boundary connections BB--BA and BC--BD remain available. Area B distributes the relevant Link NLRI change within Area B and computes any needed local path adjustments.¶
In the illustrated topology, B1 and B2 still have an alternative local path through BB and BC. If the change does not alter the reachability or other attributes that Area B advertises for P, the detailed Link NLRI change does not need to be sent to Areas A and C, and their SPF calculations are not triggered by that link-state change.¶
The example illustrates containment of an internal topology event; it does not assume that every local link failure is invisible to other areas. A change that affects an advertised metric or an externally visible path may require an inter-area update even if the destination remains reachable.¶
Now suppose the BC--BD boundary link fails and no alternative connection from Area B to Area C is available. Area B can no longer use that boundary to reach P. The affected inter-area reachability is updated or withdrawn, and Area A is notified as needed.¶
If another viable inter-area path exists, a boundary router may instead advertise the corresponding change in reachability. In either case, the inter-area notification reflects the effect on remote destinations rather than copying every internal topology change across area boundaries.¶
A boundary router also checks the area sequence of a received inter-area advertisement before re-advertising it. For example, an advertisement that traveled from C through B to A should not be sent back into B as a new inter-area advertisement.¶
The proposed mechanism is intended for large-scale networks operating within a flat routing domain, particularly those experiencing frequent topology changes. Such networks may face significant control-plane overhead when detailed link-state information is distributed throughout the entire routing domain. A representative example is a large-scale LEO satellite network with frequently changing inter-satellite connectivity. The mechanism may also be applicable to other large-scale networks that require routing-state scalability.¶
The mechanism builds on the BGP-LS-SPF routing model defined in [RFC9815]. It retains the use of link-state information and distributed SPF computation while introducing area-scoped information distribution and inter-area reachability handling.¶
A network can be divided into multiple Autonomous Systems to limit routing information distribution. The proposed mechanism instead uses routing areas within a common BGP-LS-SPF routing system, without requiring multiple ASes. A router acts as a boundary router when it has a neighbor in another area, so boundary routers do not need to be designated in advance.¶
The mechanism requires further specification of the information exchanged between areas and its interaction with the base BGP-LS-SPF procedures.¶
The extension changes the distribution scope of selected BGP-LS-SPF NLRIs relative to the single-domain dissemination model described in RFC 9815. A complete protocol specification will need to state precisely how scoped distribution interacts with NLRI origination and sequence-number processing, route-reflector behavior, and the SPF treatment of prefixes associated with remote areas.¶
This initial document describes the mechanism without specifying new BGP capability values, path attributes, or TLV encodings. The requirements for mixed deployments of routers that do and do not support the extension, along with the behavior for multiple exit boundaries and metric changes, remain topics for further specification.¶
The introduction of routing areas and boundary routers creates additional considerations for routing information exchange.¶
Incorrect or unauthorized area information may affect routing information distribution. Incorrect inter-area reachability information may also result in routing loops or forwarding failures.¶
Future protocol specifications need to address the validation and protection of area information, inter-area reachability advertisements, and associated loop-prevention information.¶
The security mechanisms defined for the underlying BGP-LS-SPF protocol remain applicable.¶
A compromised boundary router could incorrectly suppress local topology advertisements, create false representations of remote reachability, or manipulate area-path information. Such behavior could isolate destinations or redirect traffic across unintended boundaries. Validation of area membership and the authenticity of inter-area information therefore require explicit treatment in the protocol specification.¶
This document makes no IANA requests.¶
Future versions specifying protocol encodings may require additional IANA allocations.¶