bier Z. Zhang Internet-Draft T. Przygienda Intended status: Informational HPE Expires: 6 May 2027 Z. Zhang ZTE X. Xu China Mobile 2 November 2026 Adaptive Routing with BIER draft-zzhang-bier-adaptive-routing-00 Abstract ECMP is extensively used in AI DC networking, often with so called adaptive routing mechansim, with which the load/congestion/capacity information for the nexthop, next nexthop, or even the entire path is considered to dynamically adjusts routing paths based on changes in global network conditions, thereby optimizing network performance and resource utilization. This document describe how BIER can work with adaptive routing. 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 6 May 2027. 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. Zhang, et al. Expires 6 May 2027 [Page 1] Internet-Draft Adaptive Routing with BIER November 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ECMP is extensively used in modern AI DC networking, often with so called Adaptive Routing mechansim, with which the load/congestion/ capacity information for the nexthop, next nexthop, or even the entire path is considered to dynamically adjusts routing paths based on changes in global network conditions, thereby optimizing network performance and resource utilization [I-D.cheng-rtgwg-adaptive-routing-framework]. Consider the following spine and leaf network (due the limitation of ASCII art, some S-L links are not drawn, but every spine is connected to every leaf): S1 S2 S3 S4 |\ /|\ /|\ /| | \ / | \ / | \ / | | X | X | X | | / \ | / \ | / \ | |/ \|/ \|/ \| L1 L2 L3 L4 If L1 detects that S1-L2 link is congested but L1-S2 and S2-L2 are not, it can avoid S1 and choose S2 for the L1-L2 traffic. That's the concept of adaptive routing in a nut shell. Zhang, et al. Expires 6 May 2027 [Page 2] Internet-Draft Adaptive Routing with BIER November 2026 Now consider multicast using BIER [RFC8279]. Suppose the source is attached to L1, and the receivers are attached to L2 and L3. Without adaptive routing, L1 can send the BIER packet to any of the spine switches, say S1. S1 would replicate it to L2 and L3, but since the S1-L2 link is congested, L2 will experience packet losses. With adaptive routing for BIER, L1 can avoid S1 but send the copy to S2, who then replicate to L2 and L3. If none of the spines has uncongested paths to both L2 and L3, then L1 can replicate to two spines, who then forward to L2 or L3 separately. This can be achieved without changing the BIER forwarding algorithm. Oly the calculation of F-BM and some BIFT entries need to be changed, as described below. Note that, while the example and the text below uses congestion as the criterion, other criteria can be used for adaptive routing as well [I-D.ietf-idr-fare], and the scheme in this document also works with that - how a BFR neighbor is determined usable or not for a BFER from adaptive routing aspect is orthogonal. 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. Mode of Operation This is an information document for local behaviors, and there is no nomaltive specification. This secion describe how the adaptive routing is done with BIER. BIER forwarding is based on the F-BM associated with a BFR neighbor, representing all the BFERs reachable via that neighbor. The index of the lowest bit that is set in the incoming bitstring is used to look up a BIFT entry, resulting in a set of BFR neighbors that can be used to reach the BFER represented by that bit. One of the neighbors is chosen, and its F-BM is used to determine the outgoing bitstring for the copy replicated to it. The F-BM is also used to mask bits off the incoming bitstring, and the forwarding iterates for the remaining set bits. The F-BM includes all the bits for BFERs reachable via that neighbor, as described in [RFC8279]. Using the extremely simple example of 4-bit bitstring (for only 4 BFERs in the example), L1's BIFT includes four entries: Zhang, et al. Expires 6 May 2027 [Page 3] Internet-Draft Adaptive Routing with BIER November 2026 Key Neighbor 1 (L1) self (pop) 2 (l2) S1,S2,S3,S4 3 (l3) S1,S2,S3,S4 4 (L4) S1,S2,S3,S4 The F-BM is 1111 for all S1~S4 when all the links are up and adaptive routing is not used (i.e., congestion is ignored). Now let's say S1-L2 is congested and all other links are fine. With adaptive routing, the second entry then becomes: 2 (l2) S2,S3,S4 S1's F-BM also becomes 1101, because it no longer has an uncongested path to L2. Other entries and F-BMs do not change. When L1 forwards the 0110 packet (for L2 and L3), the 2nd entry is first looked up beause the index of the lowest set bit is 2. S1 is not in the entry and one of (S2, S3,S4) is chosen. Now consider that S2-L3 is also congested. The BIFT becomes: Key Neighbor 1 (L1) self (pop) 2 (L2) S2,S3,S4 3 (L3) S1, S3,S4 4 (L4) S1,S2,S3,S4 S1 F-BM: 1101 S2 F-BM: 1011 For the same packet, in the first lookup, if S2 is chosen out of (S2, S3, S4) in the 2nd entry, the outgoing bitstring becomes 0010 (0110 \& 1011), and another lookup is done for the remaining bits 0100, leading to the 3rd entry. This time a copy is sent to one of (S1, S3, S4) who all have an uncongested path to L3. Now consider that all the Sx-L3 links are congested - there is just no congested path to L3. Now the 3rd entry goes back to the following, and all the F-BMs have L3's bit added back: 3 (L3) S1,S2,S3,S4 Now we can give the formular for the calculation of the F-BM for a neighbor when adaptive routing is used: 1. Let F-BM0 represent all BFERs reachable via the neighbor (the vanilla F-BM in [RFC8279]). 2. Let F-BM1 represent all BFERs reachaable via the neighbor without congestion, based on unicast adaptive routing. Zhang, et al. Expires 6 May 2027 [Page 4] Internet-Draft Adaptive Routing with BIER November 2026 3. Let F-BM2 represent all BFERs that can be reached via all the neighbors without congestoin. ~F-BM2 then represents all BFERs that can't be reached without congestion in any way. F-BM2 = Logical OR of F-BM1 of all neighbors 4. F-BM = F-BM1 | F-BM0 & ~F-MB2 The change to BIFT entries: 1. If a BFER can be reached via some neighbors without congestion, only those neighbors are included in the BIFT entry. When a lookup hits the entry, one of those neighbors will be used. 2. If a BFER can not be reached via any neighbor without congestion, all the neighbors via which the BFER can be reached w/o considering congestion are included in the entry. This means that if there is no uncongested path to a BFER, we'll take chance to foward traffic towards it after all, even though this may sustain or further contribute to the congestion. If it is desired to drop the packet for the BFER, then F-BM1 in step 2 instead of F-BM in step 4 can be used, and the BFER's entry in the BIFT becomes a discard one. 3. Security Considerations To be added. 4. IANA Considerations No IANA consideration is needed 5. Acknowledgments The authors want to thank Duncan Roweth for his collaboration on this adaptive routing scheme for BIER. 6. References 6.1. Normative References [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . Zhang, et al. Expires 6 May 2027 [Page 5] Internet-Draft Adaptive Routing with BIER November 2026 [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, . 6.2. Informative References [I-D.cheng-rtgwg-adaptive-routing-framework] Cheng, W., Lin, C., Wang, K., Ye, J., Zhuang, R., and P. Huo, "Adaptive Routing Framework", Work in Progress, Internet-Draft, draft-cheng-rtgwg-adaptive-routing- framework-06, 29 October 2026, . [I-D.ietf-idr-fare] Xu, X., Hegde, S., Patel, K., He, Z., and H. Wu, "Fully Adaptive Routing Ethernet using BGP", Work in Progress, Internet-Draft, draft-ietf-idr-fare-00, 10 October 2026, . Authors' Addresses Zhaohui Zhang HPE Email: zhaohui.zhang@hpe.com Tony Przygienda HPE Email: antoni.przygienda@hpe.com Zheng Zhang ZTE Email: zhang.zheng@zte.com.cn Xiaohu Xu China Mobile Email: xuxiaohu_ietf@hotmail.com Zhang, et al. Expires 6 May 2027 [Page 6]