[bess] [Shepherding AD review] review of draft-ietf-bess-evpn-redundant-mcast-source-11

["Gunter van de Velde (Nokia)" <[e-mail]>]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-redundant-mcast-source-11

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-redundant-mcast-source-11.txt

# Many thanks for the shepherd writeup from Mankamana and the RTGDIR reviews from Loa and Sandy

# I found this a difficult draft to review, due to the combination of various signaling and control plane aspects. 

# Most (if not all) examples use IPv4 addresses. Is that the intention? Maybe some IPv6 addresses could be used in examples along with text explaining that the solution supports IPv6 

# Throughout the document the use of abbreviations or expanded abbreviations is used. I tried to catch some of them (for example RPF vs Reverse Path Forwarding), but did not succeed everywhere. Especially i found the term "Single Flow Groups" and "SFG" and "Single Flow Groups (SFG)" was often used inconsistently. The document better use either SFG or Single Flow Group, but maybe try to avoid using them intermixed throughout the document. There are many EVPN/Multicast abbreviations in the draft and using them inconsistent will cause additional confusion.

# The flags field that is defined by this document is in some sections identified as bit 4 (IANA section) and other as bit 5 (line 1092). Allocating single value helps.

# The provided review is mostly focusing upon readability and document structure.  I hope I managed to retain correct representation of procedures within this shepherding AD review for the draft.


#DETAILED COMMENTS
#=================

14	Abstract

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

GV> Proposed alternate Abstract

"
In Ethernet Virtual Private Networks (EVPNs), multicast traffic replication and delivery play a crucial role in enabling efficient and scalable Layer 2 and Layer 3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate multicast traffic in the network, causing inefficiencies and increased overhead.

This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate multicast traffic from redundant sources. The proposed mechanisms enhance EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies.
"

93	1.  Introduction
94
95	   Intra and Inter-subnet IP Multicast forwarding are supported in EVPN
96	   networks.  [RFC9251] describes the procedures required to optimize
97	   the delivery of IP Multicast flows when Sources and Receivers are
98	   connected to the same EVPN Broadcast Domain, whereas [RFC9625]
99	   specifies the procedures to support Inter-subnet IP Multicast in a
100	   tenant network.  Inter-subnet IP Multicast means that IP Multicast
101	   Source and Receivers of the same multicast flow are connected to
102	   different Broadcast Domains of the same tenant.
103
104	   [RFC9251], [RFC9625] or conventional IP multicast techniques do not
105	   have a solution for the case where the following two statements are
106	   true at the same time: a) a given multicast group carries more than
107	   one flow (i.e., more than one source) and b) it is desired that each
108	   receiver gets only one of the several flows.  Multicast techniques
109	   assume there are no redundant sources sending the same flows to the
110	   same IP multicast group, and, in case there were redundant sources,
111	   the receiver's application would deal with the received duplicated
112	   packets.
113
114	   As a workaround in conventional IP multicast (that is, networks
115	   running Protocol Independent Multicast [RFC7761] or Multicast Virtual
116	   Private Networks [RFC6513]), if all the redundant sources are given
117	   the same IP address, each receiver will get only one flow.  The
118	   reason is that, in conventional IP multicast, the RP (Rendezvous
119	   Point) always creates (S,G) state, and the Last Hop Router sometimes
120	   creates (S,G) state.  The (S,G) state always binds the (S,G) flow to
121	   a source-specific tree, rooted at the source IP address.  If multiple
122	   sources have the same IP address, one may end up with multiple (S,G)
123	   trees.  However, the way the trees are constructed ensures that any
124	   given Last Hop Router or Rendezvous Point router is on at most one of
125	   them.  The use of an anycast address assigned to multiple sources may
126	   be useful for warm standby redundancy solutions (Section 2).
127	   However, on one hand, it is not really helpful for hot standby
128	   redundancy solutions (Section 2) and on the other hand, configuring
129	   the same IP address (in particular, the same IPv4 address) in
130	   multiple sources may bring issues if the sources need to be reached
131	   by IP unicast traffic or if the sources are attached to the same
132	   Broadcast Domain.
133
134	   In addition, in the scenario where several multicast sources
135	   streaming traffic to the same group are attached via EVPN/OISM
136	   (Optimized Inter-Subnet Multicast), there is not necessarily any
137	   (S,G) state created for the redundant sources.  The Last Hop Routers
138	   may have only (*,G) state, and there may not be a Rendezvous Point
139	   router (creating (S,G) state) either.  Therefore, this document
140	   extends [RFC9251] and [RFC9625], and now assumes that IP Multicast
141	   source redundancy may exist.  The document also specifies how, in
142	   case two or more sources send the same IP Multicast flows into the
143	   tenant domain, the EVPN PEs avoid the receivers from getting packet
144	   duplication.  The procedures to handle redundant sources in solutions
145	   different from [RFC9251] or [RFC9625] are out of the scope of this
146	   document.

GV> Proposed readability rewrite:

"
Ethernet Virtual Private Networks (EVPN) support both intra-subnet and inter-subnet IP multicast forwarding. [RFC9251] outlines the procedures required to optimize the delivery of IP multicast flows when both sources and receivers are connected to the same EVPN Broadcast Domain. [RFC9625], on the other hand, defines the procedures for supporting inter-subnet IP multicast within a tenant network, where the IP multicast source and receivers of the same multicast flow are connected to different Broadcast Domains within the same tenant.

However, [RFC9251], [RFC9625], and conventional IP multicast techniques do not provide a solution for scenarios where:
1. A given multicast group carries multiple flows (i.e., multiple sources are active), and
2. Each receiver should receive only one of the multiple flows.

Existing multicast solutions typically assume that there are no redundant sources sending identical flows to the same IP multicast group. In cases where redundant sources do exist, the receiver application is expected to handle duplicate packets.

In conventional IP multicast networks, such as those running Protocol Independent Multicast (PIM) [RFC7761] or Multicast VPNs (MVPN) [RFC6513], a workaround is to configure all redundant sources with the same IP address. This approach ensures that each receiver gets only one flow because:
- The RP (Rendezvous Point) in the multicast network creates (S,G) state for each source.
- The Last Hop Router (LHR) may also create (S,G) state.
- The (S,G) state binds the flow to a source-specific tree rooted at the source IP address. When multiple sources share the same IP address, the resulting source-specific trees ensure that each LHR or RP resides on at most one tree.

This workaround, which often uses anycast addresses, is suitable for warm standby redundancy solutions (Section 2). However, it is not effective for hot standby redundancy scenarios (Section 2) and introduces challenges when sources need to be reachable via IP unicast or when multiple sources with the same IP address are attached to the same Broadcast Domain.

In scenarios where multiple multicast sources stream traffic to the same group using EVPN Optimized Inter-Subnet Multicast (OISM), redundant sources may not create any (S,G) state. In such cases, the Last Hop Routers may only have (*,G) state, and there may not be a Rendezvous Point router to create (S,G) state. 

This document extends [RFC9251] and [RFC9625] to address scenarios where IP multicast source redundancy exists. Specifically, it defines procedures for EVPN PEs to ensure that receivers do not experience packet duplication when two or more sources send identical IP multicast flows into the tenant domain. These procedures are limited to the context of [RFC9251] and [RFC9625]; handling redundant sources in other multicast solutions is beyond the scope of this document.
"

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

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

GV> Proposed readability rewrite:

"
* P-tunnel: The term "Provider tunnel" refers to the type of tree employed by an upstream EVPN PE to forward multicast traffic to downstream PEs. The P-tunnels supported in this document include Ingress Replication (IR), Assisted Replication (AR), Bit Indexed Explicit Replication (BIER), multicast Label Distribution Protocol (mLDP), and Point-to-Multi-Point Resource Reservation Protocol with Traffic Engineering extensions (P2MP RSVP-TE).

* Redundant G-source: A host or router transmitting a Single Flow Group (SFG) within a tenant network, where multiple hosts or routers are also transmitting the same SFG. Redundant G-sources transmitting the same SFG SHOULD have distinct IP addresses; however, they MAY share the same IP address if located in different Broadcast Domains (BDs) within the same tenant network. For the purposes of this document, redundant G-sources are assumed not to exhibit "bursty" traffic behavior.
"

GV> Can you please check if the term "SFG SHOULD" here is intended as a formal procedure requirement? or as an operational "SFG should" recommendation?

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

GV> should this not be "multicast S-ES" and "multicast S-ESI" when looking at the terminology?

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

233	      -  EVPN S-PMSIs that require the advertisement of S-PMSI Auto-
234	         Discovery (S-PMSI A-D) routes from the upstream PE, as in
235	         [RFC9572].  The interested downstream PEs join the S-PMSI tree
236	         as in [RFC9572].

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

GV> Proposed readability rewrite:

"
* Selective Multicast Tree or Selective Provider Multicast Service Interface (S-PMSI): As defined in [RFC6513], this term refers to a multicast tree to which only the PEs interested in a specific Broadcast Domain (BD) belong. In the context of this document, it is specific to EVPN. Two types of EVPN S-PMSIs are supported:

  * S-PMSIs with Auto-Discovery Routes: These S-PMSIs require the upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI A-D) routes, as described in [RFC9572]. Downstream PEs interested in the multicast traffic join the S-PMSI tree following the procedures specified in [RFC9572].

  * S-PMSIs without Auto-Discovery Routes: These S-PMSIs do not require the advertisement of S-PMSI A-D routes. Instead, they rely on the forwarding information provided by Inclusive Multicast Ethernet Tag (IMET) routes. Upstream PEs forward IP multicast flows only to downstream PEs that advertise Selective Multicast Ethernet Tag (SMET) routes for the specific flow. These S-PMSIs are supported exclusively with the following P-tunnel types: Ingress Replication (IR), Assisted Replication (AR), and Bit Indexed Explicit Replication (BIER).
"

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

GV>  Proposed readability rewrite:

"
* SFG (Single Flow Group): A multicast group that represents traffic containing a single flow. Multiple sources, which may have the same or different IP addresses, can transmit traffic for an SFG. An SFG can be represented in two forms:

  - (*,G): Indicates that any source transmitting multicast traffic to group G is considered a redundant G-source for the SFG.

  - (S,G): Indicates that S is a prefix of any length. In this representation, a source is deemed a redundant G-source for the SFG if its address matches the specified prefix S.
"

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

GV>  Proposed readability rewrite:

"
* Upstream PE: In this document, an Upstream PE refers to the EVPN PE that is either directly connected to the IP multicast source or is the PE closest to the source. The Upstream PE receives IP multicast flows through local Attachment Circuits (ACs).
"

277	   *  Warm Standby Redundancy: multicast source redundancy procedure
278	      defined in this document, by which the upstream PEs, attached to
279	      the redundant sources of the same tenant, make sure that only one
280	      source of the same flow can send multicast to the interested
281	      downstream PEs at the same time.

GV>  Proposed readability rewrite:

"
* Warm Standby Redundancy: A multicast source redundancy mechanism defined in this document, wherein the upstream PEs connected to redundant sources within the same tenant ensure that only one source of a given flow transmits multicast traffic to the interested downstream PEs at any given time.
"

287	1.2.  Background on IP Multicast Delivery in EVPN Networks

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

GV> Proposed readability rewrite:

"
IP multicast facilitates the delivery of a single copy of a packet from a source (S) to a group of receivers (G) along a multicast tree. In an EVPN tenant domain, the multicast tree can be constructed where the source (S) and the receivers for the multicast group (G) are either connected to the same Broadcast Domain (BD) or to different Broadcast Domains. The former scenario is referred to as "Intra-subnet IP Multicast forwarding", while the latter is referred to as "Inter-subnet IP Multicast forwarding"**".
"

