Multicast Redundant Ingress Router Failover
draft-ietf-mboned-redundant-ingress-failover-06

MBONED WG                                                    G. Shepherd
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                             Z. Zhang, Ed.
Expires: 24 July 2025                                    ZTE Corporation
                                                                  Y. Liu
                                                            China Mobile
                                                                Y. Cheng
                                                            China Unicom
                                                               G. Mishra
                                                            Verizon Inc.
                                                         20 January 2025

              Multicast Redundant Ingress Router Failover
            draft-ietf-mboned-redundant-ingress-failover-06

Abstract

   This document discusses multicast redundant ingress router failover
   issues, including global multicast and service provider network MVPN
   use cases.  This document analyzes the specifications for global
   multicast and multicast VPN fast upstream failover and ingress PE
   standby modes and the benefits of each mode.

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 24 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Shepherd, et al.          Expires 24 July 2025                  [Page 1]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   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.
   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 . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Failure detection . . . . . . . . . . . . . . . . . . . .   7
   4.  Stand-by Modes  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Cold Root Standby Mode  . . . . . . . . . . . . . . . . .   8
     4.2.  Warm Root Standby Mode  . . . . . . . . . . . . . . . . .   8
     4.3.  Hot Root Standby Mode . . . . . . . . . . . . . . . . . .   9
     4.4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The multicast redundant ingress router failover is an important issue
   in multicast deployment.  This document tries to do a research on it
   in the multicast domain.  The Multicast Domain is a domain which is
   used to forward multicast flow according to specific multicast
   technologies, such as PIM ([RFC7761]), BIER ([RFC8279]), P2MP TE
   tunnel ([RFC4875]), MLDP ([RFC6388]), etc.  Static configuration, AMT
   ([RFC7450]) and SR P2MP Policy ([I-D.ietf-pim-sr-p2mp-policy]) may be
   used as well.  The domain may or may not connect the multicast source
   and receiver directly.

   The ingress router is close to the multicast source.  The ingress
   router may be directly connected to the multicast source, or there
   may be multiple hops between the ingress router and the multicast
   source.  In a multicast domain, the ingress router is the router
   closest to the multicast source.  It is also called the first hop
   router in PIM, or the BFIR in BIER, or the ingress LSR in P2MP TE
   tunnel or MLDP.

Shepherd, et al.          Expires 24 July 2025                  [Page 2]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   The failover function between the multicast source and the ingress
   router can be achieved by many ways, and it is not included in this
   document.

   The egress router is close to the multicast receiver.  The egress
   router may be directly connected to the multicast receiver, or there
   may be multiple hops between the egress router and the multicast
   receiver.  In a multicast domain, the egress router is the router
   closest to the multicast receiver.  It is also called the last hop
   router in PIM, or the BFER in BIER, or the egress LSR in P2MP TE
   tunnel or MLDP.

   This document doesn't discuss the details of these technologies.
   This document discusses the general redundant ingress router failover
   ways in the multicast domain.

   This document discusses the global multicast and Service Provider
   Network MVPN use case with redundant ingress PE nodes upstream
   multicast hop (UMH) and failover from primary to standby UMH in the
   multicast domain.  This document analyzes the specifications for
   Multicast VPN Fast Upstream Failover ([RFC9026]) and the Ingress PE
   Standby Modes and the benefits of each mode.

2.  Terminology

   The following abbreviations are used in this document:

   IR: The ingress router closest to the multicast source in the
   multicast domain.

   ER: The egress router closest to the multicast receiver in the
   multicast domain.

   SIR: The IR responsible for sending multicast flows, or the IR whose
   flows are received by the ER, is called Selected-IR, or SIR for
   short.

   BIR: IR is not responsible for sending multicast flows, or the flow
   from IR is not accepted by ER, but once SIR fails, IR will replace
   the role of SIR.  This IR is called Backup-IR, or BIR for short.

3.  Multicast Redundant Ingress Router Failover

