Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions called "segments". Segment Routing can be instantiated on both MPLS and IPv6 data planes, which are referred to as SR-MPLS and SRv6.¶

BGP Egress Peer Engineering (BGP-EPE) allows an ingress Provider Edge (PE) router within the domain to use a specific egress PE and a specific external interface/neighbor to reach a particular destination.¶

The SR architecture [RFC8402] defines three types of BGP Peering Segments that may be instantiated at a BGP node:¶

• Peer Node Segment (PeerNode SID): instruction to steer to a specific peer node,¶

• Peer Adjacency Segment (PeerAdj SID): instruction to steer over a specific local interface towards a specific peer node, and¶

• Peer Set Segment (PeerSet SID): instruction to load-balance to a set of specific peer nodes.¶

[RFC9087] illustrates a centralized controller-based BGP-EPE solution involving SR path computation using the BGP Peering Segments. A centralized controller learns the BGP Peering SIDs via Border Gateway Protocol - Link State (BGP-LS) and then uses this information to program a BGP-EPE policy. [RFC9086] defines the extension to BGP-LS for advertisement of BGP Peering Segments along with their BGP peering node information.¶

There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle (L2 Bundle), for instance, a Link Aggregation Group (LAG) [IEEE802.1AX]. BGP-EPE may wish to control traffic flows on individual member links of the underlying Layer 2 bundle. In order to do so, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required.¶

This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members.¶

This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the BGP-LS Link NLRI of BGP peering link. For SR-MPLS, this document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV.¶

2. Problem Statement

In the network depicted in Figure 1, B and C establish BGP peer session on a Layer 2 bundle. Assume that, the member link 1 has the largest available bandwidth. The operator of AS1 wishes to apply a BGP-EPE policy to steer certain flows from AS1 to AS2 via member link 1 of the Layer 2 bundle to ensure there is no over-subscription.¶

                 L2 Bundle      +--------+
              /---member 1---\  |        |
            --+---member 2---+--C   AS2  |
+--------+ /  \---member 3---/  |        |
|        |/                     +--------+
A   AS1  B
|        |\                     +--------+
+--------+ \                    |        |
            --------------------D   AS3  |
                                |        |
                                +--------+

The existing Peer Adjacency SID can be allocated to the Layer 3 interface between B and C, which is a Layer 2 interface bundle. If steered by that Peer Adjacency SID, the traffic will be forwarded by load balancing among all the bundle member links. So, the existing mechanism cannot meet the requirement of steering traffic flows via individual member link.¶

In order to support BGP Egress Peer Engineering steering over specific Layer 2 bundle members, a BGP router needs to have the ability to assign Peer Adjacency Segments for member links. And, the Peer Adjacency Segments of bundle members need to be advertised in BGP-LS, which will be specified in this document.¶

3. Advertising Peer Adjacency Segment for L2 Bundle Member in BGP-LS

BGP peering segments are generally advertised in BGP-LS from a BGP node along with its peering topology information, in order to enable computation of BGP-EPE policies.¶

When a BGP peer session is established over a Layer 2 interface bundle, an implementation MAY allocate one or more Peer Adjacency Segments for each member link. If so, it SHOULD advertise the Peer Adjacency Segments of bundle members in BGP-LS, using the method defined in this section.¶

In order to advertise the EPE Peer Adjacency SIDs for L2 bundle members in BGP-LS, the L2 Bundle Member Attributes TLVs [RFC9085] MUST also be included in the Link Attributes for the BGP-LS Link NLRI corresponding to the BGP peering session. This BGP-LS TLV is derived from L2 Bundle Member Attributes TLV of IS-IS (Section 2 of [RFC8668]).¶

Section 2.2 of [RFC9085] restricted that the L2 Bundle Member Attributes TLV "should only be added to the BGP-LS Attribute associated with the BGP-LS Link NLRI that describes the link of the IGP node". This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the BGP-LS Link NLRI of BGP peering link.¶

Each L2 Bundle Member Attributes TLV that advertises a member EPE SID MUST include exactly the relevant PeerAdj SID TLV or SRv6 End.X SID TLV for that member.¶

Note that the inclusion of a L2 Bundle Member Attributes TLV implies that the identified link is a member of the L2 bundle and that the member link is operationally up. The advertisement of a Peer Adjacency SID (within a PeerAdj SID or SRv6 End.X SID sub-TLV) further implies that the SID is valid and programmed for forwarding on that member link.¶

If the advertised Peer Adjacency SID for a member link undergoes a change (e.g., label value or SRv6 SID update), becomes invalid, or is administratively disabled, the implementation MUST update the BGP-LS advertisement to reflect the new state. This MUST be done by updating (re-advertising) the corresponding L2 Bundle Member Attributes TLV with the modified or removed SID sub-TLV. If the member link itself fails or is removed from the bundle, the implementation MUST withdraw the entire corresponding L2 Bundle Member Attributes TLV in BGP-LS.¶

The PeerSet SID, as defined in Section 5.3 of [RFC9086], MAY be instantiated and additionally associated and shared between one or more PeerNode SIDs or PeerAdj SIDs. The specification of PeerSet SID assignment or advertisement for individual L2 Bundle members is outside the scope of this document.¶

4. Manageability Considerations

The manageability considerations described in [RFC9552] and [RFC9086] also apply to this document.¶

