Skip to main content

Multicast Source Redundancy in EVPN Networks
draft-ietf-bess-evpn-redundant-mcast-source-09

Document Type Active Internet-Draft (bess WG)
Authors Jorge Rabadan , Jayant Kotalwar , Senthil Sathappan , Zhaohui (Jeffrey) Zhang , Wen Lin
Last updated 2024-01-22
Replaces draft-skr-bess-evpn-redundant-mcast-source
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Mankamana Prasad Mishra
Shepherd write-up Show Last changed 2024-07-17
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to mankamis@cisco.com
draft-ietf-bess-evpn-redundant-mcast-source-09
BESS Workgroup                                           J. Rabadan, Ed.
Internet-Draft                                               J. Kotalwar
Intended status: Standards Track                            S. Sathappan
Expires: 25 July 2024                                              Nokia
                                                                Z. Zhang
                                                                  W. Lin
                                                                 Juniper
                                                         22 January 2024

              Multicast Source Redundancy in EVPN Networks
             draft-ietf-bess-evpn-redundant-mcast-source-09

Abstract

   Ethernet Virtual Private Network (EVPN) supports intra and inter-
   subnet IP multicast forwarding.  However, EVPN (or conventional IP
   multicast techniques for that matter) do not have a solution for the
   case where the following two statements are true at the same time: a)
   a given multicast group carries more than one flow (i.e., more than
   one source), and b) it is desired that each receiver gets only one of
   the several flows.  Existing multicast techniques assume there are no
   redundant sources sending the same flow to the same IP multicast
   group, and, in case there were redundant sources, the receiver's
   application would deal with the received duplicated packets.  This
   document extends the existing EVPN specifications and assumes that IP
   Multicast source redundancy may exist.  It also assumes that, in case
   two or more sources send the same IP Multicast flows into the tenant
   domain, the EVPN PEs need to avoid that the receivers get packet
   duplication by following the described procedures.

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 25 July 2024.

Rabadan, et al.           Expires 25 July 2024                  [Page 1]
Internet-Draft           EVPN Redundant Sources             January 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 (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Background on IP Multicast Delivery in EVPN Networks  . .   7
       1.2.1.  Intra-subnet IP Multicast Forwarding  . . . . . . . .   7
       1.2.2.  Inter-subnet IP Multicast Forwarding  . . . . . . . .   8
     1.3.  Multi-Homed IP Multicast Sources in EVPN  . . . . . . . .  10
     1.4.  The Need for Redundant IP Multicast Sources in EVPN . . .  12
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .  12
   3.  BGP EVPN Extensions . . . . . . . . . . . . . . . . . . . . .  14
   4.  Warm Standby (WS) Solution for Redundant G-Sources  . . . . .  15
     4.1.  Warm Standby Example in an OISM Network . . . . . . . . .  17
     4.2.  Warm Standby Example in a Single-BD Tenant Network  . . .  19
   5.  Hot Standby Solution for Redundant G-Sources  . . . . . . . .  20
     5.1.  Extensions for the Advertisement of DCB Labels  . . . . .  24
     5.2.  Use of BFD in the HS Solution . . . . . . . . . . . . . .  25
     5.3.  Hot Standby Example in an OISM Network  . . . . . . . . .  25
     5.4.  Hot Standby Example in a Single-BD Tenant Network . . . .  29
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  30
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  31
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

Rabadan, et al.           Expires 25 July 2024                  [Page 2]
Internet-Draft           EVPN Redundant Sources             January 2024

1.  Introduction

   Intra and Inter-subnet IP Multicast forwarding are supported in EVPN
   networks.  [RFC9251] describes the procedures required to optimize
   the delivery of IP Multicast flows when Sources and Receivers are
   connected to the same EVPN Broadcast Domain, whereas
   [I-D.ietf-bess-evpn-irb-mcast] specifies the procedures to support
   Inter-subnet IP Multicast in a tenant network.  Inter-subnet IP
   Multicast means that IP Multicast Source and Receivers of the same
   multicast flow are connected to different Broadcast Domains of the
   same tenant.

   [RFC9251], [I-D.ietf-bess-evpn-irb-mcast] or conventional IP
   multicast techniques do not have a solution for the case where the
   following two statements are true at the same time: a) a given
   multicast group carries more than one flow (i.e., more than one
   source) and b) it is desired that each receiver gets only one of the
   several flows.  Multicast techniques assume there are no redundant
   sources sending the same flows to the same IP multicast group, and,
   in case there were redundant sources, the receiver's application
   would deal with the received duplicated packets.

   As a workaround in conventional IP multicast (that is, networks
   running Protocol Independent Multicast [RFC7761] or Multicast Virtual
   Private Networks [RFC6513]), if all the redundant sources are given
   the same IP address, each receiver will get only one flow.  The
   reason is that, in conventional IP multicast, the RP (Rendezvous
   Point) always creates (S,G) state, and the Last Hop Router sometimes
   creates (S,G) state.  The (S,G) state always binds the (S,G) flow to
   a source-specific tree, rooted at the source IP address.  If multiple
   sources have the same IP address, one may end up with multiple (S,G)
   trees.  However, the way the trees are constructed ensures that any
   given Last Hop Router or Rendezvous Point router is on at most one of
   them.  The use of an anycast address assigned to multiple sources may
   be useful for warm standby redundancy solutions (Section 2).
   However, on one hand, it is not really helpful for hot standby
   redundancy solutions (Section 2) and on the other hand, configuring
   the same IP address (in particular, the same IPv4 address) in
   multiple sources may bring issues if the sources need to be reached
   by IP unicast traffic or if the sources are attached to the same
   Broadcast Domain.

   In addition, in the scenario where several multicast sources
   streaming traffic to the same group are attached via EVPN/OISM
   (Optimized Inter-Subnet Multicast), there is not necessarily any
   (S,G) state created for the redundant sources.  The Last Hop Routers
   may have only (*,G) state, and there may not be a Rendezvous Point
   router (creating (S,G) state) either.  Therefore, this document

Rabadan, et al.           Expires 25 July 2024                  [Page 3]
Internet-Draft           EVPN Redundant Sources             January 2024

   extends [RFC9251] and [I-D.ietf-bess-evpn-irb-mcast], and now assumes
   that IP Multicast source redundancy may exist.  The document also
   specifies how, in case two or more sources send the same IP Multicast
   flows into the tenant domain, the EVPN PEs avoid the receivers from
   getting packet duplication.  The procedures to handle redundant
   sources in solutions different from [RFC9251] or
   [I-D.ietf-bess-evpn-irb-mcast] are out of the scope of this document.

   The solution provides support for Warm Standby and Hot Standby
   redundancy.  Warm Standby is defined as the redundancy scenario in
   which the upstream PEs, attached to the redundant sources of the same
   tenant, make sure that only one source of the same flow can send
   multicast to the interested downstream PEs at the same time.  In Hot
   Standby mode, the upstream PEs forward the redundant multicast flows
   to the downstream PEs, and the downstream PEs make sure only one flow
   is forwarded to the interested attached receivers.

1.1.  Terminology

   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.

   *  Broadcast Domain (BD): an emulated ethernet, such that two systems
      on the same BD will receive each other's link-local broadcasts.
      In this document, BD also refers to the instantiation of a
      Broadcast Domain on an EVPN PE.  An EVPN PE can be attached to one
      or multiple BDs of the same tenant.

   *  BUM: Broadcast, Unknown unicast and Multicast traffic.

   *  Designated Forwarder (DF): as defined in [RFC7432], an ethernet
      segment may be multi-homed (attached to more than one PE).  An
      ethernet segment may also contain multiple BDs, of one or more
      EVIs.  For each such EVI, one of the PEs attached to the segment
      becomes that EVI's DF for that segment.  Since a BD may belong to
      only one EVI, we can speak unambiguously of the BD's DF for a
      given segment.

   *  Downstream PE: in this document a Downstream PE is referred to as
      the EVPN PE that is connected to the IP Multicast receivers and
      gets the IP Multicast flows from remote EVPN PEs.

   *  G-traffic: any frame with an IP payload whose IP Destination
      Address (IP DA) is a multicast group G.

