Summary

  • The IESG-approved BGP-EPE extension lets BGP-LS advertise a Peer Adjacency SID or SRv6 End.X SID for an individual physical member beneath one Layer 2 peering bundle.
  • The advertisement can report that a member is up and its SID is programmed. It does not choose load policy, prove current capacity, prevent packet reordering, supply MC-LAG loop safety or authorize production use.

A forwarding instruction for a smaller object

BGP Egress Peer Engineering already lets an ingress provider-edge router select an egress router and a particular external neighbor or interface. RFC 9086 provides BGP-LS advertisements for the peering segments a controller can use when computing that policy. The difficulty appears when the Layer 3 peering interface is a Link Aggregation Group or another Layer 2 bundle.

At that level, one logical link hides several physical members. A PeerAdj SID for the logical link can steer traffic to the bundle, after which its member-selection behavior distributes packets. It cannot deliberately say “use member two.” The draft approved by the IESG on 6 August 2026 adds that missing granularity.

The parent BGP-LS Link NLRI still identifies the logical peering bundle. Beneath it, an L2 Bundle Member Attributes TLV identifies one physical member and carries exactly the relevant SR-MPLS PeerAdj SID or SRv6 End.X SID. The distinction between parent and member identifiers prevents the logical adjacency and its physical constituents from collapsing into one name.

This is useful precision. A controller can direct selected flows onto a member with available capacity instead of accepting the bundle's ordinary hash. It can also maintain different instructions for SR-MPLS and SRv6 while using the same member boundary. But the SID remains an instruction interpreted by a forwarding system, not a description of every property of that system.

The advertisement has a clock

The draft gives the advertisement explicit semantics. Including a member TLV implies that the member is operationally up. Including its Peer Adjacency SID further implies that the SID is valid and programmed for forwarding on that member.

Those statements are made at control-plane time. If the SID changes, becomes invalid or is administratively disabled, the router must update the advertisement and modify or remove the SID. If the member fails or leaves the bundle, it must withdraw the whole member TLV.

Churn control makes the timing boundary visible. An implementation may use a hold-off timer to suppress intermediate advertisements during a brief flap. Once the link stabilises down or is removed, withdrawal must occur without further delay. A controller therefore needs the speaker, session, sequence, receipt time and age of the topology record. “BGP-LS says up” without an observation clock is not a current-state claim.

Consistency checks belong beside it. The draft recommends warnings when the parent bundle and member state disagree, such as a member advertised up while the parent is down. It also requires operator control over whether member SIDs are advertised and which internal or external peer receives the information. An available instruction may be deliberately undisclosed; absence is not proof that the member does not exist.

Precision spends balance and ordering

The logical bundle provides a natural distribution mechanism. Pinning selected flows to members can override it. One lane may congest while the others remain underused, even though every SID is valid and every advertisement is syntactically correct.

The draft places the response with the controller or policy engine. It should observe member utilisation and adjust assignments. Operators may use real-time bandwidth or other metrics and choose whether steering granularity is per flow, destination or application. The protocol supplies the member instruction; it does not decide the load-balancing policy.

Packet order is a second retained duty. Members can have different latency. Sending different packets from one flow over different members, or reassigning a flow while packets are in flight, can reorder delivery. Consistent five-tuple or other flow-invariant classification reduces the risk. Per-packet balancing should not be used with member PeerAdj steering when ordering matters.

That means a successful forwarding action is still not an application outcome. Evidence needs the selected SID, effective policy, flow classifier, per-member counters, queue and loss state, reassignment event, packet-order observation and rollback result. A controller that records only the topology instruction preserves intent and discards consequence.

Trusted distribution is not final authority

Member information can expose useful internal topology and steering instructions. The draft says it must remain inside trusted Segment Routing domains, or between trusted peering domains, with BGP filtering and policy controlling propagation.

That scope restriction matters. It does not make every consumer inside the boundary equally authorised to program traffic. Authentication can establish which BGP-LS speaker supplied the data. Filtering can limit who receives it. Neither decides whether a workload may consume a scarce member, whether a maintenance window is open or who bears a reordering incident.

MC-LAG provides the clearest limit. The extension does not define multi-chassis loop prevention. It assumes that the underlying L2/LAG system already supplies loop-free member forwarding. A controller can possess an exact member SID while lacking the state required to know whether using it is safe in that topology.

Keep the mechanism thin

The extension updates a small set of BGP-LS rules and requires no new IANA allocation. It does not replace LAG operation, telemetry, capacity planning, policy approval or rollback. That narrowness is a strength.

The approved draft also records two contributor-reported implementations, while warning that the list is not independently verified and does not imply IETF endorsement. Running code is valuable evidence about feasibility. It is not proof that a particular deployed router, software release, controller and bundle are correct now.

A durable design keeps each handoff visible: the router reports the member and SID; telemetry reports utilisation and loss; the controller proposes a flow assignment; policy authorises the use; the data plane supplies outcome evidence; the operator owns rollback. Standardise the shared instruction. Leave decisions with the party that bears the congestion and outage.

Sources