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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Gunter,

Thanks, once again. Just published version 13.

I went through sections 4.1 and 5.1 and tried to add as much normative language as possible.

Also, please check out my comments along yours below.

Thanks!
Jorge

From: Gunter van de Velde (Nokia) <[e-mail]>
Date: Friday, December 13, 2024 at 6:09 AM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [Shepherding AD review] review of draft-ietf-bess-evpn-redundant-mcast-source-11
Hi Jorge,

Thanks for the fast update. Some minor follow-up observations. I believe the draft is almost there.

General comment:
===============
The text looks much more readable now, thank you for the update and the additional refinements.

I’d like to suggest a review of Sections 4.1 and 5.1 through the lens of normative language. Specifically, consider whether statements might benefit from using terms like "MUST," "MUST NOT," or "MAY" for clarity. I’ve noticed instances where the word "will" is used, and I wonder if this could lead to potential confusion for implementers.

As a side note, when using the term "SHOULD," it’s helpful to clearly outline the implications and scenarios where conformance would be beneficial for implementers and operators. I’ve tried to identify a few potential candidates for normative keywords in the detailed comment section, but there may be additional instances worth revisiting or updating.

Detailed Comments:
=================

656        *  The Hot Standby solution is recommended for scenarios requiring
657           fast failover times, provided that the additional bandwidth
658           consumption (due to multiple transmissions of SFG packets to
659           downstream PEs) is acceptable.
660
661        *  The Warm Standby solution is more bandwidth-efficient but incurs
662           longer failover times in the event of a G-source or upstream PE
663           failure.  Additionally, only the upstream PEs connected to
664           redundant G-sources for the same SFG need to support the new
665           procedures in the Warm Standby solution.

GV> Maybe flip these two sections around? In the earlier section Warm standby was first discussed and hot standby was discussed last.
[jorge] good point, swapped now.


697        2.  The Flags field within the extended community will be set to
698            '0x00' on transmission and ignored on reception.

GV> Maybe normative language is appropriate here?


“
2.  The Flags field within the extended community MUST be set to
'0x00' on transmission and MUST be ignored on reception.
“
[jorge] sure, added the MUST



724            *  The multicast groups that carry Single Flow Groups (SFGs) in
725               the tenant domain.

GV> s/ Single Flow Groups (SFGs)/SFG/
[jorge] done, thanks


756            *  Includes the following attributes in the S-PMSI A-D route:

GV> Would this not be “MUST include the following attributes ….”?
[jorge] done, thanks


765               -  Multicast Flags Extended Community: includes the SFG flag
766                  to indicate that the route conveys an SFG.

GV> Would this not be “MUST include the SFG flag”?
[jorge] done, thanks


804               1.  A consistent Designated Forwarder Election Algorithm must
805                   be used across all upstream PEs for the Single Forwarder
806                   election.  For instance, in OISM networks, the Default
807                   Designated Forwarder Election Algorithm MUST NOT be used
808                   if redundant G-sources are attached to Broadcast Domains
809                   with different Ethernet Tags.

GV> s/Election Algorithm must/ Election Algorithm MUST/
[jorge] done, thanks


1003    5.1.  Specification

GV> Check this statement for upper/lower case normative language. There are few keywords here in lower case (i.e. must/may), in a procedure section which may be confusing for implementors.
[jorge] ok


1042           *  Advertises an S-PMSI A-D route for each Single Flow Group.
1043              These routes:

GV> maybe: s/Advertises an S-PMSI A-D route/MUST Advertise an S-PMSI A-D route/
[jorge] done, thanks


1045              -  Use the Broadcast Domain Route Target (BD-RT) and, if
1046                 applicable, the Supplementary Broadcast Domain Route Target
1047                 (SBD-RT) so that the routes are imported in all the PEs of
1048                 the tenant domain.

GV> is this a "MAY use the..."?
[jorge] I don’t think we can use a MAY here.


1050              -  Include ESI Label Extended Communities to convey the S-ESI
1051                 labels associated with the Single Flow Group.  These ESI-
1052                 labels are DCB (Domain-wide Common Block) labels and match
1053                 the labels advertised by the EVPN A-D per ES routes for
1054                 each S-ES.

GV> is this "MUST include ESI...."?
[jorge] done, thanks


1056           *  Includes a PMSI Tunnel Attribute as specified in the Warm
1057              Standby procedure.

GV> maybe "MUST include a PMSI..."
[jorge] It’s really a MAY. Added:
“MAY include a PMSI Tunnel Attribute depending on the tunnel type, as specified in the Warm Standby procedure.”


1059           *  Triggers S-PMSI A-D route advertisement based on the SFG
1060              configuration, not the reception of traffic