297	1.2.1.  Intra-subnet IP Multicast Forwarding
298
299	   When the source S1 and receivers interested in G1 are attached to the
300	   same Broadcast Domain, the EVPN network can deliver the IP Multicast
301	   traffic to the receivers in two different ways (Figure 1):
302
303	                     S1  +                        S1  +
304	           (a)       +   |              (b)       +   |
305	                     |   | (S1,G1)                |   | (S1,G1)
306	                 PE1 |   |                    PE1 |   |
307	                 +-----+ v                    +-----+ v
308	                 |+---+|                      |+---+|
309	                 ||BD1||                      ||BD1||
310	                 |+---+|                      |+---+|
311	                 +-----+                      +-----+
312	            +-------|-------+            +-------|
313	            |       |       |            |       |
314	            v       v       v            v       v
315	         +-----+ +-----+ +-----+      +-----+ +-----+ +-----+
316	         |+---+| |-----| |-----|      |+---+| |+---+| |+---+|
317	         ||BD1|| ||BD1|| ||BD1||      ||BD1|| ||BD1|| ||BD1||
318	         |+---+| |-----| |-----|      |+---+| |+---+| |+---+|
319	         +-----+ +-----+ +-----+      +-----+ +-----+ +-----+
320	         PE2|    PE3|    PE4|         PE2|    PE3|    PE4
321	          - | - - - | -     |          - | - - - | -
322	         |  |       |  |    |         |  |       |  |
323	            v       v       v            v       v
324	         |  R1      R2 |    R3        |  R1      R2 |    R3
325	          - - - G1- - -                - - - G1- - -
326
327	                    Figure 1: Intra-subnet IP Multicast
328
329	   Model (a) illustrated in Figure 1 is referred to as "IP Multicast
330	   delivery as BUM traffic".  This way of delivering IP Multicast
331	   traffic does not require any extensions to [RFC7432], however, it
332	   sends the IP Multicast flows to non-interested receivers, such as
333	   e.g., R3 in Figure 1.  In this example, downstream PEs can snoop
334	   IGMP/MLD messages from the receivers so that layer-2 multicast state
335	   is created and, for instance, PE4 can avoid sending (S1,G1) to R3,
336	   since R3 is not interested in (S1,G1).
337
338	   Model (b) in Figure 1 uses an S-PMSI to optimize the delivery of the
339	   (S1,G1) flow.  For instance, assuming PE1 uses IR, PE1 sends (S1,G1)
340	   only to the downstream PEs that issued an SMET route for (S1,G1),
341	   that is, PE2 and PE3.  In case PE1 uses any P-tunnel different than
342	   IR, AR or BIER, PE1 will advertise an S-PMSI A-D route for (S1,G1)
343	   and PE2/PE2 will join that tree.

GV> Proposed readability rewrite:

"
When the source S1 and the receivers interested in G1 are connected to the same Broadcast Domain (BD), the EVPN network can deliver IP multicast traffic to the receivers using two different approaches, as illustrated in 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


* Model (a): IP Multicast Delivery as BUM Traffic

Model (a) in Figure 1 is referred to as "IP multicast delivery as BUM traffic". This approach does not require any extensions to [RFC7432]. However, it results in the delivery of IP multicast flows to non-interested receivers, such as R3 in Figure 1. 

To optimize this behavior, downstream PEs can snoop IGMP/MLD messages from receivers to build Layer 2 multicast state. For instance, PE4 could avoid forwarding (S1,G1) to R3, since R3 has not expressed interest in (S1,G1).

* Model (b): Optimized Delivery with S-PMSI

Model (b) in Figure 1 uses a "Selective Provider Multicast Service Interface (S-PMSI)" to optimize the delivery of the (S1,G1)flow. 

- For example, if PE1 uses "Ingress Replication (IR)", it will forward (S1,G1) only to downstream PEs that have issued a "Selective Multicast Ethernet Tag (SMET)" route for (S1,G1), such as PE2 and PE3. 
- If PE1 uses a P-tunnel type other than IR (e.g., Assisted Replication (AR) or Bit Indexed Explicit Replication (BIER)), PE1 will advertise an "S-PMSI Auto-Discovery (A-D)" route for (S1,G1). Downstream PEs such as PE2 and PE3 will then join the corresponding multicast tree to receive the flow.
"

347	1.2.2.  Inter-subnet IP Multicast Forwarding
348
349	   If the source and receivers are attached to different BDs of the same
350	   tenant domain, the EVPN network can also use Inclusive or Selective
351	   Trees as depicted in Figure 2, models (a) and (b) respectively.
352
353	                     S1  +                     S1  +
354	           (a)       +   |              (b)    +   |
355	                     |   | (S1,G1)             |   | (S1,G1)
356	                 PE1 |   |                 PE1 |   |
357	                 +-----+ v                 +-----+ v
358	                 |+---+|                   |+---+|
359	                 ||BD1||                   ||BD1||
360	                 |+---+|                   |+---+|
361	                 +-----+                   +-----+
362	            +-------|-------+         +-------|
363	            |       |       |         |       |
364	            v       v       v         v       v
365	         +-----+ +-----+ +-----+   +-----+ +-----+ +-----+
366	         |+---+| |+---+| |+---+|   |+---+| |+---+| |+---+|
367	         ||SBD|| ||SBD|| ||SBD||   ||SBD|| ||SBD|| ||SBD||
368	         |+-|-+| |+-|-+| |+---+|   |+-|-+| |+-|-+| |+---+|
369	         | VRF | | VRF | | VRF |   | VRF | | VRF | | VRF |
370	         |+-v-+| |+-v-+| |+---+|   |+-v-+| |+-v-+| |+---+|
371	         ||BD2|| ||BD3|| ||BD4||   ||BD2|| ||BD3|| ||BD4||
372	         |+-|-+| |+-|-+| |+---+|   |+-|-+| |+-|-+| |+---+|
373	         +--|--+ +--|--+ +-----+   +--|--+ +--|--+ +-----+
374	         PE2|    PE3|    PE4       PE2|    PE3|    PE4
375	          - | - - - | -             - | - - - | -
376	         |  |       |  |           |  |       |  |
377	            v       v                 v       v
378	         |  R1      R2 |    R3     |  R1      R2 |    R3
379	          - - - G1- - -             - - - G1- - -
380
381	                    Figure 2: Inter-subnet IP Multicast
382
383	   [RFC9625] specifies the procedures to optimize the Inter-subnet
384	   Multicast forwarding in an EVPN network.  The IP Multicast flows are
385	   always sent in the context of the source BD.  As described in
386	   [RFC9625], if the downstream PE is not attached to the source BD, the
387	   IP Multicast flow is received on the SBD (Supplementary Broadcast
388	   Domain), as in the example in Figure 2.
389
390	   [RFC9625] supports Inclusive or Selective Multicast Trees, and as
391	   explained in Section 1.2.1, the Selective Multicast Trees are setup
392	   in a different way, depending on the P-tunnel being used by the
393	   source Broadcast Domain.  As an example, model (a) in Figure 2
394	   illustrates the use of an Inclusive Multicast Tree for Broadcast
395	   Domain BD1 on PE1.  Since the downstream PEs are not attached to BD1,
396	   they will all receive (S1,G1) in the context of the Supplementary
397	   Broadcast Domain (SBD) and will locally route the flow to the local
398	   Attachment Circuits.  Model (b) uses a similar forwarding model,
399	   however PE1 sends the (S1,G1) flow in a Selective Multicast Tree.  If
400	   the P-tunnel is Ingress Replication (IR), Assisted Replication (AR)
401	   or Bit Index Explicit Replication (BIER), PE1 does not need to
402	   advertise an S-PMSI A-D route.
403
404	   [RFC9625] is a superset of the procedures in [RFC9251], in which
405	   sources and receivers can be in the same or different Broadcast
406	   Domain of the same tenant.  [RFC9625] ensures every upstream PE
407	   attached to a source will learn of all other PEs (attached to the
408	   same Tenant Domain) that have interest in a particular set of flows.
409	   This is because the downstream PEs advertise SMET routes for a set of
410	   flows with the Supplementary Broadcast Domain's Route Target and they
411	   are imported by all the Upstream PEs of the tenant.  As a result of
412	   that, inter-subnet multicasting can be done within the Tenant Domain,
413	   without requiring any Rendezvous Points (RP), shared trees, Upstream
414	   Multicast Hop (UMH) selection or any other complex aspects of
415	   conventional multicast routing techniques.

GV> Proposed readability rewrite:

"
1.2.2. Inter-subnet IP Multicast Forwarding

When the source and receivers are connected to different BDs within the same tenant domain, the EVPN network can deliver IP multicast traffic using either Inclusive or Selective Multicast Trees, as illustrated in Figure 2 with models (a) and (b), respectively.


                     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

* Procedure Overview
As defined in [RFC9625], inter-subnet multicast forwarding in EVPN is optimized by ensuring IP multicast flows are sent within the context of the source BD. If a downstream PE is not connected to the source BD, the IP multicast flow is delivered to the Supplementary Broadcast Domain (SBD), as shown in Figure 2.

* Inclusive and Selective Multicast Trees
- Model (a): Inclusive Multicast Tree  
  In this model, the Inclusive Multicast Tree for BD1 on PE1 delivers (S1,G1) to all downstream PEs, such as PE2, PE3, and PE4, in the context of the SBD. Each downstream PE then locally routes the flow to its Attachment Circuits, ensuring delivery to interested receivers.

- Model (b): Selective Multicast Tree
  In this model, PE1 optimizes forwarding by delivering (S1,G1) only to downstream PEs that explicitly indicate interest in the flow via Selective Multicast Ethernet Tag (SMET) routes.  
  - If the P-tunnel type is "Ingress Replication (IR)", "Assisted Replication (AR)", or "Bit Indexed Explicit Replication (BIER)", PE1 does not need to advertise an S-PMSI A-D route.
  - Downstream PEs join the multicast tree based on the SMET routes advertised for (S1,G1).

* Advantages of [RFC9625]
- [RFC9625] extends the procedures defined in [RFC9251] to support both intra- and inter-subnet multicast forwarding for EVPN.  
- It ensures that every upstream PE attached to a source is aware of all downstream PEs within the same tenant domain that have interest in specific flows. This is achieved through the advertisement of SMET routes for the SBD Route Target, which are imported by all upstream PEs.

* Elimination of Complexity
The inter-subnet multicast mechanism defined in [RFC9625] eliminates the need for:
- Rendezvous Points (RP),
- Shared trees,
- Upstream Multicast Hop selection, or
- Other complex conventional multicast routing techniques.

By leveraging the EVPN framework, inter-subnet multicast forwarding achieves efficient delivery without introducing unnecessary overhead or dependencies on traditional IP multicast protocols.
"

