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

1.1. The IXP Route-Server Decoupling Problem

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

3.1. Scenario 1: Granular Target-Client PeerNode SID

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

3.2. Scenario 2: Aggregated Multi-Path PeerSet SID

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

3.3. Scenario 3: Control-Plane Route-Server PeerNode SID

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

4.1. PeerNode SID Sub-TLV (Type 1101)

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

    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 = 1101 (PeerNode)  |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flags(8-bit)   |   Reserved    |             Weight            |
   |V=1, L=1, S=0  |   0x00        |             0x0000            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SID/Label (20-bit MPLS Label)       |  Exp  |S|
   |                 Value (e.g., 24001)                 |  000  |1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.2. PeerSet SID Sub-TLV (Type 1103)

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

    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 = 1103 (PeerSet)   |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flags(8-bit)   |   Reserved    |             Weight            |
   |V=1, L=1, S=1  |   0x00        |             0x0000            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SID/Label (20-bit MPLS Label)       |  Exp  |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.3. Peer Descriptor Sub-TLVs (Types 1105, 1106, 260)

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

   o  Peer AS Sub-TLV (Type 1105):
      *  Type (2 octets): 1105.
      *  Length (2 octets): 4.
      *  Value (4 octets): The 32-bit Autonomous System number. In
         Scenario 1, this MUST reflect the true Origin AS of the target
         Client BR rather than the RS AS.

   o  Peer BGP Router-ID Sub-TLV (Type 1106):
      *  Type (2 octets): 1106.
      *  Length (2 octets): 4.
      *  Value (4 octets): The 4-octet BGP Router-ID identifying the
         specific target Client BR.

   o  Remote Interface IP Address TLV (Type 260):
      *  Type (2 octets): 260.
      *  Length (2 octets): 4 for IPv4 or 16 for IPv6.
      *  Value: Under this document's specification for Scenario 1, this
         field MUST contain the literal IP address parsed from the BGP
         NEXT_HOP attribute ($IP_Client). This binds the EPE SID
         explicitly to the data-plane-active interface of the target
         Client BR inside the IXP fabric.

5.1. SID Creation and Triggering Logic

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

5.2. Dynamic Hardware and ARP/ND Co-location

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

5.3. SID Withdrawal and Aging Mechanics

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

• 1. 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.¶

  2. Purge the explicit NHLFE binding from the hardware forwarding pipeline.¶

  3. Release the allocated label or index back into the local SRLM pool for future assignment.¶

10.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>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC7854]

Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.

[RFC7908]

Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, <https://www.rfc-editor.org/info/rfc7908>.

[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>.

[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>.

10.2. Informative References