BGP-LS Extensions for Inter-AS Topology Retrieval

Internet-Draft	BGP-LS-Inter-AS-Ext	August 2026
Wang, et al.	Expires 1 March 2027	[Page]

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 an Inter-AS Link, as well as three new type-length-values (TLVs) for the BGP-LS Inter-AS Link descriptor. These BGP-LS extensions enable network controller 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 inter-AS topology using information provided by the BGP-LS protocol.¶

1. Introduction

BGP-LS [RFC9552] describes the use of the BGP protocol for advertising Link-State topology information. It enables applications such as Software-Defined Network Controller[RFC7426] to collect the underlay network topology. [RFC9552] covers the advertisement of topology information from within an 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 [RFC9552] to advertise the interconnect topology information.¶

This document defines the Inter-AS Link NLRI and some new TLVs for BGP-LS to cover scenarios where an network controller needs to get the interconnection topology information between different AS domains when sourced from IGPs. These additions may also be used as an alternative to [RFC9086] for a BGP-LS topology scenario defined in Section 8.¶

Automatically building the inter-AS view is possible when both sides are upgraded to support the extensions. The correlation depends on the accuracy of the information that is available to a peer.¶

4. Inter-AS Domain Scenarios

Figure 1 illustrates the multi-domain scenarios discussed in this document. Typically, an 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.¶

In Figure 1, S2 (in IGP domain A) and T1 (in IGP domain B) are connected to the SDN controller via BGP-LS, but they can only report the topology information within the IGP A and IGP B themselves, and can't report the Inter-AS topology information between them because there is no IGP protocol running on the Inter-AS links. The border routers, SB1/SB3 in IGP A and TB2/TB4 in IGP B know the Inter-AS links among them, and can advertise such information via underlying OSPF [RFC5392] or IS-IS [RFC9346], but there is no place in [RFC9552] to transfer such information.¶

                        +-----------------+
                 +------+ SDN Controller  +-----+
                 |      +-----------------+     |
                 |                              |
                 |BGP-LS                        |BGP-LS
                 |                              |
 +---------------+-------+               +------+--------------+
 | +--+         +|-+   +-+-+           +-+-+   +|-+        +--+|
 | |S1+---------+S2+---+SB1+-----------+TB2+---+T1+--------+T2||
 | +-++         +--+   +-+-+           +-+-+   +--+        +-++|
 |   |                   |               |                   | |
 |   |                   |               |                   | |
 | +-++        +--+    +-+-+           +-+-+   +--+        +-++|
 | |S4+--------+S3+----+SB3+-----------+TB4+---+T3+--------+T4||
 | +--+        +--+    +-+-+           +-+-+   +--+        +--+|
 |                       |               |                     |
 |                       |               |                     |
 |       IGP A           |               |      IGP B          |
 +-----------------------+               +---------------------+

             Figure 1: Inter-AS Domain Scenario

5. Inter-AS Link NLRI

[RFC9552] defines four NLRI types (Node, Link, IPv4 Topology Prefix, and IPv6 Topology Prefix) to transfer the topology and prefix information. For an Inter-AS link, as the two ends of the link belong in different IGP domains and the link does not run an IGP protocol, it is not appropriate to advertise their information within the existing NLRI types listed above.¶