417	1.3.  Multi-Homed IP Multicast Sources in EVPN
418
419	   Contrary to conventional multicast routing technologies, multi-homing
420	   PEs attached to the same source can never create IP Multicast packet
421	   duplication if the PEs use a multi-homed Ethernet Segment.  Figure 3
422	   illustrates this by showing two multi-homing PEs (PE1 and PE2) that
423	   are attached to the same source (S1).  We assume that S1 is connected
424	   to an all-active ethernet segment by a layer-2 switch (SW1) with a
425	   Link Aggregation Group (LAG) to PE1 and PE2.
426
427	                                     S1
428	                                     |
429	                                     v
430	                                  +-----+
431	                                  | SW1 |
432	                                  +-----+
433	                            +----  |   |
434	                     (S1,G1)| +----+   +----+
435	         IGMP               | | all-active  |
436	         J(S1,G1)     PE1   v |    ES-1     |    PE2
437	         +---->   +-----------|---+     +---|-----------+
438	                  | +---+   +---+ |     | +---+         |
439	          R1  <-----|BD2|   |BD1| |     | |BD1|         |
440	                  | +---+---+---+ |     | +---+---+     |
441	             +----|     |VRF|  |  |     |     |VRF|     |----+
442	             |    | +---+---+  |  |     | +---+---+     |    |
443	             |    | |SBD|      |  |     | |SBD|         |    |
444	             |    | +---+      |  |     | +---+         |    |
445	             |    +------------|--+     +---------------+    |
446	             |                 |                             |
447	             |                 |                             |
448	             |                 |                             |
449	             |  EVPN           |               ^             |
450	             |  OISM           v    PE3        | SMET        |
451	             |              +---------------+  | (*,G1)      |
452	             |              | +---+         |  |             |
453	             |              | |SBD|         |                |
454	             |              | +---+---+     |                |
455	             +--------------|     |VRF|     |----------------+
456	                            | +---+---+---+ |
457	                            | |BD2|   |BD3| |
458	                            | +-|-+   +-|-+ |
459	                            +---|-------|---+
460	                            ^   |       |   ^
461	                   IGMP     |   v       v   | IGMP
462	                    J(*,G1) |  R2       R3  | J(S1,G1)
463
464	                 Figure 3: All-active Multi-homing and OISM
465
466	   When receiving the (S1,G1) flow from S1, SW1 will choose only one
467	   link to send the flow, as per [RFC7432].  Assuming PE1 is the
468	   receiving PE on Broadcast Domain BD1, the IP Multicast flow will be
469	   forwarded as soon as BD1 creates multicast state for (S1,G1) or
470	   (*,G1).  In the example of Figure 3, receivers R1, R2 and R3 are
471	   interested in the multicast flow to G1.  R1 will receive (S1,G1)
472	   directly via the IRB interface as per [RFC9625].  Upon receiving IGMP
473	   reports from R2 and R3, PE3 will issue an SMET (*,G1) route that will
474	   create state in PE1's Broadcast Domain BD1.  PE1 will therefore
475	   forward the IP Multicast flow to PE3's SBD and PE3 will forward to R2
476	   and R3, as per [RFC9625] procedures.
477
478	   When IP Multicast source multi-homing is required, EVPN multi-homed
479	   Ethernet Segments MUST be used.  EVPN multi-homing guarantees that
480	   only one Upstream PE will forward a given multicast flow at the time,
481	   avoiding packet duplication at the Downstream PEs.  In addition, the
482	   SMET route for a given flow creates state in all the multi-homing
483	   Upstream PEs.  Therefore, in case of failure on the Upstream PE
484	   forwarding the flow, the backup Upstream PE can forward the flow
485	   immediately.
486
487	   This document assumes that multi-homing PEs attached to the same
488	   source always use multi-homed Ethernet Segments.

GV> Proposed readability rewrite:

"
1.3. Multi-Homed IP Multicast Sources in EVPN

Unlike conventional multicast routing technologies, multi-homed PEs connected to the same source do not create IP multicast packet duplication when utilizing a multi-homed Ethernet Segment. Figure 3 illustrates this scenario, where two multi-homed PEs (PE1 and PE2) are attached to the same source S1. The source S1 is connected via a Layer 2 switch (SW1) to an all-active Ethernet Segment (ES-1), with a Link Aggregation Group (LAG) extending to PE1 and PE2.


                                     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 S1 transmits the (S1,G1) flow, SW1 selects a single link within the all-active Ethernet Segment to forward the flow, as per [RFC7432]. In this example, assuming PE1 is the receiving PE for Broadcast Domain BD1, the multicast flow is forwarded once BD1 establishes multicast state for (S1,G1) or (*,G1).

In Figure 3:
- Receiver R1 receives (S1,G1) directly via the IRB interface, following the procedures in [RFC9625].
- Receivers R2 and R3, upon issuing IGMP reports, trigger PE3 to advertise an SMET (*,G1) route. This creates multicast state in PE1's BD1, enabling PE1 to forward the multicast flow to PE3's SBD. PE3 subsequently delivers the flow to R2 and R3 as defined in [RFC9625].

* Requirements for Multi-Homed IP Multicast Sources
- When IP multicast source multi-homing is needed, EVPN multi-homed Ethernet Segments MUST be used.
- EVPN multi-homing ensures that only one upstream PE forwards a given multicast flow at a time, preventing packet duplication at downstream PEs.
- The SMET route for a multicast flow ensures that all upstream PEs in the multi-homed Ethernet Segment maintain state for the flow. This allows for immediate failover, as the backup PE can seamlessly take over forwarding in case of an upstream PE failure.

* Assumptions
This document assumes that multi-homed PEs connected to the same source always utilize multi-homed Ethernet Segments.
"

490	1.4.  The Need for Redundant IP Multicast Sources in EVPN
491
492	   While multi-homing PEs to the same IP Multicast G-source provides
493	   certain level of resiliency, multicast applications are often
494	   critical in the Operator's network and greater level of redundancy is
495	   required.  This document assumes that:
496
497	   a.  Redundant G-sources for an Single Flow Group (SFG) may exist in
498	       the EVPN tenant network.  A Redundant G-source is a host or a
499	       router that sends an Single Flow Group stream in a tenant network
500	       where there is another host or router sending traffic to the same
501	       Single Flow Group.
502
503	   b.  Those redundant G-sources may be in the same Broadcast Domain or
504	       different Broadcast Domains of the tenant.  There must not be
505	       restrictions imposed on the location of the receiver systems
506	       either.
507
508	   c.  The redundant G-sources can be single-homed to only one EVPN PE
509	       or multi-homed to multiple EVPN PEs.
510
511	   d.  The EVPN PEs must avoid duplication of packets of the same Single
512	       Flow Group on the receiver systems.

GV> Proposed readability rewrite:

"
1.4. The Need for Redundant IP Multicast Sources in EVPN

While multi-homing PEs to the same IP multicast G-source provides a certain level of resiliency, multicast applications are often critical in operator networks, necessitating a higher level of redundancy. This document assumes the following:

a. Redundant G-sources:  
   Redundant G-sources for a Single Flow Group (SFG) may exist within the EVPN tenant network. A redundant G-source is defined as a host or router transmitting an SFG stream in a tenant network where another host or router is also sending traffic to the same SFG.

b. G-source Placement:  
   Redundant G-sources may reside in the same BD or in different BDs of the tenant network. There must be no restrictions on the locations of receiver systems within the tenant.

c. G-source attachment to EVPN PEs:  
   Redundant G-sources may be either single-homed to a single EVPN PE or multi-homed to multiple EVPN PEs.

d. Packet Duplication Avoidance:  
   The EVPN PEs must ensure that receiver systems do not experience duplicate packets for the same SFG. 

This framework ensures that EVPN networks can effectively support redundant multicast sources while maintaining high reliability and operational efficiency.
"

514	2.  Solution Overview
515
516	   An Single Flow Group (SFG) is represented as (*,G) if any source that
517	   issues multicast traffic to G is a redundant G-source.
518	   Alternatively, this document allows a Single Flow Group to be
519	   represented as (S,G), where the source IP address "S" is a prefix of
520	   any length.  In this case, a source is considered a redundant
521	   G-source for the Single Flow Group if it is contained in the prefix.
522	   This document allows variable length prefixes in the Sources
523	   advertised in S-PMSI A-D routes only for the particular application
524	   of redundant G-sources.
525
526	   There are two redundant G-source solutions described in this
527	   document:
528
529	   *  Warm Standby Solution
530
531	   *  Hot Standby Solution
532
533	   The Warm Standby solution is considered an upstream-PE-based solution
534	   (since downstream PEs do not participate in the procedures), in which
535	   all the upstream PEs attached to redundant G-sources for a Single
536	   Flow Group represented by (*,G) or (S,G) will elect a "Single
537	   Forwarder" (SF) among themselves.  Once a Single Forwarder is
538	   elected, the upstream PEs add an Reverse Path Forwarding check to the
539	   (*,G) or (S,G) state for the Single Flow Group:
540
541	   *  A non-Single Forwarder upstream PE discards any (*,G)/(S,G)
542	      packets received over a local Attachment Circuit.
543
544	   *  The Single Forwarder accepts and forwards any (*,G)/(S,G) packets
545	      it receives over a single local Attachment Circuit (for the Single
546	      Flow Group).  In case (*,G)/(S,G) packets for the Single Flow
547	      Group are received over multiple local Attachment Circuits, they
548	      will be discarded in all the local Attachment Circuits but one.
549	      The procedure to choose the local Attachment Circuit that accepts
550	      packets is a local implementation matter.
551
552	   A failure on the Single Forwarder will result in the election of a
553	   new Single Forwarder.  The Election requires BGP extensions on the
554	   existing EVPN routes.  These extensions and associated procedures are
555	   described in Section 3 and Section 4 respectively.
556
557	   In the Hot Standby solution the downstream PEs are the ones avoiding
558	   the Single Flow Group duplication.  The upstream PEs are aware of the
559	   locally attached G-sources and add a unique Ethernet Segment
560	   Identifier label (ESI-label) per Single Flow Group to the multicast
561	   packets forwarded to downstream PEs.  The downstream PEs pull the
562	   Single Flow Group from all the upstream PEs attached to the redundant
563	   G-sources and avoid duplication on the receiver systems by adding a
564	   Reverse Path Forwarding check to the (*,G) state for the Single Flow
565	   Group:
566
567	   *  A downstream PE discards any (*,G) packets it receives from the
568	      "wrong G-source".
569
570	   *  The wrong G-source is identified in the data path by an Ethernet
571	      Segment Identifier label that is different than the Ethernet
572	      Segment Identifier label used for the selected G-source.
573
574	   *  Note that the Ethernet Segment Identifier label is used here for
575	      "ingress filtering" (at the egress/downstream PE) as opposed to
576	      the [RFC7432] "egress filtering" (at the egress/downstream PE)
577	      used in the split-horizon procedures.  In [RFC7432] the Ethernet
578	      Segment Identifier label indicates what egress Attachment Circuits
579	      must be skipped when forwarding BUM traffic to the egress.  In
580	      this document, the Ethernet Segment Identifier label indicates
581	      what ingress traffic must be discarded at the downstream PE.
582
583	   The use of Ethernet Segment Identifier labels for Single Flow Groups
584	   forwarded by upstream PEs require some control plane and data plane
585	   extensions in the procedures used by [RFC7432] for multi-homing.
586	   Upon failure of the selected G-source, the downstream PE will switch
587	   over to a different selected G-source, and will therefore change the
588	   Reverse Path Forwarding check for the (*,G) state.  The extensions
589	   and associated procedures are described in Section 3 and Section 5
590	   respectively.
591
592	   An operator should use the Hot Standby solution if they require a
593	   fast fail-over time and the additional bandwidth consumption is
594	   acceptable (Single Flow Group packets are received multiple times on
595	   the downstream PEs).  Otherwise the operator should use the Warm
596	   Standby solution, at the expense of a slower fail-over time in case
597	   of a G-source or upstream PE failure.  Besides bandwidth efficiency,
598	   another advantage of the Warm Standby solution is that only the
599	   upstream PEs attached to the redundant G-sources for the same Single
600	   Flow Group need to be upgraded to support the new procedures.
601
602	   This document does not impose the support of both solutions on a
603	   system.  If one solution is supported, the support of the other
604	   solution is OPTIONAL.

GV> Proposed readability rewrite:

"
2. Solution Overview

A Single Flow Group (SFG) can be represented as (*,G) if any source transmitting multicast traffic to group G is considered a redundant G-source. Alternatively, this document allows an SFG to be represented as (S,G), where the source IP address S is a prefix of variable length. In this case, a source is deemed a redundant G-source for the SFG if its address falls within the specified prefix. The use of variable-length prefixes in source advertisements via S-PMSI A-D routes is permitted in this document only for the specific application of redundant G-sources.

This document describes two solutions for handling redundant G-sources:

- Warm Standby Solution
- Hot Standby Solution

2.1. Warm Standby Solution

The Warm Standby solution is an upstream PE-based solution, where downstream PEs do not participate in the procedures. In this solution, all upstream PEs connected to redundant G-sources for a Single Flow Group (*,G) or (S,G) elect a "Single Forwarder (SF)" among themselves. After the Single Forwarder is elected, the upstream PEs apply Reverse Path Forwarding  checks to the multicast state for the SFG:

- Non-Single Forwarder Behavior:  
  A non-Single Forwarder upstream PE discards all (*,G) or (S,G) packets received over its local Attachment Circuit.

- Single Forwarder Behavior:  
  The Single Forwarder accepts and forwards (*,G) or (S,G) packets received on a single local Attachment Circuit for the SFG. If packets are received on multiple local Attachment Circuits, the Single Forwarder discards packets on all but one. The selection of the Attachment Circuit for forwarding is a local implementation detail.

In the event of a failure of the Single Forwarder, a new Single Forwarder is elected among the upstream PEs. This election process requires BGP extensions on existing EVPN routes, which are detailed in Sections 3 and 4.

2.2. Hot Standby Solution

The Hot Standby solution relies on downstream PEs to prevent duplication of SFG packets. Upstream PEs, aware of locally connected G-sources, append a unique Ethernet Segment Identifier (ESI) label to multicast packets for each SFG. Downstream PEs receive SFG packets from all upstream PEs attached to redundant G-sources and avoid duplication by performing an RPF check on the (*,G) state for the SFG:

- Packet Filtering:  
  A downstream PE discards (*,G) packets received from the "wrong G-source." 

- Wrong G-source Identification:  
  The "wrong G-source" is identified using an ESI label that differs from the ESI label associated with the selected G-source.

- ESI Label Usage:  
  In this solution, the ESI label is used for "ingress filtering" at the downstream PE, rather than for "egress filtering" as described in [RFC7432]. In [RFC7432], the ESI label indicates which egress Attachment Circuits must be excluded when forwarding BUM traffic. Here, the ESI label identifies ingress traffic that should be discarded by the downstream PE.

Control plane and data plane extensions to [RFC7432] are required to support ESI labels for SFGs forwarded by upstream PEs. Upon failure of the selected G-source, the downstream PE switches to a different G-source and updates its RPF check for the (*,G) state. These extensions and procedures are described in Sections 3 and 5.

2.3. Solution Selection

Operators should select a solution based on their specific requirements:
- The Hot Standby solution is recommended for scenarios requiring fast failover times, provided that the additional bandwidth consumption (due to multiple transmissions of SFG packets to downstream PEs) is acceptable.
- The Warm Standby solution is more bandwidth-efficient but incurs longer failover times in the event of a G-source or upstream PE failure. Additionally, only the upstream PEs connected to redundant G-sources for the same SFG need to support the new procedures in the Warm Standby solution.

2.4. System Support

This document does not mandate support for both solutions on a single system. If one solution is implemented, support for the other is OPTIONAL.
"

606	3.  BGP EVPN Extensions
607
608	   This document makes use of the following BGP EVPN extensions:
609
610	   1.  Single Flow Group flag in the Multicast Flags Extended Community
611
612	       The Single Flow Group (SFG) flag is a new bit requested to IANA
613	       out of the registry Multicast Flags Extended Community Flag
614	       Values.  This new flag is set for S-PMSI A-D routes that carry a
615	       (*,G)/(S,G) Single Flow Group in the NLRI.
616
617	   2.  ESI Label Extended Community is used in S-PMSI A-D routes
618
619	       The Hot Standby solution requires the advertisement of one or
620	       more ESI Label Extended Communities [RFC7432] that encode the
621	       Ethernet Segment Identifier(s) associated to an S-PMSI A-D
622	       (*,G)/(S,G) route that advertises the presence of a Single Flow
623	       Group.  Only the ESI Label value in the extended community is
624	       relevant to the procedures in this document.  The Flags field in
625	       the extended community will be advertised as 0x00 and ignored on
626	       reception.  [RFC7432] specifies that the ESI Label Extended
627	       Community is advertised along with the A-D per ES route.  This
628	       documents extends the use of this extended community so that it
629	       can be advertised multiple times (with different ESI values)
630	       along with the EVPN S-PMSI A-D route.

GV> Proposed readability rewrite:

"
3. BGP EVPN Extensions

This document introduces the following BGP EVPN extensions:

3.1. Single Flow Group Flag in the Multicast Flags Extended Community

A new Single Flow Group (SFG) flag is defined within the Multicast Flags Extended Community. This flag is requested from the IANA registry for "Multicast Flags Extended Community Flag Values". The SFG flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single Flow Group information in the NLRI.

3.2. ESI Label Extended Community in S-PMSI A-D Routes

The Hot Standby solution requires the advertisement of one or more ESI Label Extended Communities, as defined in [RFC7432]. These extended communities encode the ESI values associated with an S-PMSI A-D (*,G) or (S,G) route that advertises the presence of a Single Flow Group. 

Key considerations include:
- Only the ESI Label value in the extended community is relevant to the procedures defined in this document. 
- The Flags field within the extended community will be set to `0x00` on transmission and ignored on reception.

[RFC7432] specifies the use of the ESI Label Extended Community in conjunction with the A-D per ES route. This document extends the applicability of the ESI Label Extended Community by allowing its inclusion multiple times (with different ESI values) alongside the EVPN S-PMSI A-D route.

These extensions enable the precise encoding and advertisement of Single Flow Group-related information, facilitating efficient multicast traffic handling in EVPN networks.
"

632	4.  Warm Standby (WS) Solution for Redundant G-Sources
633
634	   This section describes the Warm Standby solution for redundant
635	   sources.
636
637	4.1.  Specification
638
639	   The general procedure is described as follows:
640
641	   1.  Configuration of the upstream PEs
642
643	       Upstream PEs (possibly attached to redundant G-sources) need to
644	       be configured to know which groups are carrying only flows from
645	       redundant G-sources, that is, the Single Flow Groups (SFGs) in
646	       the tenant domain.  They will also be configured to know which
647	       local Broadcast Domains may be attached to a redundant G-source.
648	       The Single Flow Groups can be configured for any source, E.g.,
649	       SFG for "*", or for a prefix that contains multiple sources that
650	       will issue the same SFG, i.e., "192.0.2.0/30".  In the latter
651	       case sources 192.0.2.1 and 192.0.2.2 are considered as Redundant
652	       G-sources (since they are contained in 192.0.2.0/30), whereas
653	       192.0.2.10 is not considered a redundant G-source for the same
654	       SFG.
655
656	       As an example (Figure 4):
657
658	       *  PE1 is configured to know that G1 is an SFG for any source and
659	          redundant G-sources for G1 may be attached to Broadcast
660	          Domains BD1 or BD2.
661
662	       *  Or PE1 can also be configured to know that G1 is an SFG for
663	          the sources contained in 192.0.2.0/30, and those redundant
664	          G-sources may be attached to Broadcast Domains BD1 or BD2.
665
666	   2.  Signaling the location of a G-source for a given Single Flow
667	       Group
668
669	       Upon receiving G-traffic for a configured SFG on a Broadcast
670	       Domain, an upstream PE configured to follow this procedure, e.g.,
671	       PE1:
672
673	       *  Originates an S-PMSI A-D (*,G)/(S,G) route for the SFG.  An
674	          (*,G) route is advertised if the SFG is configured for any
675	          source, and an (S,G) route is advertised (where the Source can
676	          have any length) if the SFG is configured for a prefix.
677
678	       *  The S-PMSI A-D route is imported by all the PEs attached to
679	          the tenant domain.  In order to do that, the route will use
680	          the SBD-RT (Supplementary Broadcast Domain Route Target) if
681	          the SBD exists, in addition to the BD-RT (Broadcast Domain
682	          Route Target) of the Broadcast Domain over which the G-traffic
683	          is received.  The route SHOULD also carry a Designated
684	          Forwarder Election Extended Community and the SFG flag (in the
685	          Multicast Flags Extended Community) indicating that it conveys
686	          an SFG.  The Designated Forwarder Election extended community
687	          and its use is specified in [RFC8584].
688
689	       *  The above S-PMSI A-D route MAY be advertised with or without
690	          PMSI Tunnel Attribute:
691
692	          -  With no PMSI Tunnel Attribute if an I-PMSI or S-PMSI A-D
693	             with Ingress Replication, Assisted Replication or BIER are
694	             to be used.
695
696	          -  With PMSI Tunnel Attribute in any other case.
967
698	       *  The S-PMSI A-D route is triggered by the first packet of the
699	          SFG and withdrawn when the flow is not received anymore.
700	          Detecting when the G-source is no longer active is a local
701	          implementation matter.  The use of a timer is RECOMMENDED.
702	          The timer is started when the traffic to G1 is not received.
703	          Upon expiration of the timer, the PE will withdraw the route.
703
705	   3.  Single Forwarder (SF) Election
706	       If the PE with a local G-source receives one or more S-PMSI A-D
707	       routes for the same Single Flow Group from a remote PE, it will
708	       run a Single Forwarder Election based on the information encoded
709	       in the Designated Forwarder Election extended community.  Two
710	       S-PMSI A-D routes are considered for the same SFG if they are
711	       advertised for the same tenant, and their Multicast Source
712	       Length, Multicast Source, Multicast Group Length and Multicast
713	       Group fields match.
714
715	       1.  A given Designated Forwarder Algorithm can only be used if
716	           all the PEs running the Algorithm have consistent input.  For
717	           example, in an OISM network, if the redundant G-sources for
718	           an SFG are attached to Broadcast Domains with different
719	           Ethernet Tags, the Default Designated Forwarder Election
720	           Algorithm MUST NOT be used.
721
722	       2.  In case the there is a mismatch in the Designated Forwarder
723	           Election Algorithm or capabilities advertised by two PEs
724	           competing for the Single Forwarder role, the lowest PE IP
725	           address (given by the Originator Address in the S- PMSI A-D
726	           route) will be used as a tie-breaker.
727
728	   4.  Reverse Path Forwarding check on the PEs attached to a redundant
729	       G-source
730
731	       All the PEs with a local G-source for the Single Flow Group will
732	       add a Reverse Path Forwarding check to the (*,G)/(S,G) state for
733	       the Single Flow Group.  That Reverse Path Forwarding check
734	       depends on the Single Forwarder Election result:
735
736	       1.  The non-Single Forwarder PEs discard any (*,G)/(S,G) packets
737	           for the Single Flow Group received over a local Attachment
738	           Circuit.
739
740	       2.  The Single Forwarder accepts any (*,G)/(S,G) packets for the
741	           Single Flow Group it receives over one (and only one) local
742	           Attachment Circuit.
743
744	   The solution above provides redundancy for Single Flow Groups and it
745	   does not require an upgrade of the downstream PEs (PEs where there is
746	   certainty that no redundant G-sources are connected).  Other
747	   G-sources for non-Single Flow Groups may exist in the same tenant
748	   domain.  This document does not change the existing procedures for
749	   non-Single Flow Group G-sources.
750
751	   The redundant G-sources can be single-homed or multi-homed to a
752	   Broadcast Domain in the tenant domain.  Multi-homing does not change
753	   the above procedures.
754
755	   Section 4.2 and Section 4.3 show two examples of the Warm Standby
756	   solution.

GV> Proposed readability rewrite:

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

This section specifies the Warm Standby (WS) solution for handling redundant multicast sources (G-sources).

4.1. Specification

The Warm Standby solution follows these general procedures:

1. Configuration of Upstream PEs

Upstream PEs, potentially connected to redundant G-sources, must be configured to recognize:
- The multicast groups that carry Single Flow Groups (SFGs) in the tenant domain.
- The local Broadcast Domains that may host redundant G-sources.

