MBONED WG G. Shepherd Internet-Draft Cisco Systems, Inc. Intended status: Informational Z. Zhang, Ed. Expires: 5 January 2026 ZTE Corporation Y. Liu China Mobile Y. Cheng China Unicom G. Mishra Verizon Inc. 4 July 2025 Multicast Redundant Ingress Router Failover draft-ietf-mboned-redundant-ingress-failover-07 Abstract This document analyzes the redundant ingress router failover problem of a multicast domain, and analyzes the possible backup modes and advantages of each mode when deploying multiple ingress devices to forward the same multicast flow in a multicast domain. 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 5 January 2026. Copyright Notice Copyright (c) 2025 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. Shepherd, et al. Expires 5 January 2026 [Page 1] Internet-Draft Multicast Redundant In-Router Failover July 2025 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multicast Redundant Ingress Router Failover . . . . . . . . . 3 3.1. Swichover . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Failure detection . . . . . . . . . . . . . . . . . . . . 7 4. Stand-by Modes . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Cold Standby Mode . . . . . . . . . . . . . . . . . . . . 8 4.2. Warm Standby Mode . . . . . . . . . . . . . . . . . . . . 8 4.3. Hot Standby Mode . . . . . . . . . . . . . . . . . . . . 9 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Multicast redundant ingress router failover is an important issue in multicast deployments, especially in backbone multicast domains or multicast provider domains. Backbone multicast domains or multicast provider domains are referred to as multicast domains in the following sections. A multicast domain is a domain used to forward multicast flow based on specific multicast technologies, such as PIM [RFC7761], BIER [RFC8279], P2MP TE tunnel [RFC4875], MLDP [RFC6388], etc. Static configuration, tunnel based technologies, such as AMT [RFC7450], SR P2MP policies [I-D.ietf-pim-sr-p2mp-policy] can also be used. The domain may or may not be directly connected to the actual multicast source and receivers. The ingress device of the multicast domain, such as the ingress router, can be connected to the multicast source by a single hop or multiple hops. In PIM, it is also called the first hop router, in BIER, it is called the BFIR, and in P2MP TE tunnel or MLDP, it is called the ingress LSR. Shepherd, et al. Expires 5 January 2026 [Page 2] Internet-Draft Multicast Redundant In-Router Failover July 2025 The egress device of the multicast domain, such as the egress router, may be connected to the multicast receiver by a single hop or multiple hops. In PIM, it is also called the last hop router, in BIER, it is called the BFER, and in P2MP TE tunnel or MLDP, it is called the egress LSR. In order to ensure the reliability of multicast flow, there may be two or more ingress devices or egress devices in the multicast domain. That means the same multicast flow may enter the multicast domain from multiple ingress devices of the multicast domain. This draft does not discuss the protection method between the ingress device and the multicast source, between the egress device and the receiver, nor does it discuss the details of the technologies such as PIM and BIER. It only discusses the issue of failover of the ingress router of the multicast domain. This document discusses the deployment of multiple ingress devices in a multicast domain. When a fault occurs, the switching method from the primary ingress device to the backup ingress device and the common fault detection methods are discussed. The advantages and disadvantages of the switching methods are analyzed to provide a reference for multicast deployment. 2. Terminology The following abbreviations are used in this document: IR: The ingress router for multicast flows in a multicast domain. ER: The egress router for multicast flows in a multicast domain. SIR: The IR responsible for sending the multicast flow, or the IR whose flow is received by the ER, is called Selected-IR, or SIR for short. BIR: The IR may or may not send multicast flows. Multicast flows from IR will not be accepted by ER. Once SIR fails, IR will replace the role of SIR and multicast flows from IR will be accepted by ER. This IR is called backup IR, or BIR for short. 3. Multicast Redundant Ingress Router Failover Shepherd, et al. Expires 5 January 2026 [Page 3] Internet-Draft Multicast Redundant In-Router Failover July 2025 source ... +-----+ +-----+ +----------+ IR1 +------+ IR2 +---------+ |multicast +-----+ +-----+ | |domain ... | | | | +-----+ +-----+ | | | Rm | | Rn | | | ++---++ +--+--+ | | | | | | | +-----+ +---+ +-----+ | | | | | | | +-v---+ +--v--+ +--v--+ | +---+ ER1 +------+ ER2 +------+ ER3 +---+ +-----+ +-----+ +-----+ ... ... ... receiver receiver receiver Figure 1 This is a common multicast networking scenario. The multicast domain includes the area from IR to ER. The flow sent by the multicast source enters the multicast domain from at least one IR, is forwarded in the multicast domain, reaches the ER, is forwarded by the ER, and finally the receiver receives the multicast flow. The ingress device IR of the multicast domain is a key node for the normal forwarding of multicast flows. When two or more IRs are deployed, there may be multiple protection modes for IR, such as cold standby, warm standby and hot standby. These modes are also described in [RFC9026]. However, [RFC9026] mainly focuses on signaling notifications in MVPN scenarios and does not involve the protection mode of multiple ingress devices in the multicast domain and the impact on multicast flow transmission in the multicast domain. As shown in Figure 1, a same multicast flow enters the multicast domain from two IRs. Both IRs are UMH (Upflow Multicast Hop) candidates of ER. Different multicast technologies may be used in the multicast domain according to the deployment of the network administrator. Assuming that PIM technology is used, two multicast trees can be pre-established with two IRs as roots. Shepherd, et al. Expires 5 January 2026 [Page 4] Internet-Draft Multicast Redundant In-Router Failover July 2025 3.1. Swichover When a node or link in the multicast domain fails, the forwarding of multicast flow may be affected. However, it is not necessary to switch multicast flow from SIR to BIR in all cases. The following are situations where switching is not required: * When PIM is used as the multicast forwarding protocol in a domain, a forwarding tree of (S, G) or (*, G) is pre-built. When a node other than SIR or a link in the forwarding tree fails, the tree is partially rebuilt. * When BIER is used as the multicast forwarding protocol in a multicast domain, when a node other than SIR or a link in the domain fails, there is no need to rebuild the forwarding path, BIER forwarding will be restored as the IGP route converges. * When P2MP TE tunnel or MLDP is used as the multicast forwarding protocol in a multicast domain, a forwarding LSP is pre- established. When a node other than the SIR in the LSP or a link in the domain fails, the LSP may be partially rebuilt. * When a static multicast tree or SR P2MP policy is used in a multicast domain, when a node other than the SIR on the forwarding path or a link has a problem, the controller needs to recalculate a new forwarding path to bypass the faulty node or link. When a critical failure occurs, it is necessary to switch from SIR to BIR, for example: SIR encounters a device failure, or the forwarding channel between SIR and ER fails, causing ER to be unable to receive multicast flows from SIR, and this failure cannot be restored in a short time. At this time, the multicast flow will be forwarded by BIR. ER receives the flow forwarded by BIR and forwards it to the receiver. Shepherd, et al. Expires 5 January 2026 [Page 5] Internet-Draft Multicast Redundant In-Router Failover July 2025 source ... +-----+ +-----+ +----------+ IR1 +------+ IR2 +---------+ | +--+--+ +--+--+ | | | | | | +--+--+ +--+--+ | | | Rx | | Ry | | | +-+-+-+ ++---++ | | | | | | | | | +-----------+ | | | | | | | | | | +---------+ | | | | | | | | | | +-v-v-+ +--v-v+ | | | Rm | | Rn | | | ++---++ +--+--+ | | | | | | | +-----+ +---+ +-----+ | | | | | | | +-v---+ +--v--+ +--v--+ | +---+ ER1 +------+ ER2 +------+ ER3 +---+ +-----+ +-----+ +-----+ ... ... ... receiver receiver receiver Figure 2 For example, in Figure 2, there is only one path in some areas of the network. IR1 and Rx are key nodes in the domain. When IR1 or Rx fails, there is no other path between IR1 and ER. * When PIM is used in the multicast domain, Rm and Rn can select Ry as the upflow node, send Join messages, and build a new tree with IR2 as the root. * When BIER is used in the multicast domain, IR2 should be responsible for the forwarding role and forward flow to ER. * When P2MP TE tunnel or MLDP is used in the domain, LSP initiated from IR2 can be built and replace the LSP initiated from IR1. * When a static multicast tree or SR P2MP policy is used in the multicast domain, the controller should build a new forwarding path with IR2 as the root to forward the multicast flow to ER. Shepherd, et al. Expires 5 January 2026 [Page 6] Internet-Draft Multicast Redundant In-Router Failover July 2025 3.2. Failure detection The IR node itself and the key forwarding link between IR and ER are factors that affect traffic forwarding within the multicast domain. In order to achieve fast switching, BIR can establish a forwarding channel with ER in advance and monitor the status of SIR. When the SIR node fails, it will take over the work of SIR. BIR can establish a BFD [RFC5880] session with SIR to detect the SIR status, or it can be detected by ping and other methods. However, it should be noted that the detection between BIR and SIR does not represent the actual forwarding path status between SIR and ER. When SIR is working normally, only the link between BIR and SIR fails, which may cause BIR to make wrong judgments and switch, thereby generating unnecessary duplicate flow. In this case, ER must support selective reception and be compatible with IR switching errors. There may be problems with the forwarding path between SIR and ER, but the link between BIR and SIR is normal and cannot be detected by BIR. Therefore, ER can also detect the forwarding path between SIR and ER and actively switch to BIR to forward flow when problems are found. The detection between SIR and ER can be based on multipoint BFD [RFC8562]. When BIER is used to forward flow in the multicast domain, the detection between SIR and ER can also be based on BIER BFD [I-D.ietf-bier-bfd]. When MPLS is used to forward flow in the multicast domain, BFD [RFC5884] based on MPLS LSP can be used for detection. 4. Stand-by Modes Detection and IR switching can be three modes: cold standby, warm standby, and hot standby. When the three modes are used to protect IR, the transmission mode of multicast flow in the multicast domain is different, and the impact on the network is also different. When the multicast domain uses the PIM protocol to forward flow, ER will establish a multicast tree to BIR through signaling. When the multicast domain uses BIER to forward flow, ER will notify BIR the request to receive multicast flow through the BIER overlay protocol. When the multicast domain uses P2MP TE or MLDP to forward flow, a multicast forwarding channel is established from BIR to ER. The PIM multicast tree with BIR as the root and the P2MP TE or MLDP tunnel from BIR to ER can also be established in advance, and ER directly notifies BIR to use the multicast tree or tunnel for forwarding. Shepherd, et al. Expires 5 January 2026 [Page 7] Internet-Draft Multicast Redundant In-Router Failover July 2025 4.1. Cold Standby Mode In cold standby mode, ER selects a SIR (e.g. IR1 in Figure 1) as the SIR and signals it to obtain the multicast flow. When ER finds that it cannot receive the flow from IR1 through the detection means in Section 3.2, ER signals IR2 to obtain the multicast flow. * For IR, IR (including SIR and BIR) only performs the normal operation of forwarding the flow according to ER request. * For ER, ER must select an IR as the SIR and signal it. When the SIR fails or the path between SIR and ER fails, ER must signal BIR to obtain the flow. * For intermediate routers, they know nothing about the role of IR, they only forward packets. There is no duplicate packets in the domain. In this scenario, the BIR does not need to detect the status of the SIR. During the IR switching process, packet loss may occur because of the need for signaling interaction. Even if a PIM multicast tree or P2MP TE/MLDP tunnel is established in advance, packet loss may still occur. 4.2. Warm Standby Mode In warm standby mode, the ER will signal to the SIR and BIR, such as IR1 and IR2 in Figure 2, that it needs to receive flow. The SIR (such as IR1) forwards the flow to the ER. The BIR (such as IR2) must not forward flow to the ER before the SIR fails. The BIR can detect the SIR status by the method described in Section 3.2, and automatically forward flow to the ER when the SIR fails. * Normally, the SIR forwards flow to the ER. When the SIR fails or the path between the SIR and the ER fails, the BIR must start forwarding flow to the ER. The BIR can detect node failures in the SIR using the method described in Section 3.2, but may lack the method to detect path failures from the SIR to the ER. * The ER does not distinguish between the SIR and the BIR. The ER only signals to both that it needs to receive a certain flow. * For the intermediate routers, they do not know the difference between the IRs, and they are only responsible for packet forwarding. There are no duplicate packets in the domain. Shepherd, et al. Expires 5 January 2026 [Page 8] Internet-Draft Multicast Redundant In-Router Failover July 2025 When the BIR detects the SIR failure and starts forwarding flow, packet loss will occur during the switchover. In some deployments, the SIR and BIR may be responsible for different multicast flows to share the load. For a certain multicast flow, the SIR may be IR1, and for another multicast flow, the SIR may be IR2. For example, IR1 sends some multicast flows to ERs and IR2 sends other multicast flows to ERs. Another possible deployment is that two IRs can be responsible for different ERs for the same multicast flow. If IR1 detects a failure between IR1 and ERs, IR1 may notify IR2 to forward flow to these ERs. 4.3. Hot Standby Mode In hot standby mode, the ER signals both IRs that it wants to receive a certain flow. Both IRs send flows to the ER. The ER must discard duplicate flows from one of the IRs. In this case, there is no SIR or BIR. Only the ER knows which IR is the SIR. * In this mode, the IR does not need to know the role of the SIR or BIR, IR only forwards the flow based on the request received from the ER. * ER will send flow reception signals to both IRs and discard the duplicate flow from the backup BIR when it receives a duplicate flow. After switching the ER receives and forwards the flow from the BIR. It should be noted that the ER may choose different SIRs or BIRs for different multicast flows. * Intermediate routers do not know the role of the IR, they only forward packets. There are duplicate packets within the domain. In this mode, BIR does not need to detect the status of SIR. ER will detect the failure of SIR. Since duplicate flow packets arrive at ER, although packet loss may occur when ER switches to receive and forward flow from BIR, the packet loss is very small compared to the previous two modes. 4.4. Summary The following table is a simple comparison of the three modes. "SIR failover" means that the SIR fails or the path between the SIR and the ER fails. Shepherd, et al. Expires 5 January 2026 [Page 9] Internet-Draft Multicast Redundant In-Router Failover July 2025 +==============+=================+==================+===============+ | role | Cold Mode | Warm Mode | Hot Mode | +==============+=================+==================+===============+ | IR | Forwards flow | Acting as | Does not need | | | based on ER's | either SIR or | to know SIR | | | request. | BIR, BIR must | or BIR role, | | | | not forward | just forwards | | | | flow to ER | flow based on | | | | until SIR | ER's request. | | | | fails over. | | +--------------+-----------------+------------------+---------------+ | ER | Must select an | Does not | Signals both | | | IR as SIR to | select SIR or | SIR and BIR. | | | signal request, | BIR, just | Drops | | | signals BIR to | signals both | duplicate | | | request flow | of them. | flow from BIR | | | when SIR fails | | until SIR | | | over. | | fails over. | +--------------+-----------------+------------------+---------------+ | Intermediate | Know nothing | Know nothing | No knowledge | | routers | about SIR or | about SIR or | of SIR or | | | BIR. Do not | BIR. Do not | BIR. Forward | | | forward | forward | duplicate | | | duplicate flow. | duplicate | flow. | | | | flow. | | +--------------+-----------------+------------------+---------------+ Table 1 Cold standby mode is the easiest to implement, but has the longest convergence time. Warm standby mode has a moderate packet loss rate and convergence time, but it is difficult for BIR to know the path failure between SIR and ER. Hot standby mode has the lowest packet loss rate, but there is duplicated packet forwarding within the domain, which consumes more bandwidth. For example, in the MVPN scenario, the hot root standby mode described in Section 5 [RFC9026] is the best recommended method for MVPN fast failover optimization. There may be duplicated packet forwarding within the domain, which will be discarded according to the provisions of [RFC9026] Section 6 and [RFC6513] Section 9.1. For network administrators, the most appropriate standby mode should be selected based on the actual network deployment, such as whether there is enough bandwidth to accommodate duplicate flow. Shepherd, et al. Expires 5 January 2026 [Page 10] Internet-Draft Multicast Redundant In-Router Failover July 2025 5. IANA Considerations This document does not have any requests for IANA allocation. 6. Security Considerations This document adds no new security considerations. 7. References 7.1. Normative References [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [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, . 7.2. Informative References Shepherd, et al. Expires 5 January 2026 [Page 11] Internet-Draft Multicast Redundant In-Router Failover July 2025 [I-D.ietf-bier-bfd] Xiong, Q., Mirsky, G., hu, F., Liu, C., and G. S. Mishra, "BIER BFD", Work in Progress, Internet-Draft, draft-ietf- bier-bfd-08, 26 February 2025, . [I-D.ietf-pim-sr-p2mp-policy] Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. J. Zhang, "Segment Routing Point-to-Multipoint Policy", Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp- policy-12, 23 May 2025, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, . [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., "Multicast VPN Fast Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, April 2021, . Authors' Addresses Greg Shepherd Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, United States of America Email: gjshep@gmail.com Shepherd, et al. Expires 5 January 2026 [Page 12] Internet-Draft Multicast Redundant In-Router Failover July 2025 Zheng Zhang (editor) ZTE Corporation Nanjing China Email: zhang.zheng@zte.com.cn Yisong Liu China Mobile Beijing Email: liuyisong@chinamobile.com Ying Cheng China Unicom Beijing China Email: chengying10@chinaunicom.cn Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Shepherd, et al. Expires 5 January 2026 [Page 13]