BGP Egress Peer Engineering (EPE) SID Allocation and Extensions for IXP Route-Server Scenarios

Segment Routing (SR) leverages source routing to enable centralized controllers to program end-to-end paths across multi-domain networks. As extended by , BGP Egress Peer Engineering (EPE) provides the central controller with Segment Identifiers (SIDs) corresponding to the external link, node, or peer set connected to an egress border router (Egress BR). These SIDs are then advertised via BGP Link-State (BGP-LS).

Internet Exchange Points (IXPs) represent a critical component of global inter-domain infrastructure. In a typical public peering IXP setup, an Egress BR connects to a shared Layer 2 switch fabric (the IXP fabric) and peers with a centralized Route-Server (RS). The RS acts as a control-plane broker; it collects routing updates from IXP participants (Client BRs) and redistributes them without modifying the BGP NEXT_HOP attribute. Consequently, the NEXT_HOP of routes learned from the RS points directly to the respective Client BRs, bypassing the RS in the data plane. Standard EPE procedures under [RFC9086] assume that an EPE SID maps to a direct, point-to-point BGP session. In an IXP RS environment, if an Egress BR merely allocates a single PeerNode SID to the RS control-plane session, the controller completely loses visibility into the underlying multi-tenant IXP fabric. It cannot steer traffic to a specific target Client BR or perform load balancing over a select group of peers. This document fills this operational gap by specifying the architecture and strict procedural steps required to instantiate, map, and signal EPE SIDs (PeerNode and PeerSet) within an IXP Route-Server multi-access topology.

The following terms are used in this document in accordance with the conventions defined in , , and standard IXP designs: Egress BR: The local edge router executing BGP EPE and connected to the IXP network. Route-Server (RS): The centralized control-plane server on the IXP that redistributes BGP paths among participants. Client BR: A remote peer router connected to the same IXP fabric that exchanges routes via the RS. NHLFE: Next Hop Label Forwarding Entry. SRLM: Segment Routing Local Label Manager.

When an Egress BR is enabled for BGP EPE in an IXP RS environment, the local EPE engine MUST implement a decoupled tracking model that parses the BGP NEXT_HOP properties rather than the BGP Peer session address. Three distinct allocation scenarios are specified below.

In this scenario, the Egress BR instantiates a discrete PeerNode SID for each individual Client BR accessible via the Route-Server. This enables granular, target-specific egress traffic engineering. The Egress BR MUST execute the following sequence: Step 1: Establish an EPE-enabled BGP session with the IXP Route-Server. Step 2: Parse incoming BGP UPDATE messages received from the RS. The EPE engine MUST bypass the session source IP and extract the literal BGP NEXT_HOP attribute ($IP_Client) and the Origin AS from the AS_PATH. Step 3: Perform a local Layer 2 resolution check. The Egress BR queries its Address Resolution Protocol (ARP) or Neighbor Discovery (ND) cache for $IP_Client to retrieve the associated Hardware Address ($MAC_Client) binding on the shared IXP VLAN interface. Step 4: Request a locally significant SID from the SRLM. The SRLM allocates an unassigned label or index to represent this $IP_Client node segment (e.g., Label 24001). Step 5: Bind the allocated SID to an explicit hardware NHLFE. The entry MUST map to a pop-and-forward behavior: pop the incoming EPE label, encapsulate the inner payload with a destination MAC equal to $MAC_Client, and push the frame directly out of the physical egress interface facing the IXP fabric. Step 6: Construct and originate a BGP-LS Link NLRI containing the newly bound PeerNode SID to notify the upstream SR controller.