The SFG configuration may apply to any source (e.g., (*) or to a specific source prefix (e.g., "192.0.2.0/30"). For instance:
- If the prefix is 192.0.2.0/30, the sources 192.0.2.1 and 192.0.2.2 are considered redundant G-sources for the SFG, while 192.0.2.10 is not.

Example Configuration (Figure 4):
- PE1 is configured to recognize G1 as an SFG for any source, with potential redundant G-sources attached to Broadcast Domains BD1 and BD2.
- Alternatively, PE1 may recognize G1 as an SFG for sources within 192.0.2.0/30, with redundant G-sources in BD1 and BD2.

2. Signaling the Location of a G-Source for an SFG

Upon receiving multicast traffic for a configured SFG on a Broadcast Domain, an upstream PE (e.g., PE1):
- Advertises an S-PMSI A-D route for the SFG:
  - An (*,G) route if the SFG is configured for any source.
  - An (S,G) route (where S can have any prefix length) if the SFG is configured for a source prefix.

- Includes the following attributes in the S-PMSI A-D route:
  - Route Targets (RTs): The Supplementary Broadcast Domain Route Target (SBD-RT), if applicable, and the Broadcast Domain Route Target (BD-RT) of the Broadcast Domain receiving the traffic.
  - Multicast Flags Extended Community: Includes the SFG flag to indicate that the route conveys an SFG.
  - Designated Forwarder Election Extended Community: Specifies the algorithm and preferences for Single Forwarder  election, as defined in [RFC8584].

- Advertises the route:
  - Without a PMSI Tunnel Attribute if using Ingress Replication (IR), Assisted Replication (AR), or Bit Indexed Explicit Replication (BIER).
  - With a PMSI Tunnel Attribute for other tunnel types.

- Withdraws the S-PMSI A-D route when the SFG traffic ceases. A timer is RECOMMEMDED to detect inactivity and trigger route withdrawal.

3. Single Forwarder Election

If a PE receives one or more S-PMSI A-D routes for the same SFG from remote PEs, it performs Single Forwarder Election based on the Designated Forwarder Election Extended Community.

- Two routes are considered part of the same SFG if they match on the following fields:
  - Tenant
  - Multicast Source Length
  - Multicast Source
  - Multicast Group Length
  - Multicast Group

- Election Rules:
  1. A consistent Designated Forwarder Election Algorithm must be used across all PEs. For instance, in OISM networks, the Default Designated Forwarder Election Algorithm MUST NOT be used if redundant G-sources are attached to Broadcast Domains with different Ethernet Tags.
  2. In case of a mismatch in the Designated Forwarder Election Algorithm or capabilities, the tie-breaker is the lowest PE IP address (as advertised in the Originator Address field of the S-PMSI A-D route).


4. Reverse Path Forwarding Checks on Upstream PEs

All PEs with a local G-source for an SFG apply an RPF check to the (*,G) or (S,G) state based on the SF election result:
1. Non-Single Forwarder PEs: Discard all (*,G) or (S,G) packets received on local Attachment Circuits.
2. Single Forwarder PEs: Forward (*,G) or (S,G) packets received on one (and only one) local Attachment Circuit.

Key Features of the Warm Standby Solution

- The solution ensures redundancy for SFGs without requiring upgrades to downstream PEs (where no redundant G-sources are connected).
- Existing procedures for non-SFG G-sources remain unchanged.
- Redundant G-sources can be either single-homed or multi-homed. Multi-homing does not alter the above procedures.

Examples of the Warm Standby solution are provided in Sections 4.2 and 4.3.
"

758	4.2.  Warm Standby Example in an OISM Network
759
760	   Figure 4 illustrates an example in which S1 and S2 are redundant
761	   G-sources for the Single Flow Group (*,G1).
762
763	                        S1 (Single               S2
764	                        |   Forwarder)           |
765	                 (S1,G1)|                 (S2,G1)|
766	                        |                        |
767	               PE1      |               PE2      |
768	               +--------v---+           +--------v---+
769	        S-PMSI |      +---+ |           |      +---+ | S-PMSI
770	        (*,G1) |  +---|BD1| |           |  +---|BD2| | (*,G1)
771	       Pref200 |  |VRF+---+ |           |  |VRF+---+ | Pref100
772	         |SFG  |+---+  | |  |           |+---+  |    |  SFG|
773	         | +----|SBD|--+ |  |-----------||SBD|--+    |---+ |
774	         v |   |+---+    |  |           |+---+       |   | v
775	           |   +---------|--+           +------------+   |
776	    SMET   |             |                               | SMET
777	    (*,G1) |             |   (S1,G1)                     | (*,G1)
778	           |    +--------+------------------+            |
779	       ^   |    |                           |            |   ^
780	       |   |    |                EVPN       |            |   |
781	       |   |    |                OISM       |            |   |
782	       |   |    |                           |            |   |
783	       PE3 |    |           PE4             |            | PE5
784	       +--------v---+       +------------+  |   +------------+
785	       |      +---+ |       |      +---+ |  |   |      +---+ |
786	       |  +---|SBD| |-------|  +---|SBD| |--|---|  +---|SBD| |
787	       |  |VRF+---+ |       |  |VRF+---+ |  |   |  |VRF+---+ |
788	       |+---+  |    |       |+---+  |    |  |   |+---+  |    |
789	       ||BD3|--+    |       ||BD4|--+    |  +--->|BD1|--+    |
790	       |+---+       |       |+---+       |      |+---+       |
791	       +------------+       +------------+      +------------+
792	         |  ^                                     |  ^
793	         |  | IGMP                                |  | IGMP
794	         R1 | J(*,G1)                             R3 | J(*,G1)
795
796	          Figure 4: Warm Standby Solution for Redundant G-Sources
797
798	   The Warm Standby solution works as follows:
799
800	   1.  Configuration of the upstream PEs, PE1 and PE2
801	       PE1 and PE2 are configured to know that G1 is an Single Flow
802	       Group for any source and redundant G-sources for G1 may be
803	       attached to Broadcast Domains BD1 or BD2, respectively.
804
805	   2.  Signaling the location of S1 and S2 for (*,G1)
806
807	       Upon receiving traffic to G1 on a local Attachment Circuit, PE1
808	       and PE2 originate S-PMSI A-D (*,G1) routes with the SBD-RT
809	       (Supplementary Broadcast Domain Route Target), Designated
810	       Forwarder Election Extended Community and the SFG flag in the
811	       Multicast Flags Extended Community, indicating that it conveys a
812	       Single Flow Group.
813
814	   3.  Single Forwarder (SF) Election
815
816	       Based on the Designated Forwarder Election extended community
817	       content, PE1 and PE2 elect a Single Forwarder for (*,G1).
818	       Assuming both PEs agree on e.g., Preference based Election as the
819	       algorithm to use [I-D.ietf-bess-evpn-pref-df], and PE1 has a
820	       higher preference, PE1 becomes the Single Forwarder for (*,G1).
821
822	   4.  Reverse Path Forwarding check on the PEs attached to a redundant
823	       G-source
824
825	       a.  The non-Single Forwarder, PE2, discards any (*,G1) packets
826	           received over a local Attachment Circuit.
827
828	       b.  The Single Forwarder, PE1 accepts (*,G1) packets it receives
829	           over one (and only one) local Attachment Circuit.
830
831	   The end result is that, upon receiving IGMP/MLD reports for (*,G1) or
832	   (S,G1), the downstream PEs (PE3 and PE5) will issue SMET routes and
833	   will pull the multicast Single Flow Group from PE1, and PE1 only.
834	   Upon a failure on S1, the Attachment Circuit connected to source S1
835	   or PE1 itself will trigger the S-PMSI A-D (*,G1) withdrawal from PE1
836	   and PE2 will be promoted to Single Forwarder.

GV> Proposed readability rewrite:

"
4.2. Warm Standby Example in an OISM Network

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


                        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


Procedure

1. Configuration of Upstream PEs (PE1 and PE2) 
   - PE1 and PE2 are configured to recognize G1 as a Single Flow Group for any source.  
   - Redundant G-sources for G1 may be attached to Broadcast Domains BD1 (for PE1) and BD2 (for PE2).

2. Signaling the Location of S1 and S2 for (*,G1)  
   - Upon receiving traffic for G1 on a local Attachment Circuit:
     - PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including:
       - The Supplementary Broadcast Domain Route Target (SBD-RT),
       - The Designated Forwarder Election Extended Community, and
       - The SFG flag in the Multicast Flags Extended Community.
   - These routes indicate the presence of a Single Flow Group.

3. Single Forwarder Election 
   - Based on the Designated Forwarder Election Extended Community, PE1 and PE2 perform Single Forwarder election.
   - Assuming they use Preference-based Election [I-D.ietf-bess-evpn-pref-df], PE1 (with a higher preference) is elected as the Single Forwarder for (*,G1).

4. Reverse Path Forwarding (RPF) Check on Upstream PEs 
   - Non-Single Forwarder Behavior: PE2 discards all (*,G1) packets received on its local Attachment Circuit.  
   - Single Forwarder Behavior: PE1 forwards (*,G1) packets received on one (and only one) local Attachment Circuit.

Outcome

- Upon receiving IGMP/MLD reports for (*,G1) or (S,G1), downstream PEs (PE3 and PE5) issue SMET routes to pull the multicast Single Flow Group traffic from PE1 only.
- In the event of a failure of S1, the Attachment Circuit connected to S1, or PE1 itself, the S-PMSI A-D route for (*,G1) is withdrawn by PE1.  
- As a result, PE2 is promoted to Single Forwarder, ensuring continued delivery of (*,G1) traffic.
"

838	4.3.  Warm Standby Example in a Single-BD Tenant Network
839
840	   Figure 5 illustrates an example in which S1 and S2 are redundant
841	   G-sources for the Single Flow Group (*,G1), however, now all the
842	   G-sources and receivers are connected to the same Broadcast Domain
843	   BD1 and there is no Supplementary Broadcast Domain.
844
845	                        S1 (Single               S2
846	                        |   Forwarder)           |
847	                 (S1,G1)|                 (S2,G1)|
848	                        |                        |
849	               PE1      |               PE2      |
850	               +--------v---+           +--------v---+
851	       S-PMSI  |      +---+ |           |      +---+ | S-PMSI
852	       (*,G1)  |      |BD1| |           |      |BD1| | (*,G1)
853	       Pref200 |      +---+ |           |      +---+ | Pref100
854	        |SFG   |         |  |           |            |  SFG|
855	        |  +---|         |  |-----------|            |---+ |
856	        v  |   |         |  |           |            |   | v
857	           |   +---------|--+           +------------+   |
858	    SMET   |             |                               | SMET
859	    (*,G1) |             |     (S1,G1)                   | (*,G1)
860	           |    +--------+------------------------+      |
861	       ^   |    |                                 |      |   ^
862	       |   |    |                EVPN             |      |   |
863	       |   |    |                                 |      |   |
864	       |   |    |                                 |      |   |
865	       PE3 |    |           PE4                   |      | PE5
866	       +--------v---+       +------------+      +-|----------+
867	       |      +---+ |       |      +---+ |      | |    +---+ |
868	       |      |BD1| |-------|      |BD1| |------| +--->|BD1| |
869	       |      +---+ |       |      +---+ |      |      +---+ |
870	       |            |       |            |      |            |
871	       |            |       |            |      |            |
872	       |            |       |            |      |            |
873	       +------------+       +------------+      +------------+
874	         |  ^                                     |  ^
875	         |  | IGMP                                |  | IGMP
876	         R1 | J(*,G1)                             R3 | J(*,G1)
877
878	        Figure 5: WS Solution for Redundant G-Sources in the same BD
879
880	   The same procedure as in Section 4.2 is valid here, being this a sub-
881	   case of the one in Section 4.2.  Upon receiving traffic for the
882	   Single Flow Group G1, PE1 and PE2 advertise the S-PMSI A-D routes
883	   with route target BD1-RT only, since there is no Supplementary
884	   Broadcast Domain (SBD).

GV> Proposed readability rewrite:

"
4.3. Warm Standby Example in a Single-BD Tenant Network

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

                        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: Warm Standby Solution for Redundant G-Sources in the Same BD

Procedure

The procedures for the Warm Standby solution in this example are identical to those described in Section 4.2, with the following distinction:

- Signaling the S-PMSI A-D Routes  
  - Upon receiving traffic for the Single Flow Group (*,G1), PE1 and PE2 advertise S-PMSI A-D routes.
  - These routes include only the BD1-RT (Broadcast Domain 1 Route Target) as there is no Supplementary Broadcast Domain (SBD) in this scenario.

This example represents a specific sub-case of the broader procedure detailed in Section 4.2, adapted to a single Broadcast Domain environment. The absence of an SBD simplifies the configuration, as all signaling remains within the context of BD1.
"

886	5.  Hot Standby Solution for Redundant G-Sources
887
888	   This section describes the Hot Standby solution for redundant
889	   sources.
890
891	5.1.  Specification
892
893	   If fast-failover is required upon the failure of a G-source or PE
894	   attached to the G-source and the extra bandwidth consumption in the
895	   tenant network is not an issue, the Hot Standby solution should be
896	   used.  The procedure is as follows:
897
898	   1.  Configuration of the PEs
899
900	       As in the Warm Standby case, the upstream PEs where redundant
901	       G-sources may exist need to be configured to know which groups
902	       (for any source or a prefix containing the intended sources) are
903	       carrying only flows from redundant G-sources, that is, the Single
904	       Flow Groups in the tenant domain.
905
906	       In addition (and this is not done in Warm Standby mode), the
907	       individual redundant G-sources for a Single Flow Group need to be
908	       associated with an Ethernet Segment on the upstream PEs.  This is
909	       irrespective of the redundant G-source being multi-homed or
910	       single-homed.  Even for single-homed redundant G-sources the Hot
911	       Standby procedure relies on the ESI labels for the Reverse Path
912	       Forwarding check on downstream PEs.  The term "S-ESI" is used in
913	       this document to refer to an Ethernet Segment Identifier
914	       associated to a redundant G-source.
915
916	       Contrary to what is specified in the Warm Standby method (that is
917	       transparent to the downstream PEs), the support of the Hot
918	       Standby procedure is required not only on the upstream PEs but
919	       also on all downstream PEs connected to the receivers in the
920	       tenant network.  The downstream PEs do not need to be configured
921	       to know the connected Single Flow Groups or their Ethernet
922	       Segment Identifiers, since they get that information from the
923	       upstream PEs.  The downstream PEs will locally select an Ethernet
924	       Segment Identifier for a given Single Flow Group, and will
925	       program a Reverse Path Forwarding check to the (*,G)/(S,G) state
926	       for the Single Flow Group that will discard (*,G)/(S,G) packets
927	       from the rest of the Ethernet Segment Identifiers.  The selection
928	       of the Ethernet Segment Identifier for the Single Flow Group is
929	       based on local policy, and therefore, different downstream PEs
930	       may select different Ethernet Segment Identifiers.
931
932	   2.  Signaling the location of a G-source for a given Single Flow
933	       Group and its association to the local Ethernet Segments
934
935	       Based on the configuration in step 1, an upstream PE configured
936	       to follow the Hot Standby procedures:
937
938	       a.  Advertises an S-PMSI A-D (*,G)/(S,G) route per each
939	           configured Single Flow Group.  These routes need to be
940	           imported by all the PEs of the tenant domain, therefore they
941	           will carry the route targets BD-RT (the route target of the
942	           Broadcast Domain) and SBD-RT (the route target of the
943	           Supplementary Broadcast Domain, if the SBD exists).  The
944	           route also carries the ESI Label extended communities needed
945	           to convey all the S-ESIs associated to the Single Flow Group
946	           in the PE.
947
948	       b.  The S-PMSI A-D route will convey a PMSI Tunnel Attribute in
949	           the same cases as in the Warm Standby procedure.
950
951	       c.  The S-PMSI A-D (*,G)/(S,G) route is triggered by the
952	           configuration of the Single Flow Group and not by the
953	           reception of G-traffic.
954
955	   3.  Distribution of DCB (Domain-wide Common Block) ESI-labels and
956	       G-source ES routes
957
958	       An upstream PE advertises the corresponding EVPN ES route, A-D
959	       per EVI and A-D per ES routes for the local S-ESIs.
960
961	       a.  ES routes are used for regular Designated Forwarder Election
962	           for the S-ES.  This document does not introduce any change in
963	           the procedures related to the EVPN ES routes.
964
965	       b.  If the SBD exists, the EVPN A-D per EVI and A-D per ES routes
966	           MUST include the route target SBD-RT since they have to be
967	           imported by all the PEs in the tenant domain.
968
969	       c.  The EVPN A-D per ES routes convey the S-ESI labels that the
970	           downstream PEs use to add the Reverse Path Forwarding check
971	           for the (*,G)/(S,G) associated to the Single Flow Groups.
972	           This Reverse Path Forwarding check requires that all the
973	           packets for a given G-source are received with the same S-ESI
974	           label value on the downstream PEs.  For example, if two
975	           redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1
976	           and S-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx"
977	           for S-ES-1 and they MUST allocate the same ESI label "Ly" for
978	           S-ES-2.  In addition, Lx and Ly MUST be different.  These ESI
979	           labels are Domain-wide Common Block (DCB) labels and follow
980	           the allocation procedures in [RFC9573].
981
982	   4.  Processing of EVPN A-D per ES/EVI routes and Reverse Path
983	       Forwarding check on the downstream PEs
984	       The EVPN A-D per ES/EVI routes are received and imported in all
985	       the PEs in the tenant domain.  The processing of the EVPN A-D per
986	       ES/EVI routes on a given PE depends on its configuration:
987
988	       a.  The PEs attached to the same Broadcast Domain of the route
989	           target BD-RT that is included in the EVPN A-D per ES/EVI
990	           routes will process the routes as in [RFC7432] and [RFC8584].
991	           If the receiving PE is attached to the same Ethernet Segment
992	           as indicated in the route, [RFC7432] split-horizon procedures
993	           will be followed and the Designated Forwarder Election
994	           candidate list may be modified as in [RFC8584] if the
995	           Ethernet Segment supports the AC-DF (Attachment Circuit
996	           influenced Designated Forwarder) capability.
997
998	       b.  The PEs that are not attached to the Broadcast Domain
999	           identified by the route target BD-RT but are attached to the
1000	           Supplementary Broadcast Domain of the received route target
1001	           SBD-RT, will import the EVPN A-D per ES/EVI routes and use
1002	           them for redundant G-source mass withdrawal, as explained
1003	           later.
1004
1005	       c.  Upon importing EVPN A-D per ES routes corresponding to
1006	           different S-ESes, a PE MUST select a primary S-ES and add a
1007	           Reverse Path Forwarding check to the (*,G)/(S,G) state in the
1008	           Broadcast Domain or Supplementary Broadcast Domain.  This
1009	           Reverse Path Forwarding check will discard all ingress
1010	           packets to (*,G)/(S,G) that are not received with the ESI-
1011	           label of the primary S-ES.  The selection of the primary S-ES
1012	           is a matter of local policy.
1013
1014	   5.  G-traffic forwarding for redundant G-sources and fault detection
1015
1016	       Assuming there is (*,G) or (S,G) state for the Single Flow Group
1017	       with Output Interface list entries associated to remote EVPN PEs,
1018	       upon receiving G-traffic on a S-ES, the upstream PE will add a
1019	       S-ESI label at the bottom of the stack before forwarding the
1020	       traffic to the remote EVPN PEs.  This label is allocated from a
1021	       Domain-wide Common Block as described in step 3.  If Point-to-
1022	       multipoint or BIER PMSIs are used, this is not adding any new
1023	       data path procedures on the upstream PEs (except that the ESI-
1024	       label is allocated from a Domain-wide Common Block as described
1025	       in [RFC9573]).  However, if Ingress Replication or Assisted
1026	       Replication are used, this document extends the [RFC7432]
1027	       procedures by pushing the S-ESI labels not only on packets sent
1028	       to the PEs that shared the ES but also to the rest of the PEs in
1029	       the tenant domain.  This allows the downstream PEs to receive all
1030	       the multicast packets from the redundant G-sources with a S-ESI
1031	       label (irrespective of the PMSI type and the local ESes), and
1032	       discard any packet that conveys a S-ESI label different from the
1033	       primary S-ESI label (that is, the label associated to the
1034	       selected primary S-ES), as discussed in step 4.
1035
1036	       If the last EVPN A-D per EVI or the last EVPN A-D per ES route
1037	       for the primary S-ES is withdrawn, the downstream PE will
1038	       immediately select a new primary S-ES and will change the Reverse
1039	       Path Forwarding check.  Note that if the S-ES is re-used for
1040	       multiple tenant domains by the upstream PEs, the withdrawal of
1041	       all the EVPN A-D per-ES routes for a S-ES provides a mass
1042	       withdrawal capability that makes a downstream PE to change the
1043	       Reverse Path Forwarding check in all the tenant domains using the
1044	       same S-ES.
1045
1046	       The withdrawal of the last EVPN S-PMSI A-D route for a given
1047	       (*,G)/(S,G) that represents a Single Flow Group SHOULD make the
1048	       downstream PE remove the S-ESI label based Reverse Path
1049	       Forwarding check on (*,G)/(S,G).
1050
1051	   As in [RFC9573] this document also allows the use of context label
1052	   space ID extended community.  When the context label space ID
1053	   extended community is advertised along with the ESI label in an EVPN
1054	   A-D per ES route, the ESI label is from a context label space
1055	   identified by the Domain-wide Common Block label in the Extended
1056	   Community.

GV> Proposed readability rewrite:

"
5. Hot Standby Solution for Redundant G-Sources

This section specifies the Hot Standby solution for handling redundant multicast sources (G-sources).

5.1. Specification

The Hot Standby solution is designed for scenarios requiring fast failover in the event of a G-source or upstream PE failure. It assumes that additional bandwidth consumption in the tenant network is acceptable. The procedure is as follows:

1. Configuration of PEs

- Upstream PEs must be configured to identify Single Flow Groups in the tenant domain. This includes groups for any source or a source prefix containing redundant G-sources.
- Each redundant G-source must be associated with an ESI on the upstream PEs. This applies to both single-homed and multi-homed G-sources. For single-homed G-sources, ESI labels are essential for Reverse Path Forwarding checks on downstream PEs. The term S-ESI is used to denote the ESI associated with a redundant G-source.
- Unlike the Warm Standby solution, the Hot Standby solution requires downstream PEs to support the procedure. Downstream PEs:
  - Do not need explicit configuration for Single Flow Groups or their ESIs.
  - Dynamically select an ESI for each Single Flow Group based on local policy and program an RPF check to discard packets from other ESIs.

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

An upstream PE configured for Hot Standby procedures:
- Advertises an S-PMSI A-D route for each Single Flow Group. These routes:
  - Use the Broadcast Domain Route Target (BD-RT) and, if applicable, the Supplementary Broadcast Domain Route Target (SBD-RT).
  - Include ESI Label Extended Communities to convey the S-ESIs associated with the Single Flow Group.
- Includes a PMSI Tunnel Attribute as specified in the Warm Standby procedure.
- Triggers S-PMSI A-D route advertisement based on the SFG configuration, not the reception of traffic.

3. Distribution of Domain-wide Common Block (DCB) ESI Labels

- Upstream PEs advertise corresponding EVPN routes:
  - EVPN Ethernet Segment (ES) routes for the local S-ESIs.
  - A-D per EVI and A-D per ES routes for tenant-specific traffic.
- ESI Label Procedures:
  - S-ESI labels are used by downstream PEs to implement RPF checks for SFGs.
  - All packets for a given G-source must carry the same S-ESI label.  
  - S-ESI labels are allocated as Domain-wide Common Block (DCB) labels and follow the procedures in [RFC9573].

4. Downstream PE RPF Checks

Downstream PEs process received EVPN routes based on their configuration:
- PMSI Handling:
  Routes with BD-RT are processed per [RFC7432] and [RFC8584]. Split-horizon procedures are applied when necessary.
- SBD-RT Processing:
  Routes with SBD-RT are imported for redundant G-source mass withdrawal procedures.
- RPF Implementation:
  Upon importing EVPN routes for multiple S-ESIs, downstream PEs:
  - Select a primary S-ESI based on local policy.
  - Add an RPF check to discard packets for (*,G) or (S,G) not received with the primary S-ESI label.

5. Forwarding and Fault Detection

- G-traffic Forwarding:
  Upstream PEs append an S-ESI label to multicast traffic for SFGs before forwarding to remote PEs. This label is allocated as a DCB label.
  - For Ingress Replication and Assisted Replication, the procedures in [RFC7432] are extended to ensure S-ESI labels are applied to all tenant PEs.
- Fault Detection: 
  - Downstream PEs monitor for the withdrawal of EVPN routes associated with the primary S-ESI.
  - Upon withdrawal, downstream PEs select a new primary S-ESI and update their RPF checks.

6. Handling G-source Failures

- If all EVPN routes for a primary S-ESI are withdrawn, downstream PEs:
  - Perform mass withdrawal for all tenant domains using the S-ESI.
  - Update RPF checks to ensure continued operation.

- If the last S-PMSI A-D route for an SFG is withdrawn, the downstream PE removes the S-ESI-based RPF check for the associated (*,G) or (S,G).

This document supports the use of Context Label Space ID Extended Communities, as described in [RFC9573], for scenarios where S-ESI labels are allocated within context label spaces.
"

1058	5.2.  Extensions for the Advertisement of DCB Labels
1059
1060	   Domain-wide Common Block Labels are specified in [RFC9573] and this
1061	   document makes use of them for the procedures described in
1062	   Section 5.1.  [RFC9573] assumes that Domain-wide Common Block labels
1063	   can only be used along with Multipoint-to-Multipoint, Point-to-
1064	   Multipoint, or BIER tunnels and that, if the PMSI label is signaled
1065	   as a Domain-wide Common Block label, then the ESI label used for
1066	   multi-homing is also a Domain-wide Common Block label.  This document
1067	   extends the use of the Domain-wide Common Block allocation for ESI
1068	   labels so that:
1069
1070	   a.  Domain-wide Common Block allocated ESI labels MAY be used along
1071	       with Ingress Replication tunnels, and
1072
1073	   b.  Domain-wide Common Block allocated ESI labels MAY be used by PEs
1074	       that do not use Domain-wide Common Block allocated PMSI labels.
1075
1076	   This control plane extension is indicated by adding the DCB-flag
1077	   (Domain-wide Common Block flag) or the Context Label Space ID
1078	   extended community to the EVPN A-D per ES route(s) advertised for the
1079	   S-ES.  The DCB-flag is encoded in the ESI Label Extended Community as
1080	   follows:
1081
1082	                        1                   2                   3
1083	    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
1084	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1085	   | Type=0x06     | Sub-Type=0x01 | Flags(1 octet)|  Reserved=0   |
1086	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1087	   |  Reserved=0   |          ESI Label                            |
1088	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1089
1090	                   Figure 6: ESI Label Extended Community
1091
1092	   This document defines the bit 5 in the Flags octet of the ESI Label
1093	   Extended Community as the ESI-DCB-flag.  When the ESI-DCB-flag is
1094	   set, it indicates that the ESI label is a Domain-wide Common Block
1095	   label.
1096
1097	   A received ESI label is considered a Domain-wide Common Block label
1098	   if either of these two conditions is met:
1099
1100	   a.  The ESI label is encoded in an ESI Label Extended Community with
1101	       the ESI-DCB-flag set.
1102
1103	   b.  The ESI label is signaled from a PE that advertised a PMSI label
1104	       that is a Domain-wide Common Block label.
1105
1106	   As in [RFC9573] this document also allows the use of context label
1107	   space ID extended community.  When the context label space ID
1108	   extended community is advertised along with the ESI label in an EVPN
1109	   A-D per ES route, the ESI label is from a context label space
1110	   identified by the Domain-wide Common Block label in the Extended
1111	   Community.

GV> Proposed readability rewrite:

"
5.2. Extensions for the Advertisement of Domain-wide Common Block (DCB) Labels

Domain-wide Common Block (DCB) labels are specified in [RFC9573], and this document extends their usage as outlined in Section 5.1. [RFC9573] assumes that DCB labels are applicable only to Multipoint-to-Multipoint, Point-to-Multipoint, or Bit Indexed Explicit Replication (BIER) tunnels. Additionally, it specifies that when a PMSI label is a DCB label, the ESI label used for multi-homing must also be a DCB label. 

This document extends the use of DCB-allocated ESI labels with the following provisions:

- a. DCB-allocated ESI labels MAY be used with Ingress Replication tunnels.
- b. DCB-allocated ESI labels MAY be used by PEs that do not use DCB-allocated PMSI labels.

Control Plane Extensions

These extensions are indicated in the EVPN A-D per ES routes for the relevant S-ESs by:
1. Adding the DCB-flag** (Domain-wide Common Block flag) to the ESI Label Extended Community, or
2. Adding the Context Label Space ID Extended Community.

The encoding of the DCB-flag within the ESI Label Extended Community is shown below:

                       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

Definition of the ESI-DCB-flag

- Bit 5 of the Flags octet in the ESI Label Extended Community is defined as the ESI-DCB-flag by this document.
- When the ESI-DCB-flag is set, it indicates that the ESI label is a DCB label.

Criteria for Identifying a DCB Label

An ESI label is considered a DCB label if either of the following 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 by a PE that has advertised a PMSI label that is a DCB label.

Use of Context Label Space ID Extended Community

As specified in [RFC9573], this document also permits the use of the Context Label Space ID Extended Community. When this extended community is advertised along with the ESI label in an EVPN A-D per ES route, it indicates that the ESI label belongs to a context label space identified by the DCB label specified in the extended community.
"

1113	5.3.  Use of BFD in the HS Solution
1114
1115	   In addition to using the state of the EVPN A-D per EVI, EVPN A-D per
1116	   ES or S-PMSI A-D routes to modify the Reverse Path Forwarding check
1117	   on (*,G)/(S,G) as discussed in Section 5.1, Bidirectional Forwarding
1118	   Detection (BFD) protocol MAY be used to monitor the status of the
1119	   multipoint tunnels used to forward the Single Flow Group packets from
1120	   the redundant G-sources.
1121
1122	   The BGP-BFD Attribute is advertised along with the S-PMSI A-D or
1123	   Inclusive Multicast Ethernet Tag routes (depending on whether
1124	   Inclusive PMSI or Selective PMSI trees are used) and the procedures
1125	   described in [I-D.ietf-bess-evpn-bfd] [I-D.ietf-mpls-p2mp-bfd] are
1126	   used to bootstrap multipoint BFD sessions on the downstream PEs.

GV> Proposed readability rewrite:

"
5.3. Use of BFD in the Hot Standby Solution

In addition to utilizing the state of EVPN A-D per EVI, EVPN A-D per ES, or S-PMSI A-D routes to adjust the Reverse Path Forwarding (RPF) checks for (*,G) or (S,G), as described in Section 5.1, the Bidirectional Forwarding Detection (BFD)protocol MAY be employed to monitor the status of the multipoint tunnels used to forward Single Flow Group packets from redundant G-sources.

BFD Integration
- The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or Inclusive Multicast Ethernet Tag routes, depending on whether Inclusive PMSI or Selective PMSI trees are being utilized.
- The procedures outlined in:
  - [I-D.ietf-bess-evpn-bfd], and
  - [I-D.ietf-mpls-p2mp-bfd]
  are followed to bootstrap multipoint BFD sessions on the downstream PEs.
"

1128	5.4.  Hot Standby Example in an OISM Network
1129
1130	   Figure 7 illustrates the Hot Standby model in an Optimized Inter-
1131	   Subnet Multicast (OISM) network.  Consider S1 and S2 are redundant
1132	   G-sources for the Single Flow Group (*,G1) in Broadcast Domain BD1
1133	   (any source using G1 is assumed to transmit an SFG).  S1 and S2 are
1134	   (all-active) multi-homed to upstream PEs, PE1 and PE2.  The receivers
1135	   are attached to downstream PEs, PE3 and PE5, in Broadcast Domains BD3
1136	   and BD1, respectively.  S1 and S2 are assumed to be connected by a
1137	   Link Aggregation Group to the multi-homing PEs, and the multicast
1138	   traffic can use the link to either upstream PE.  The diagram
1139	   illustrates how S1 sends the G-traffic to PE1 and PE1 forwards to the
1140	   remote interested downstream PEs, whereas S2 sends to PE2 and PE2
1141	   forwards further.  In this Hot Standby model, the interested
1142	   downstream PEs will get duplicate G-traffic from the two G-sources
1143	   for the same Single Flow Group.  While the diagram shows that the two
1144	   flows are forwarded by different upstream PEs, the all-active multi-
1145	   homing procedures may cause that the two flows come from the same
1146	   upstream PE.  Therefore, finding out the upstream PE for the flow is
1147	   not enough for the downstream PEs to program the required Reverse
1148	   Path Forwarding check to avoid duplicate packets on the receiver.
1149
1150	                        S1(ESI-1)                S2(ESI-2)
1151	                        |                        |
1152	                        | +----------------------+
1153	                 (S1,G1)| |               (S2,G1)|
1154	                        +----------------------+ |
1155	               PE1      | |             PE2    | |
1156	               +--------v---+           +--------v---+
1157	               |      +---+ |           |      +---+ |  S-PMSI
1158	    S-PMSI     |  +---|BD1| |           |  +---|BD1| |  (*,G1)
1159	    (*,G1)     |  |VRF+---+ |           |  |VRF+---+ |   SFG
1160	     SFG       |+---+  | |  |           |+---+  | |  |   ESI1,2
1161	    ESI1,2 +---||SBD|--+ |  |-----------||SBD|--+ |  |---+  |
1162	       |   |   |+---+    |  |   EVPN    |+---+    |  |   |  v
1163	       v   |   +---------|--+   OISM    +---------|--+   |
1164	           |             |                        |      |
1165	           |             |   (S1,G1)              |      |
1166	    SMET   |   +---------+------------------+     |      | SMET
1167	    (*,G1) |   |                            |     |      | (*,G1)
1168	       ^   |   | +----------------------------+---+      |   ^
1169	       |   |   | |             (S2,G1)      | |          |   |
1170	       |   |   | |                          | |          |   |
1171	       PE3 |   | |          PE4             | |          | PE5
1172	       +-------v-v--+       +------------+  | | +------------+
1173	       |      +---+ |       |      +---+ |  | | |      +---+ |
1174	       |  +---|SBD| +-------|  +---|SBD| |--|-|-|  +---|SBD| |
1175	       |  |VRF+---+ |       |  |VRF+---+ |  | | |  |VRF+---+ |
1176	       |+---+  |    |       |+---+  |    |  | | |+---+  |    |
1177	       ||BD3|--+    |       ||BD4|--+    |  | +->|BD1|--+    |
1178	       |+---+       |       |+---+       |  +--->+---+       |
1179	       +------------+       +------------+      +------------+
1180	         |  ^                                     |  ^
1181	         |  | IGMP                                |  | IGMP
1182	         R1 | J(*,G1)                             R3 | J(*,G1)
1183
1184	     Figure 7: HS Solution for Multi-homed Redundant G-Sources in OISM
1185
1186	   In this scenario, the Hot Standby solution works as follows:
1187
1188	   1.  Configuration of the upstream PEs, PE1 and PE2
1189	       PE1 and PE2 are configured to know that G1 is a Single Flow Group
1190	       for any source (a source prefix length could have been configured
1191	       instead) and the redundant G-sources for G1 use S-ESIs ESI-1 and
1192	       ESI-2 respectively.  Both Ethernet Segments are configured in
1193	       both PEs and their ESI value can be configured or auto-derived.
1194	       The ESI-label values are allocated from a Domain-wide Common
1195	       Block [RFC9573] and are configured either locally or by a
1196	       centralized controller.  We assume ESI-1 is configured to use
1197	       ESI-label-1 and ESI-2 to use ESI-label-2.
1198
1199	       The downstream PEs, PE3, PE4 and PE5 are configured to support
1200	       Hot Standby mode and select the G-source with e.g., lowest ESI
1201	       value.
1202
1203	   2.  PE1 and PE2 advertise S-PMSI A-D (*,G1) and EVPN ES, A-D per ES
1204	       and A-D per EVI routes
1205
1206	       Based on the configuration of step 1, PE1 and PE2 advertise an
1207	       S-PMSI A-D (*,G1) route each.  The route from each of the two PEs
1208	       will include two ESI Label Extended Communities with ESI-1 and
1209	       ESI-2 respectively, as well as route target BD1-RT plus SBD-RT
1210	       and the SFG flag (in the Multicast Flags Extended Community) that
1211	       indicates that (*,G1) is a Single Flow Group.
1212
1213	       In addition, PE1 and PE2 advertise EVPN ES and A-D per ES/EVI
1214	       routes for ESI-1 and ESI-2.  The EVPN A-D per ES and per EVI
1215	       routes will include the route target of the SBD, i.e.,: SBD-RT,
1216	       so that they can be imported by the downstream PEs that are not
1217	       attached to Broadcast Domain BD1, e.g., PE3 and PE4.  The EVPN
1218	       A-D per ES routes will convey ESI-label-1 for ESI-1 (on both PEs)
1219	       and ESI-label-2 for ESI-2 (also on both PEs).
1220
1221	   3.  Processing of EVPN A-D per ES/EVI routes and Reverse Path
1222	       Forwarding check
1223
1224	       PE1 and PE2 received each other's ES and A-D per ES/EVI routes.
1225	       Regular [RFC7432] [RFC8584] procedures will be followed for the
1226	       Designated Forwarder Election and programming of the ESI-labels
1227	       for egress split-horizon filtering.  PE3/PE4 import the EVPN A-D
1228	       per ES/EVI routes in the SBD.  Since PE3 has created a (*,G1)
1229	       state based on local interest, PE3 will add a Reverse Path
1230	       Forwarding check to (*,G1) so that packets coming with ESI-
1231	       label-2 are discarded (lowest ESI value is assumed to give the
1232	       primary S-ES).
1233
1234	   4.  G-traffic forwarding and fault detection
1235	       PE1 receives G-traffic (S1,G1) on ES-1 that is forwarded within
1236	       the context of Broadcast Domain BD1.  Irrespective of the tunnel
1237	       type, PE1 pushes ESI-label-1 at the bottom of the stack and the
1238	       traffic gets to PE3 and PE5 with the mentioned ESI-label (PE4 has
1239	       no local interested receivers).  The G-traffic with ESI-label-1
1240	       passes the Reverse Path Forwarding check and it is forwarded to
1241	       R1.  In the same way, PE2 sends (S2,G1) with ESI-label-2, but
1242	       this G-traffic does not pass the Reverse Path Forwarding check
1243	       and gets discarded at PE3/PE5.
1244
1245	       If the link from S1 to PE1 fails, S1 will forward the (S1,G1)
1246	       traffic to PE2 instead.  PE1 withdraws the EVPN ES and A-D routes
1247	       for ESI-1.  Now both flows will be originated by PE2, however the
1248	       Reverse Path Forwarding checks do not change in PE3/PE5.
1249
1250	       If subsequently, the link from S1 to PE2 fails, PE2 also
1251	       withdraws the EVPN ES and A-D routes for ESI-1.  Since PE3 and
1252	       PE5 have no longer A-D per ES/EVI routes for ESI-1, they
1253	       immediately change the Reverse Path Forwarding check so that
1254	       packets with ESI-label-2 are now accepted.
1255
1256	   Figure 8 illustrates a scenario where sources S1 and S2 are single-
1257	   homed to PE1 and PE2 respectively.  This scenario is a sub-case of
1258	   the one in Figure 7.  Now ES-1 only exists in PE1, hence only PE1
1259	   advertises the EVPN A-D per ES/EVI routes for ESI-1.  Similarly, ES-2
1260	   only exists in PE2 and PE2 is the only PE advertising EVPN A-D routes
1261	   for ESI-2.  The same procedures as in Figure 7 apply to this use-
1262	   case.
1263
1264	                        S1(ESI-1)                S2(ESI-2)
1265	                        |                        |
1266	                 (S1,G1)|                 (S2,G1)|
1267	                        |                        |
1268	               PE1      |               PE2      |
1269	               +--------v---+           +--------v---+
1270	               |      +---+ |           |      +---+ |  S-PMSI
1271	    S-PMSI     |  +---|BD1| |           |  +---|BD2| |  (*,G1)
1272	    (*,G1)     |  |VRF+---+ |           |  |VRF+---+ |   SFG
1273	     SFG       |+---+  | |  |           |+---+  | |  |   ESI2
1274	     ESI1  +---||SBD|--+ |  |-----------||SBD|--+ |  |---+  |
1275	       |   |   |+---+    |  |   EVPN    |+---+    |  |   |  v
1276	       v   |   +---------|--+   OISM    +---------|--+   |
1277	           |             |                        |      |
1278	           |             |   (S1,G1)              |      |
1279	    SMET   |   +---------+------------------+     |      | SMET
1280	    (*,G1) |   |                            |     |      | (*,G1)
1281	       ^   |   | +--------------------------------+----+ |   ^
1282	       |   |   | |             (S2,G1)      |          | |   |
1283	       |   |   | |                          |          | |   |
1284	       PE3 |   | |          PE4             |          | | PE5
1285	       +-------v-v--+       +------------+  |   +------v-----+
1286	       |      +---+ |       |      +---+ |  |   |      +---+ |
1287	       |  +---|SBD| |-------|  +---|SBD| |--|---|  +---|SBD| |
1288	       |  |VRF+---+ |       |  |VRF+---+ |  |   |  |VRF+---+ |
1289	       |+---+  |    |       |+---+  |    |  |   |+---+  |    |
1290	       ||BD3|--+    |       ||BD4|--+    |  +--->|BD1|--+    |
1291	       |+---+       |       |+---+       |      |+---+       |
1292	       +------------+       +------------+      +------------+
1293	         |  ^                                     |  ^
1294	         |  | IGMP                                |  | IGMP
1295	         R1 | J(*,G1)                             R3 | J(*,G1)
1296
1297	     Figure 8: HS Solution for single-homed Redundant G-Sources in OISM

GV> Proposed readability rewrite:

"
5.4. Hot Standby Example in an OISM Network

This section describes the Hot Standby model applied in an Optimized Inter-Subnet Multicast (OISM) network. Figures 7 and 8 illustrate scenarios with multi-homed and single-homed redundant G-sources, respectively.

Multi-Homed Redundant G-Sources

Scenario (Figure 7):
- S1 and S2 are redundant G-sources for the Single Flow Group (*,G1), connected to Broadcast Domain BD1.
- S1 and S2 are all-active multi-homed to upstream PEs (PE1 and PE2).
- Receivers are connected to downstream PEs (PE3 and PE5) in Broadcast Domains BD3 and BD1, respectively.
- S1 and S2 are connected to the multi-homing PEs using a LAG. Multicast traffic can traverse either link.
- In this model, downstream PEs receive duplicate G-traffic for (*,G1) and must use RPF checks to avoid delivering duplicate packets to receivers.

                        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

Procedure:

1. Configuration of Upstream PEs (PE1 and PE2):
   - PE1 and PE2 are configured to recognize (*,G1) as a Single Flow Group.
   - Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 for S2.
   - The Ethernet Segments (ES-1 and ES-2) are configured on both PEs. ESI-labels are allocated from a Domain-wide Common Block (DCB) [RFC9573] - ESI-label-1 for ESI-1 and ESI-label-2 for ESI-2.

2. Advertisement of EVPN Routes:
   - PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), including:
     - Route Targets: BD1-RT and SBD-RT.
     - ESI Label Extended Communities for ESI-1 and ESI-2.
     - The SFG flag indicating that (*,G1) represents a Single Flow Group.
   - EVPN ES and A-D per ES/EVI routes are also advertised for ESI-1 and ESI-2. These include SBD-RT for downstream PE import.