Rabadan, et al.           Expires 25 July 2024                  [Page 4]
Internet-Draft           EVPN Redundant Sources             January 2024

   *  G-source: any system sourcing IP multicast traffic to group G.

   *  IGMP: Internet Group Management Protocol.

   *  Inclusive Multicast Tree or Inclusive Provider Multicast Service
      Interface (I-PMSI): defined in [RFC6513], in this document it is
      applicable only to EVPN and refers to the default multicast tree
      for a given BD.  All the EVPN PEs that are attached to a specific
      BD belong to the I-PMSI for the BD.  The I-PMSI trees are signaled
      by EVPN Inclusive Multicast Ethernet Tag (IMET) routes.

   *  IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in
      [RFC7432].

   *  MLD: Multicast Listener Discovery.

   *  MVPN: Multicast Virtual Private Networks, as in [RFC6513].

   *  OISM: Optimized Inter-Subnet Multicast, as in
      [I-D.ietf-bess-evpn-irb-mcast].

   *  PIM: Protocol Independent Multicast, as in [RFC7761].

   *  P-tunnel: Provider tunnel refers to the type of tree a given
      upstream EVPN PE uses to forward multicast traffic to downstream
      PEs.  Examples of P-tunnels supported in this document are Ingress
      Replication (IR), Assisted Replication (AR), Bit Indexed Explicit
      Replication (BIER), multicast Label Distribution Protocol (mLDP)
      or Point to Multi-Point Resource Reservation protocol with Traffic
      Engineering extensions (P2MP RSVP-TE).

   *  Redundant G-source: a host or router that transmits an SFG in a
      tenant network where there are more hosts or routers transmitting
      the same SFG.  Redundant G-sources for the same SFG SHOULD have
      different IP addresses, although they MAY have the same IP address
      when in different BDs of the same tenant network.  Redundant
      G-sources are assumed NOT to be "bursty" in this document (typical
      example are Broadcast TV G-sources or similar).

   *  S-ES and S-ESI: multicast Source Ethernet Segment and multicast
      Source Ethernet Segment Identifier.  The Ethernet Segment and
      Ethernet Segment Identifier associated to a G-source.

   *  Selective Multicast Tree or Selective Provider Multicast Service
      Interface (S-PMSI): defined in [RFC6513], in this document it is
      applicable only to EVPN and refers to the multicast tree to which
      only the interested PEs of a given BD belong to.  There are two
      types of EVPN S-PMSIs:

Rabadan, et al.           Expires 25 July 2024                  [Page 5]
Internet-Draft           EVPN Redundant Sources             January 2024

      -  EVPN S-PMSIs that require the advertisement of S-PMSI Auto-
         Discovery (S-PMSI A-D) routes from the upstream PE, as in
         [I-D.ietf-bess-evpn-bum-procedure-updates].  The interested
         downstream PEs join the S-PMSI tree as in
         [I-D.ietf-bess-evpn-bum-procedure-updates].

      -  EVPN S-PMSIs that don't require the advertisement of S-PMSI AD
         routes.  They use the forwarding information of the IMET
         routes, but upstream PEs send IP Multicast flows only to
         downstream PEs issuing Selective Multicast Ethernet Tag (SMET)
         routes for the flow.  These S-PMSIs are only supported with the
         following P-tunnels: Ingress Replication (IR), Assisted
         Replication (AR) and BIER.

   *  SFG: Single Flow Group, i.e., a multicast group which represents
      traffic that contains only a single flow.  Multiple sources - with
      the same or different IP - may be transmitting an SFG.  An SFG is
      represented as (*,G) if any source that issues multicast traffic
      to G is a redundant G-source.  An SFG can also be represented as
      (S,G), where S is a prefix of any length.  In this case, a source
      is considered a redundant G-source for the SFG if it is contained
      in the prefix.

   *  SMET route: Selective Multicast Ethernet Tag route, as in
      [RFC9251].

   *  (S,G) and (*,G): used to describe multicast packets or multicast
      state.  S stands for Source (IP address of the multicast traffic)
      and G stands for the Group or multicast destination IP address of
      the group.  An (S,G) multicast packet refers to an IP packet with
      source IP address "S" and destination IP address "G", and it is
      forwarded on a multicast router if there is a corresponding state
      for (S,G).  A (*,G) multicast packet refers to an IP packet with
      "any" source IP address and a destination IP address "G", and it
      is forwarded on a multicast router based on the existence of the
      corresponding (*,G) state.  The document uses variations of these
      terms.  For example, (S1,G1) represents the multicast packets or
      multicast state for source IP address "S1" and group IP address
      "G1".

   *  Upstream PE: in this document an Upstream PE is referred to as the
      EVPN PE that is connected to the IP Multicast source or closest to
      it.  It receives the IP Multicast flows on local ACs (Attachment
      Circuits).

Rabadan, et al.           Expires 25 July 2024                  [Page 6]
Internet-Draft           EVPN Redundant Sources             January 2024

   This document also assumes familiarity with the terminology of
   [RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251],
   [I-D.ietf-bess-evpn-irb-mcast], [RFC9136] and
   [I-D.ietf-bess-evpn-bum-procedure-updates].

1.2.  Background on IP Multicast Delivery in EVPN Networks

   IP Multicast is all about forwarding a single copy of a packet from a
   source S to a group of receivers G along a multicast tree.  That
   multicast tree can be created in an EVPN tenant domain where S and
   the receivers for G are connected to the same Broadcast Domain or
   different Broadcast Domain.  In the former case, we refer to Intra-
   subnet IP Multicast forwarding, whereas the latter case will be
   referred to as Inter-subnet IP Multicast forwarding.

1.2.1.  Intra-subnet IP Multicast Forwarding

   When the source S1 and receivers interested in G1 are attached to the
   same Broadcast Domain, the EVPN network can deliver the IP Multicast
   traffic to the receivers in two different ways (Figure 1):

                     S1  +                        S1  +
           (a)       +   |              (b)       +   |
                     |   | (S1,G1)                |   | (S1,G1)
                 PE1 |   |                    PE1 |   |
                 +-----+ v                    +-----+ v
                 |+---+|                      |+---+|
                 ||BD1||                      ||BD1||
                 |+---+|                      |+---+|
                 +-----+                      +-----+
            +-------|-------+            +-------|
            |       |       |            |       |
            v       v       v            v       v
         +-----+ +-----+ +-----+      +-----+ +-----+ +-----+
         |+---+| |-----| |-----|      |+---+| |+---+| |+---+|
         ||BD1|| ||BD1|| ||BD1||      ||BD1|| ||BD1|| ||BD1||
         |+---+| |-----| |-----|      |+---+| |+---+| |+---+|
         +-----+ +-----+ +-----+      +-----+ +-----+ +-----+
         PE2|    PE3|    PE4|         PE2|    PE3|    PE4
          - | - - - | -     |          - | - - - | -
         |  |       |  |    |         |  |       |  |
            v       v       v            v       v
         |  R1      R2 |    R3        |  R1      R2 |    R3
          - - - G1- - -                - - - G1- - -

                    Figure 1: Intra-subnet IP Multicast

Rabadan, et al.           Expires 25 July 2024                  [Page 7]
Internet-Draft           EVPN Redundant Sources             January 2024

   Model (a) illustrated in Figure 1 is referred to as "IP Multicast
   delivery as BUM traffic".  This way of delivering IP Multicast
   traffic does not require any extensions to [RFC7432], however, it
   sends the IP Multicast flows to non-interested receivers, such as
   e.g., R3 in Figure 1.  In this example, downstream PEs can snoop
   IGMP/MLD messages from the receivers so that layer-2 multicast state
   is created and, for instance, PE4 can avoid sending (S1,G1) to R3,
   since R3 is not interested in (S1,G1).

   Model (b) in Figure 1 uses an S-PMSI to optimize the delivery of the
   (S1,G1) flow.  For instance, assuming PE1 uses IR, PE1 sends (S1,G1)
   only to the downstream PEs that issued an SMET route for (S1,G1),
   that is, PE2 and PE3.  In case PE1 uses any P-tunnel different than
   IR, AR or BIER, PE1 will advertise an S-PMSI A-D route for (S1,G1)
   and PE2/PE2 will join that tree.

   Procedures for Model (b) are specified in [RFC9251].

1.2.2.  Inter-subnet IP Multicast Forwarding

   If the source and receivers are attached to different BDs of the same
   tenant domain, the EVPN network can also use Inclusive or Selective
   Trees as depicted in Figure 2, models (a) and (b) respectively.

