| Internet-Draft | Region Division for BGP-LS SPF | November 2026 |
| Min, et al. | Expires 6 May 2027 | [Page] |
In large-scale networks using BGP-LS SPF routing, region division is necessary to make the networks stable. Some networks (e.g., satellite networks) have the characteristics of a flat design, which means that no backbone region exists in the network. This document presents a routing framework for region division in large-scale flat BGP-LS SPF routing networks. This framework can realize flexible region division, establish intra-region and inter-region paths, and complete end-to-end data forwarding.¶
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.¶
To tackle issues such as slow convergence and excessive flooding overhead, large-scale routing networks generally adopt the method of region division to improve the efficiency of routing convergence and network management. The existing region division method typically divides a network into a backbone region and multiple non-backbone regions. The backbone region is unique and holds routing information for all regions. The non-backbone regions establish fixed connections around the backbone region. Thus, the nodes in the backbone region are responsible for traffic forwarding between all regions, and require higher performance. However, some networks (e.g., satellite networks) have the characteristics of a flat design, which means that no backbone region exists in the network. For these networks, the existing region division method does not work.¶
This document describes a routing framework for region division in large-scale flat routing networks. This framework can be implemented on the basis of the existing BGP Link State (BGP-LS) Shortest Path First (SPF) routing [RFC9815], with some potential minor extensions defined in other documents.¶
This document is the successor of [I-D.hou-satellite-routing-framework], which described a region-based routing framework for satellite networks on the basis of existing Interior Gateway Protocols; this document re-targets that framework at BGP-LS SPF. [RFC9717] describes an alternative, hierarchical routing architecture for satellite networks based on two-level IS-IS. [I-D.xu-lsvr-midr-use-cases] describes use cases and requirements for multi-domain BGP-LS SPF, to which the framework in this document is applicable, and [I-D.miao-rtgwg-satellite-routing-reqs] lists routing requirements for large satellite networks that motivate it.¶
Taking into account both of the generality and the practicability, this document adopts the quadrangle as the basic model of region division. That is, a region (e.g., R19) has four contiguous neighbor regions (R14, R18, R24, and R20), one in each type refers to a direction, as shown in Figure 1. In the figure, h is the number of nodes a region spans in one direction (for a satellite network, the number of satellites of one orbit plane that belong to the region) and l is the number of nodes it spans in the other direction (for a satellite network, the number of orbit planes); both are planned region parameters.¶
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | R18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| R14| | R19 | | |R24 |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--+--| 2 |
+---+ | +---+ +---+ +---+ | +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | R20 | | | l=3
| +---+ +---+ +---+ |
h=3 | 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
According to the relative position of a network node in the region, a network node can be classified as one of two types: the internal node or the border node. An internal node does not connect to nodes outside of the region it belongs to. A border node is part of its region and has connections to nodes outside of its region. Internal nodes and border nodes are collectively referred to as intra-region nodes. A node within a neighbor region that has a connection to a border node is called a cross-region neighbor node.¶
The region border node should have the following features:¶
(1) The capability of establishing connections with cross-region neighbor nodes.¶
The border node acts as the agent for external connections of the local region, and is responsible for establishing connections with cross-region neighbor nodes. During the connection establishment process, these nodes build an adjacency relationship with each other.¶
(2) The capability of maintaining connections with cross-region neighbor nodes.¶
Changes in the connection relationship between a border node and a cross-region neighbor node need to be advertised to the nodes in the same region. Figure 2 presents a link failure between R19 adn R24; Node 8 is responsible for informing the other nodes in region R19.¶
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | R18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| R14| | R19 | | |R24 |
| | | | | | |
+---+ | +---+ +---+ +---+ \|/ +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--X--| 2 |
+---+ | +---+ +---+ +---+ /|\ +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | R20 | | |
| +---+ +---+ +---+ |
| 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
(3) The capability of preventing routing information advertisement loops between regions.¶
When a border node advertises routing information of its region to an adjacent region, there should be a mechanism deployed that prevents the advertised routing information from being looped back to the region the border node belongs to.¶
In addition to the above features required of the border node, both the border node and the internal node share the following feature:¶
(1) The capability of maintaining intra-region network information.¶
When a region is initially created, each node within the region establishes connections with its neighbor nodes, determines the nodes of the region based on the planned region parameters, advertises its own network information to the other nodes within the region, and continuously monitors its own direct links. When a sudden failure occurs, the node advertises it and updates its local network information and the intra-region topology.¶
Figure 3 presents a link failure between Node 5 and Node 8; Node 5 and Node 8 are responsible for informing the other nodes in region R19.¶
+---+ +---+ +---+
| 3 |-----| 6 |-----| 9 |
| +---+ +---+ +---+ |
| | R18 | | |
----+----+---------+---------+----+----
+---+ | +---+ +---+ +---+ | +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+ | +---+ +---+ +---+ | +---+
| R14| | R19 | | |R24 |
| | | | | | |
+---+ | +---+ +---+ \ / +---+ | +---+
| 8 |--+--| 2 |-----| 5 |--X--| 8 |--+--| 2 |
+---+ | +---+ +---+ / \ +---+ | +---+
| | | | | | |
| | | | | | |
+---+ | +---+ +---+ +---+ | +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+ | +---+ +---+ +---+ | +---+
----+----+---------+---------+----+----
| | R20 | | |
| +---+ +---+ +---+ |
| 1 |-----| 4 |-----| 7 |
+---+ +---+ +---+
As shown in Figure 4, N2 and N4 are located in the same region, R19. N2 serves as the source node and sends data traffic to the destination node N4. The data forwarding path between N2 and N4 passes through nodes N2, N5, and N4 in turn. The routing process is consistent with the existing BGP-LS SPF routing [RFC9815].¶
| .--. .--. |
| ...-| N3 |-... <--> ...-| N6 |-... |
| \__/ \__/ |
| ^ R18 ^ |
-------------+--------+-------------------+---------+-------------
R14 | v R19 v | R24
.--. | .--. .--. | .--.
..-| N4 |-... <+> ...-| N1 |-... <--> ...-| N4 |-... <+> ...-| N1 |-.
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v | v --------------->| v | v
.--. | .--. .--. | .--.
..-| N5 |-... <+> ...-| N2 |-... <--> ...-| N5 |-... <+> ...-| N2 |-.
\__/ | \__/ \__/ | \__/
^ | ^ ^ | ^
| | | | | |
v | v v | v
.--. | .--. .--. | .--.
..-| N6 |-... <+> ...-| N3 |-... <--> ...-| N6 |-... <+> ...-| N3 |-.
\__/ | \__/ \__/ | \__/
| ^ ^ |
-------------+--------+-------------------+---------+-------------
| v R20 v |
| .--. .--. |
| ...-| N1 |-... <--> ...-| N4 |-... |
| \__/ \__/ |
As shown in Figure 5, the BGP-LS SPF network is divided into 30 regions (R1 to R30). Source node S is located in region R4 and destination node D is located in region R22. S sends data to D. The data forwarding path between S and D passes through regions R4, R9, R14, R19, R18, R17, and R22 in turn.¶
+-----+-----+-----+-----+-----+-----+ | R1 | R6 | R11 | R16 | R21 | R26 | | | | | | | | +-----+-----+-----+-----+-----+-----+ | R2 | R7 | R12 | R17 | R22 | R27 | | | | | ^>> | | +-----+-----+-----+----^+-----+-----+ | R3 | R8 | R13 | R18^| R23 | R28 | | | | | ^| | | +-----+-----+-----+----^+-----+-----+ | R4 | R9 | R14 | R19^| R24 | R29 | | >>>>>>>>>>>>>>>>>>>>| | | +-----+-----+-----+-----+-----+-----+ | R5 | R10 | R15 | R20 | R25 | R30 | | | | | | | | +-----+-----+-----+-----+-----+-----+
As shown in Figure 6, the data is first forwarded from Node N6 in region R14 to Node N3 in region R19. Node N3 resolves the destination address and looks up the intra-region and inter-region routing tables to forward the data. According to the inter-region routing table, if the destination node is located in region R22, the data packet is forwarded via region R18, and the next hop node is Node N6 within region R19. Each node within region R19 repeats the above operations, and finally forwards the data packet is forwarded to Node N6 within region R18. For a border node, the next hop address in the inter-region routing table is the port address of the cross-region neighbor node.¶
| .--. .--. |
| ...-| N3 |-... <--> ...-| N6 |-... |
| \__/ \__/ |
| ^ R18 ^ ^ |
-------------+--------+-----------------|-+---------+-------------
R14 | v R19 | v | R24
.--. | .--. .--. | .--.
..-| N4 |-... <+> ...-| N1 |-... <--> ...-| N4 |-... <+> ...-| N1 |-.
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v | v | v | v
.--. | .--. .--. | .--.
..-| N5 |-... <+> ...-| N2 |-... <--> ...-| N5 |-... <+> ...-| N2 |-.
\__/ | \__/ \__/ | \__/
^ | ^ ^ ^ | ^
| | | | | | |
v ---------------> v --------------->| v | v
.--. | .--. .--. | .--.
..-| N6 |-... <+> ...-| N3 |-... <--> ...-| N6 |-... <+> ...-| N3 |-.
\__/ | \__/ \__/ | \__/
| ^ ^ |
-------------+--------+-------------------+---------+-------------
| v R20 v |
| .--. .--. |
| ...-| N1 |-... <--> ...-| N4 |-... |
| \__/ \__/ |
Security issues discussed in [RFC9815] apply to this document.¶
The authors would like to acknowledge Fenlin Zhou for his contribution to the predecessor of this document.¶
This document has no IANA actions.¶