An implementation SHOULD provide operational controls for the following aspects:¶

• Selective Advertisement: Controls to enable, disable, or filter the advertisement of L2 bundle member Peer Adjacency SIDs, including the ability to limit advertisements based on specific BGP peer, session type (e.g., iBGP or eBGP), or routing policy.¶

• Granularity Control: The ability to suppress the advertisement of per-member SIDs while still advertising the SID for the parent bundle interface, allowing operators to choose the appropriate level of steering granularity.¶

• Churn Handling: Mechanisms to dampen advertisement churn caused by frequent operational state changes (up/down) of L2 bundle member links, such as configurable timers to delay withdrawal announcements.¶

• Consistency Verification: Capabilities to assist in operational monitoring and troubleshooting, such as logging or raising notifications when inconsistencies are detected between the advertised state of the parent bundle link and its member links (e.g., a member link is advertised as up while the parent bundle is down).¶

The operator MUST be provided with the options of configuring, enabling, and disabling the advertisement of Peer Adjacency Segment for L2 Bundle member links, as well as control of which information is advertised to which internal or external peer.¶

5. Applicability Considerations for MC-LAG Bundles

This document does not define MC-LAG loop-prevention behavior and assumes the underlying L2/LAG system already provides loop-free member forwarding.¶

6. Implementation Status

[Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942]].¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

7. Security Considerations

The security considerations described in [RFC9552] and [RFC9086] also apply to this document.¶

The distribution of Layer 2 bundle information via BGP-LS exposes critical network adjacency details that could compromise infrastructure security if accessed by unauthorized parties. This includes sensitive data about interface bindings, LAGs, and peer connectivity states.¶

To mitigate risks, implementations MUST: (1) support mechanisms to enforce strict access controls through BGP peer authentication (the use of TCP-AO [RFC5925] is RECOMMENDED) and route filtering; (2) protect data integrity using encryption (e.g., TLS [RFC9325]) for BGP-LS sessions in untrusted domains; and (3) implement operational safeguards including network segmentation and activity monitoring. Special consideration applies to multi-domain environments where L2 topology exposure could reveal cross-provider interconnection architectures.¶

Operators should monitor for emerging threats targeting exposed L2 infrastructure data. Regular audits of BGP-LS access patterns are RECOMMENDED to detect potential reconnaissance activities.¶

8. IANA Considerations

This document has no IANA actions.¶

9. Acknowledgements

The authors would like to acknowledge Sasha Vainshtein, Acee Lindem, Liyan Gong, Yongqing Zhu, Lan cheng, Wisdomtan, Yisong Liu, Libin Liu, Liu Yao, Hongwei Li, Allan Michael, Huo Pengfei, Gyan Mishra, Dong Jie, Meng Liu, Wei Wang, Yimi Zhang, Haiyang Zhang, Jiangbo Wang, Zheng Zhang, Yujia Gao, Alex Lee, David Wright, Xiaolan Wang, shawnzhsh, RuanZheng for their careful reviews and very helpful comments.¶

The authors would also like to thank Susan Hares for her shepherd review and helpful comments to improve this document.¶

Thanks to Andrew Stone for the RTGDIR Early review.¶

Thanks to Gunter Van de Velde for the Shepherding AD review.¶

10. References

Appendix A. Example

This section shows an example of how Node B in Figure 1 allocates and advertises Peer Adjacency Segments for L2 bundle members.¶

B allocates a PeerAdj SID for the Layer 2 interface bundle to peer C, along with a PeerAdj SID for each member link. B programs its forwarding table accordingly:¶

+===============================+====================+
|          PeerAdj SID          | Outgoing Interface |
+---------------+---------------+                    |
| IF on SR-MPLS |  IF on SRv6   |                    |
|   Data Plane  |  Data Plane   |                    |
+===============+===============+====================+
|     1010      |     A::A0     | L2 Bundle to C     |
+---------------+---------------+--------------------+
|     1011      |     A::A1     | Member link 1 to C |
+---------------+---------------+--------------------+
|     1012      |     A::A2     | Member link 2 to C |
+---------------+---------------+--------------------+
|     1013      |     A::A3     | Member link 3 to C |
+---------------+---------------+--------------------+

B signals the related BGP-LS Link NLRI and Link Attributes including the PeerAdj SID for L3 parent link to the BGP-EPE controller, as specified in Section 5.2 of [RFC9086]. In addition, B also advertises L2 Bundle Member Attribute TLVs carrying the PeerAdj SIDs for L2 bundle members.¶

For SR-MPLS, the Link Attributes are as follows:¶

• PeerAdj SID TLV (Label-1010)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 1)¶

  • PeerAdj SID TLV (Label-1011)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 2)¶

  • PeerAdj SID TLV (Label-1012)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 3)¶

  • PeerAdj SID TLV (Label-1013)¶

For SRv6, the Link Attributes are as follows:¶

• SRv6 End.X SID TLV (SID-A::A0)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 1)¶

  • SRv6 End.X SID TLV (SID-A::A1)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 2)¶

  • SRv6 End.X SID TLV (SID-A::A2)¶

• L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 3)¶

  • SRv6 End.X SID TLV (SID-A::A3)¶

Appendix B. Cross WG Information

This section describes cross-working group information for the IETF review process. This section will be removed by the RFC Editor before publication.¶

Authors' Addresses