BIER Working Group Internet-Draft Y. Liu Intended status: Standards Track China Mobile Expires: April 25, 2024 C. Lin Y. Qiu New H3C Technologies October 23, 2023 BIER Loop Avoidance using Segment Routing draft-liu-bier-uloop-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 25, 2024. Copyright Notice Copyright (c) 2023 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 Liu, et al. Expires April, 2024 [Page 1] Internet-Draft BIER loop Avoidance October 2023 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document provides a mechanism leveraging SR-MPLS and/or SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................4 2. Loop-free convergence process..................................4 3. Computing Loop-avoiding Path...................................4 3.1. Explicit Path of Loop-avoiding............................5 3.2. Calculation Method of Explicit Path.......................5 4. Example Application............................................6 5. IANA Considerations............................................7 6. Security Considerations........................................7 7. References.....................................................7 7.1. Normative References......................................7 7.2. Informative References....................................8 8. Acknowledgments................................................8 Authors' Addresses................................................9 liu, et al. Expires April, 2024 [Page 2] Internet-Draft BIER loop Avoidance October 2023 1. Introduction Forwarding loops happen during the convergence of the IGP, as a result of transient inconsistency among forwarding states of the nodes of the network. When the network topology changes, loops may appear on new forwarding paths due to the different convergence speeds of each node's routing. During the multicast packet forwarding process, when the upstream BFR senses that its BFR-NBR is not reachable, the upstream BFR as a PLR node can quickly switch multicast traffic to backup path through the BIER FRR mechanism [I-D.ietf-bier-frr]. If the network fails to recover, multicast traffic will switch back from the backup path to the primary path. As shown in Figure 1 below, R1 is connected to the multicast source, and all IGP links are symmetric metric. Except for the link cost between G and H, which is 100, the cost of all other links is 1. The multicast data packet sent from R1 to R9 is initially forwarded along the path R1->R2->R3->R4->R9. When the link between R2 and R3 fails, or node R3 fails, there may be a loop in traffic between R2 and R7. SRC --- R1 ----- R2 ------ R3----- R4 | | | \ | | | \ | | | \ R5 ----- R6 ------ R7------R8----- R9----Receiver 100 Figure 1 When R2 senses that R3's route is unreachable, R2 will send the packet to backup BFR-NBR R6. However, because R6's BIFT has not yet been updated, the BFR-NBR recorded on R6 to BFER R9 is still R2. Therefore, after R6 receives the multicast packet, it will send the packet to R9 according to the bitstring in the BIER header. Multicast traffic may loop between R2 and R6. If BIFT on R7 converges after R6, during the convergence process, the multicast packet sent by R2 to R9 also may loop between R6 and R7. This document provides a mechanism leveraging SR-MPLS and/or SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. liu, et al. Expires April, 2024 [Page 3] Internet-Draft BIER loop Avoidance October 2023 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. Loop-free convergence process Upon a topology change, when a BFR converging for BFERs does not trust the loop-freeness of its post-convergence paths for BFERs, it performs convergence processing as follows. After computing the new path to BFER, for a predetermined amount of time C, BFR installs a BIFT for BFR-NBR that steers packets to BFER via a loop-free forwarding path. For example, forwarding through explicit SR unicast path or through explicit P2MP path. C should be greater than or equal to the worst-case convergence time of a node, network-wide. The determination of "C" is outside the scope of this document. The forwarding path is computed when the event occurs. After C elapses, BFR installs the normal post-convergence forwarding entry for BFER that ensure the loop-free property. Taking Figure 1 as an example, when the link between R2 and R3 fails, R6 received multicast service from its downstream BFR neighbor R2. Within the interval C, R6 specifies the interface connecting R6 and R7 as the outbound interface, and forwards multicast packets sent to R9 according to a strictly explicit path to the next BFR neighbor R7. After R7 receives the multicast message from the explicit path, it performs similar processing as R6. If it is within the interval C, continue to specify the interface connecting R7 and R8 as the outbound interface, and forward multicast packets to BFR neighbor R8 according to the strict explicit path. By analogy, before the routing convergence is completed, the traffic on the backup path is forwarded along the path R6->R7->R8->R9. 3. Computing Loop-avoiding Path When the link between R2 and R3 fails, R6 receives multicast message from its downstream BFR neighbor R2 and temporarily redirects the traffic targeting R9 to an explicit path, forwarding it based on the specified node label or SRv6 SID in the explicit path. liu, et al. Expires April, 2024 [Page 4] Internet-Draft BIER loop Avoidance October 2023 When the link between R2 and R3 fails to recover, the process of avoiding loops is also similar. 3.1. Explicit Path of Loop-avoiding The explicit path of loop-avoiding can be (but not limited to): * SR policy TE path. Treat each node or adjacent SID on the explicit path as a segment on the SR Policy TE path. During the convergence process, add SRv6 encapsulation to the BIER message, specify the SRH Segment List, and send it to the next BFR in the backup path. After reaching the next BFR, decapsulate the outer layer SR- MPLS/SRv6 packet header, restore the original BIER packet, and continue forwarding according to the BIER header. * BIER-TE forwarding path. During the convergence process, each node on the explicit path is treated as a BIER-TE node and forwarded through BIER-TE. The bit position of nodes on the BIER-TE path can be arranged into the bitstring of the original BIER header, or the BIER-TE header can be encapsulated outside the BIER message. * P2MP policy forwarding path. During the convergence process, multicast messages are forwarded through the path specified by the P2MP policy. 3.2. Calculation Method of Explicit Path There are currently two methods to calculate the nodes included in the explicit path. Method 1: Similar to [RFC7490], we use the concept of P-Space and Q- Space for TI-LFA. Generate explicit SR/SRv6-based path from P to Q. The repair list is expressed generally as {P node (NODE SID), all ADJ/End. X SIDs from P node to Q node}. a) Using the BFER destination node, calculate the optimal convergence path tree. That is, when the link fails, the source node reconverges to the calculated SPF tree. b) Find the Q node. On the convergence path tree, traverse the parent nodes starting from the BFER destination node until finding the farthest node from the destination node, which is not affected by the link failure and can reach the destination node, as the Q node. c) Find the P node. On the convergence path tree, traverse the parent nodes starting from the Q node until finding a node that liu, et al. Expires April, 2024 [Page 5] Internet-Draft BIER loop Avoidance October 2023 is not affected by the link failure on the path from the source node to that node. This node will be considered as the P node. d) Calculate the repair segment list path. Calculate the repair segment list path. The repair segment list path is found by computing the explicit SR/SRv6-based path from P to Q when these nodes are not adjacent along the convergence path. For SR-MPLS, the repair list is expressed {Node_SID(P), AdjSID(P->Q)}; For SRv6, the repair list is expressed {END_SID(P), END. X(P->Q)}. e) Calculate the output interface. The next hop output interface that converges again after a link failure. Method 2: Directly from source node S to destination node Q, generating a strict explicit path. For SR-MPLS, the repair list is expressed {AdjSID(S->Q)}; For SRv6, the repair list is expressed {END. X(S->Q)}. If the Q nodes and Q nodes of different receivers are the same, which means that multicast packets can be forwarded through the same path, it is necessary to merge the multicast forwarding paths to avoid headend replication. Try to place the multicast replication point on the node closest to the multicast receivers. 4. Example Application SRC --- R1 ----- R2 ------ R3----- R4----- R10----Receiver1 | | | \ | | | \ | | | \ R5 ----- R6 ------ R7------R8----- R9----Receiver2 100 Figure 2 As an example, in Figure 2, R1 is connected to the multicast source, and all IGP links are symmetric metric. Except for the link cost between R7 and R8, the cost of all other links is 1. The multicast data packet sent from R1 to R9 and R10 is initially forwarded along the path R1->R2->R3->R4->R9/R10. When the link between R2 and R3 fails, or node R3 fails, there may be a loop in traffic between R2 and R7. Therefore, we will compute the repair path and repair list for the from R1 to R9 and R10 in the event of the link between R2 and R3 fails, or node R3 fails. liu, et al. Expires April, 2024 [Page 6] Internet-Draft BIER loop Avoidance October 2023 1) The expected convergence path from R1 to R9 and R10 considering the failure of link between R2 and R3 or of node R3 is R2/R5->R6->R7->R8->R9> and R2/R5->R6->R7->R8->R4->R10>. 2) Q is computed and results in [R8]. 3) P is computed and results in [R7]. 4) To the two leaf nodes R9 and R10, both need to go through the R7->R8 link. For SR-MPLS, the repair list of R1 for destination R9 and R10 considering the failure of link between R2 and R3 or of node R3 is: . For SRv6, the repair list of R1 for destination R9 and R10 considering the failure of link between R2 and R3 or of node R3 is: . When the link between R2 and R3 fails, or R3 fails, multicast traffic is first sent to R8 along the R1->R2/R5->R6->R7->R8 path, and then two copies are replicated at R8. One copy is forwarded to R9, and the other copy is forwarded to R10. 5. IANA Considerations No requirements for IANA. 6. Security Considerations The behavior described in this document is internal functionality to a router that result in the ability to explicitly steer traffic over the post convergence path after a remote topology change in a manner that guarantees loop freeness. Because the behavior serves to minimize the disruption associated with a topology change, it can be seen as a modest security enhancement. 7. References 7.1. Normative References [I-D.ietf-6man-ipv6-alt-mark] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate Marking Method", draft-ietf-6man-ipv6-alt-mark-16 (work in progress), July 2022. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . liu, et al. Expires April, 2024 [Page 7] Internet-Draft BIER loop Avoidance October 2023 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., So, N., "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", BCP 14, RFC 8174, DOI 10.17487/RFC7490, April 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References TBD 8. Acknowledgments The authors would like to thank the following for their valuable contributions of this document: TBD liu, et al. Expires April, 2024 [Page 8] Internet-Draft BIER loop Avoidance October 2023 Authors' Addresses Yisong Liu China Mobile Email: liuyisong@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Yuanxiang Qiu New H3C Technologies China Email: qiuyuanxiang@h3c.com liu, et al. Expires April, 2024 [Page 9]