Rabadan, et al.           Expires 25 July 2024                  [Page 8]
Internet-Draft           EVPN Redundant Sources             January 2024

                     S1  +                     S1  +
           (a)       +   |              (b)    +   |
                     |   | (S1,G1)             |   | (S1,G1)
                 PE1 |   |                 PE1 |   |
                 +-----+ v                 +-----+ v
                 |+---+|                   |+---+|
                 ||BD1||                   ||BD1||
                 |+---+|                   |+---+|
                 +-----+                   +-----+
            +-------|-------+         +-------|
            |       |       |         |       |
            v       v       v         v       v
         +-----+ +-----+ +-----+   +-----+ +-----+ +-----+
         |+---+| |+---+| |+---+|   |+---+| |+---+| |+---+|
         ||SBD|| ||SBD|| ||SBD||   ||SBD|| ||SBD|| ||SBD||
         |+-|-+| |+-|-+| |+---+|   |+-|-+| |+-|-+| |+---+|
         | VRF | | VRF | | VRF |   | VRF | | VRF | | VRF |
         |+-v-+| |+-v-+| |+---+|   |+-v-+| |+-v-+| |+---+|
         ||BD2|| ||BD3|| ||BD4||   ||BD2|| ||BD3|| ||BD4||
         |+-|-+| |+-|-+| |+---+|   |+-|-+| |+-|-+| |+---+|
         +--|--+ +--|--+ +-----+   +--|--+ +--|--+ +-----+
         PE2|    PE3|    PE4       PE2|    PE3|    PE4
          - | - - - | -             - | - - - | -
         |  |       |  |           |  |       |  |
            v       v                 v       v
         |  R1      R2 |    R3     |  R1      R2 |    R3
          - - - G1- - -             - - - G1- - -

                    Figure 2: Inter-subnet IP Multicast

   [I-D.ietf-bess-evpn-irb-mcast] specifies the procedures to optimize
   the Inter-subnet Multicast forwarding in an EVPN network.  The IP
   Multicast flows are always sent in the context of the source BD.  As
   described in [I-D.ietf-bess-evpn-irb-mcast], if the downstream PE is
   not attached to the source BD, the IP Multicast flow is received on
   the SBD (Supplementary Broadcast Domain), as in the example in
   Figure 2.

   [I-D.ietf-bess-evpn-irb-mcast] supports Inclusive or Selective
   Multicast Trees, and as explained in Section 1.2.1, the Selective
   Multicast Trees are setup in a different way, depending on the
   P-tunnel being used by the source Broadcast Domain.  As an example,
   model (a) in Figure 2 illustrates the use of an Inclusive Multicast
   Tree for Broadcast Domain BD1 on PE1.  Since the downstream PEs are
   not attached to BD1, they will all receive (S1,G1) in the context of
   the Supplementary Broadcast Domain (SBD) and will locally route the
   flow to the local Attachment Circuits.  Model (b) uses a similar
   forwarding model, however PE1 sends the (S1,G1) flow in a Selective

Rabadan, et al.           Expires 25 July 2024                  [Page 9]
Internet-Draft           EVPN Redundant Sources             January 2024

   Multicast Tree.  If the P-tunnel is Ingress Replication (IR),
   Assisted Replication (AR) or Bit Index Explicit Replication (BIER),
   PE1 does not need to advertise an S-PMSI A-D route.

   [I-D.ietf-bess-evpn-irb-mcast] is a superset of the procedures in
   [RFC9251], in which sources and receivers can be in the same or
   different Broadcast Domain of the same tenant.
   [I-D.ietf-bess-evpn-irb-mcast] ensures every upstream PE attached to
   a source will learn of all other PEs (attached to the same Tenant
   Domain) that have interest in a particular set of flows.  This is
   because the downstream PEs advertise SMET routes for a set of flows
   with the Supplementary Broadcast Domain's Route Target and they are
   imported by all the Upstream PEs of the tenant.  As a result of that,
   inter-subnet multicasting can be done within the Tenant Domain,
   without requiring any Rendezvous Points (RP), shared trees, Upstream
   Multicast Hop (UMH) selection or any other complex aspects of
   conventional multicast routing techniques.

1.3.  Multi-Homed IP Multicast Sources in EVPN

   Contrary to conventional multicast routing technologies, multi-homing
   PEs attached to the same source can never create IP Multicast packet
   duplication if the PEs use a multi-homed Ethernet Segment.  Figure 3
   illustrates this by showing two multi-homing PEs (PE1 and PE2) that
   are attached to the same source (S1).  We assume that S1 is connected
   to an all-active ethernet segment by a layer-2 switch (SW1) with a
   Link Aggregation Group (LAG) to PE1 and PE2.

Rabadan, et al.           Expires 25 July 2024                 [Page 10]
Internet-Draft           EVPN Redundant Sources             January 2024

                                     S1
                                     |
                                     v
                                  +-----+
                                  | SW1 |
                                  +-----+
                            +----  |   |
                     (S1,G1)| +----+   +----+
         IGMP               | | all-active  |
         J(S1,G1)     PE1   v |    ES-1     |    PE2
         +---->   +-----------|---+     +---|-----------+
                  | +---+   +---+ |     | +---+         |
          R1  <-----|BD2|   |BD1| |     | |BD1|         |
                  | +---+---+---+ |     | +---+---+     |
             +----|     |VRF|  |  |     |     |VRF|     |----+
             |    | +---+---+  |  |     | +---+---+     |    |
             |    | |SBD|      |  |     | |SBD|         |    |
             |    | +---+      |  |     | +---+         |    |
             |    +------------|--+     +---------------+    |
             |                 |                             |
             |                 |                             |
             |                 |                             |
             |  EVPN           |               ^             |
             |  OISM           v    PE3        | SMET        |
             |              +---------------+  | (*,G1)      |
             |              | +---+         |  |             |
             |              | |SBD|         |                |
             |              | +---+---+     |                |
             +--------------|     |VRF|     |----------------+
                            | +---+---+---+ |
                            | |BD2|   |BD3| |
                            | +-|-+   +-|-+ |
                            +---|-------|---+
                            ^   |       |   ^
                   IGMP     |   v       v   | IGMP
                    J(*,G1) |  R2       R3  | J(S1,G1)

                 Figure 3: All-active Multi-homing and OISM

   When receiving the (S1,G1) flow from S1, SW1 will choose only one
   link to send the flow, as per [RFC7432].  Assuming PE1 is the
   receiving PE on Broadcast Domain BD1, the IP Multicast flow will be
   forwarded as soon as BD1 creates multicast state for (S1,G1) or
   (*,G1).  In the example of Figure 3, receivers R1, R2 and R3 are
   interested in the multicast flow to G1.  R1 will receive (S1,G1)
   directly via the IRB interface as per [I-D.ietf-bess-evpn-irb-mcast].
   Upon receiving IGMP reports from R2 and R3, PE3 will issue an SMET
   (*,G1) route that will create state in PE1's Broadcast Domain BD1.

Rabadan, et al.           Expires 25 July 2024                 [Page 11]
Internet-Draft           EVPN Redundant Sources             January 2024

   PE1 will therefore forward the IP Multicast flow to PE3's SBD and PE3
   will forward to R2 and R3, as per [I-D.ietf-bess-evpn-irb-mcast]
   procedures.

   When IP Multicast source multi-homing is required, EVPN multi-homed
   Ethernet Segments MUST be used.  EVPN multi-homing guarantees that
   only one Upstream PE will forward a given multicast flow at the time,
   avoiding packet duplication at the Downstream PEs.  In addition, the
   SMET route for a given flow creates state in all the multi-homing
   Upstream PEs.  Therefore, in case of failure on the Upstream PE
   forwarding the flow, the backup Upstream PE can forward the flow
   immediately.

   This document assumes that multi-homing PEs attached to the same
   source always use multi-homed Ethernet Segments.

1.4.  The Need for Redundant IP Multicast Sources in EVPN

   While multi-homing PEs to the same IP Multicast G-source provides
   certain level of resiliency, multicast applications are often
   critical in the Operator's network and greater level of redundancy is
   required.  This document assumes that:

   a.  Redundant G-sources for an Single Flow Group (SFG) may exist in
       the EVPN tenant network.  A Redundant G-source is a host or a
       router that sends an Single Flow Group stream in a tenant network
       where there is another host or router sending traffic to the same
       Single Flow Group.

   b.  Those redundant G-sources may be in the same Broadcast Domain or
       different Broadcast Domains of the tenant.  There must not be
       restrictions imposed on the location of the receiver systems
       either.

   c.  The redundant G-sources can be single-homed to only one EVPN PE
       or multi-homed to multiple EVPN PEs.

   d.  The EVPN PEs must avoid duplication of packets of the same Single
       Flow Group on the receiver systems.

2.  Solution Overview

   An Single Flow Group (SFG) is represented as (*,G) if any source that
   issues multicast traffic to G is a redundant G-source.
   Alternatively, this document allows a Single Flow Group to be
   represented as (S,G), where the source IP address "S" is a prefix of
   any length.  In this case, a source is considered a redundant
   G-source for the Single Flow Group if it is contained in the prefix.