This document defines a new NLRI type 7 (see Section 12) within the BGP-LS NLRI, referred to as the Inter-AS Link NLRI. The Inter-AS Link NLRI is encoded in the format shown in Figure 2 as explained below:¶

      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
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                           (8 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //              Local Node Descriptors (variable)              //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //           Inter-AS Link Descriptors (variable)              //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Inter-AS Link NLRI Format

This section describes the encoding of the Inter-AS Link NLRI while the more detailed procedures for sourcing of this information from the underlying IGP are described in Section 7.¶

The "Protocol-ID" is set to the value indicating the source protocol of the Inter-AS Link information, as specified in Section 5.2 of [RFC9552]. When the information is sourced from OSPF or IS-IS, the value MUST correspond to one of IGP values as specified in [RFC9552].¶

The semantics of the "Identifier" field are the same as defined in [RFC9552] and MUST be set to the BGP-LS Instance Identifier to identify the IGP domain into which the information associated with the Inter-AS link is advertised. Therefore, the "Identifier" values for the two half-links (refer to section 5.2.2 of [RFC9552]) of the Inter-AS link SHOULD be different depending on the configuration of Identifiers for the two IGP domains.¶

The "Local Node Descriptors" field is encoded using the TLV 256 defined in section 5.2.1.2 of [RFC9552] to identify the ASBR associated with the specific half-link of the Inter-AS link. The following Sub-TLVs are included as the Local Node Descriptors:¶

- Autonomous System (TLV 512) section 5.2.1.4 of [RFC9552] MUST be included.¶

- OSPF Area-ID (TLV 514) section 5.2.1.4 of [RFC9552] MUST be included only in the case of OSPF, when the Inter-AS TE LSA from which information is sourced is being flooded with an area-scope. It is not included when the LSA is flooded with AS-scope.¶

- IGP Router ID (TLV 515) MUST be included, encoded for either OSPF or IS-IS, depending on the source protocol as specified in section 5.2.1.4 of [RFC9552].¶

- One or both of IPv4 and IPv6 Router-ID of the ASBR using TLV 1028 and/or 1029 [RFC9552], depending on whether the ASBR is configured with one or both of the IPv4 and IPv6 TE Router-IDs. If both are known, then both MUST be present. (Note: while [RFC9552] introduced these TLVs for use in the BGP-LS attribute, this document also leverages the same TLVs for use in the NLRI.)¶

Inter-AS Link Descriptors are encoded as TLVs that identify the specific half-link of the Inter-AS link. Section 6 of this document introduces the TLVs that MUST be included as the Inter-AS Link Descriptors:¶

- Remote AS Number (TLV 270), and¶

- One or both of IPv4 and IPv6 Remote ASBR ID using TLV 271 and/or TLV 272, depending on whether the Remote ASBR is configured with one or both of the IPv4 and IPv6 TE Router-IDs.¶

Additionally, the following TLVs MUST be included as Inter-AS Link Descriptors if they are being advertised in the underlying IGP advertisement of the Inter-AS link as they help identify individual links when there is more than one Inter-AS link between two ASBRs.¶

- Link Local/Remote Identifiers (TLV 258) section 5.2.2 of [RFC9552]¶

- IPv4 Interface Address (TLV 259) section 5.2.2 of [RFC9552]¶

- IPv4 Neighbor Address (TLV 260) section 5.2.2 of [RFC9552]¶

- IPv6 Interface Address (TLV 261) section 5.2.2 of [RFC9552]¶

- IPv6 Neighbor Address (TLV 262) section 5.2.2 of [RFC9552]¶

6. Inter-AS Link Descriptor TLVs

This document introduces three TLVs for inclusion as Inter-AS Link Descriptors within the Inter-AS 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: Inter-AS Link Descriptor TLVs

The encoding of these TLVs is aligned with the corresponding advertisements in [RFC9346] and [RFC5392], which keeps the BGP-LS protocol agnostic to the underlying 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, 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. For OSPF, refer to IPv4 Remote ASBR ID Sub-TLV in [RFC5392]; for IS-IS, refer to the IPv4 Remote ASBR Identifier Sub-TLV in [RFC9346].¶

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. For OSPF, refer to IPv6 Remote ASBR ID Sub-TLV in [RFC5392]; for IS-IS, refer to IPv6 Remote ASBR Identifier Sub-TLV in [RFC9346].¶

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(unicast or link-local IPv6 address). If the neighboring ASBR does not have an IPv6 address, the IPv4 Remote ASBR ID TLV MUST be included instead. If both are known, then both MUST be present.¶

7. Advertisement of IGP Information for Inter-AS Links

Advertisement of Inter-AS Links along with their TE information 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]¶

The routers that connect to an SDN controller via the BGP-LS protocol within each domain will advertise the information from the above IGPs for the Inter-AS link. To retrieve the Inter-AS topology, the Autonomous System TLV, Remote AS number, IPv6 Remote ASBR ID and/or IPv4 Remote ASBR ID MUST be presented within the Inter-AS Link NLRI of each Inter-AS link.¶

When advertising these Inter-AS Links from the IGPs into BGP-LS as Inter-AS Links, the sourcing of information for the Inter-AS Link NLRI except for the Inter-AS 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 Inter-AS Link Descriptor TLVs of the Inter-AS Link 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 the 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 Inter-AS Link NLRI of that specific link.¶

8. Solutions for other Alternative Scenarios

In some scenario, it is possible that the router running BGP-LS acts as also the role of the ASBR. Take the topology in following figure as the example:¶

