Internet-Draft BGP-LS-Inter-AS-Ext April 2026
Wang, et al. Expires 9 October 2026 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-ietf-idr-bgpls-inter-as-topology-ext-22
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Wang
China Telecom
H. Chen
Individual
K. Talaulikar
Cisco Systems
S. Zhuang
Huawei Technologies
C. Lin
New H3C Technologies

BGP-LS Extension for Inter-AS Topology Retrieval

Abstract

This document specifies the procedure for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for a Stub Link, as well as three new type-length-values (TLVs) for the BGP-LS Stub Link descriptor. These BGP-LS extensions enable Software-Defined Networking (SDN) controllers to retrieve network topology across inter-AS environments.

These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by the BGP-LS protocol.

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 9 October 2026.

▲

Table of Contents

1. Introduction

BGP-LS [RFC9552] describes the use of BGP protocol for advertisement of the Link-State topology information. It enables applications such as a SDN controllers to collect the underlay network topology. [RFC9552] covers the advertisement of topology information from within Interior Gateway Protocol (IGP) domain. If the network has more than one IGP domain, and these domains interconnect with each other via inter-AS links, there is no mechanism within the current BGP-LS to advertise the interconnect topology information.

[RFC9086] defines extensions for exporting BGP peering node topology information (including peers, interfaces, and peering ASes) in a way that is used to compute efficient BGP Peering Engineering policies and strategies. This information can also be used to compute interconnection topology among different IGP domains, but it requires every border router to run the BGP-LS protocol and report such information to SDN controllers. Considering there will be several border routers on the network boundary, such solution restricts its deployment flexibility.

This document defines the Stub Link NLRI and some new TLVs for BGP-LS to cover scenarios where a SDN controller needs to get the interconnection topology information between different AS domains when sourced from IGPs.

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.

3. Terminology

The following terms are defined in this document:

4. Inter-AS Domain Scenarios

Figure 1 illustrates the multi-domain scenarios discussed in this document. Typically, the SDN Controller can retrieve the topology of IGP A and IGP B individually via the BGP-LS protocol, but it cannot obtain topology connection information between these two IGP domains, as IGP protocols are generally not run on the inter-AS links.

                      +-----------------+
                 +----+IP SDN Controller+----+
                 |    +-----------------+    |
                 |                           |
                 |BGP-LS                     |BGP-LS
                 |                           |
 +---------------+-----+               +-----+--------------+
 | +--+        +-++   ++-+           +-++   +|-+        +--+|
 | |S1+--------+S2+---+B1+-----------+B2+---+T1+--------+T2||
 | +-++   N1   +-++   ++-+           +-++   ++++   N2   +-++|
 |   |           |     |               |     ||           | |
 |   |           |     |               |     ||           | |
 | +-++        +-++   ++-+           +-++   ++++        +-++|
 | |S4+--------+S3+---+B3+-----------+B4+---+T3+--------+T4||
 | +--+        +--+   ++-+           +-++   ++-+        +--+|
 |                     |               |                    |
 |                     |               |                    |
 |       IGP A         |               |      IGP B         |
 +---------------------+               +--------------------+

             Figure 1: Inter-AS Domain Scenarios

This document introduces three TLVs for inclusion as Stub Link Descriptors within the Stub Link NLRI for the advertisement of inter-AS link information via BGP-LS.

+-----------+---------------------+--------------+----------------+
|  TLV Code | Description         |IS-IS/OSPF TLV| Reference      |
|   Point   |                     |   /Sub-TLV   | (RFC/Section)  |
+-----------+---------------------+--------------+----------------+
|    270    |Remote AS Number     |   24/21      | [RFC9346]/3.4.1|
|           |                     |              | [RFC5392]/3.3.1|
|    271    |IPv4 Remote ASBR ID  |   25/22      | [RFC9346]/3.4.2|
|           |                     |              | [RFC5392]/3.3.2|
|    272    |IPv6 Remote ASBR ID  |   26/24      | [RFC9346]/3.4.3|
|           |                     |              | [RFC5392]/3.3.3|
+-----------+---------------------+--------------+----------------+
             Figure 3: Stub Link Descriptor TLVs

The encoding of these TLVs are aligned with the corresponding advertisements in [RFC9346] and [RFC5392], which keeps the BGP-LS protocol agnostic to the underly protocol.

6.1. Remote AS Number TLV

The Remote AS Number TLV specifies the AS number of the neighboring AS to which the advertised link connects.

The Remote AS Number TLV is TLV Type 270 and is 4 octets in length. Its format is as follows:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote AS Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 4: Remote AS Number TLV Format

The Remote AS Number field has 4 octets. When only 2 octets are used for the AS number (for example, when such information is advertised from OSPF, as in current deployments), the left (high-order) 2 octets MUST be set to 0.

6.2. IPv4 Remote ASBR ID

The IPv4 Remote ASBR ID TLV specifies the IPv4 identifier of the remote ASBR to which the advertised inter-AS link connects. This can be any stable, routable IPv4 address of the remote ASBR. The use of the TE Router ID, as specified in the Traffic Engineering Router ID TLV [RFC9346] is RECOMMENDED.

The IPv4 Remote ASBR ID TLV is TLV Type 271 and is 4 octets in length. Its format is as follows:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 5:  IPv4 Remote ASBR ID TLV Format