Rabadan, et al.           Expires 25 July 2024                 [Page 12]
Internet-Draft           EVPN Redundant Sources             January 2024

   This document allows variable length prefixes in the Sources
   advertised in S-PMSI A-D routes only for the particular application
   of redundant G-sources.

   There are two redundant G-source solutions described in this
   document:

   *  Warm Standby Solution

   *  Hot Standby Solution

   The Warm Standby solution is considered an upstream-PE-based solution
   (since downstream PEs do not participate in the procedures), in which
   all the upstream PEs attached to redundant G-sources for a Single
   Flow Group represented by (*,G) or (S,G) will elect a "Single
   Forwarder" (SF) among themselves.  Once a Single Forwarder is
   elected, the upstream PEs add an Reverse Path Forwarding check to the
   (*,G) or (S,G) state for the Single Flow Group:

   *  A non-Single Forwarder upstream PE discards any (*,G)/(S,G)
      packets received over a local Attachment Circuit.

   *  The Single Forwarder accepts and forwards any (*,G)/(S,G) packets
      it receives over a single local Attachment Circuit (for the Single
      Flow Group).  In case (*,G)/(S,G) packets for the Single Flow
      Group are received over multiple local Attachment Circuits, they
      will be discarded in all the local Attachment Circuits but one.
      The procedure to choose the local Attachment Circuit that accepts
      packets is a local implementation matter.

   A failure on the Single Forwarder will result in the election of a
   new Single Forwarder.  The Election requires BGP extensions on the
   existing EVPN routes.  These extensions and associated procedures are
   described in Section 3 and Section 4 respectively.

   In the Hot Standby solution the downstream PEs are the ones avoiding
   the Single Flow Group duplication.  The upstream PEs are aware of the
   locally attached G-sources and add a unique Ethernet Segment
   Identifier label (ESI-label) per Single Flow Group to the multicast
   packets forwarded to downstream PEs.  The downstream PEs pull the
   Single Flow Group from all the upstream PEs attached to the redundant
   G-sources and avoid duplication on the receiver systems by adding a
   Reverse Path Forwarding check to the (*,G) state for the Single Flow
   Group:

   *  A downstream PE discards any (*,G) packets it receives from the
      "wrong G-source".

Rabadan, et al.           Expires 25 July 2024                 [Page 13]
Internet-Draft           EVPN Redundant Sources             January 2024

   *  The wrong G-source is identified in the data path by an Ethernet
      Segment Identifier label that is different than the Ethernet
      Segment Identifier label used for the selected G-source.

   *  Note that the Ethernet Segment Identifier label is used here for
      "ingress filtering" (at the egress/downstream PE) as opposed to
      the [RFC7432] "egress filtering" (at the egress/downstream PE)
      used in the split-horizon procedures.  In [RFC7432] the Ethernet
      Segment Identifier label indicates what egress Attachment Circuits
      must be skipped when forwarding BUM traffic to the egress.  In
      this document, the Ethernet Segment Identifier label indicates
      what ingress traffic must be discarded at the downstream PE.

   The use of Ethernet Segment Identifier labels for Single Flow Groups
   forwarded by upstream PEs require some control plane and data plane
   extensions in the procedures used by [RFC7432] for multi-homing.
   Upon failure of the selected G-source, the downstream PE will switch
   over to a different selected G-source, and will therefore change the
   Reverse Path Forwarding check for the (*,G) state.  The extensions
   and associated procedures are described in Section 3 and Section 5
   respectively.

   An operator should use the Hot Standby solution if they require a
   fast fail-over time and the additional bandwidth consumption is
   acceptable (Single Flow Group packets are received multiple times on
   the downstream PEs).  Otherwise the operator should use the Warm
   Standby solution, at the expense of a slower fail-over time in case
   of a G-source or upstream PE failure.  Besides bandwidth efficiency,
   another advantage of the Warm Standby solution is that only the
   upstream PEs attached to the redundant G-sources for the same Single
   Flow Group need to be upgraded to support the new procedures.

   This document does not impose the support of both solutions on a
   system.  If one solution is supported, the support of the other
   solution is OPTIONAL.

3.  BGP EVPN Extensions

   This document makes use of the following BGP EVPN extensions:

   1.  Single Flow Group flag in the Multicast Flags Extended Community

       The Single Flow Group (SFG) flag is a new bit requested to IANA
       out of the registry Multicast Flags Extended Community Flag
       Values.  This new flag is set for S-PMSI A-D routes that carry a
       (*,G)/(S,G) Single Flow Group in the NLRI.

   2.  ESI Label Extended Community is used in S-PMSI A-D routes

Rabadan, et al.           Expires 25 July 2024                 [Page 14]
Internet-Draft           EVPN Redundant Sources             January 2024

       The Hot Standby solution requires the advertisement of one or
       more ESI Label Extended Communities [RFC7432] that encode the
       Ethernet Segment Identifier(s) associated to an S-PMSI A-D
       (*,G)/(S,G) route that advertises the presence of a Single Flow
       Group.  Only the ESI Label value in the extended community is
       relevant to the procedures in this document.  The Flags field in
       the extended community will be advertised as 0x00 and ignored on
       reception.  [RFC7432] specifies that the ESI Label Extended
       Community is advertised along with the A-D per ES route.  This
       documents extends the use of this extended community so that it
       can be advertised multiple times (with different ESI values)
       along with the EVPN S-PMSI A-D route.

4.  Warm Standby (WS) Solution for Redundant G-Sources

   The general procedure is described as follows:

   1.  Configuration of the upstream PEs

       Upstream PEs (possibly attached to redundant G-sources) need to
       be configured to know which groups are carrying only flows from
       redundant G-sources, that is, the Single Flow Groups (SFGs) in
       the tenant domain.  They will also be configured to know which
       local Broadcast Domains may be attached to a redundant G-source.
       The Single Flow Groups can be configured for any source, E.g.,
       SFG for "*", or for a prefix that contains multiple sources that
       will issue the same SFG, i.e., "192.0.2.0/30".  In the latter
       case sources 192.0.2.1 and 192.0.2.2 are considered as Redundant
       G-sources (since they are contained in 192.0.2.0/30), whereas
       192.0.2.10 is not considered a redundant G-source for the same
       SFG.

       As an example (Figure 4):

       *  PE1 is configured to know that G1 is an SFG for any source and
          redundant G-sources for G1 may be attached to Broadcast
          Domains BD1 or BD2.

       *  Or PE1 can also be configured to know that G1 is an SFG for
          the sources contained in 192.0.2.0/30, and those redundant
          G-sources may be attached to Broadcast Domains BD1 or BD2.

   2.  Signaling the location of a G-source for a given Single Flow
       Group

       Upon receiving G-traffic for a configured SFG on a Broadcast
       Domain, an upstream PE configured to follow this procedure, e.g.,
       PE1:

Rabadan, et al.           Expires 25 July 2024                 [Page 15]
Internet-Draft           EVPN Redundant Sources             January 2024

       *  Originates an S-PMSI A-D (*,G)/(S,G) route for the SFG.  An
          (*,G) route is advertised if the SFG is configured for any
          source, and an (S,G) route is advertised (where the Source can
          have any length) if the SFG is configured for a prefix.

       *  The S-PMSI A-D route is imported by all the PEs attached to
          the tenant domain.  In order to do that, the route will use
          the SBD-RT (Supplementary Broadcast Domain Route Target) in
          addition to the BD-RT (Broadcast Domain Route Target) of the
          Broadcast Domain over which the G-traffic is received.  The
          route SHOULD also carry a Designated Forwarder Election
          Extended Community and a flag indicating that it conveys an
          SFG.  The Designated Forwarder Election extended community and
          its use is specified in [RFC8584].

       *  The above S-PMSI A-D route MAY be advertised with or without
          PMSI Tunnel Attribute:

          -  With no PMSI Tunnel Attribute if an I-PMSI or S-PMSI A-D
             with Ingress Replication, Assisted Replication or BIER are
             to be used.

          -  With PMSI Tunnel Attribute in any other case.

       *  The S-PMSI A-D route is triggered by the first packet of the
          SFG and withdrawn when the flow is not received anymore.
          Detecting when the G-source is no longer active is a local
          implementation matter.  The use of a timer is RECOMMENDED.
          The timer is started when the traffic to G1 is not received.
          Upon expiration of the timer, the PE will withdraw the route.

   3.  Single Forwarder (SF) Election

       If the PE with a local G-source receives one or more S-PMSI A-D
       routes for the same Single Flow Group from a remote PE, it will
       run a Single Forwarder Election based on the information encoded
       in the Designated Forwarder Election extended community.  Two
       S-PMSI A-D routes are considered for the same SFG if they are
       advertised for the same tenant, and their Multicast Source
       Length, Multicast Source, Multicast Group Length and Multicast
       Group fields match.

       1.  A given Designated Forwarder Algorithm can only be used if
           all the PEs running the Algorithm have consistent input.  For
           example, in an OISM network, if the redundant G-sources for
           an SFG are attached to Broadcast Domains with different
           Ethernet Tags, the Default Designated Forwarder Election
           Algorithm MUST NOT be used.

