BGP-LS Extensions for Inter-AS Topology Retrieval

BGP-LS describes the use of the BGP protocol for advertising Link-State topology information. It enables applications such as Software-Defined Network Controllers to collect the underlay network topology. 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 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 a network controller needs to get the interconnection topology information between different AS domains when such information is sourced from IGPs. These additions may also be used as an alternative to for a BGP-LS topology scenario defined in . Automatically building the inter-AS view is possible when the sender and receiver of BGP-LS are upgraded to support the extensions. The correlation depends on the accuracy of the information that is available to a BGP-LS receiver/consumer.

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 when, and only when, they appear in all capitals, as shown here.

The following terms are defined in this document: DC: Data Center SDN: Software-Defined Network

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 BGP-LS, but it cannot obtain topology connection information between these two IGP domains, as IGP protocols do generally not run over 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, respectively. They cannot report the Inter-AS topology information between them because there is no IGP protocol runs over the Inter-AS links. The border routers SB1/SB3 (in IGP A) and TB2/TB4 (in IGP B) are aware of the Inter-AS links connecting them, and can advertise such information via underlying OSPF or IS-IS ; however, currently lacks an encoding to convey this information in BGP-LS.

defines four NLRI types (Node, Link, IPv4 Topology Prefix, and IPv6 Topology Prefix) to carry the topology and prefix information. For an Inter-AS link, since the two ends of the link belong to different IGP domains and the link does not run an IGP protocol, it is not appropriate to advertise its information using the existing NLRI types listed above. This document defines a new NLRI type 7 (see ) 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:

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 . The "Protocol-ID" field is set to the value indicating the source protocol of the Inter-AS Link information, as specified in Section 5.2 of . The semantics of the "Identifier" field are the same as defined in 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 ) of the Inter-AS link SHOULD be different depending on the configuration of Identifiers for the two IGP domains. The consumer of the Inter-AS Link NLRI MUST use (ASN, BGP-LS ID) tuple to distinguish the IGP domains in different ASes. This behavior takes precedence over the requirement in Section 5.2 of to assign unique BGP-LS Instance-IDs to routing protocol instances operating in different IGP domains. The "Local Node Descriptors" field is encoded using the TLV 256, as defined in Section 5.2.1.2 of ,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) MUST be included. - OSPF Area-ID (TLV 514) (Section 5.2.1.4 of) 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 MUST NOT be 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 . - One or both of the IPv4 and IPv6 Router-IDs of the ASBR using TLV 1028 and/or TLV 1029 , 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 introduced these TLVs for use in the BGP-LS attribute, this document also leverages them for use in the NLRI.) The 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 - IPv4 Interface Address (TLV 259), Section 5.2.2 of - IPv4 Neighbor Address (TLV 260), Section 5.2.2 of - IPv6 Interface Address (TLV 261), Section 5.2.2 of - IPv6 Neighbor Address (TLV 262), Section 5.2.2 of

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.

The encoding of these TLVs is aligned with the corresponding advertisements in and , which keeps the BGP-LS protocol agnostic to the underlying protocol.

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. Its format is as follows:

The Remote AS Number field has 4 octets in length. When only 2 octets are used for the AS number, the left (high-order) 2 octets MUST be set to 0. If not, the receiver will mistreat it as the 4 octets AS number and then can not retrieval the Inter-AS topology correctly.

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 the IPv4 Remote ASBR ID Sub-TLV in ; for IS-IS, refer to the IPv4 Remote ASBR Identifier Sub-TLV in . The IPv4 Remote ASBR ID TLV is TLV Type 271 and is 4 octets in length. Its format is as follows:

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 the IPv6 Remote ASBR ID Sub-TLV in ; for IS-IS, refer to IPv6 Remote ASBR Identifier Sub-TLV in . The IPv6 Remote ASBR ID TLV is TLV Type 272 and is 16 octets in length. Its format is as follows:

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. If both are known, then both MUST be present.

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 - In OSPFv3 via the Inter-AS-TE-v3 LSA - In IS-IS via the Inter-AS Reachability Information TLV (TLV 141) As indicated in and , 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. The consumer of such information can then retrieve the Inter-AS topology from it. When advertising these Inter-AS Links from the IGPs into BGP-LS as Inter-AS Links, with the exception of the Inter-AS Link Descriptors, the sourcing of information for the Inter-AS Link NLRI follows the same procedures as specified in . The information about the Remote AS Number and the IPv4/IPv6 Remote ASBR IDs specified in is derived from the Remote AS Number and IPv4/IPv6 Remote ASBR ID TLVs specified for OSPF/IS-IS in and 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 and ; their procedures are therefore the same as in . The OSPF/IS-IS 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 and other BGP-LS extensions in the BGP-LS Attribute associated with the Inter-AS Link NLRI of that specific link.

In some scenario, a router running BGP-LS may also act as an ASBR. Take the topology in following figure as the example: In this alternative topology, it is SB1, which is also an ASBR in IGP A, runs the BGP-LS protocol with an SDN controller. All other information is kept the same as that in Figure 1.

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 solution on SB1 (reports the local information via the Link NLRI with Protocol-ID set to 'BGP'), plus the solution proposed in 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 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 with the Inter-AS NLRI with the following settings: • Protocol-ID – set to 'Direct' or 'Static configuration' per definition in Section 5.2 of , • Local Node Descriptors include: o Autonomous System (TLV 512) (Section 5.2 of ), o IGP Router-ID (TLV 515) (Section 5.2 of ), and o Inter-AS Link Descriptors (per ). 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 ( and ).

Section 3.3 of (Traffic Engineering for Multi-domain) describes a scenario in which a service provider needs to perform end-to-end traffic engineering across 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 stitch the two IGP domain topologies together, calculate the end-to-end path that spans two IGP domains and their interconnection links, guide the traffic from S1 (in IGP A) to T2 (in IGP B) to traverse the desired nodes and links. If there are no interconnection links from the Inter-AS NLRI that is defined in this document, an SDN controller cannot stitch the two IGP domains together and is unable to calculate the end-to-end path for the communication nodes located in different domains.

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 . 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 . 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. Either the IPv6 Remote ASBR ID or IPv4 Remote ASBR ID MUST be presented in the Inter-AS Link Descriptors. In particular, the Remote AS Number and the IPv4 and/or IPv6 Remote ASBR ID should be checked for consistency with the Inter-AS Link 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.

BGP-LS security is specified in . 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 controlled administrative domain. 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 controlled administrative domain or filters it before it leaves the controlled administrative domain.

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

IANA has allocated (via Early Allocation) a codepoint for the Inter-AS Link NLRI type from the "BGP-LS NLRI Types" registry under the "Border Gateway Protocol - Link State (BGP-LS) Parameters" group:

IANA has allocated (via Early Allocation) codepoints for the following TLVs from "BGP-LS NLRI and Attribute TLVs" registry under the "Border Gateway Protocol - Link State (BGP-LS) Parameters" group. They are used as Inter-AS Link Descriptor TLVs:

The authors would like to thank Susan Hares, Mohamed Boucadair, Mahesh Jethanandani, Éric Vyncke, Acee Lindem, Jie Dong, Shaowen Ma, Jeff Tantsura and Dhruv Dhody for their valuable comments and suggestions.