6.3. IPv6 Remote ASBR ID

The IPv6 Remote ASBR ID TLV specifies the IPv6 identifier of the remote ASBR to which the advertised inter-AS link connects. This can be any stable, routable IPv6 address of the remote ASBR. The use of the TE Router ID, as specified in the IPv6 Traffic Engineering Router ID TLV [RFC9346] is RECOMMENDED.

The IPv6 Remote ASBR ID TLV is TLV Type 272 and is 16 octets in length. Its format is as follows:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 6:  IPv6 Remote ASBR ID TLV Format

The IPv6 Remote ASBR ID TLV MUST be included if the neighboring ASBR has an IPv6 address. If the neighboring ASBR does not have an IPv6 address, the IPv4 Remote ASBR ID TLV MUST be included instead. Both an IPv4 Remote ASBR ID TLV and an IPv6 Remote ASBR ID TLV MAY be present in an inter-AS Stub Link NLRI.

7. Advertisement of IGP Information for Inter-AS Links

Advertisement of Inter-AS Links along with their TE information is done is done in IGPs as follows:

- In OSPFv2 via the Inter-AS-TE-v2 LSA [RFC5392]

- In OSPFv3 via the Inter-AS-TE-v3 LSA[RFC5392]

- In IS-IS via the Inter-AS Reachability Information TLV (TLV 141) [RFC9346]

When advertising these Inter-AS Links from the IGPs into BGP-LS as Stub Links, the sourcing of information for the Stub Link NLRI except for the Stub Link Descriptors follows the same procedures as specified in [RFC9552]. The information about the Remote AS Number and the IPv4/IPv6 Remote ASBR IDs specified in Section 6 are derived from the Remote AS Number and IPv4/IPv6 Remote ASBR ID TLVs specified for OSPF and IS-IS in [RFC5392] and [RFC9346] respectively. The rest of the Stub Descriptor TLVs of the Stub NLRI are sourced from the base OSPF/ISIS TE TLVs that were originally introduced for normal IGP links and which are also encoded for the inter-AS TE links as specified in [RFC5392] and [RFC9346]; their procedures are therefore same as in [RFC9552].

The OSPF/ISIS Inter-AS Link advertisements also include various link properties (e.g., TE metric, Admin Groups, SRLGs, etc.) which are encoded using the same TLVs as for normal IGP links. These link properties are advertised using their corresponding BGP-LS TLVs as specified in [RFC9552] and other BGP-LS extensions in the BGP-LS Attribute associated with the Stub Link NLRI of that specific link.

8. Security Considerations

BGP-LS security is specified in [RFC9552]. This extension to BGP-LS focuses on scenarios where a single entity-operated network includes multiple IGP domains composed of its backbone network, several Metro-Area Networks (MANs), and Internet Data Centers (IDCs). The configuration of these networks, operated by a single administrative entity, creates a "walled garden". Within this single administrative domain, the network operator needs to monitor and engineer traffic flows traversing a network that spans multiple Autonomous Systems (ASes). The network operator can obtain this inter-AS topology information via the procedure described in this document.

A single administrative domain consisting of two ASes that passes information about Stub Link characteristics does not cause issues within a "walled garden". However, the Stub Link NLRI and its characteristics (Link/Local Identifier, IPv4 Interface Address, IPv4 Neighbor Address, IPv6 Interface Address, IPv6 Neighbor Address, Multi-Topology Identifier, Remote-AS Number, IPv4 Remote ASBR ID, and IPv6 Remote ASBR ID) constitute critical network information. As such, operators SHOULD handle this critical information in a manner that restricts it to the walled garden.

9. IANA Considerations

This document requests IANA to update the allocated codepoints from under the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group as follows:

9.1. New BGP-LS NLRI type

IANA has allocated codepoint for the Stub Link NLRI type from the "BGP-LS NLRI Types" registry as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |   NLRI Type   |          Reference            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       7       | Stub Link NLRI|        This document          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 7:  Stub Link NLRI Codepoint

IANA has allocated codepoints for the following TLVs from "BGP-LS NLRI and Attribute TLVs" registry:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TLV Code Point  |   Description         |      Reference        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      270          | Remote AS Number      | Allocation from IANA  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      271          |  IPv4 Remote ASBR ID  | Allocation from IANA  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      272          |  IPv6 Remote ASBR ID  | Allocation from IANA  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 8:  BGP-LS Link Descriptors TLV

10. Acknowledgement

The author would like to thank Susan Hares, Acee Lindem, Jie Dong, Shaowen Ma, Jeff Tantsura and Dhruv Dhody for their valuable comments and suggestions.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5392]
Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, , <https://www.rfc-editor.org/info/rfc5392>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9346]
Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 9346, DOI 10.17487/RFC9346, , <https://www.rfc-editor.org/info/rfc9346>.
[RFC9552]
Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, , <https://www.rfc-editor.org/info/rfc9552>.

11.2. Informative References

[RFC9086]
Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, , <https://www.rfc-editor.org/info/rfc9086>.

Authors' Addresses

Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Huaimo Chen
Individual
Boston, MA
United States of America
Ketan Talaulikar
Cisco Systems
India
Shunwan Zhuang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
100095
China
Changwang Lin
New H3C Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
China