Rabadan, et al.           Expires 25 July 2024                 [Page 16]
Internet-Draft           EVPN Redundant Sources             January 2024

       2.  In case the there is a mismatch in the Designated Forwarder
           Election Algorithm or capabilities advertised by two PEs
           competing for the Single Forwarder role, the lowest PE IP
           address (given by the Originator Address in the S- PMSI A-D
           route) will be used as a tie-breaker.

   4.  Reverse Path Forwarding check on the PEs attached to a redundant
       G-source

       All the PEs with a local G-source for the Single Flow Group will
       add a Reverse Path Forwarding check to the (*,G)/(S,G) state for
       the Single Flow Group.  That Reverse Path Forwarding check
       depends on the Single Forwarder Election result:

       1.  The non-Single Forwarder PEs discard any (*,G)/(S,G) packets
           for the Single Flow Group received over a local Attachment
           Circuit.

       2.  The Single Forwarder accepts any (*,G)/(S,G) packets for the
           Single Flow Group it receives over one (and only one) local
           Attachment Circuit.

   The solution above provides redundancy for Single Flow Groups and it
   does not require an upgrade of the downstream PEs (PEs where there is
   certainty that no redundant G-sources are connected).  Other
   G-sources for non-Single Flow Groups may exist in the same tenant
   domain.  This document does not change the existing procedures for
   non-Single Flow Group G-sources.

   The redundant G-sources can be single-homed or multi-homed to a
   Broadcast Domain in the tenant domain.  Multi-homing does not change
   the above procedures.

   Section 4.1 and Section 4.2 show two examples of the Warm Standby
   solution.

4.1.  Warm Standby Example in an OISM Network

   Figure 4 illustrates an example in which S1 and S2 are redundant
   G-sources for the Single Flow Group (*,G1).

Rabadan, et al.           Expires 25 July 2024                 [Page 17]
Internet-Draft           EVPN Redundant Sources             January 2024

                        S1 (Single               S2
                        |   Forwarder)           |
                 (S1,G1)|                 (S2,G1)|
                        |                        |
               PE1      |               PE2      |
               +--------v---+           +--------v---+
        S-PMSI |      +---+ |           |      +---+ | S-PMSI
        (*,G1) |  +---|BD1| |           |  +---|BD2| | (*,G1)
       Pref200 |  |VRF+---+ |           |  |VRF+---+ | Pref100
         |SFG  |+---+  | |  |           |+---+  |    |  SFG|
         | +----|SBD|--+ |  |-----------||SBD|--+    |---+ |
         v |   |+---+    |  |           |+---+       |   | v
           |   +---------|--+           +------------+   |
    SMET   |             |                               | SMET
    (*,G1) |             |   (S1,G1)                     | (*,G1)
           |    +--------+------------------+            |
       ^   |    |                           |            |   ^
       |   |    |                EVPN       |            |   |
       |   |    |                OISM       |            |   |
       |   |    |                           |            |   |
       PE3 |    |           PE4             |            | PE5
       +--------v---+       +------------+  |   +------------+
       |      +---+ |       |      +---+ |  |   |      +---+ |
       |  +---|SBD| |-------|  +---|SBD| |--|---|  +---|SBD| |
       |  |VRF+---+ |       |  |VRF+---+ |  |   |  |VRF+---+ |
       |+---+  |    |       |+---+  |    |  |   |+---+  |    |
       ||BD3|--+    |       ||BD4|--+    |  +--->|BD1|--+    |
       |+---+       |       |+---+       |      |+---+       |
       +------------+       +------------+      +------------+
         |  ^                                     |  ^
         |  | IGMP                                |  | IGMP
         R1 | J(*,G1)                             R3 | J(*,G1)

          Figure 4: Warm Standby Solution for Redundant G-Sources

   The Warm Standby solution works as follows:

   1.  Configuration of the upstream PEs, PE1 and PE2

       PE1 and PE2 are configured to know that G1 is an Single Flow
       Group for any source and redundant G-sources for G1 may be
       attached to Broadcast Domains BD1 or BD2, respectively.

   2.  Signaling the location of S1 and S2 for (*,G1)

Rabadan, et al.           Expires 25 July 2024                 [Page 18]
Internet-Draft           EVPN Redundant Sources             January 2024

       Upon receiving (S1,G1) traffic on a local Attachment Circuit, PE1
       and PE2 originate S-PMSI A-D (*,G1) routes with the SBD-RT
       (Supplementary Broadcast Domain Route Target), Designated
       Forwarder Election Extended Community and a flag indicating that
       it conveys a Single Flow Group.

   3.  Single Forwarder (SF) Election

       Based on the Designated Forwarder Election extended community
       content, PE1 and PE2 elect a Single Forwarder for (*,G1).
       Assuming both PEs agree on e.g., Preference based Election as the
       algorithm to use [I-D.ietf-bess-evpn-pref-df], and PE1 has a
       higher preference, PE1 becomes the Single Forwarder for (*,G1).

   4.  Reverse Path Forwarding check on the PEs attached to a redundant
       G-source

       a.  The non-Single Forwarder, PE2, discards any (*,G1) packets
           received over a local Attachment Circuit.

       b.  The Single Forwarder, PE1 accepts (*,G1) packets it receives
           over one (and only one) local Attachment Circuit.

   The end result is that, upon receiving reports for (*,G1) or (S,G1),
   the downstream PEs (PE3 and PE5) will issue SMET routes and will pull
   the multicast Single Flow Group from PE1, and PE1 only.  Upon a
   failure on S1, the Attachment Circuit connected to source S1 or PE1
   itself will trigger the S-PMSI A-D (*,G1) withdrawal from PE1 and PE2
   will be promoted to Single Forwarder.

4.2.  Warm Standby Example in a Single-BD Tenant Network

   Figure 5 illustrates an example in which S1 and S2 are redundant
   G-sources for the Single Flow Group (*,G1), however, now all the
   G-sources and receivers are connected to the same Broadcast Domain
   BD1 and there is no Supplementary Broadcast Domain.

Rabadan, et al.           Expires 25 July 2024                 [Page 19]
Internet-Draft           EVPN Redundant Sources             January 2024

                        S1 (Single               S2
                        |   Forwarder)           |
                 (S1,G1)|                 (S2,G1)|
                        |                        |
               PE1      |               PE2      |
               +--------v---+           +--------v---+
       S-PMSI  |      +---+ |           |      +---+ | S-PMSI
       (*,G1)  |      |BD1| |           |      |BD1| | (*,G1)
       Pref200 |      +---+ |           |      +---+ | Pref100
        |SFG   |         |  |           |            |  SFG|
        |  +---|         |  |-----------|            |---+ |
        v  |   |         |  |           |            |   | v
           |   +---------|--+           +------------+   |
    SMET   |             |                               | SMET
    (*,G1) |             |     (S1,G1)                   | (*,G1)
           |    +--------+------------------------+      |
       ^   |    |                                 |      |   ^
       |   |    |                EVPN             |      |   |
       |   |    |                                 |      |   |
       |   |    |                                 |      |   |
       PE3 |    |           PE4                   |      | PE5
       +--------v---+       +------------+      +-|----------+
       |      +---+ |       |      +---+ |      | |    +---+ |
       |      |BD1| |-------|      |BD1| |------| +--->|BD1| |
       |      +---+ |       |      +---+ |      |      +---+ |
       |            |       |            |      |            |
       |            |       |            |      |            |
       |            |       |            |      |            |
       +------------+       +------------+      +------------+
         |  ^                                     |  ^
         |  | IGMP                                |  | IGMP
         R1 | J(*,G1)                             R3 | J(*,G1)

        Figure 5: WS Solution for Redundant G-Sources in the same BD

   The same procedure as in Section 4.1 is valid here, being this a sub-
   case of the one in Section 4.1.  Upon receiving traffic for the
   Single Flow Group G1, PE1 and PE2 advertise the S-PMSI A-D routes
   with route target BD1-RT only, since there is no Supplementary
   Broadcast Domain (SBD).

5.  Hot Standby Solution for Redundant G-Sources

   If fast-failover is required upon the failure of a G-source or PE
   attached to the G-source and the extra bandwidth consumption in the
   tenant network is not an issue, the Hot Standby solution should be
   used.  The procedure is as follows:

Rabadan, et al.           Expires 25 July 2024                 [Page 20]
Internet-Draft           EVPN Redundant Sources             January 2024

   1.  Configuration of the PEs

       As in the Warm Standby case, the upstream PEs where redundant
       G-sources may exist need to be configured to know which groups
       (for any source or a prefix containing the intended sources) are
       carrying only flows from redundant G-sources, that is, the Single
       Flow Groups in the tenant domain.

       In addition (and this is not done in Warm Standby mode), the
       individual redundant G-sources for a Single Flow Group need to be
       associated with an Ethernet Segment on the upstream PEs.  This is
       irrespective of the redundant G-source being multi-homed or
       single-homed.  Even for single-homed redundant G-sources the Hot
       Standby procedure relies on the ESI labels for the Reverse Path
       Forwarding check on downstream PEs.  The term "S-ESI" is used in
       this document to refer to an Ethernet Segment Identifier
       associated to a redundant G-source.

       Contrary to what is specified in the Warm Standby method (that is
       transparent to the downstream PEs), the support of the Hot
       Standby procedure is required not only on the upstream PEs but
       also on all downstream PEs connected to the receivers in the
       tenant network.  The downstream PEs do not need to be configured
       to know the connected Single Flow Groups or their Ethernet
       Segment Identifiers, since they get that information from the
       upstream PEs.  The downstream PEs will locally select an Ethernet
       Segment Identifier for a given Single Flow Group, and will
       program a Reverse Path Forwarding check to the (*,G)/(S,G) state
       for the Single Flow Group that will discard (*,G)/(S,G) packets
       from the rest of the Ethernet Segment Identifiers.  The selection
       of the Ethernet Segment Identifier for the Single Flow Group is
       based on local policy.

   2.  Signaling the location of a G-source for a given Single Flow
       Group and its association to the local Ethernet Segments

       Based on the configuration in step 1, an upstream PE configured
       to follow the Hot Standby procedures:

       a.  Advertises an S-PMSI A-D (*,G)/(S,G) route per each
           configured Single Flow Group.  These routes need to be
           imported by all the PEs of the tenant domain, therefore they
           will carry the route targets BD-RT (the route target of the
           Broadcast Domain) and SBD-RT (the route target of the
           Supplementary Broadcast Domain, if the SBD exists).  The
           route also carries the ESI Label extended communities needed
           to convey all the S-ESIs associated to the Single Flow Group
           in the PE.

Rabadan, et al.           Expires 25 July 2024                 [Page 21]
Internet-Draft           EVPN Redundant Sources             January 2024

       b.  The S-PMSI A-D route will convey a PMSI Tunnel Attribute in
           the same cases as in the Warm Standby procedure.

       c.  The S-PMSI A-D (*,G)/(S,G) route is triggered by the
           configuration of the Single Flow Group and not by the
           reception of G-traffic.

   3.  Distribution of DCB (Domain-wide Common Block) ESI-labels and
       G-source ES routes

       An upstream PE advertises the corresponding EVPN ES route, A-D
       per EVI and A-D per ES routes for the local S-ESIs.

       a.  ES routes are used for regular Designated Forwarder Election
           for the S-ES.  This document does not introduce any change in
           the procedures related to the EVPN ES routes.

       b.  The EVPN A-D per EVI and A-D per ES routes MUST include the
           route target SBD-RT since they have to be imported by all the
           PEs in the tenant domain.

       c.  The EVPN A-D per ES routes convey the S-ESI labels that the
           downstream PEs use to add the Reverse Path Forwarding check
           for the (*,G)/(S,G) associated to the Single Flow Groups.
           This Reverse Path Forwarding check requires that all the
           packets for a given G-source are received with the same S-ESI
           label value on the downstream PEs.  For example, if two
           redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1
           and S-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx"
           for S-ES-1 and they MUST allocate the same ESI label "Ly" for
           S-ES-2.  In addition, Lx and Ly MUST be different.  These ESI
           labels are Domain-wide Common Block (DCB) labels and follow
           the allocation procedures in
           [I-D.ietf-bess-mvpn-evpn-aggregation-label].

   4.  Processing of EVPN A-D per ES/EVI routes and Reverse Path
       Forwarding check on the downstream PEs

       The EVPN A-D per ES/EVI routes are received and imported in all
       the PEs in the tenant domain.  The processing of the EVPN A-D per
       ES/EVI routes on a given PE depends on its configuration:

       a.  The PEs attached to the same Broadcast Domain of the route
           target BD-RT that is included in the EVPN A-D per ES/EVI
           routes will process the routes as in [RFC7432] and [RFC8584].
           If the receiving PE is attached to the same Ethernet Segment
           as indicated in the route, [RFC7432] split-horizon procedures
           will be followed and the Designated Forwarder Election

Rabadan, et al.           Expires 25 July 2024                 [Page 22]
Internet-Draft           EVPN Redundant Sources             January 2024

           candidate list may be modified as in [RFC8584] if the
           Ethernet Segment supports the AC-DF (Attachment Circuit
           influenced Designated Forwarder) capability.

       b.  The PEs that are not attached to the Broadcast Domain
           identified by the route target BD-RT but are attached to the
           Supplementary Broadcast Domain of the received route target
           SBD-RT, will import the EVPN A-D per ES/EVI routes and use
           them for redundant G-source mass withdrawal, as explained
           later.

       c.  Upon importing EVPN A-D per ES routes corresponding to
           different S-ESes, a PE MUST select a primary S-ES and add a
           Reverse Path Forwarding check to the (*,G)/(S,G) state in the
           Broadcast Domain or Supplementary Broadcast Domain.  This
           Reverse Path Forwarding check will discard all ingress
           packets to (*,G)/(S,G) that are not received with the ESI-
           label of the primary S-ES.  The selection of the primary S-ES
           is a matter of local policy.

   5.  G-traffic forwarding for redundant G-sources and fault detection

       Assuming there is (*,G) or (S,G) state for the Single Flow Group
       with Output Interface list entries associated to remote EVPN PEs,
       upon receiving G-traffic on a S-ES, the upstream PE will add a
       S-ESI label at the bottom of the stack before forwarding the
       traffic to the remote EVPN PEs.  This label is allocated from a
       Domain-wide Common Block as described in step 3.  If Point-to-
       multipoint or BIER PMSIs are used, this is not adding any new
       data path procedures on the upstream PEs (except that the ESI-
       label is allocated from a Domain-wide Common Block as described
       in [I-D.ietf-bess-mvpn-evpn-aggregation-label]).  However, if
       Ingress Replication or Assisted Replication are used, this
       document extends the [RFC7432] procedures by pushing the S-ESI
       labels not only on packets sent to the PEs that shared the ES but
       also to the rest of the PEs in the tenant domain.  This allows
       the downstream PEs to receive all the multicast packets from the
       redundant G-sources with a S-ESI label (irrespective of the PMSI
       type and the local ESes), and discard any packet that conveys a
       S-ESI label different from the primary S-ESI label (that is, the
       label associated to the selected primary S-ES), as discussed in
       step 4.

       If the last EVPN A-D per EVI or the last EVPN A-D per ES route
       for the primary S-ES is withdrawn, the downstream PE will
       immediately select a new primary S-ES and will change the Reverse
       Path Forwarding check.  Note that if the S-ES is re-used for
       multiple tenant domains by the upstream PEs, the withdrawal of

Rabadan, et al.           Expires 25 July 2024                 [Page 23]
Internet-Draft           EVPN Redundant Sources             January 2024

       all the EVPN A-D per-ES routes for a S-ES provides a mass
       withdrawal capability that makes a downstream PE to change the
       Reverse Path Forwarding check in all the tenant domains using the
       same S-ES.

       The withdrawal of the last EVPN S-PMSI A-D route for a given
       (*,G)/(S,G) that represents a Single Flow Group SHOULD make the
       downstream PE remove the S-ESI label based Reverse Path
       Forwarding check on (*,G)/(S,G).

5.1.  Extensions for the Advertisement of DCB Labels

   Domain-wide Common Block Labels are specified in
   [I-D.ietf-bess-mvpn-evpn-aggregation-label] and this document makes
   use of them for the procedures described in Section 5.
   [I-D.ietf-bess-mvpn-evpn-aggregation-label] assumes that Domain-wide
   Common Block labels can only be used along with Multipoint-to-
   Multipoint, Point-to-Multipoint, or BIER tunnels and that, if the
   PMSI label is signaled as a Domain-wide Common Block label, then the
   ESI label used for multi-homing is also a Domain-wide Common Block
   label.  This document extends the use of the Domain-wide Common Block
   allocation for ESI labels so that:

   a.  Domain-wide Common Block allocated ESI labels MAY be used along
       with Ingress Replication tunnels, and

   b.  Domain-wide Common Block allocated ESI labels MAY be used by PEs
       that do not use Domain-wide Common Block allocated PMSI labels.

   This control plane extension is indicated by adding the DCB-flag
   (Domain-wide Common Block flag) or the Context Label Space ID
   extended community to the EVPN A-D per ES route(s) advertised for the
   S-ES.  The DCB-flag is encoded in the ESI Label Extended Community as
   follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=0x06     | Sub-Type=0x01 | Flags(1 octet)|  Reserved=0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved=0   |          ESI Label                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: ESI Label Extended Community