Where a remote autonomous system maintains multiple Client BR nodes on the same IXP fabric, or where policy dictates uniform treatment of a cluster of peers, the Egress BR allocates a collective PeerSet SID. The execution steps are defined as follows: Step 1: Perform individual Target-Client PeerNode SID instantiations as defined in Section 3.1 for Client BR-A ($IP_ClientA, Label 24001) and Client BR-B ($IP_ClientB, Label 24002). Step 2: Apply a matching local administrative policy (e.g., match on Origin AS or BGP Community string) to identify that Client BR-A and Client BR-B belong to the same target peer set. Step 3: Request an aggregated segment from the SRLM. The SRLM allocates a unique PeerSet SID (e.g., Label 25001). Step 4: Build a dynamic multipath NHLFE in the forwarding plane. The entry for the PeerSet SID MUST point to an Equal-Cost Multi-Path (ECMP) or Unequal-Cost Multi-Path (UCMP) bucket containing the resolved framer paths of both Client BR-A and Client BR-B. Incoming packets bearing Label 25001 will be load-balanced over the IXP fabric directly to the respective MAC addresses, completely bypassing the RS. Step 5: Package the PeerSet attribute into a BGP-LS Link NLRI containing a PeerSet Sub-TLV for controller orchestration.

To ensure network resiliency and non-disruptive fallback, the Egress BR SHOULD allocate a basic PeerNode SID mapped directly to the Route-Server entity itself. The execution steps are defined as follows: Step 1: Identify the direct control-plane IP address of the Route-Server session ($IP_RS). Step 2: Allocate a standalone PeerNode SID from the SRLM linked strictly to $IP_RS (e.g., Label 24000). Step 3: Construct a standard recursive NHLFE. Unlike the target-client SIDs, this entry MUST execute a label pop followed by a standard recursive lookup in the main BGP routing table (FIB). Step 4: Maintain this SID as a coarse-grained operational fallback. If the controller lacks refined topology data or during transient convergence states, it can apply this SID to enforce path termination at the IXP boundary while letting standard local RIB metrics handle internal IXP dispersion.

In accordance with , the EPE SIDs allocated via the processes above MUST be advertised via BGP-LS using the Link NLRI format. The SIDs are nested within the BGP-LS Link Attribute TLV (Type 1095). This section specifies the exact field layouts, flags, and descriptor values mandatory for correct controller operation.

The PeerNode SID Sub-TLV is used in Scenario 1 (Target Client BR) and Scenario 3 (Route-Server itself). Its internal format is shown below:

Field Definitions: Type (2 octets): 1101, identifying the PeerNode SID Sub-TLV. Length (2 octets): 8, indicating the length of the value fields. Flags (1 octet): V-Flag (Value Flag, bit 0): MUST be set to 1. This specifies that the SID/Label field carries a literal local label value rather than a baseline index. L-Flag (Local Flag, bit 1): MUST be set to 1. This indicates the allocated label value has strictly local significance to the Egress BR. S-Flag (Set Flag, bit 2): MUST be set to 0, confirming this segment describes an individual node endpoint. Reserved (1 octet): MUST be set to 0x00 on transmission and ignored on receipt. Weight (2 octets): 0x0000. Not used for discrete single-node forwarding instances. SID/Label (4 octets, structured as standard MPLS format): Label (20 bits): The explicit 20-bit MPLS label value assigned by the SRLM (e.g., 24001 or 24000). Exp (3 bits): Experimental bits. Set to 000. S (1 bit): Bottom-of-Stack bit. Set to 1 in BGP-LS signaling. To uniquely identify the target context, the Link NLRI Local Descriptor MUST contain the Local BGP Router-ID of the Egress BR. Crucially, the Link NLRI Remote Descriptor and accompanying Attribute Sub-TLVs MUST be aligned as follows: Peer AS Sub-TLV (Type 1105): Contains the Autonomous System number of the targeted Client BR. Peer BGP Router-ID Sub-TLV (Type 1106): Contains the BGP Router-ID of the remote Client BR. Remote Interface IP Address TLV (Type 260): MUST be filled with the literal $IP_Client address extracted from the NEXT_HOP attribute, enabling the controller to cross-reference the data plane interface.

The PeerSet SID Sub-TLV is deployed in Scenario 2 to facilitate group multi-path steering. Its encoding shares the physical layout of the Node SID but injects unique functional parameters:

Field Definitions: Type (2 octets): 1103, identifying the PeerSet SID Sub-TLV. Flags (1 octet): V-Flag (bit 0): MUST be set to 1. L-Flag (bit 1): MUST be set to 1. S-Flag (bit 2): MUST be set to 1. This flag acts as the key differentiator, instructing the controller that multiple links propagated with this exact SID share a common ECMP forwarding group on the Egress BR. SID/Label (4 octets): Contains the common 20-bit MPLS group label value assigned to the load-balancing set (e.g., 25001). Multiple Link NLRIs MAY carry the identical PeerSet SID value if those links are constituent members of the same ECMP load-balancing group programmed in the hardware pipeline of the Egress BR. This allows the central controller to mathematically reconstruct the exact resource pooling boundaries implemented within the egress switching fabric.

To allow the central controller to cross-reference un-peered data plane endpoints across the multi-access IXP network, any Link NLRI carrying an IXP-decoupled EPE SID MUST accompany the following descriptor sub-TLVs within the Link Attributes:

Unlike standard EPE implementations where SIDs are static and bound directly to established peer sessions, the EPE SIDs in an IXP Route- Server environment are strictly data-driven and dynamically managed. Their lifecycle MUST be bound to the existence of valid BGP routing states received from the Route-Server.

The Egress BR MUST NOT allocate an EPE SID for a remote Client BR simply upon connecting to the IXP fabric. The instantiation of the "virtual connection" and its corresponding SID MUST be triggered exclusively by routing updates: Triggering Event: Upon receiving a BGP UPDATE message from the Route-Server, the Egress BR parses the attributes. If the NEXT_HOP attribute contains an IP address ($IP_Client) that does not currently map to any active EPE SID, the local EPE engine MUST initiate the allocation sequence specified in Section 3.1. Deduping Mechanism: If multiple BGP prefixes received from the RS share the identical NEXT_HOP ($IP_Client), they MUST be mapped to the same pre-existing PeerNode SID. The Egress BR MUST NOT allocate redundant SIDs for the same next-hop address. The Egress BR SHOULD immediately trigger an asynchronous ARP (for IPv4) or Neighbor Discovery (for IPv6) solicitation for the extracted $IP_Client upon receiving the routing trigger. The BGP-LS advertisement of the PeerNode SID (Type 1101) MUST be suppressed until the Layer 2 hardware address ($MAC_Client) is successfully resolved and programmed into the local adjacency table. This prevents the central controller from directing traffic to an unresolvable data-plane blackhole.

To ensure data-plane validity, the control-plane SID allocation MUST be strictly tied to Layer 2 resolution status:

When a remote Client BR disconnects from the IXP or withdraws its advertised network footprints, the Egress BR MUST implement an aging and teardown procedure: Tracking State: The Egress BR MUST maintain a reference count of active BGP paths associated with each resolved $IP_Client. Withdrawal Trigger: When a BGP WITHDRAW message is received from the Route-Server, or when paths naturally expire, the reference count for that specific $IP_Client MUST be decremented. Tear-down Execution: When the active path reference count for a particular $IP_Client reaches exactly zero (meaning no remaining prefixes utilize this Client BR as a data-plane next-hop), the Egress BR MUST: Immediately originate a BGP-LS Link NLRI update to withdraw the corresponding PeerNode SID (and any associated PeerSet SIDs) from the controller's topology map. Purge the explicit NHLFE binding from the hardware forwarding pipeline. Release the allocated label or index back into the local SRLM pool for future assignment.

The operational modifications defined in this document do not alter the underlying security properties of BGP-LS or Segment Routing. However, instantiating data plane NHLFE bindings based on unverified BGP NEXT_HOP attributes introduces a risk of traffic redirection or black- holing if a compromised Route-Server injects malicious updates. An Egress BR implementing these procedures MUST perform rigorous Layer 2 neighbor checking as defined in Section 3.1, Step 3. If an incoming NEXT_HOP cannot be mapped to a valid ARP/ND entry within a reasonable timeout window, the corresponding PeerNode SID MUST NOT be programmed into the hardware forwarding plane, and an operational error SHOULD be logged.

This document introduces no new registries. IANA is requested to maintain the existing sub-TLV allocations in the "BGP-LS Node/Link Descriptor Sub-TLVs" registry established by .

The following people made significant contributions to this document:

The authors would like to acknowledge the review and inputs from xxx.