Shepherd, et al.          Expires 24 July 2025                  [Page 3]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

                                 source
                                  ...
                            +-----+      +-----+
                 +----------+ IR1 +------+ IR2 +---------+
                 |multicast +-----+      +-----+         |
                 |domain            ...                  |
                 |                                       |
                 |          +-----+      +-----+         |
                 |          | Rm  |      | Rn  |         |
                 |          ++---++      +--+--+         |
                 |           |   |          |            |
                 |     +-----+   +---+      +-----+      |
                 |     |             |            |      |
                 |   +-v---+      +--v--+      +--v--+   |
                 +---+ ER1 +------+ ER2 +------+ ER3 +---+
                     +-----+      +-----+      +-----+
                      ...           ...          ...
                    receiver      receiver     receiver
                                 Figure 1

   Typically, a multicast source is connected to two IRs directly or
   through multiple hops to avoid single node failure.  As shown in
   Figure 1, there are two IRs close to the multicast source.  These two
   IRs are UMH (Upstream Multicast Hop) candidates for ER.

   The two IRs obtain multicast flows from the multicast source.  How to
   forward the multicast flows to the ER varies according to the
   technology deployed in the multicast domain.  For example, for the
   PIM used in this domain, two PIM trees can be built with the two IRs
   as roots.

   The IR cooperates with other routers in the multicast domain, such as
   the ER, to minimize multicast flow packet loss during IR switchover.

3.1.  Swichover

   Some failures may occur in the domain, such as link failure and node
   failure.  If the failed link or node is located on the multicast flow
   forwarding path, multicast flow packets may be lost.

   If there are multiple paths from IR to ER, there is no need to switch
   IR when some nodes or links fail.

   *  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
      or link in the forwarding tree fails, the tree is partially
      rebuilt.

Shepherd, et al.          Expires 24 July 2025                  [Page 4]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   *  When BIER is used as the multicast forwarding protocol within the
      domain, when a node or link fails, there is no need to rebuild the
      forwarding tree, and BIER forwarding is restored as the IGP
      routing converges.

   *  When P2MP TE tunnels or MLDP are used as multicast forwarding
      protocols in a domain, forwarding LSPs are pre-established.  When
      a node or link in the LSP fails, the LSP may be partially rebuilt.

   *  When a static multicast tree or SR P2MP policy is used in a
      domain, the controller needs to recalculate a new forwarding path
      to bypass the failed node or link.

   In some cases, there are some critical nodes or links in the network.
   Due to the failure of critical nodes or links, the multicast path
   cannot be restored.  The IR needs to be switched.

Shepherd, et al.          Expires 24 July 2025                  [Page 5]
Internet-Draft   Multicast Redundant In-Router Failover     January 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 domain, Rm and Rn can select Ry as the
      upstream node, send Join messages, and build a new tree with IR2
      as the root.

   *  When BIER is used in the 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
      the LSP used does not work.

   *  When static multicast tree or SR P2MP policy is used in the
      domain, the controller should let IR2 forward multicast flow to
      ER.

Shepherd, et al.          Expires 24 July 2025                  [Page 6]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

