SRv6 Traffic Engineering
– BGP Egress Peer Engineering Technical Whitepaper

In traditional inter-domain networks, an SRv6 TE Policy can use a Node SID to steer service traffic toward a designated Autonomous System Border Router (ASBR). However, a Node SID only identifies the destination node. It cannot specify which EBGP peer or external link the traffic should use after reaching the ASBR to leave the local autonomous system. When an ASBR connects to multiple external peers, or to the same peer through multiple physical links, the final egress is typically determined by local BGP best-path selection and Equal-Cost Multipath (ECMP). Therefore, Node SID can control the path within the domain, but it cannot provide precise control over the inter-domain egress.

BGP Egress Peer Engineering (BGP EPE) is introduced to address this limitation. BGP EPE assigns dedicated Peer SIDs to EBGP peers, peering links, or peer sets. This turns the inter-domain egress, which is normally selected implicitly by BGP, into a network resource that can be explicitly steered by an SRv6 Policy. A controller can add a PeerNode SID, PeerAdj SID, or PeerSet SID to the SID List. After the traffic reaches the ASBR, the policy can continue to steer it toward a specific EBGP peer, physical egress link, or set of egress paths. This extends SRv6 TE control from intra-domain path selection to precise inter-domain egress engineering.

In traditional BGP networks, devices compare candidate paths based on factors such as Local Preference, AS_PATH, Origin, MED, eBGP/iBGP relationship, and the IGP cost to the BGP next hop. The device selects the best path and installs it in the routing and forwarding tables. Routing policies can modify these attributes to influence path selection. As a result, they have long been the primary mechanism for controlling inter-domain egress.

However, traditional routing policies generally operate on route prefixes and their attributes. For example, modifying Local Preference or Community can influence egress selection for a group of prefixes. This approach is mature and reliable. It is suitable for global policies, primary/backup egress, and coarse-grained traffic optimization. However, if different services accessing the same destination prefix need to use different egress paths, changing the BGP best path can affect all traffic matching that prefix. When policies also need to distinguish between service types, users, source addresses, or real-time network conditions, configuration and maintenance become significantly more complex.

Unlike attribute-based path selection, BGP EPE represents EBGP peers and external peering links as SRv6 Peer SIDs that can be directly steered. By adding a PeerNode SID, PeerAdj SID, or PeerSet SID to the SID List of an SRv6 Policy, a controller can explicitly specify which peer, physical link, or peer set the traffic uses after reaching the ASBR. In other words, traditional routing policies influence which path BGP selects, while BGP EPE enables specific traffic to use a designated egress. The two mechanisms are complementary rather than mutually exclusive. BGP and routing policies continue to handle basic route propagation, reachability, and normal best-path selection. BGP EPE adds the missing control between reaching the border node and selecting the inter-domain egress, enabling more granular end-to-end traffic engineering across domains.

To enable a controller to directly specify egress selection in an SRv6 Policy, BGP EPE supports automatic or static Peer SID allocation. Based on the forwarding object identified by the Peer SID and the level of control it provides, this article focuses on the following three common types:

A PeerNode SID identifies a BGP peer. BGP EPE can assign a corresponding PeerNode SID to each BGP session, allowing the controller to steer traffic through a specific peer to leave the local autonomous system.

When a device establishes an EBGP session with a remote device through a Loopback interface, multiple physical links may be available to reach that peer. In this case, a single PeerNode SID can be associated with multiple valid egress interfaces. Traffic matching the PeerNode SID is load-balanced across these interfaces. Therefore, a PeerNode SID controls which BGP peer the traffic uses to leave the autonomous system, but does not specify a particular physical link to that peer.

A PeerAdj SID identifies an adjacency link that reaches a specific BGP peer. Unlike a PeerNode SID, which represents the entire peer, a PeerAdj SID directly identifies a specific egress adjacency.

When a device establishes an EBGP session through a Loopback interface and reaches the same peer through multiple physical links, BGP EPE can assign a separate PeerAdj SID to each physical link. When forwarding traffic based on a PeerAdj SID, the device uses only the egress link associated with that SID. It does not load-balance traffic across other links to the same peer.

Compared with a PeerNode SID, a PeerAdj SID provides finer-grained egress control. It is suitable for scenarios that require a specific physical link, need to avoid a congested link, or require deterministic path selection.

A PeerSet SID identifies a group of BGP peers in a BGP EPE SRv6 Peer Set. It allows multiple egress paths with common service attributes to be treated as a logical resource pool.

A PeerSet SID can be associated with multiple PeerNode SIDs or PeerAdj SIDs. When forwarding traffic based on a PeerSet SID, the device can load-balance traffic across valid peers and their associated adjacency links within the Peer Set.

PeerSet SID is suitable for grouping multiple egress paths with common service attributes into a logical resource pool. For example, these may include multiple peers belonging to the same remote AS, having similar link costs, or providing the same service level. The ingress SRv6 Policy only needs to reference a single PeerSet SID. The border router can then perform load balancing or failover among the members of the set. Changes to the egress members do not require corresponding changes to the ingress policy.

The following cross-domain network example illustrates how different Peer SIDs are allocated and used for forwarding in a real network.

As shown in the figure, AS 100 establishes inter-domain EBGP connections with AS 200 and AS 300 through ASBR1 and ASBR2, respectively. Both AS 200 and AS 300 can further reach AS 400, giving AS 100 multiple available inter-domain egress paths. BGP EPE can represent these peers and external links as Peer SIDs with different levels of granularity. This allows the controller to select a specific peer, a specific physical link, or a group of egress paths based on service requirements.