GV> Is there a MUST and MUST NOT here?
[jorge] added:
“MUST trigger the S-PMSI A-D route advertisement based on the SFG configuration (and not based the reception of traffic).”



1083              -  All packets for a given G-source must carry the same S-ESI
1084                 label.  For example, if two redundant G-sources are multi-
1085                 homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and PE2
1086                 MUST allocate the same ESI label "Lx" for S-ES-1 and they
1087                 MUST allocate the same ESI label "Ly" for S-ES-2.  In
1088                 addition, Lx and Ly MUST be different.

GV> maybe s/must/MUST/
[jorge] done, thx


1102           *  The PEs attached to the same Broadcast Domain of the route
1103              target BD-RT that is included in the EVPN A-D per ES/EVI
1104              routes will process the routes as in [RFC7432] and [RFC8584].
1105              If the receiving PE is attached to the same Ethernet Segment
1106              as indicated in the route, [RFC7432] split-horizon procedures
1107              will be followed and the Designated Forwarder Election
1108              candidate list may be modified as in [RFC8584] if the Ethernet
1109              Segment supports the AC-DF (Attachment Circuit influenced
1110              Designated Forwarder) capability.

GV> maybe s/routes will process the routes as in [RFC7432]/routes MUST process the routes as in [RFC7432]/
GV> maybe s/will be followed and the/MUST be followed and the/
GV> maybe s/candidate list may be modified/candidate list MAY be modified/
[jorge] the above is just to illustrate that there are no changes on that behavior compared to the cited references, so I replaced the “will” is present tense. Hope it is ok.


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

GV> Is there a normative meaning for the "will" used in this procedure?
[jorge] added a MUST


1127       5.  G-traffic forwarding for redundant G-sources and fault detection
1128           *  If there is (*,G) or (S,G) state for the SFG with Output
1129              Interface list entries associated to remote EVPN PEs, upon
1130              receiving G-traffic on a S-ES, the upstream PE will add a
1131              S-ESI label at the bottom of the stack before forwarding the
1132              traffic to the remote EVPN PEs.  This label is allocated from
1133              a Domain-wide Common Block as described in step 3.  If Point-
1134              to-multipoint or BIER PMSIs are used, this is not adding any
1135              new data path procedures on the upstream PEs (except that the
1136              ESI-label is allocated from a Domain-wide Common Block as
1137              described in [RFC9573]).  However, if Ingress Replication or
1138              Assisted Replication are used, this document extends the
1139              [RFC7432] procedures by pushing the S-ESI labels not only on
1140              packets sent to the PEs that shared the ES but to all the PEs
1141              in the tenant domain.  This allows the downstream PEs to
1142              receive all the multicast packets from the redundant G-sources
1143              with a S-ESI label (irrespective of the PMSI type and the
1144              local ESes), and discard any packet that conveys a S-ESI label
1145              different from the primary S-ESI label (that is, the label
1146              associated to the selected primary S-ES), as discussed in step
1147              4.
1148
1149           *  If the last EVPN A-D per EVI or the last EVPN A-D per ES route
1150              for the primary S-ES is withdrawn, the downstream PE will
1151              immediately select a new primary S-ES and will change the
1152              Reverse Path Forwarding check.  Note that if the S-ES is re-
1153              used for multiple tenant domains by the upstream PEs, the
1154              withdrawal of all the EVPN A-D per-ES routes for a S-ES
1155              provides a mass withdrawal capability that makes a downstream
1156              PE change the Reverse Path Forwarding check in all the tenant
1157              domains using the same S-ES.
1158
1159           *  The withdrawal of the last EVPN S-PMSI A-D route for a given
1160              (*,G)/(S,G) that represents a SFG SHOULD make the downstream
1161              PE remove the S-ESI label based Reverse Path Forwarding check
1162              on (*,G)/(S,G).

GV> Something went wrong from my suggestion. What about:

"
G-Traffic Forwarding for Redundant G-Sources and Fault Detection

1)Traffic Forwarding with S-ESI Labels
* When there is an existing (*,G) or (S,G) state for the Source-Forwarding Group (SFG) with output interface list entries associated with remote EVPN PEs, the upstream PE will add an S-ESI label to the bottom of the stack when forwarding G-traffic received on a S-ES. This label is allocated from a domain-wide common block as described in Step 3.

* If point-to-multipoint or BIER PMSIs are used, this procedure does not introduce new data path requirements on the upstream PEs, apart from allocating the S-ESI label from the domain-wide common block as per [RFC9573]. However, when Ingress Replication or Assisted Replication are employed, this document extends the procedures defined in [RFC7432]. In these scenarios, the upstream PE pushes the S-ESI labels on packets not only destined for PEs sharing the ES but also for all PEs within the tenant domain. This ensures that downstream PEs receive all multicast packets from redundant G-sources with an S-ESI label, regardless of the PMSI type or local ESes. Downstream PEs will discard any packet carrying an S-ESI label different from the primary S-ESI label (associated with the selected primary S-ES), as outlined in Step 4.

