IDR Working Group C. Lin Internet Draft New H3C Technologies Updates: 9085, 9086 (if approved) Z. Li Intended status: Standards Track China Mobile Expires: March 02, 2025 R. Pang China Unicom K. Talaulikar Cisco Systems M. Chen New H3C Technologies September 02, 2024 Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members draft-ietf-idr-sr-epe-over-l2bundle-00 Abstract There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, 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 Link NLRI of BGP peering link. 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. 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 March 02, 2025. Lin, et al. Expire March 02, 2025 [Page 1] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 Copyright Notice Copyright (c) 2024 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................4 2. Problem Statement..............................................4 3. Advertising Peer Adjacency Segment for L2 Bundle Member in BGP-LS ..................................................................5 3.1. SR-MPLS...................................................5 3.2. SRv6......................................................6 4. Manageability Considerations...................................7 5. MC-LAG Bundles Considerations..................................7 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................9 Appendix A. Example...............................................9 Acknowledgements.................................................11 Authors' Addresses...............................................11 Lin, et al. Expires March 02, 2025 [Page 2] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 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: o Peer Node Segment (PeerNode SID): instruction to steer to a specific peer node o Peer Adjacency Segment (PeerAdj SID): instruction to steer over a specific local interface towards a specific peer node o 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 Link NLRI of BGP peering link. 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. Lin, et al. Expires March 02, 2025 [Page 3] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 | | | +--------+ Figure 1: 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 over 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. Lin, et al. Expires March 02, 2025 [Page 4] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 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. 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 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 Link NLRI of BGP peering link. Each L2 Bundle Member Attributes TLV identifies an L2 bundle member, and includes the EPE Peer Adjacency SID for the associated L2 bundle 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. If any member link fails, an implementation MUST withdraw the L2 Bundle Member Attributes TLV in BGP-LS, along with the Peer Adjacency Segments for the failed member link. 3.1. SR-MPLS For SR-MPLS, Section 5 of [RFC9086] 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 [RFC9086] 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 [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. Lin, et al. Expires March 02, 2025 [Page 5] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 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 LINK NLRI are the same as those for the PeerAdj SID, as described in Section 5.2 of [RFC9086]. This information mustnot be included in the BGP-LS Link NLRI that corresponds to the PeerNode SID, as defined in Section 5.1 of [RFC9086]. 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 [RFC9086]) must be generated to advertise Peer Link information when generating the BGP-LS Link NLRI (as described in Section 5.1 of [RFC9086]) corresponding to the PeerNode SID. The L2 Bundle Member Attributes TLV should be 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 [RFC9086]. * Link Attribute TLVs: - include the PeerAdj SID TLV [RFC9086] for Peer Link(Optional) - include the L2 Bundle Member Attributes TLV. o include the PeerAdj SID TLV [RFC9086] for each L2 Bundle Member. 3.2. SRv6 For SRv6, according to Section 4.1 of [RFC9514], 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 [RFC9514] 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 [RFC 9514], SRv6 BGP PeerNode is no longer advertised as BGP 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 LINK NLRI are the same as those for the Peer Adjacency SID, as described in Section 5.2 of [RFC9086]. Lin, et al. Expires March 02, 2025 [Page 6] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 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 [RFC9086]. * Link Attribute TLV: - include the SRv6 End.X SID TLV [RFC9514] for Peer Link (Optional). - include the L2 Bundle Member Attributes TLV. o include the SRv6 End.X SID TLV [RFC9514] for each L2 Bundle Member. 4. Manageability Considerations The manageability considerations described in [RFC9552] and [RFC9086] also apply to this document. 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. MC-LAG Bundles Considerations In environments where MC-LAG (Multi-Chassis Link Aggregation Group) bundles are deployed across multiple devices, it is critical to implement mechanisms to prevent Broadcast, Unknown Unicast, and Multicast (BUM) traffic from looping and ensure a loop-free network. The following loop prevention mechanisms are included: o Split Horizon Forwarding: Each MC-LAG device maintains a split horizon rule where it does not forward BUM traffic received from one MC-LAG member port to another MC-LAG member port. This prevents BUM frames from being forwarded back into the MC-LAG, creating loops. o Designated Forwarder Election: In a typical MC-LAG configuration, one device is elected as the designated forwarder for BUM traffic. This ensures that only one device is responsible for forwarding BUM frames, preventing the possibility of multiple devices forwarding the same frame simultaneously and causing a loop. Lin, et al. Expires March 02, 2025 [Page 7] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 o Consistent Hashing Algorithms: MC-LAG devices employ consistent hashing algorithms to ensure that traffic distribution across member links is stable and predictable. This minimizes the risk of reordering and helps in effective loop prevention. By incorporating these mechanisms, MC-LAG deployments can effectively prevent BUM traffic from looping and ensure a stable, loop-free network. 6. Security Considerations The security considerations described in [RFC9552] and [RFC9086] also apply to this document. This document does not introduce any new security consideration. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, . Lin, et al. Expires March 02, 2025 [Page 8] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, . [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, . [RFC9552] K. Talaulikar, "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, . 8.2. Informative References [IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE 802.1AX, . [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, . [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 2021, . 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: Lin, et al. Expires March 02, 2025 [Page 9] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 +===============================+====================+ | 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: o PeerAdj SID TLV (Label-1010) o L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 1) * PeerAdj SID TLV (Label-1011) o L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 2) * PeerAdj SID TLV (Label-1012) o 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: o SRv6 End.X SID TLV (SID-A::A0) o L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 1) * SRv6 End.X SID TLV (SID-A::A1) Lin, et al. Expires March 02, 2025 [Page 10] Internet-Draft SR BGP EPE over L2 Bundle Members September 2024 o L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 2) * SRv6 End.X SID TLV (SID-A::A2) o L2 Bundle Member Attribute TLV (Link Local Identifier describing the member link 3) * SRv6 End.X SID TLV (SID-A::A3) Acknowledgements Many thanks to Sasha Vainshtein, Acee Lindem, Chen Ran, Liyan Gong, Yongqing Zhu, Lan cheng, Wisdom Tan, Yisong Liu, Libin Liu, Liu Yao, Hongwei Li, Allan Michael, Huo Pengfei, Gyan Mishra, Dong Jie, Meng Liu, etc. for their valuable comments on this document. Authors' Addresses Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Zhenqiang Li China Mobile China Email: lizhenqiang@chinamobile.com Ran Pang China Unicom China Email: pangran@chinaunicom.cn Ketan Talaulikar Cisco Systems India Email: ketant.ietf@gmail.com Mengxiao Chen New H3C Technologies China Email: chen.mengxiao@h3c.com Lin, et al. Expires March 02, 2025 [Page 11]