3.2.  Failure detection

   For successful IR switchover, some method should be used to monitor
   IR node failures or path failures between IR and ER, and once
   failures occur, IR can switchover.  Either BFD or PING method can be
   used.

   BFD [RFC5880] can be used for all deployments.  Multipoint BFD
   [RFC8562] can also be used for failure detection between IR and ER.
   BFD for MPLS LSP [RFC5884] can be used for P2MP TE tunnel or MLDP
   deployments.  BIER BFD [I-D.ietf-bier-bfd] can be used for BIER
   deployments.

   IPv4 PING [RFC0792] and IPv6 PING [RFC4443] can also be used for all
   deployments.  LSP-Ping [RFC8029] can be used for P2MP TE tunnel or
   MLDP deployment.  BIER PING [I-D.ietf-bier-ping] can be used for BIER
   deployment.

   BIR and ER can easily detect SIR node and path failures through BFD
   and PING methods.  If monitoring is done between SIR and ER, it is a
   challenge to quickly trigger a switch when BIR needs to start
   forwarding multicast flows.  If monitoring is between BIR and SIR,
   the path between BIR and SIR may fail, but the path is not the path
   from SIR to ER, and BIR may mistakenly trigger a switch, which will
   generate unnecessary duplicate flow.  In this case, ER must support
   selective reception and be compatible with IR switch errors.  In
   order to minimize false switches, the reliability of SIR/BIR
   detection needs to be enhanced, such as using redundant reliable
   paths for detection.

   Multicast VPN Fast Upstream Failover [RFC9026] defines a mechanism to
   detect the state of P-Tunnel X-PMSI A-D routes using P2MP BFD
   [RFC5880] with a new advertised BGP attribute called the BFD
   discriminator optional transitive attribute.

   Multicast VPN Fast Upstream Failover [RFC9026] defines a new "Standby
   PE" BGP community where the downstream PE initiates and sends a
   "Standby BGP C-multicast route" with the standby upstream PE UMH
   route RT import EC, which constructs the NLRI using the standby
   upstream PE UMH route's RD to identify the standby upstream PE.

4.  Stand-by Modes

   If there are multiple IRs that can act as UMHs, and if an IR fails,
   there is no other path from the IR to the ER, and the IR needs to be
   switched.

Shepherd, et al.          Expires 24 July 2025                  [Page 7]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   Multicast IR protection usually has three alternate modes.  [RFC9026]
   has some descriptions of this.  This document discusses the details
   of these three modes here.

   When an ER discovers a node or path failure, it may send a request to
   the upstream router or IR.  The request from the ER may be PIM tree
   construction, or BIER overlay protocol signaling, or LSP
   construction, or some other way to let the IR know whether to forward
   the multicast flow.

4.1.  Cold Root Standby Mode

   In cold root standby mode, ER selects a SIR, such as IR1 in Figure 1,
   as the SIR and signals it to get the multicast flow.

   When ER finds that the SIR is down, or ER finds that it cannot
   receive the flow from IR1, ER signals IR2 to get the multicast flow.

   *  For IR, IR (including SIR and BIR) only performs the normal
      operation of forwarding the flow according to ER's request.

   *  For ER, ER must select an IR as the SIR and signal it.  When SIR
      fails or the path between SIR and ER fails, ER must signal BIR to
      get the flow.

   *  For intermediate routers, they know nothing about the role of IR,
      they just do packet forwarding.  There is no duplicate packet in
      the domain.

   If an IR switchover occurs, the ER detects the SIR failure and
   signals the BIR.  Packet loss occurs during the signaling process
   until the ER receives the flow from the BIR.

4.2.  Warm Root Standby Mode

   In warm root standby mode, ER signals IR1 and IR2.

   If IR1 is SIR, IR1 forwards flow to ER.  BIR (such as IR2) shall not
   forward flow to ER until SIR fails.

   *  For IR, IR should play the role of SIR or BIR.  BIR shall not
      forward flow to ER.  When SIR fails or the path between SIR and ER
      fails, BIR must start forwarding flow to ER.  But it is difficult
      to know the path failure by BIR itself, some method should be
      taken to let BIR get the failure notification.

   *  For ER, ER does not choose SIR or BIR.  ER just signals to both of
      them.

Shepherd, et al.          Expires 24 July 2025                  [Page 8]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   *  For intermediate routers, they have no idea about the role of IR,
      they just do packet forwarding.  There are no duplicate packets in
      the domain.

   In case of IR switching, the BIR detects the SIR failure and switches
   to the SIR.  There is packet loss during IR switching.

   In some deployments, the SIR and BIR may be responsible for different
   multicast flows.  For a particular multicast flow, the SIR may be IR1
   and for another multicast flow, the SIR may be IR2.  So two IRs can
   share the multicast forwarding load.  Another possible deployment is
   that two IRs can be responsible for different ERs for one multicast
   flow.  For example, IR1 sends some multicast flows to ERs and IR2
   sends some other multicast flows to ERs.  If IR1 detects a failure
   among IR1 and ERs, IR1 may notify IR2 to take over the responsibility
   of forwarding the multicast flows to ERs that previously sent by IR1.

