Glossary

BGP EPE

BGP Egress Peer Engineering

What is BGP EPE

BGP EPE (BGP Egress Peer Engineering) is an SRv6 traffic-engineering capability that lets a controller explicitly select which EBGP peer, physical link, or group of peers traffic uses to leave an autonomous system (AS). It does this by assigning a dedicated Peer SID to each EBGP peer, adjacent link, or peer set, turning a decision that BGP would otherwise make implicitly into a network resource that can be programmed directly into an SRv6 Policy's SID List.

BGP EPE exists to close a specific gap in cross-domain SRv6 traffic engineering. An SRv6 TE Policy can use a Node SID to steer traffic to a given autonomous system border router (ASBR), but a Node SID can only express "reach this node" — it says nothing about which EBGP peer or external link the traffic should take once it arrives. When an ASBR has multiple external peers, or multiple physical links to the same peer, the actual egress is normally left to local BGP best-path selection and ECMP. Node SID alone can steer the path inside the domain, but it cannot precisely orchestrate the cross-domain exit. BGP EPE was introduced to extend SRv6's programmability across that last hop.

How BGP EPE Works

Traditional BGP egress selection compares candidate paths using attributes such as Local Preference, AS_PATH, Origin, MED, eBGP/iBGP relationship, and IGP cost to the next hop, then installs a single best path. Routing policy can influence this outcome by modifying those attributes, which works well for global policy, primary/backup egress, or coarse-grained traffic tuning — but because it acts on route prefixes and their attributes, it affects every flow matching that prefix at once. When different business types, users, source addresses, or real-time network conditions each need a different egress for the same destination, prefix-based policy quickly becomes complex to maintain.

BGP EPE takes a different approach: instead of influencing which path BGP picks, it lets specific traffic be steered to a specific egress. It does this through three Peer SID types, each offering a different level of granularity:

  1. PeerNode SID — identifies a single BGP peer. BGP EPE assigns one PeerNode SID per BGP session. If multiple physical links reach that peer (for example, when the session is established over Loopback interfaces), traffic that hits the PeerNode SID load-balances across all valid links to that peer — it controls which peer to exit through, not which link.

  2. PeerAdj SID — identifies one specific adjacent link to a peer, rather than the peer as a whole. Traffic that hits a PeerAdj SID uses only the link that SID is bound to, with no load balancing across the peer's other links. This gives finer-grained control than PeerNode SID and suits cases that need a specific physical link, congestion avoidance, or deterministic paths.

  3. PeerSet SID — identifies a group of peers gathered into a BGP EPE SRv6 Peer Set, turning multiple egresses with similar business attributes (same remote AS, comparable link cost, equivalent service tier) into one logical resource pool. A PeerSet SID can reference multiple PeerNode or PeerAdj SIDs; traffic hitting it load-balances or fails over across the set's members. The ingress policy only needs to reference the PeerSet SID, so egress membership can change without touching ingress configuration.

In a typical cross-domain flow — for example, VPN traffic from CE1 to CE2 — SRv6 Locators establish domain-internal and cross-domain reachability (via IS-IS and EBGP respectively), the egress PE advertises an End.DT4 SID and Color community for the VPN route, and a controller builds an SRv6 TE Policy on the headend PE whose SID List includes ordinary End SIDs to steer traffic toward the ASBR, plus a BGP EPE Peer SID to select the specific cross-domain egress once traffic arrives there. The ASBR executes that Peer SID's forwarding behavior instead of falling back to its ordinary BGP best path, and the packet continues along the SID List to its destination.

Why BGP EPE is Beneficial

BGP EPE gives operators the last piece of end-to-end SRv6 traffic engineering — control over the cross-domain exit itself:

· Fills the gap Node SID leaves open: Node SID gets traffic to the right ASBR; BGP EPE decides what happens next, so SRv6 Policy can programmatically control the entire path, not just the intra-domain portion.

· Per-flow egress control without touching route attributes: Because PeerNode, PeerAdj, and PeerSet SIDs are referenced directly in a SID List, different flows toward the same destination prefix can take different egresses — something prefix-based routing policy struggles to do without affecting every flow that matches.

· Granularity to match the requirement: PeerNode SID selects a peer, PeerAdj SID pins a specific physical link, and PeerSet SID pools equivalent egresses for load balancing or failover — operators choose the right level of control instead of a single coarse mechanism.

· Simplifies egress-set changes: With PeerSet SID, adding or removing a member egress only requires updating the peer set — the ingress SRv6 Policy that references the PeerSet SID doesn't need to change.

· Complements BGP rather than replacing it: BGP and routing policy continue to handle route propagation, reachability, and general path preference; BGP EPE adds a final, explicit control point at the ASBR for the specific traffic that needs it.

The trade-off is that BGP EPE adds another layer of SID allocation and controller-driven policy on top of standard BGP and SRv6 TE — it's a targeted tool for flows that genuinely need per-egress precision, not a wholesale replacement for standard BGP path selection.

At Asteraix

What We Can Do at Asteraix

AsterNOS supports BGP EPE as part of its native SRv6 stack, configured directly from the BGP process alongside standard EBGP peering.

· Native SRv6 BGP EPE in the BGP process: Enabling egress-engineering enable under router bgp <AS_number> [vrf <vrf_name>] turns on BGP EPE for the instance, so Peer SIDs are provisioned in the same configuration flow operators already use for EBGP.

· All three Peer SID types, auto or static: AsterNOS supports PeerNode SID (neighbor <peer-ip> egress-engineering peer-node-sid {auto|<node_ID>}), PeerAdj SID (egress-engineering adjacency <nexthop_ip> adjacency-sid {auto|<node_ID>}), and PeerSet SID (egress-engineering peer-set <peer_set_name> peer-set-sid {auto|<node_ID>} plus neighbor <peer-ip> egress-engineering peer-set <peer_set_name>), with SID values either assigned automatically or pinned to a specific node ID.

· Works with the rest of the AsterNOS SRv6 stack: BGP EPE Peer SIDs slot directly into SRv6 TE Policy SID Lists alongside End and End.DT4 SIDs, so the same headend policy can steer traffic across IS-IS-based intra-domain paths and BGP EPE-controlled cross-domain egress in a single design.

· VRF-aware for multi-tenant edges: Because BGP EPE is configured per BGP instance, it supports the vrf <vrf_name> scope used across AsterNOS's routing stack, keeping egress engineering isolated per tenant where needed.

· Built for ASBR-role hardware: AsterNOS runs on switches and routers spanning access, aggregation, and data center roles, so BGP EPE-capable ASBRs can be deployed at the scale a given cross-domain design requires.