Interface Index Capability for BGP

Here are several issues that arise when using unnumbered links due to BGP's lack of support for interface index. Scenario 1: BGP-LS-SPF BGP-LS-SPF is a solution that leverages both the BGP protocol and the BGP-LS extension . In the BGP SPF routing domain, BGP routers collect network-wide topology information through the BGP-LS-SPF protocol and perform cross-domain path calculation to compute routes using the SPF algorithm. This approach aims to achieve intelligent traffic engineering and automated routing optimization in large-scale data center or carrier networks. When an IGP protocol advertises an unnumbered link, it uses the local interface index and the remote interface index to distinguish between different unnumbered links. BGP-LS-SPF reuses the BGP-LS information from the IGP. However, during the deployment of BGP-LS-SPF, if the remote interface index is unknown, it may lead to path calculation errors. Scenario 2: BGP Egress Peer Engineering (EPE) When deploying EPE, the BGP-LS peer link information in EPE is defined as follows (see Section 5.2 of ): Link Descriptors MUST include the following TLV, as defined in :

Link Local/Remote Identifiers (TLV 258) contains the 4-octet Link Local Identifier followed by the 4-octet Link Remote Identifier. The value 0 is used by default when the link remote identifier is unknown.

Currently, BGP has no mechanism to obtain the peer's Link Remote Identifier. Scenario 3: BGP neighbor monitoring During neighbor monitoring, if displaying bidirectional neighbor connectivity, without the Link Remote Identifier, the corresponding neighbor relationships on both sides cannot be matched. Therefore, fundamentally, in unnumbered BGP scenarios, BGP peer information should include: local router-id, peer address, peer AS number, local interface index, and remote interface index. This document defines a new BGP capability, as specified in , for advertising support of the interface index capability, thereby advertising local interface indexes and obtaining neighbor interface indexes.

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 terminology is used in this document.

BGP: Border Gateway Protocol
EPE: Egress Peer Engineering
BGP-LS-SPF: BGP Link State Shortest Path First Routing

In the BGP protocol, the OPEN message carries the newly added Interface Index Capability TLV to exchange interface index information with neighbors. When sending an OPEN message, the Interface Index Capability is included to advertise the Interface Index of the interface used to establish the neighbor relationship. When receiving an OPEN message, if it contains the Interface Index Capability, the peer's Remote Interface Index is saved. If the Interface Index Capability is not carried, save the Remote Interface Index as 0. The format of the Interface Index Capability is shown in .

A BGP speaker that receives an OPEN message containing the Interface Index Capability with a Capability Length (as defined in ) other than 4 MUST treat the capability as malformed and ignore it. In this case, the Remote Interface Index of the peer MUST be set to 0, and the BGP session SHOULD still be established. An implementation MAY log this condition for further analysis. If the Interface Index Value is 0, it indicates that the local interface index of the sender is unknown. The receiver MUST treat the Remote Interface Index as 0, and the BGP session SHOULD still be established. Per , a BGP speaker that does not recognize or does not support the Interface Index Capability MUST silently ignore it, and the procedures described in this document do not apply to that BGP session.

A new BGP Capability named "Interface Index Capability" will be requested from the "Capability Codes" registry within the "IETF Review" range . Capability Codes

Code Point	Description	Reference
TBD	Interface Index Capability	This document

This document defines a new BGP capability that is carried in the OPEN message as specified in ; it does not introduce any new BGP messages or modify the BGP finite state machine. The Interface Index carried in this capability is not considered sensitive information, as it is already advertised by the routing protocols of the local node (e.g., via the Link Local/Remote Identifiers TLV in BGP-LS ). However, a malicious BGP peer could advertise an incorrect Interface Index, which could mislead the receiver in scenarios such as those described in (e.g., causing mismatches when correlating bidirectional neighbor relationships or computing paths over unnumbered links). This document does not introduce any new mechanisms to protect the BGP session beyond those that already exist. Existing mechanisms to protect BGP sessions, such as the Generalized TTL Security Mechanism (GTSM) and the TCP Authentication Option (TCP-AO) , SHOULD be used to protect the integrity of the BGP session.