Rabadan, et al.           Expires 25 July 2024                 [Page 24]
Internet-Draft           EVPN Redundant Sources             January 2024

   This document defines the bit 5 in the Flags octet of the ESI Label
   Extended Community as the ESI-DCB-flag.  When the ESI-DCB-flag is
   set, it indicates that the ESI label is a Domain-wide Common Block
   label.

   A received ESI label is considered a Domain-wide Common Block label
   if either of these two conditions is met:

   a.  The ESI label is encoded in an ESI Label Extended Community with
       the ESI-DCB-flag set.

   b.  The ESI label is signaled from a PE that advertised a PMSI label
       that is a Domain-wide Common Block label.

   As in [I-D.ietf-bess-mvpn-evpn-aggregation-label] this document also
   allows the use of context label space ID extended community.  When
   the context label space ID extended community is advertised along
   with the ESI label in an EVPN A-D per ES route, the ESI label is from
   a context label space identified by the Domain-wide Common Block
   label in the Extended Community.

5.2.  Use of BFD in the HS Solution

   In addition to using the state of the EVPN A-D per EVI, EVPN A-D per
   ES or S-PMSI A-D routes to modify the Reverse Path Forwarding check
   on (*,G)/(S,G) as discussed in Section 5, Bidirectional Forwarding
   Detection (BFD) protocol MAY be used to monitor the status of the
   multipoint tunnels used to forward the Single Flow Group packets from
   the redundant G-sources.

   The BGP-BFD Attribute is advertised along with the S-PMSI A-D or
   Inclusive Multicast Ethernet Tag routes (depending on whether
   Inclusive PMSI or Selective PMSI trees are used) and the procedures
   described in [I-D.ietf-bess-evpn-bfd] [I-D.ietf-mpls-p2mp-bfd] are
   used to bootstrap multipoint BFD sessions on the downstream PEs.

5.3.  Hot Standby Example in an OISM Network

   Figure 7 illustrates the Hot Standby model in an Optimized Inter-
   Subnet Multicast (OISM) network.  Consider S1 and S2 are redundant
   G-sources for the Single Flow Group (*,G1) in Broadcast Domain BD1
   (any source using G1 is assumed to transmit an SFG).  S1 and S2 are
   (all-active) multi-homed to upstream PEs, PE1 and PE2.  The receivers
   are attached to downstream PEs, PE3 and PE5, in Broadcast Domains BD3
   and BD1, respectively.  S1 and S2 are assumed to be connected by a
   Link Aggregation Group to the multi-homing PEs, and the multicast
   traffic can use the link to either upstream PE.  The diagram
   illustrates how S1 sends the G-traffic to PE1 and PE1 forwards to the

Rabadan, et al.           Expires 25 July 2024                 [Page 25]
Internet-Draft           EVPN Redundant Sources             January 2024

   remote interested downstream PEs, whereas S2 sends to PE2 and PE2
   forwards further.  In this Hot Standby model, the interested
   downstream PEs will get duplicate G-traffic from the two G-sources
   for the same Single Flow Group.  While the diagram shows that the two
   flows are forwarded by different upstream PEs, the all-active multi-
   homing procedures may cause that the two flows come from the same
   upstream PE.  Therefore, finding out the upstream PE for the flow is
   not enough for the downstream PEs to program the required Reverse
   Path Forwarding check to avoid duplicate packets on the receiver.

                        S1(ESI-1)                S2(ESI-2)
                        |                        |
                        | +----------------------+
                 (S1,G1)| |               (S2,G1)|
                        +----------------------+ |
               PE1      | |             PE2    | |
               +--------v---+           +--------v---+
               |      +---+ |           |      +---+ |  S-PMSI
    S-PMSI     |  +---|BD1| |           |  +---|BD1| |  (*,G1)
    (*,G1)     |  |VRF+---+ |           |  |VRF+---+ |   SFG
     SFG       |+---+  | |  |           |+---+  | |  |   ESI1,2
    ESI1,2 +---||SBD|--+ |  |-----------||SBD|--+ |  |---+  |
       |   |   |+---+    |  |   EVPN    |+---+    |  |   |  v
       v   |   +---------|--+   OISM    +---------|--+   |
           |             |                        |      |
           |             |   (S1,G1)              |      |
    SMET   |   +---------+------------------+     |      | SMET
    (*,G1) |   |                            |     |      | (*,G1)
       ^   |   | +----------------------------+---+      |   ^
       |   |   | |             (S2,G1)      | |          |   |
       |   |   | |                          | |          |   |
       PE3 |   | |          PE4             | |          | PE5
       +-------v-v--+       +------------+  | | +------------+
       |      +---+ |       |      +---+ |  | | |      +---+ |
       |  +---|SBD| +-------|  +---|SBD| |--|-|-|  +---|SBD| |
       |  |VRF+---+ |       |  |VRF+---+ |  | | |  |VRF+---+ |
       |+---+  |    |       |+---+  |    |  | | |+---+  |    |
       ||BD3|--+    |       ||BD4|--+    |  | +->|BD1|--+    |
       |+---+       |       |+---+       |  +--->+---+       |
       +------------+       +------------+      +------------+
         |  ^                                     |  ^
         |  | IGMP                                |  | IGMP
         R1 | J(*,G1)                             R3 | J(*,G1)

     Figure 7: HS Solution for Multi-homed Redundant G-Sources in OISM

   In this scenario, the Hot Standby solution works as follows:

Rabadan, et al.           Expires 25 July 2024                 [Page 26]
Internet-Draft           EVPN Redundant Sources             January 2024

   1.  Configuration of the upstream PEs, PE1 and PE2

       PE1 and PE2 are configured to know that G1 is a Single Flow Group
       for any source (a source prefix length could have been configured
       instead) and the redundant G-sources for G1 use S-ESIs ESI-1 and
       ESI-2 respectively.  Both Ethernet Segments are configured in
       both PEs and their ESI value can be configured or auto-derived.
       The ESI-label values are allocated from a Domain-wide Common
       Block [I-D.ietf-bess-mvpn-evpn-aggregation-label] and are
       configured either locally or by a centralized controller.  We
       assume ESI-1 is configured to use ESI-label-1 and ESI-2 to use
       ESI-label-2.

       The downstream PEs, PE3, PE4 and PE5 are configured to support
       Hot Standby mode and select the G-source with e.g., lowest ESI
       value.

   2.  PE1 and PE2 advertise S-PMSI A-D (*,G1) and EVPN ES, A-D per ES
       and A-D per EVI routes

       Based on the configuration of step 1, PE1 and PE2 advertise an
       S-PMSI A-D (*,G1) route each.  The route from each of the two PEs
       will include TWO ESI Label Extended Communities with ESI-1 and
       ESI-2 respectively, as well as route target BD1-RT plus SBD-RT
       and a flag that indicates that (*,G1) is a Single Flow Group.

       In addition, PE1 and PE2 advertise EVPN ES and A-D per ES/EVI
       routes for ESI-1 and ESI-2.  The EVPN A-D per ES and per EVI
       routes will include the route target of the SBD, i.e.,: SBD-RT,
       so that they can be imported by the downstream PEs that are not
       attached to Broadcast Domain BD1, e.g., PE3 and PE4.  The EVPN
       A-D per ES routes will convey ESI-label-1 for ESI-1 (on both PEs)
       and ESI-label-2 for ESI-2 (also on both PEs).

   3.  Processing of EVPN A-D per ES/EVI routes and Reverse Path
       Forwarding check

       PE1 and PE2 received each other's ES and A-D per ES/EVI routes.
       Regular [RFC7432] [RFC8584] procedures will be followed for the
       Designated Forwarder Election and programming of the ESI-labels
       for egress split-horizon filtering.  PE3/PE4 import the EVPN A-D
       per ES/EVI routes in the SBD.  Since PE3 has created a (*,G1)
       state based on local interest, PE3 will add a Reverse Path
       Forwarding check to (*,G1) so that packets coming with ESI-
       label-2 are discarded (lowest ESI value is assumed to give the
       primary S-ES).

   4.  G-traffic forwarding and fault detection