• ASBR1 and ASBR3 are connected through two directly connected physical links and establish an EBGP peering relationship through their Loopback interfaces. On ASBR1, BGP EPE assigns PeerNode SID 100:AB:1::1 to peer ASBR3, and assigns PeerAdj SIDs 100:AB:1::2 and 100:AB:1::3 to the two physical links, respectively. When ASBR1 forwards traffic based on PeerNode SID 100:AB:1::1, the traffic is steered through ASBR3 into AS 200, without specifying either physical link. Both valid links can therefore participate in load balancing. When traffic matches PeerAdj SID 100:AB:1::2 or 100:AB:1::3, it is forwarded only through the physical link associated with that SID to ASBR3.

• ASBR2 establishes EBGP peering relationships with ASBR3 and ASBR4. Since both AS 200, where ASBR3 resides, and AS 300, where ASBR4 resides, can reach AS 400, ASBR2 can add the two peers to the same BGP EPE Peer Set and assign the PeerSet SID 100:AB:4::2 to the set. When ASBR2 forwards traffic based on this PeerSet SID, it can load-balance traffic between ASBR3 and ASBR4. Some traffic enters AS 200 through ASBR3, while other traffic enters AS 300 through ASBR4. AS 200 and AS 300 then continue forwarding the traffic toward ASBR5 in AS 400. With this approach, the ingress policy only needs to reference the PeerSet SID. It does not need to specify each peer in the set individually.

This example uses traffic from CE1 to CE2 in VPN A to illustrate the complete workflow of BGP EPE working with an SRv6 TE Policy, from establishing basic reachability and advertising service routes to policy deployment and data forwarding.

1. Establishing Basic Reachability

PE1, ASBR1, ASBR2, and PE2 each advertise their respective SRv6 Locator routes. Intra-domain Locators are distributed through IS-IS, while inter-domain Locators are advertised through EBGP. This provides each node with basic IPv6 reachability to the nodes associated with the SIDs. At the same time, ASBR1 assigns BGP EPE SID 200:1::10 to the EBGP peer with ASBR2. This SID identifies the specific inter-domain egress.

2. Advertising Service Routes

CE2 advertises the private IPv4 route 2.2.2.2 to PE2. PE2 assigns End.DT4 SID 400:1::1 to the VPN instance and advertises the VPNv4 route to PE1 through MP-EBGP, along with a Color Extended Community. The End.DT4 SID is used for decapsulation and VPN table lookup when the traffic reaches PE2. The Color is used by PE1 to associate the route with the corresponding SRv6 TE Policy.

3. Deploying the SRv6 TE Policy

The controller creates an SRv6 TE Policy on the headend PE1, identified by Color 100 and the remote endpoint, and assigns it a Binding SID (BSID) 100:1::10. The policy’s SID List contains the following SIDs in order: the End SID 200:1::2 of ASBR1, the BGP EPE SID 200:1::10 on ASBR1, the End SID 300:1::2 of ASBR2, and the End SID 400:1::2 of PE2. The regular End SIDs steer packets toward the specified nodes, while the BGP EPE SID selects the inter-domain peer or egress on ASBR1.

4. Matching the Ingress Policy and Encapsulation

When PE1 receives a service packet destined for 2.2.2.2, it uses the Color carried in the VPN route to match the corresponding SRv6 TE Policy. PE1 encapsulates the original IPv4 packet with an IPv6 header and an SRH. It then combines the End.DT4 SID 400:1::1 carried in the VPN route with the SID List in the TE Policy to form the complete forwarding instruction. The outer IPv6 destination address is initially set to the first active SID in the SID List, 200:1::2.

5. Selecting the Inter-Domain Egress

When the packet reaches ASBR1, it first executes End SID 200:1::2 and updates the active SID to the BGP EPE SID 200:1::10. ASBR1 then performs the forwarding behavior associated with this Peer SID. The packet is therefore forwarded through the inter-domain egress toward ASBR2 as specified by the policy, rather than relying entirely on the normal BGP best-path selection for the destination prefix. The packet then continues through the SID List to ASBR2 and PE2.

6. Tunnel Decapsulation

When the packet reaches PE2 and completes the processing of the node SIDs along the TE path, it ultimately matches End.DT4 SID 400:1::1. PE2 removes the outer IPv6 header and SRH, performs a lookup for the original IPv4 destination 2.2.2.2 in the corresponding VPN instance, and forwards the packet to CE2. In this workflow, the SRv6 TE Policy controls the intra-domain and inter-domain path, BGP EPE provides additional control over the specific ASBR egress, and the End.DT4 SID completes VPN service delivery.

1. Enter BGP configuration mode.

  router bgp <AS_number> [vrf <vrf_name>]

2. Enable SRv6 BGP EPE.

  egress-engineering enable

3. Bind the Locator.

  segment-route srv6
   locator <locator_name>

1. Enter BGP configuration mode

    router bgp <AS_number> [vrf <vrf_name>]

2. Enable SRv6 BGP EPE for the specified BGP peer.

    neighbor <peer-ip> egress-engineering peer-node-sid {auto|<node_ID>}

1.  Enter BGP configuration mode.

    router bgp <AS_number> [vrf <vrf_name>]

2. Enable SRv6 BGP EPE for the specified link.

    Egress-engineering adjacency <nexthop_ip> adjacency-sid {auto|<node_ID>}

If a device has BGP peering relationships with multiple remote devices, these peers can be added to the same Peer Set, and a PeerSet SID can be assigned to the Peer Set. When forwarding traffic based on the PeerSet SID, the device can load-balance traffic across the valid peers in the Peer Set.

1. Enter BGP configuration mode.

    router bgp <AS_number> [vrf <vrf_name>]

2. Create a BGP EPE Peer Set.

    Egress-engineering peer-set <peer_set_name> peer-set-sid {auto|<node_ID>}

3. Add the neighbor to the Peer Set.

    neighbor <peer-ip> egress-engineering peer-set <peer_set_name>