4.3.  Hot Root Standby Mode

   In hot-root standby mode, the ER signals to both IRs.

   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.

   *  For the IR, the IR does not need to know the role of the SIR or
      BIR, the IR just forwards flows based on the request received from
      the ER.

   *  For the ER, the ER signals both IRs for flows.  And the ER must
      discard duplicate flows from the backup BIR.  When the SIR fails
      or the path between the SIR and the ER fails, the ER must switch
      forwarding planes to forward flow packets from the BIR.  It should
      be noted that ER may choose different SIR or BIR for different
      multicast flows.

   *  For intermediate routers, they do not know the role of IR, they
      only do packet forwarding.  There is duplicate packet forwarding
      within the domain.

   In the case of IR switching, ER detects SIR failure.  Since there are
   duplicate flow packets arriving at ER, ER just switches to forwarding
   the flow from BIR.  There may be packet loss during switching.

Shepherd, et al.          Expires 24 July 2025                  [Page 9]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

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.

   +==============+=================+==================+===============+
   | 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 root standby mode is the easiest to implement, but has the
   longest convergence time.

   Hot root standby mode has the least packet loss, but there are
   duplicate packet forwardings within the domain, which consumes more
   bandwidth.

   Warm root standby mode has a moderate packet loss rate and
   convergence time, but it is difficult for the BIR to know about the
   failure between the SIR and ER.

Shepherd, et al.          Expires 24 July 2025                 [Page 10]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   The hot root standby mode described in Section 5 [RFC9026] is the
   best UMH protection mechanism.  There can be duplicate packet
   forwardings within the domain, and these packets will be discarded
   according to [RFC9026] Section 6 and [RFC6513] Section 9.1.  Hot root
   standby mode is the best recommended method for MVPN fast failover
   optimization.

   For network administrators, the most appropriate standby mode should
   be selected based on the network deployment.

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,
              <https://www.rfc-editor.org/info/rfc4875>.

   [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,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC7450]  Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
              DOI 10.17487/RFC7450, February 2015,
              <https://www.rfc-editor.org/info/rfc7450>.

   [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, <https://www.rfc-editor.org/info/rfc7761>.

Shepherd, et al.          Expires 24 July 2025                 [Page 11]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   [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,
              <https://www.rfc-editor.org/info/rfc8279>.

7.2.  Informative References

   [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-07, 26 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              bfd-07>.

   [I-D.ietf-bier-ping]
              Nainar, N. K., Pignataro, C., Chen, M., and G. Mirsky,
              "BIER Ping and Trace", Work in Progress, Internet-Draft,
              draft-ietf-bier-ping-15, 8 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              ping-15>.

   [I-D.ietf-pim-sr-p2mp-policy]
              Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., Zhang,
              Z. J., and M. P. Mishra, "Segment Routing Point-to-
              Multipoint Policy", Work in Progress, Internet-Draft,
              draft-ietf-pim-sr-p2mp-policy-10, 5 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
              p2mp-policy-10>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [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, <https://www.rfc-editor.org/info/rfc5884>.

Shepherd, et al.          Expires 24 July 2025                 [Page 12]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

   [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, <https://www.rfc-editor.org/info/rfc8562>.

   [RFC9026]  Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
              "Multicast VPN Fast Upstream Failover", RFC 9026,
              DOI 10.17487/RFC9026, April 2021,
              <https://www.rfc-editor.org/info/rfc9026>.

Authors' Addresses

   Greg Shepherd
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose,
   United States of America
   Email: gjshep@gmail.com

   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

Shepherd, et al.          Expires 24 July 2025                 [Page 13]
Internet-Draft   Multicast Redundant In-Router Failover     January 2025

   Gyan Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

Shepherd, et al.          Expires 24 July 2025                 [Page 14]