In this alternative topology, it is SB1, which is also the ASBR of IGP A, runs BGP-LS protocol with an SDN controller. All other information are kept the same as that in Figure 1.¶

                        +-----------------+
                 +------+  SDN Controller +-----+
                 |      +-----------------+     |
                 |                              |
                 +-------+BGP-LS                |BGP-LS
                         |                      |
 +-----------------------+               +------+--------------+
 | +--+         +--+   +-+-+           +-+-+   ++-+        +--+|
 | |S1+---------+S2+---+SB1+-----------+TB2+---+T1+--------+T2||
 | +-++         +--+   +-+-+           +-+-+   +--+        +-++|
 |   |                   |               |                   | |
 |   |                   |               |                   | |
 | +-++        +--+    +-+-+           +-+-+   +--+        +-++|
 | |S4+--------+S3+----+SB3+-----------+TB4+---+T3+--------+T4||
 | +--+        +--+    +-+-+           +-+-+   +--+        +--+|
 |                       |               |                     |
 |                       |               |                     |
 |       IGP A           |               |      IGP B          |
 +-----------------------+               +---------------------+

             Figure 7: Alternative Inter-AS Domain Scenario

To retrieve the Inter-AS topology among IGP A and IGP B in alternative scenario in Figure 7, one possible solution is to utilize the BGP EPE [RFC9086] solution on SB1 (reports the local information via the Link NLRI with 'protocol-id' set to 'BGP'), plus the solution proposed in Section 5 of this document that pass the BGP-LS Inter-AS NLRI on another ASBR (e.g. SB3 in Figure 7) with 'protocol-id' set to 'OSPF' or 'IS-IS').¶

Another solution for the use case shown in Figure 7 allows the SBI to directly put into BGP-LS an Inter-AS Link NLRI indicating the source is a local route (directly connected interface or static route) that the ASBR uses to get to the Inter-AS link. Given this topology, SB1 sends the BGP-LS NLRI with the Inter-AS NLRI with the following settings:¶

• ‘protocol-id – set to 'direct' or 'static' per definition in [RFC9552],¶

• Local Node Descriptors include:¶

o Autonomous System (TLV 512) [RFC9552],¶

o IGP Router-ID (TLV 515), and¶

o Inter-AS Link Descriptors (per Section 6).¶

The above information on SB1 is configured locally, and the same information on SB3 is from OSPF/IS-IS.¶

Alignment between the two sides of the Inter-AS link (e.g. SB1 – TB2) that uses the source of “static” or “direct” is made by a controller mapping the AS-number and IP Address supported by the Inter-AS Link information (Section 5 and Section 6).¶

9. Inter-AS Topology Use Case

[RFC8735] section 3.3 "Traffic Engineering for Multi-domain" describes the scenario that the service provider needs to do traffic engineering from end to end that spans multiple domains. To program the end to end path, and let the traffic pass the non-congested links, especially the links that interconnect to the different domains, an SDN controller that covers all these domains which belong to the service provider needs to know the Inter-AS topology information from the Inter-AS Link NLRI via the BGP-LS. It binds the half link information from each domain together, calculates the end-to-end path for the assured service traffic and uses the final path information to control the transmission of the assured traffic.¶

The use case can also be explained via the scenario described in Figure 1.¶

If S1 wants to send traffic to T2 with assured performance, it should know the end-to-end path from the SDN controller, especially the connection topology among the four border routers (SB1, SB3, TB2 and TB4).¶

Such connection topology information is sent by S2 and T1 respectively via the BGP-LS protocol, to the SDN controller. The SDN controller can then stick the two IGP domain topologies together, calculate the end-to-end path that spans two IGP domains and their inter-connection links, guide the traffic from S1 (in IGP A) to T2 (IGP B) traverse the desired nodes and links.¶

If there are no inter-connection links from the Inter-AS NLRI that is defined in this document, an SDN controller can't stick the two IGP domains together and can't then calculate the end-to-end path for the communication nodes located in different domains.¶

10. Operational Considerations

The extensions defined in this document are intended primarily for deployments in which a controller collects topology information from multiple ASes under a common administrative control. A typical deployment consists of one or more BGP-LS speakers in each AS advertising the intra-AS topology together with the Inter-AS Link NLRIs to a centralized or logically centralized controller. The controller correlates the information advertised from the two ends of an Inter-AS link and constructs an inter-AS topology as described in Section 9.¶