3. RPF Check on Downstream PEs:
   - Downstream PEs (e.g., PE3 and PE5) use EVPN A-D per ES/EVI routes to configure RPF checks.
   - The primary S-ESI is selected based on local policy (e.g., lowest ESI value). For example:
     - Packets with ESI-label-2 are discarded if ESI-label-1 is selected as the primary label.

4. Traffic Forwarding and Fault Detection:
   - PE1 forwards (S1,G1) traffic with ESI-label-1. This traffic passes RPF checks on downstream PEs and is delivered to receivers.
   - PE2 forwards (S2,G1) traffic with ESI-label-2. This traffic fails RPF checks and is discarded.
   - If the link between S1 and PE1 fails, PE1 withdraws EVPN routes for ESI-1. PE2 continues forwarding (S1,G1) traffic using ESI-label-2.
   - If all links to S1 fail, downstream PEs update RPF checks to accept ESI-label-2 traffic.

Single-Homed Redundant G-Sources

Scenario (Figure 8):
- S1 is single-homed to PE1 using ESI-1, and S2 is single-homed to PE2 using ESI-2.
- The scenario is a subset of the multi-homed case. Only one PE advertises EVPN A-D per ES/EVI routes for each S-ESI.

                        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

Procedure:
- The procedures follow the same logic as described in the multi-homed scenario, with the distinction that each ESI is specific to a single PE.