2)Handling Route Withdrawals and Fault Detection
* If the last EVPN A-D per EVI route or the last EVPN A-D per ES route for the primary S-ES is withdrawn, the downstream PE will immediately select a new primary S-ES and update the Reverse Path Forwarding (RPF) check accordingly.

* For scenarios where the same S-ES is used across multiple tenant domains by the upstream PEs, the withdrawal of all EVPN A-D per-ES routes associated with an S-ES enables a mass withdrawal mechanism. This allows the downstream PE to simultaneously update the RPF check for all tenant domains that rely on the same S-ES.

3)Removal of RPF Checks on S-PMSI Withdrawal
* The withdrawal of the last EVPN S-PMSI A-D route for a given (*,G) or (S,G) that represents an SFG SHOULD result in the downstream PE removing the S-ESI label-based RPF check for that (*,G) or (S,G).
"
[jorge] ok, done


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

GV> Should it be explicitly stated in the text that bit 4 is requested? I understand it is already in the table below.
[jorge] ok, done


1493       IANA is requested to allocate a bit in the ESI Label Extended
1494       Community Flags registry that was introduced by
1495       [I-D.ietf-bess-evpn-mh-split-horizon].  This bit is the ESI-DCB flag
1496       and indicates that the ESI label contained in the ESI Label Extended
1497       Community is a Domain-wide Common Block label.  This bit is defined
1498       as follows:

GV> Should it be explicitly stated in the text that bit 5 is requested? I understand it is already in the table below.
[jorge] ok, done



G/

From: Jorge Rabadan (Nokia) <[e-mail]>
Sent: Thursday, December 12, 2024 7:57 PM
To: Gunter van de Velde (Nokia) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Shepherding AD review] review of draft-ietf-bess-evpn-redundant-mcast-source-11


Hi Gunter,

Thank you very much for your yet another thorough and great review!

Your comments are addressed in version 12, which we just published.
Please see our response to your comments in line below with [jorge].
Thanks!
Jorge


From: Gunter van de Velde (Nokia) <mailto:[e-mail]>
Date: Friday, December 6, 2024 at 8:06 AM
To: mailto:[e-mail] <mailto:[e-mail]>
Cc: mailto:[e-mail] <mailto:[e-mail]>, 'BESS' <mailto:[e-mail]>
Subject: [Shepherding AD review] review of draft-ietf-bess-evpn-redundant-mcast-source-11
# 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
[jorge] the spec supports ipv6 for sure. Added this sentence at the beginning of sections 4 and 5:
“Note that while the examples use IPv4 addresses, the solution supports both IPv4 and IPv6 sources.”


# 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.
[jorge] thanks. I made a few changes to along those lines.


# 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.
[jorge] actually it is a different bit in a different extended community, but the second one was not indicated in the IANA section – it was an oversight, fixed now, thanks!


# 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.
"
[jorge] ok, taken, thanks.


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.
"
[jorge] ok, taken almost verbatim, thanks.



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.
"
[jorge] done, thanks.


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?
[jorge] good point, changed to lower case.


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?
[jorge] the intent is that S-ES (and S-ESI) conveys the fact that it is used for multicast only. So I left it as it was for the moment.


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).
"
[jorge] done, thanks.


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.
"
[jorge] done, thanks.


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).
"
[jorge] done, thanks.



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.
"
[jorge] done, thanks.



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"**".
"
[jorge] done, thanks.



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.
"
[jorge] took it all, and added some minor clarification, thanks.


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.
"
[jorge] took it all, thanks.


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.
"
[jorge] took it all, but changed the structure a little bit


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.
"
[jorge] thanks, I took it all.


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.
"
[jorge] took it all, thanks


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.
"
[jorge] done, thanks!


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.
"
[jorge] took it all with small changes to prevent changing the meaning.


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.
"
[jorge] done, copied almost verbatim


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.
"
[jorge] done, thanks!


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."
[jorge] the above was missing some important information, so I took your suggestions but complete the text with the missing pieces. Thanks!


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.
"
[jorge] added with some modifications.


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.
"
[jorge] done, except that we removed the reference to evpn-bfd, as per the discussion on the mailing list and the request from Sasha.


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.
"
[jorge] I took the text but had to modify some paragraphs. Please check it out.


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.
"
[jorge] took it all, thx


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?
[jorge] as discussed at the top, it was an oversight. The new IANA section reflects the two requests now.


Brgds,
G/