The Inter-AS Link NLRI introduces additional topology state into BGP-LS. The amount of additional state is generally proportional to the number of Inter-AS links advertised to the controller. In networks containing a large number of ASes or Inter-AS links, operators should consider the resulting increase in BGP-LS state, update processing, and controller processing. Changes to an Inter-AS link or its associated attributes may result in BGP-LS updates in addition to the updates associated with the intra-AS topology. Operators should therefore apply the same scaling, filtering, and session-engineering practices used for other BGP-LS topology information, and should advertise only the Inter-AS topology information required by the consuming applications.¶

Deployment of the extensions does not require all routers in an AS to support the Inter-AS Link NLRI. Only the routers that originate the relevant Inter-AS information into the IGP, the BGP-LS speakers that export this information, and the BGP-LS consumers that process the new NLRI need to support the corresponding functions. This allows the extensions to be introduced incrementally. A BGP-LS consumer that does not support the Inter-AS Link NLRI cannot use the information defined in this document to construct the corresponding Inter-AS links.¶

An Inter-AS link is normally represented by information learned from each side of the link. The controller correlates these advertisements using the local and remote AS information and the ASBR identifiers carried in the Inter-AS Link NLRI. If the two advertisements cannot be correlated, the controller may observe an unpaired or incomplete Inter-AS link rather than a complete link between the two ASes.¶

When troubleshooting such a condition, an operator should first verify that the Inter-AS link information is correctly originated on both ASBRs and is present in the corresponding OSPF or IS-IS advertisements described in Section 7. The operator should then verify that the BGP-LS speakers have received the information and advertised the corresponding Inter-AS Link NLRIs to the controller. In particular, the Remote AS Number and the IPv4 and/or IPv6 Remote ASBR ID should be checked for consistency with the Local Node Descriptors advertised from the opposite side of the link. Operators should also check BGP-LS import/export policies and filtering along the path to the controller, since filtering one of the advertisements may leave the controller with only one half of the Inter-AS link.¶

Implementations are encouraged to provide operational visibility into Inter-AS Link NLRIs, including their source protocol, local and remote AS numbers, local and remote ASBR identifiers, and whether the controller was able to correlate the advertisements from the two ends of a link. Such information can help distinguish an error in the underlying IGP advertisement from filtering or propagation problems in BGP-LS and from a correlation failure at the controller.¶

The topology information described in this document can reveal information about interconnections between ASes. Operators should therefore control the scope of its distribution using existing BGP policy mechanisms. In particular, advertisements should be limited to the BGP-LS consumers that require the information.¶

11. 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 Metropolitan-Area Networks (MANs), and Data Centers (DCs). 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 Inter-AS Link characteristics does not cause issues within a "walled garden". However, the Inter-AS 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 or filtering it before it leaves the walled garden.¶

12. 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:¶

12.1. New BGP-LS NLRI type

IANA has allocated a codepoint for the Inter-AS Link NLRI type from the "BGP-LS NLRI Types" registry in the "Border Gateway Protocol – Link State (BGP-LS) Parameter" Group:¶

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |   NLRI Type       |        Reference          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       7       | Inter-AS Link NLRI|      This document        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 8:  Inter-AS Link NLRI Codepoint

12.2. New Inter-AS Link Descriptors

IANA has allocated codepoints for the following TLVs from "BGP-LS NLRI and Attribute TLVs" registry in the "Border Gateway Protocol – Link State (BGP-LS) Parameter" Group. They are used as Inter-AS Link Descriptor TLVs:¶

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TLV Code Point  |   Description         |      Reference        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      270          | Remote AS Number      |     This document     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      271          |  IPv4 Remote ASBR ID  |     This document     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      272          |  IPv6 Remote ASBR ID  |     This document     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 9:  BGP-LS Inter-AS Link Descriptors TLV

14. References

14.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3630]: Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, October 2003, <https://www.rfc-editor.org/info/rfc3630>.
[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, January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC7426]: Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <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, February 2023, <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, December 2023, <https://www.rfc-editor.org/info/rfc9552>.

14.2. Informative References

[RFC8735]: Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, "Scenarios and Simulation Results of PCE in a Native IP Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, <https://www.rfc-editor.org/info/rfc8735>.
[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, August 2021, <https://www.rfc-editor.org/info/rfc9086>.