]> New H3C Technologies

China linchangwang.04414@h3c.com

China Mobile

China lizhenqiang@chinamobile.com

China Unicom

China pangran@chinaunicom.cn

Cisco Systems

India ketant.ietf@gmail.com

ZTE Corporation

China chen.ran@zte.com.cn

Routing IDR Working Group SR, BGP-LS, EPE, L2 Bundle Member This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. It updates RFC 9085 to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute of the BGP-LS Link NLRI for a BGP peering link. For SR-MPLS, it updates RFC 9085 and RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle Member Attributes TLV.

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

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. 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) . 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 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 and to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement In the network depicted in , 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.

BGP-EPE over L2 Bundle

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.

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 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 ). Section 2.2 of 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 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.

SR-MPLS For SR-MPLS, Section 5 of defined the PeerAdj SID TLV and its usage for the BGP-LS advertisement of the BGP-EPE PeerAdj SID for L3 link. When advertising the SR-MPLS BGP-EPE Peer Adjacency SIDs for L2 bundle members, the PeerAdj SID TLV MUST be carried in the L2 Bundle Member Attributes TLV to advertise the SR-MPLS Peer Adjacency SID for the associated L2 bundle member. This document updates and to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. When advertising SR-MPLS BGP-EPE Peer Adjacency SIDs for L2 bundle members, since L2 bundle information is considered a Layer 3 link attribute, it MUST be advertised in the BGP-LS Link NLRI. The details for BGP-LS Link NLRI are the same as those for the PeerAdj SID, as described in Section 5.2 of . This information MUST NOT be included in the BGP-LS Link NLRI that corresponds to the PeerNode SID, as defined in Section 5.1 of . Note that for directly connected EBGP neighbors, if a BGP neighbor is established over an L2 Bundle, an additional BGP-LS Link NLRI (as described in Section 5.2 of ) MUST be generated to advertise Peer Link information when generating the BGP-LS Link NLRI (as described in Section 5.1 of ) corresponding to the PeerNode SID. The L2 Bundle Member Attributes TLV is included under the BGP-LS Link Attribute TLVs. The SR-MPLS BGP-EPE Peer Adjacency SIDs for L2 bundle members are advertised with a BGP-LS Link NLRI, where:

• BGP-LS Link NLRI: as described in Section 5.2 of .
• Link Attribute TLVs:
  • (Optional) include the PeerAdj SID TLV for the underlying Bundle link to the BGP peer node.
  • include the L2 Bundle Member Attributes TLV.
    • include the PeerAdj SID TLV for each L2 Bundle Member.

It is necessary to clarify the use of link identifiers in this context. The parent BGP-LS Link NLRI (as described in Section 5.2 of ) MUST use the Link Local Identifier (and if known, Link Remote Identifier) corresponding to the Layer 2 bundle interface itself for its Link Descriptors. Within each L2 Bundle Member Attributes TLV, the included Link Local Identifier MUST be that of the specific physical member link. This distinction ensures unambiguous identification of both the logical peering link (the bundle) and the underlying physical constituents.

SRv6 For SRv6, according to Section 4.1 of , the SRv6 End.X SID TLV is used for the advertisement of L3 link BGP EPE Peer Adjacency SID. When advertising the SRv6 BGP-EPE Peer Adjacency SIDs for L2 bundle members, the SRv6 End.X SID TLV MUST be carried in the L2 Bundle Member Attributes TLV to advertise the SRv6 Peer Adjacency SID for the associated L2 bundle member. Note Appendix A of , SRv6 BGP PeerNode is no longer advertised as BGP-LS Link NLRI. When advertising SRv6 BGP-EPE Peer Adjacency SIDs for L2 bundle members, since L2 bundle information is considered a Layer 3 link attribute, it MUST be advertised in the BGP-LS Link NLRI. The details for BGP-LS Link NLRI are the same as those for the Peer Adjacency SID, as described in Section 5.2 of . The SRv6 BGP-EPE Peer Adjacency SIDs for L2 bundle members are advertised with a BGP-LS Link NLRI, where:

• BGP-LS Link NLRI: as described in Section 5.2 of .
• Link Attribute TLV:
  • (Optional) include the SRv6 End.X SID TLV for the underlying link to the BGP peer node.
  • include the L2 Bundle Member Attributes TLV.
    • include the SRv6 End.X SID TLV for each L2 Bundle Member.

The SRv6 End.X SID TLV included within the L2 Bundle Member Attributes TLV follows the same format and sub-TLV rules as defined in Section 4.1 of . This includes the optional inclusion of the SRv6 SID Structure TLV as a sub-TLV. The use (or omission) of the SRv6 SID Structure TLV for an End.X SID advertised for an L2 bundle member link MUST be consistent with the rules and practices defined in and .

Manageability Considerations The manageability considerations described in and 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.

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.

Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to ]. 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 . 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 , "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".

New H3C Technologies

• Organization: New H3C Technologies.
• Implementation: H3C CR16000, CR19000 series routers implementation.
• Description: All sections including all the "MUST" and "SHOULD" clauses have been implemented in above-mentioned New H3C Products (running Version 7.1.110 and above).
• Maturity Level: Product
• Coverage: All sections.
• Version: Draft-00
• Licensing: N/A
• Implementation experience: Nothing specific.
• Contact: li_meng_limeng@h3c.com
• Last updated: July 19, 2025

ZTE Corp

• Organization: ZTE Corporation
• Implementation: ZTE's M6000 Series Routers
• Description: This feature has been implemented in ZTE M6000 series routers and follows the definition and mechanism as defined in Section 3 including all the "MUST" and "SHOULD" clauses.
• Maturity Level: Beta
• Coverage: All
• Version: Draft-00
• Licensing: N/A
• Implementation experience: Nothing specific.
• Contact: zhu.xiaolong@zte.com.cn
• Last updated: July 19, 2025

Security Considerations The security considerations described in and 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 is RECOMMENDED) and route filtering; (2) protect data integrity using encryption (e.g., TLS ) 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.

IANA Considerations This document has no IANA actions.

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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies. This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Informative References n.d. IEEE 802.1AX This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.

Example This section shows an example of how Node B in 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: 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 . 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)

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.

Spring WG illustrates a centralized controller-based BGP Egress Peer Engineering solution involving SR path computation using the BGP Peering Segments. Section 4.2 of explains how to use the End.X SID corresponding to an L2 member link. Section 2.2 of 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". defines the extension to BGP-LS for advertisement of BGP Peering Segments along with their BGP peering node information. This document updates 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 and to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV.

PCE This document only covers BGP-LS and does not involve PCE.

SRV6 OPS Not related to SRv6 OPS, this document only addresses updates to BGP, and RFC9087 and RFC8986 are available for reference in SPRING.