Rabadan, et al.           Expires 25 July 2024                 [Page 27]
Internet-Draft           EVPN Redundant Sources             January 2024

       PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within
       the context of Broadcast Domain BD1.  Irrespective of the tunnel
       type, PE1 pushes ESI-label-1 at the bottom of the stack and the
       traffic gets to PE3 and PE5 with the mentioned ESI-label (PE4 has
       no local interested receivers).  The G-traffic with ESI-label-1
       passes the Reverse Path Forwarding check and it is forwarded to
       R1.  In the same way, PE2 sends (S2,G1) with ESI-label-2, but
       this G-traffic does not pass the Reverse Path Forwarding check
       and gets discarded at PE3/PE5.

       If the link from S1 to PE1 fails, S1 will forward the (S1,G1)
       traffic to PE2 instead.  PE1 withdraws the EVPN ES and A-D routes
       for ESI-1.  Now both flows will be originated by PE2, however the
       Reverse Path Forwarding checks do not change in PE3/PE5.

       If subsequently, the link from S1 to PE2 fails, PE2 also
       withdraws the EVPN ES and A-D routes for ESI-1.  Since PE3 and
       PE5 have no longer A-D per ES/EVI routes for ESI-1, they
       immediately change the Reverse Path Forwarding check so that
       packets with ESI-label-2 are now accepted.

   Figure 8 illustrates a scenario where sources S1 and S2 are single-
   homed to PE1 and PE2 respectively.  This scenario is a sub-case of
   the one in Figure 7.  Now ES-1 only exists in PE1, hence only PE1
   advertises the EVPN A-D per ES/EVI routes for ESI-1.  Similarly, ES-2
   only exists in PE2 and PE2 is the only PE advertising EVPN A-D routes
   for ESI-2.  The same procedures as in Figure 7 apply to this use-
   case.

Rabadan, et al.           Expires 25 July 2024                 [Page 28]
Internet-Draft           EVPN Redundant Sources             January 2024

                        S1(ESI-1)                S2(ESI-2)
                        |                        |
                 (S1,G1)|                 (S2,G1)|
                        |                        |
               PE1      |               PE2      |
               +--------v---+           +--------v---+
               |      +---+ |           |      +---+ |  S-PMSI
    S-PMSI     |  +---|BD1| |           |  +---|BD2| |  (*,G1)
    (*,G1)     |  |VRF+---+ |           |  |VRF+---+ |   SFG
     SFG       |+---+  | |  |           |+---+  | |  |   ESI2
     ESI1  +---||SBD|--+ |  |-----------||SBD|--+ |  |---+  |
       |   |   |+---+    |  |   EVPN    |+---+    |  |   |  v
       v   |   +---------|--+   OISM    +---------|--+   |
           |             |                        |      |
           |             |   (S1,G1)              |      |
    SMET   |   +---------+------------------+     |      | SMET
    (*,G1) |   |                            |     |      | (*,G1)
       ^   |   | +--------------------------------+----+ |   ^
       |   |   | |             (S2,G1)      |          | |   |
       |   |   | |                          |          | |   |
       PE3 |   | |          PE4             |          | | PE5
       +-------v-v--+       +------------+  |   +------v-----+
       |      +---+ |       |      +---+ |  |   |      +---+ |
       |  +---|SBD| |-------|  +---|SBD| |--|---|  +---|SBD| |
       |  |VRF+---+ |       |  |VRF+---+ |  |   |  |VRF+---+ |
       |+---+  |    |       |+---+  |    |  |   |+---+  |    |
       ||BD3|--+    |       ||BD4|--+    |  +--->|BD1|--+    |
       |+---+       |       |+---+       |      |+---+       |
       +------------+       +------------+      +------------+
         |  ^                                     |  ^
         |  | IGMP                                |  | IGMP
         R1 | J(*,G1)                             R3 | J(*,G1)

     Figure 8: HS Solution for single-homed Redundant G-Sources in OISM

5.4.  Hot Standby Example in a Single-BD Tenant Network

   Irrespective of the redundant G-sources being multi-homed or single-
   homed, if the tenant network has only one Broadcast Domain, e.g.,
   BD1, the procedures of Section 5.2 still apply, only that routes do
   not include any SBD route target, i.e.,: SBD-RT, and all the
   procedures apply to Broadcast Domain BD1 only.

6.  Security Considerations

   The same Security Considerations described in
   [I-D.ietf-bess-evpn-irb-mcast] are valid for this document.

Rabadan, et al.           Expires 25 July 2024                 [Page 29]
Internet-Draft           EVPN Redundant Sources             January 2024

   From a security perspective, out of the two methods described in this
   document, the Warm Standby method is considered lighter in terms of
   control plane and therefore its impact is low on the processing
   capabilities of the PEs.  The Hot Standby method adds more burden on
   the control plane of all the PEs of the tenant with sources and
   receivers.

7.  IANA Considerations

   IANA is requested to allocate a bit in the Multicast Flags Extended
   Community registry that was introduced by [RFC9251].  This bit
   indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is
   associated with an SFG (Single Flow Group).  This bit is called
   "Single Flow Group" bit and it is defined as follows:

                +=====+===================+===============+
                | Bit | Name              | Reference     |
                +=====+===================+===============+
                | 4   | Single Flow Group | This Document |
                +-----+-------------------+---------------+

                                  Table 1

8.  References

8.1.  Normative References

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [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>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC9251]  Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
              and W. Lin, "Internet Group Management Protocol (IGMP) and
              Multicast Listener Discovery (MLD) Proxies for Ethernet
              VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
              <https://www.rfc-editor.org/info/rfc9251>.

Rabadan, et al.           Expires 25 July 2024                 [Page 30]
Internet-Draft           EVPN Redundant Sources             January 2024

   [I-D.ietf-bess-evpn-irb-mcast]
              Lin, W., Zhang, Z. J., Drake, J., Rosen, E. C., Rabadan,
              J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast
              (OISM) Forwarding", Work in Progress, Internet-Draft,
              draft-ietf-bess-evpn-irb-mcast-09, 21 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-irb-mcast-09>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
              J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
              VPN Designated Forwarder Election Extensibility",
              RFC 8584, DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.ietf-bess-mvpn-evpn-aggregation-label]
              Zhang, Z. J., Rosen, E. C., Lin, W., Li, Z., and I.
              Wijnands, "MVPN/EVPN Tunnel Aggregation with Common
              Labels", Work in Progress, Internet-Draft, draft-ietf-
              bess-mvpn-evpn-aggregation-label-14, 4 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              mvpn-evpn-aggregation-label-14>.

8.2.  Informative References

   [RFC9136]  Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
              A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
              (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
              <https://www.rfc-editor.org/info/rfc9136>.

   [I-D.ietf-bess-evpn-bum-procedure-updates]
              Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
              Sajassi, "Updates on EVPN BUM Procedures", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
              procedure-updates-14, 18 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-bum-procedure-updates-14>.

Rabadan, et al.           Expires 25 July 2024                 [Page 31]
Internet-Draft           EVPN Redundant Sources             January 2024

   [I-D.ietf-bess-evpn-pref-df]
              Rabadan, J., Sathappan, S., Lin, W., Drake, J., and A.
              Sajassi, "Preference-based EVPN DF Election", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-13,
              9 October 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-bess-evpn-pref-df-13>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [I-D.ietf-bess-evpn-bfd]
              Govindan, V. P., Mudigonda, M., Sajassi, A., Mirsky, G.,
              and D. E. Eastlake, "EVPN Network Layer Fault Management",
              Work in Progress, Internet-Draft, draft-ietf-bess-evpn-
              bfd-05, 14 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-bfd-05>.

   [I-D.ietf-mpls-p2mp-bfd]
              Mirsky, G., Mishra, G. S., and D. E. Eastlake, "BFD for
              Multipoint Networks over Point-to-Multi-Point MPLS LSP",
              Work in Progress, Internet-Draft, draft-ietf-mpls-p2mp-
              bfd-06, 15 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              p2mp-bfd-06>.

   [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>.

Appendix A.  Acknowledgments

   The authors would like to thank Mankamana Mishra, Ali Sajassi and
   Greg Mirsky for their review and valuable comments.

Appendix B.  Contributors

   In addition to the authors listed on the front page, the following
   people have significantly contributed to this document:

   Eric C.  Rosen

   Email: erosen52@gmail.com

Rabadan, et al.           Expires 25 July 2024                 [Page 32]
Internet-Draft           EVPN Redundant Sources             January 2024

Authors' Addresses

   Jorge Rabadan (editor)
   Nokia
   520 Almanor Avenue
   Sunnyvale, CA 94085
   United States of America
   Email: jorge.rabadan@nokia.com

   Jayant Kotalwar
   Nokia
   520 Almanor Avenue
   Sunnyvale, CA 94085 USA
   Email: jayant.kotalwar@nokia.com

   Senthil Sathappan
   Nokia
   520 Almanor Avenue
   Sunnyvale, CA 94085 USA
   Email: senthil.sathappan@nokia.com

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

   Wen Lin
   Juniper Networks
   Email: wlin@juniper.net

Rabadan, et al.           Expires 25 July 2024                 [Page 33]