Figures 7 and 8 demonstrate the application of the Hot Standby solution, ensuring seamless traffic forwarding while avoiding duplication in the presence of redundant G-sources.
"

1299	5.5.  Hot Standby Example in a Single-BD Tenant Network
1300
1301	   Irrespective of the redundant G-sources being multi-homed or single-
1302	   homed, if the tenant network has only one Broadcast Domain, e.g.,
1303	   BD1, the procedures of Section 5.4 still apply, only that routes do
1304	   not include any SBD route target, i.e.,: SBD-RT, and all the
1305	   procedures apply to Broadcast Domain BD1 only.

GV> Proposed readability rewrite:

"
5.5. Hot Standby Example in a Single-Broadcast Domain Tenant Network

The Hot Standby procedures described in Section 5.4 apply equally to scenarios where the tenant network comprises a single Broadcast Domain (e.g., BD1), irrespective of whether the redundant G-sources are multi-homed or single-homed.

In such cases:
- The advertised routes do not include the Supplementary Broadcast Domain Route Target (SBD-RT).
- All procedures are confined to the single Broadcast Domain (BD1).

The absence of the SBD simplifies the configuration and limits the scope of the Hot Standby solution to BD1, while maintaining the integrity of the procedures for managing redundant G-sources.
"

1319	7.  IANA Considerations
1320
1321	   IANA is requested to allocate a bit in the Multicast Flags Extended
1322	   Community registry that was introduced by [RFC9251].  This bit
1323	   indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is
1324	   associated with an SFG (Single Flow Group).  This bit is called
1325	   "Single Flow Group" bit and it is defined as follows:
1326
1327	                +=====+===================+===============+
1328	                | Bit | Name              | Reference     |
1329	                +=====+===================+===============+
1330	                | 4   | Single Flow Group | This Document |
1331	                +-----+-------------------+---------------+
1332
1333	                                  Table 1

GV> Oddly on line 1092 the following was written "This document defines the bit 5 in the Flags octet of the ESI Label"
Is this bit 4 or bit 5 that is defined?

Brgds,
G/