<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">nbsp " "> <!ENTITYRFC6513 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">zwsp "​"> <!ENTITYRFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">nbhy "‑"> <!ENTITYRFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"> <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC9573 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9573.xml"> <!ENTITY RFC9625 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9625.xml"> <!ENTITY I-D.ietf-mpls-p2mp-bfd SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-p2mp-bfd.xml"> <!ENTITY I-D.ietf-bess-evpn-bfd SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-bfd.xml"> <!ENTITY I-D.ietf-bess-evpn-mh-split-horizon SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-mh-split-horizon.xml"> <!ENTITY RFC9572 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9572.xml"> <!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"> <!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"> <!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"> <!ENTITY RFC7761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"> <!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9135.xml"> <!ENTITY I-D.ietf-bess-evpn-pref-df SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-pref-df.xml"> <!ENTITY RFC3376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"> <!ENTITY RFC3810 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"> <!ENTITY RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"> <!ENTITY RFC9574 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9574.xml">wj "⁠"> ]> <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-bess-evpn-redundant-mcast-source-15" number="9856" ipr="trust200902"submissionType="IETF"> <!-- Generated by id2xml 1.5.0 on 2020-10-30T09:57:27Z --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="no"?> <?rfc text-list-symbols="o*+?> <?rfc toc="yes"?>submissionType="IETF" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version="3"> <front> <title abbrev="EVPN Redundant Sources">Multicast Source Redundancy inEVPN Networks</title>EVPNs</title> <seriesInfo name="RFC" value="9856"/> <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan"> <organization>Nokia</organization> <address> <postal> <street>520 Almanor Avenue</street> <city>Sunnyvale</city> <region>CA</region> <code>94085</code><country>USA</country><country>United States of America</country> </postal> <email>jorge.rabadan@nokia.com</email> </address> </author> <author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar"> <organization>Nokia</organization> <address> <postal> <street>520 Almanor Avenue</street><street>Sunnyvale, CA 94085 USA</street><city>Sunnyvale</city> <region>CA</region> <code>94085</code> <country>United States of America</country> </postal> <email>jayant.kotalwar@nokia.com</email> </address> </author> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> <organization>Nokia</organization> <address> <postal> <street>520 Almanor Avenue</street><street>Sunnyvale, CA 94085 USA</street><city>Sunnyvale</city> <region>CA</region> <code>94085</code> <country>United States of America</country> </postal> <email>senthil.sathappan@nokia.com</email> </address> </author> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <organization abbrev="Juniper">Juniper Networks</organization> <address> <email>zzhang@juniper.net</email> </address> </author> <author fullname="Wen Lin" initials="W." surname="Lin"> <organization abbrev="Juniper">Juniper Networks</organization> <address> <email>wlin@juniper.net</email> </address> </author> <dateday="14" month="February"month="August" year="2025"/><workgroup>BESS Workgroup</workgroup><area>RTG</area> <workgroup>bess</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalablelayer-2Layer 2 andlayer-3Layer 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 IP 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 IP multicast traffic from redundant sources. The proposed mechanisms enhance the 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.</t> </abstract> </front> <middle> <section anchor="sect-1"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Ethernet Virtual Private Networks(EVPN)(EVPNs) <xreftarget="RFC7432"/>target="RFC7432" format="default"/> support both intra-subnet and inter-subnet IP multicast forwarding. <xreftarget="RFC9251"/>target="RFC9251" format="default"/> 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. <xreftarget="RFC9625"/>,target="RFC9625" format="default"/>, 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.</t> <t>However, <xreftarget="RFC9251"/>,target="RFC9251" format="default"/>, <xreftarget="RFC9625"/>,target="RFC9625" format="default"/>, and conventional IP multicast techniques do not provide a solution for scenarios where:<list style="numbers"></t> <ol spacing="normal" type="1"><li> <t>A given multicast group carries multiple flows (i.e., multiple sources are active), and</t> </li> <li> <t>Each receiver should receive only from one source.</t></list></t></li> </ol> <t>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.</t> <t>In conventional IP multicast networks, such as those running Protocol IndependentMulticast (PIM)Multicasts (PIMs) <xreftarget="RFC7761"/>target="RFC7761" format="default"/> or MulticastVPNs (MVPN)Virtual Private Networks (MVPNs) <xreftarget="RFC6513"/>,target="RFC6513" format="default"/>, a workaround is to configure all redundant sources with the same IP address. This approach ensures that each receiver gets only one flow because:<list style="symbols"></t> <ul spacing="normal"> <li> <t>TheRP (Rendezvous Point)Rendezvous Point (RP) in the multicast network always creates the (S,G) state for each source.</t> </li> <li> <t>The Last Hop Router (LHR) may also create the (S,G) state.</t> </li> <li> <t>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.</t></list></t></li> </ul> <t>This workaround, which often uses anycast addresses, is suitable forwarm standbyWarm Standby (WS) redundancy solutions (<xreftarget="sect-4"/>).target="sect-4" format="default"/>). However, it is not effective forhot standbyHot Standby (HS) redundancy scenarios (<xreftarget="sect-5"/>)target="sect-5" format="default"/>), and it 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), there is not necessarily any (S,G) state created for the redundant sources. In such cases, the Last Hop Routers may only have a (*,G) state, and there may not bea Rendezvous Pointan RP router to create an (S,G) state.</t> <t>This document extends <xreftarget="RFC9251"/>target="RFC9251" format="default"/> and <xreftarget="RFC9625"/>target="RFC9625" format="default"/> to address scenarios where IP multicast source redundancy exists. Specifically, it defines procedures for EVPNPEs (ProviderProvider Edgedevices/routers)(PE) devices/routers 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 <xreftarget="RFC9251"/>target="RFC9251" format="default"/> and <xreftarget="RFC9625"/>;target="RFC9625" format="default"/>; handling redundant sources in other multicast solutions is beyond the scope of this document.</t> <section anchor="sect-1.1"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t><t><list style="symbols"> <t>Broadcast Domain (BD): an<dl spacing="normal" newline="false"> <dt>BD:</dt><dd>Broadcast Domain. An emulated Ethernet, such that two systems on the same BD will receive each other's link-local broadcasts. In this document,BD"BD" also refers to the instantiation of a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one or multiple BDs of the sametenant.</t> <t>BUM: Broadcast,tenant.</dd> <dt>BUM:</dt><dd>Broadcast, Unknownunicast,Unicast, and Multicasttraffic.</t> <t>Designated Forwarder (DF): astraffic.</dd> <dt>DF:</dt><dd>Designated Forwarder. As defined in <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, an Ethernet Segment may be multi-homed (attached to more than one PE). An Ethernet Segment may also contain multipleBDs,BDs of one or more EVIs. For each such EVI, one of the PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a givensegment.</t> <t>Downstream PE: insegment.</dd> <dt>Downstream PE:</dt><dd>In thisdocumentdocument, a Downstream PE is referred to as the EVPN PE that is connected to the IP Multicast receivers and gets the IP Multicast flows from remote EVPNPEs.</t> <t>EVI: EVPN Instance.</t> <t>G-traffic:PEs.</dd> <dt>EVI:</dt><dd>EVPN Instance.</dd> <!-- [rfced] We have removed "(IP DA)" as the abbreviation does not seem to be used in this document. DA (by itself) also does not appear. Elsewhere, the text refers to "destination IP address". Are these the same? Should the definition for G-traffic be updated for consistency? Original: * G-traffic: any frame with an IP payload whose IP Destination Address (IP DA) is a multicast groupG.</t> <t>G-source: anyG. Perhaps: G-traffic: Any frame with an IP payload whose destination IP address is a multicast group G. --> <dt>G-traffic:</dt><dd>Any frame with an IP payload whose IP Destination Address is a multicast group G.</dd> <dt>G-source:</dt><dd>Any system sourcing IP multicast traffic to groupG.</t> <t>HotG.</dd> <dt>Hot StandbyRedundancy:Redundancy:</dt><dd>The multicast source redundancy procedure defined in this document, by which the upstream PEs forward the redundant multicast flows to the downstream PEs, and the downstream PEs make sure only one flow is forwarded to the interested attachedreceivers.</t> <t>IGMP: Internetreceivers.</dd> <dt>IGMP:</dt><dd>Internet Group Management Protocol <xreftarget="RFC3376"/>.</t> <t>Inclusivetarget="RFC3376" format="default"/>.</dd> <dt>I-PMSI:</dt><dd>Inclusive Multicast Tree or Inclusive Provider Multicast ServiceInterface (I-PMSI):Interface. While defined in <xreftarget="RFC6513"/>,target="RFC6513" format="default"/>, in this document it isapplicableonly applicable to EVPN and refers to the default multicast tree for a given BD. All the EVPN PEs that are attached to a specific BD belong to the I-PMSI for the BD. The I-PMSI trees are signaled by EVPN Inclusive Multicast Ethernet Tag (IMET)routes.</t> <t>IMET route: EVPNroutes.</dd> <dt>IMET route:</dt><dd>EVPN Inclusive Multicast Ethernet Tag route, as in <xreftarget="RFC7432"/>.</t> <t>MLD: Multicasttarget="RFC7432" format="default"/>.</dd> <dt>MLD:</dt><dd>Multicast Listener Discovery <xreftarget="RFC3810"/>.</t> <t>MVPN: Multicasttarget="RFC3810" format="default"/>.</dd> <dt>MVPN:</dt><dd>Multicast Virtual Private Networks, as in <xreftarget="RFC6513"/>.</t> <t>OISM: Optimizedtarget="RFC6513" format="default"/>.</dd> <dt>OISM:</dt><dd>Optimized Inter-Subnet Multicast, as in <xreftarget="RFC9625"/>.</t> <t>PE: Provider Edge.</t> <t>PIM: Protocoltarget="RFC9625" format="default"/>.</dd> <dt>PE:</dt><dd>Provider Edge.</dd> <dt>PIM:</dt><dd>Protocol Independent Multicast, as in <xreftarget="RFC7761"/>.</t> <t>P-tunnel: Thetarget="RFC7761" format="default"/>.</dd> <dt>P-tunnel:</dt><dd>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) <xreftarget="RFC9574"/>,target="RFC9574" format="default"/>, Bit Indexed Explicit Replication (BIER) <xreftarget="RFC8296"/>,target="RFC8296" format="default"/>, multicast Label Distribution Protocol (mLDP), andPoint-to-Multi-Point Resource Reservation Protocol withPoint-to-Multipoint (P2MP) RSVP - Traffic Engineeringextensions (P2MP RSVP-TE).</t> <t>Redundant G-source: A(RSVP-TE) extensions.</dd> <dt>Redundant G-source:</dt><dd>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 assumednotto not exhibit "bursty" trafficbehavior.</t> <t>S-ESbehavior.</dd> <dt>S-ES andS-ESI: multicastS-ESI:</dt><dd>Multicast Source Ethernet Segment and multicast Source Ethernet Segment Identifier. The Ethernet Segment and Ethernet Segment Identifier associated to aG-source.</t> <t>SelectiveG-source.</dd> <dt>S-PMSI:</dt><dd><t>Selective Multicast Tree or Selective Provider Multicast ServiceInterface (S-PMSI):Interface. As defined in <xreftarget="RFC6513"/>,target="RFC6513" format="default"/>, 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 aresupported:<list style="symbols"> <t>S-PMSIssupported:</t> <dl spacing="normal" newline="false"> <dt>S-PMSIs with Auto-DiscoveryRoutes: Theseroutes:</dt><dd>These S-PMSIs require the upstream PE to advertise S-PMSI Auto-Discovery (S-PMSI A-D) routes, as described in <xreftarget="RFC9572"/>.target="RFC9572" format="default"/>. Downstream PEs interested in the multicast traffic join the S-PMSI tree following the procedures specified in <xreftarget="RFC9572"/>.</t> <t>S-PMSIstarget="RFC9572" format="default"/>.</dd> <dt>S-PMSIs without Auto-DiscoveryRoutes: TheseRoutes:</dt><dd>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).</t> </list></t> <t>SFG (Single(BIER).</dd> </dl> </dd> <dt>SFG:</dt><dd><t>Single FlowGroup):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 twoforms: <list style="symbols"> <t>(*,G): Indicatesforms:</t> <dl spacing="normal" newline="false"> <dt>(*,G):</dt><dd>Indicates that any source transmitting multicast traffic to group G is considered a redundant G-source for theSFG.</t> <t>(S,G): IndicatesSFG.</dd> <dt>(S,G):</dt><dd>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 prefixS.</t> </list></t> <t>SMET route: SelectiveS.</dd> </dl> </dd> <dt>SMET route:</dt><dd>Selective Multicast Ethernet Tag route, as in <xreftarget="RFC9251"/>.</t> <t>(S,G)target="RFC9251" format="default"/>.</dd> <dt>(S,G) and(*,G): used(*,G):</dt><dd>Used to describe multicast packets or multicast state.S"S" stands for Source (IP address of the multicasttraffic)traffic), andG"G" stands for the Group or multicast destination IP address of the group. An (S,G) multicast packet refers to an IP packet with source IP address "S" and destination IP address "G", and it is forwarded on a multicast router if there is a corresponding state for (S,G). A (*,G) multicast packet refers to an IP packet with "any" source IP address and a destination IP address "G", and it is forwarded on a multicast router based on the existence of the corresponding (*,G) state. The document uses variations of these terms. For example, (S1,G1) represents the multicast packets or multicast state for source IP address "S1" and group IP address"G1".</t> <t>Upstream PE: In"G1".</dd> <dt>Upstream PE:</dt><dd>In this document, an Upstream PE refers to either the EVPN PE that iseitherdirectly connected to the IP multicast source oristhe PE closest to the source. The Upstream PE receives IP multicast flows through local Attachment Circuits(ACs).</t> <t>Warm(ACs).</dd> <dt>Warm StandbyRedundancy: ARedundancy:</dt><dd>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 giventime.</t> </list></t>time.</dd> </dl> <t>This document also assumes familiarity with the terminology of <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, <xreftarget="RFC4364"/>,target="RFC4364" format="default"/>, <xreftarget="RFC6513"/>,target="RFC6513" format="default"/>, <xreftarget="RFC6514"/>,target="RFC6514" format="default"/>, <xreftarget="RFC9251"/>,target="RFC9251" format="default"/>, <xreftarget="RFC9625"/>,target="RFC9625" format="default"/>, <xreftarget="RFC9136"/>,target="RFC9136" format="default"/>, and <xreftarget="RFC9572"/>.</t>target="RFC9572" format="default"/>.</t> </section> <section anchor="sect-1.2"title="Backgroundnumbered="true" toc="default"> <name>Background on IP Multicast Delivery in EVPNNetworks">Networks</name> <t>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".</t> <section anchor="sect-1.2.1"title="Intra-subnetnumbered="true" toc="default"> <name>Intra-Subnet IP MulticastForwarding">Forwarding</name> <t>When the source S1 and the receivers interested in G1 are connected to the same BroadcastDomain (BD),Domain, the EVPN network can deliver IP multicast traffic to the receivers using two different approaches, as illustrated in <xreftarget="ure-intra-subnet-ip-multicast"/>:</t>target="ure-intra-subnet-ip-multicast" format="default"/>:</t> <figureanchor="ure-intra-subnet-ip-multicast" title="Intra-subnetanchor="ure-intra-subnet-ip-multicast"> <name>Intra-Subnet IPMulticast"> <artwork><![CDATA[Multicast</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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- - - ]]></artwork> </figure><t><list style="symbols"> <t>Model (a): IP<dl spacing="normal" newline="false"> <dt>Model (a):</dt> <dd> <t>IP Multicast Delivery as BUMTraffic <vspace blankLines="1"/>TheTraffic</t> <t>The upstream PE sends the IP Multicast flows to all downstream PEs, even to PEs with non-interested receivers, such as, e.g., PE4 in <xreftarget="ure-intra-subnet-ip-multicast"/>.target="ure-intra-subnet-ip-multicast" format="default"/>. 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).</t><t>Model (b): Optimized</dd> <dt>Model (b):</dt> <dd> <t>Optimized Delivery withS-PMSI<vspace blankLines="1"/>ModelS-PMSI</t> <t>Model (b) in <xreftarget="ure-intra-subnet-ip-multicast"/>target="ure-intra-subnet-ip-multicast" format="default"/> uses a "Selective Provider Multicast Service Interface (S-PMSI)" to optimize the delivery of the (S1,G1) flow.<list style="symbols"> <t>For</t> <ul spacing="normal"> <li>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 andPE3.</t> <t>IfPE3.</li> <li>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). DownstreamPEsPEs, such as PE2 andPE3PE3, will then join the corresponding multicast tree to receive theflow.</t> </list></t> </list></t>flow.</li> </ul> </dd> </dl> <t>Procedures for Model (b) are specified in <xreftarget="RFC9251"/>.</t>target="RFC9251" format="default"/>.</t> </section> <section anchor="sect-1.2.2"title="Inter-subnetnumbered="true" toc="default"> <name>Inter-Subnet IP MulticastForwarding">Forwarding</name> <t>When the sources 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 <xreftarget="ure-inter-subnet-ip-multicast"/>target="ure-inter-subnet-ip-multicast" format="default"/> with models (a) and (b), respectively.</t> <figureanchor="ure-inter-subnet-ip-multicast" title="Inter-subnetanchor="ure-inter-subnet-ip-multicast"> <name>Inter-Subnet IPMulticast"> <artwork><![CDATA[Multicast</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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- - - ]]></artwork> </figure> <t>As defined in <xreftarget="RFC9625"/>,target="RFC9625" format="default"/>, 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 <xreftarget="ure-inter-subnet-ip-multicast"/>.</t> <t><list style="symbols"> <t>Inclusivetarget="ure-inter-subnet-ip-multicast" format="default"/>.</t> <ul spacing="normal"> <li><t>Inclusive and Selective MulticastTrees<list style="empty"> <t>Model (a):Trees</t> <dl spacing="normal"> <dt>Model (a):</dt><dd><t> Inclusive Multicast Tree</t> <t>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 interestedreceivers.</t> <t>Model (b): Selectivereceivers.</t></dd> <dt>Model (b):</dt><dd><t>Selective Multicast Tree</t> <t>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).</t> </list></t> <t>Advantages(S1,G1).</t></dd> </dl> </li> <li><t>Advantages of <xreftarget="RFC9625"/><list style="empty">target="RFC9625" format="default"/></t> <t><xreftarget="RFC9625"/>target="RFC9625" format="default"/> extends the procedures defined in <xreftarget="RFC9251"/>target="RFC9251" format="default"/> 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 with the SBD Route Target, which are imported by all upstream PEs.</t></list></t> <t>Elimination</li> <li><t>Elimination ofComplexity<list style="empty">Complexity</t> <t>The inter-subnet multicast mechanism defined in <xreftarget="RFC9625"/>target="RFC9625" format="default"/> eliminates the need for: Rendezvous Points(RP),(RPs), Shared trees, Upstream Multicast Hop selection, or other complex conventional multicast routing techniques.</t></list></t> </list>By</li> </ul> <t>By leveraging the EVPN framework, inter-subnet multicast forwarding achieves efficient delivery without introducing unnecessary overhead or dependencies on classic IP multicast protocols.</t> </section> </section> <section anchor="sect-1.3"title="Multi-Homednumbered="true" toc="default"> <name>Multi-Homed IP Multicast Sources inEVPN">EVPN</name> <t>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. <xreftarget="ure-all-active-multi-homing-and-oism"/>target="ure-all-active-multi-homing-and-oism" format="default"/> 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.</t> <figureanchor="ure-all-active-multi-homing-and-oism" title="All-active Multi-homing and OISM"> <artwork><![CDATA[anchor="ure-all-active-multi-homing-and-oism"> <name>All-Active Multi-Homing and OISM</name> <artwork name="" type="" align="left" alt=""><![CDATA[ S1 | v +-----+ | SW1 | +-----+ +---- | | (S1,G1)| +----+ +----+ IGMP/MLD | | 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/MLD | v v | IGMP/MLD J(*,G1) | R2 R3 | J(S1,G1) ]]></artwork> </figure> <t>When S1 transmits the (S1,G1) flow, SW1 selects a single link within the all-active Ethernet Segment to forward the flow, as per <xreftarget="RFC7432"/>.target="RFC7432" format="default"/>. In this example, assuming PE1 is the receiving PE forBroadcast DomainBD1, the multicast flow is forwarded once BD1 establishes multicast state for (S1,G1) or (*,G1). In <xreftarget="ure-all-active-multi-homing-and-oism"/>: <list style="symbols">target="ure-all-active-multi-homing-and-oism" format="default"/>: </t> <ul spacing="normal"> <li> <t>Receiver R1 receives (S1,G1) directly via the IRB (Integrated Routing and Bridging) interface, defined in <xreftarget="RFC9135"/>,target="RFC9135" format="default"/>, following the procedures in <xreftarget="RFC9625"/>.</t>target="RFC9625" format="default"/>.</t> </li> <li> <t>Receivers R2 and R3, upon issuing IGMP/MLD 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 <xreftarget="RFC9625"/>.</t> </list>Requirementstarget="RFC9625" format="default"/>.</t> </li> </ul> <t>Requirements for Multi-Homed IP Multicast Sources:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>When IP multicast source multi-homing is needed, EVPN multi-homed Ethernet SegmentsMUST<bcp14>MUST</bcp14> be used.</t> </li> <li> <t>EVPN multi-homing ensures that only one upstream PE forwards a given multicast flow at a time, preventing packet duplication at downstream PEs.</t> </li> <li> <t>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.</t></list></t></li> </ul> <t>This document assumes that multi-homed PEs connected to the same source always utilize multi-homed Ethernet Segments.</t> </section> <section anchor="sect-1.4"title="Thenumbered="true" toc="default"> <name>The Need for Redundant IP Multicast Sources inEVPN">EVPN</name> <t>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:</t><t><list style="letters"> <t>Redundant<ol type="a" spacing="normal"> <li>Redundant G-sources:redundantRedundant G-sources for an 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 sameSFG.</t> <t>G-sourceSFG.</li> <li>G-source placement:redundantRedundant 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 thetenant.</t> <t>G-sourcetenant.</li> <li>G-source attachment to EVPN PEs:redundantRedundant G-sources may be either single-homed to a single EVPN PE or multi-homed to multiple EVPNPEs.</t> <t>PacketPEs.</li> <li>Packet duplication avoidance:theThe EVPN PEs must ensure that receiver systems do not experience duplicate packets for the sameSFG.</t> </list>ThisSFG.</li> </ol> <t>This framework ensures that EVPN networks can effectively support redundant multicast sources while maintaining high reliability and operational efficiency.</t> </section> </section> <section anchor="sect-2"title="Solution Overview">numbered="true" toc="default"> <name>Solution Overview</name> <t>An 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.</t> <t>This document describes two solutions for handling redundant G-sources:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Warm Standby Solution</t> </li> <li> <t>Hot Standby Solution</t></list></t></li> </ul> <section anchor="sect-2.1"title="Warmnumbered="true" toc="default"> <name>Warm StandbySolution">Solution</name> <t>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 an SFG (*,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:<list style="symbols"> <t>Non-Single</t> <ul spacing="normal"> <li>Non-Single Forwarder Behavior:aA non-Single Forwarder upstream PE discards all (*,G) or (S,G) packets received over its local AttachmentCircuit.</t> <t>SingleCircuit.</li> <li>Single Forwarder Behavior:theThe 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 implementationdetail.</t> </list></t>detail.</li> </ul> <t>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 <xreftarget="sect-3"/>target="sect-3" format="counter"/> and <xreftarget="sect-4"/>.</t>target="sect-4" format="counter"/>.</t> </section> <section anchor="sect-2.2"title="Hotnumbered="true" toc="default"> <name>Hot StandbySolution">Solution</name> <t>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 a Reverse Path Forwarding check on the (*,G) state for the SFG:</t><t><list style="symbols"> <t>Packet<ul spacing="normal"> <li>Packet Filtering:aA downstream PE discards (*,G) packets received from the "wrongG-source."</t> <t>WrongG-source."</li> <li>Wrong G-source Identification:theThe "wrong G-source" is identified using an ESI label that differs from the ESI label associated with the selectedG-source.</t> <t>ESIG-source.</li> <li>ESI Label Usage:inIn this solution, the ESI label is used for "ingress filtering" at the downstream PE, rather than for "egress filtering" as described in <xreftarget="RFC7432"/>.target="RFC7432" format="default"/>. In <xreftarget="RFC7432"/>,target="RFC7432" format="default"/>, 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 downstreamPE.</t> </list></t>PE.</li> </ul> <t>Control plane and data plane extensions to <xreftarget="RFC7432"/>target="RFC7432" format="default"/> 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 Reverse Path Forwarding check for the (*,G) state. These extensions and procedures are described in Sections <xreftarget="sect-3"/>target="sect-3" format="counter"/> and <xreftarget="sect-5"/>.</t>target="sect-5" format="counter"/>.</t> </section> <section anchor="sect-2.3"title="Solution Selection">numbered="true" toc="default"> <name>Solution Selection</name> <t>Operators should select a solution based on their specific requirements:<list style="symbols"></t> <ul spacing="normal"> <li> <t>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.</t> </li> <li> <t>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.</t></list></t></li> </ul> </section> <section anchor="sect-2.4"title="System Support">numbered="true" toc="default"> <name>System Support</name> <t>This document does not mandate support for both solutions on a single system. If one solution is implemented, support for the other isOPTIONAL.</t><bcp14>OPTIONAL</bcp14>.</t> </section> </section> <section anchor="sect-3"title="BGPnumbered="true" toc="default"> <name>BGP EVPNExtensions">Extensions</name> <t>This document introduces the following BGP EVPN extensions:</t> <section anchor="sect-3.1"title="Singlenumbered="true" toc="default"> <name>Single Flow Group Flag in the Multicast Flags ExtendedCommunity">Community</name> <t>A new Single Flow Group (SFG) flag is defined within the Multicast Flags Extended Community. This flagis requested fromhas been registered as bit 4 in theIANA registry for"Multicast Flags ExtendedCommunity Flag Values".Community" registry (see <xref target="sfg"/>). The SFG flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single Flow Group information in theNLRI (BGPBGP EVPN Network Layer ReachabilityInformation).</t>Information (NLRI).</t> </section> <section anchor="sect-3.2"title="ESInumbered="true" toc="default"> <name>ESI Label Extended Community in S-PMSI A-DRoutes">Routes</name> <t>The Hot Standby solution requires the advertisement of one or more ESI Label Extended Communities <xreftarget="RFC7432"/>target="RFC7432" format="default"/> alongside the S-PMSI A-D routes. 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.</t> <t>Key considerations include:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>When advertised with the S-PMSI A-D routes, only the ESI Label value in the extended community is relevant to the procedures defined in this document.</t> </li> <li> <t>The Flags field within the extended communityMUST<bcp14>MUST</bcp14> be set to'0x00'"0x00" on transmission andMUST<bcp14>MUST</bcp14> be ignored on reception.</t></list><xref target="RFC7432"/></li> </ol> <t><xref target="RFC7432" format="default"/> 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 Label values) alongside the EVPN S-PMSI A-D route. These extensions enable the precise encoding and advertisement ofSingle Flow Group-relatedSFG-related information, facilitating efficient multicast traffic handling in EVPN networks.</t> </section> </section> <section anchor="sect-4"title="Warmnumbered="true" toc="default"> <name>Warm Standby (WS) Solution for RedundantG-Sources">G-Sources</name> <t>This section specifies the Warm Standby(WS)solution for handling redundant multicast sources (G-sources). Note that while the examples use IPv4 addresses, the solution supports both IPv4 and IPv6 sources.</t> <section anchor="sect-4.1"title="Specification">numbered="true" toc="default"> <name>Specification</name> <t>The Warm Standby solution follows these general procedures:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>Configuration of the upstreamPEs<vspace blankLines="1"/>UpstreamPEs</t> <t>Upstream PEs, potentially connected to redundant G-sources, are configured to recognize:<list style="symbols"></t> <ul spacing="normal"> <li> <t>The multicast groups that carry an SFG in the tenant domain.</t> </li> <li> <t>The local Broadcast Domains that may host redundant G-sources</t></list>The</li> </ul> <t>The SFG configuration applies to either'any'"any" source, i.e., (*) or to a specific'source prefix'"source prefix" (e.g., "192.0.2.0/30" or "2001:db8::/120"). For instance, if the IPv4 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. In a different example for IPv6, if the prefix is 2001:db8::/120, sources 2001:db8::1 or 2001:db8::2 are considered redundant G-sources for the SFG, but 2001:db8:1::1 isnot.<vspace blankLines="1"/>Examplenot.</t> <t>Example Configuration (<xreftarget="ure-ws-solution-for-redundant-g-sources"/>):<list style="symbols">target="ure-ws-solution-for-redundant-g-sources" format="default"/>):</t> <ul spacing="normal"> <li> <t>PE1 is configured to recognize G1 as an SFG for any source, with potential redundant G-sources attached toBroadcast DomainsBD1 and BD2.</t> </li> <li> <t>Alternatively, PE1 may recognize G1 as an SFG for sources within 192.0.2.0/30 (or 2001:db8::/120), with redundant G-sources in BD1 and BD2.</t></list></t></li> </ul> </li> <li> <t>Signaling the location of a G-source for anSFG<vspace blankLines="1"/>UponSFG</t> <t>Upon receiving the first IP multicast packet for a configured SFG on a Broadcast Domain, an upstream PE (e.g.,PE1):<list style="symbols"> <t>MUSTPE1):</t> <ul spacing="normal"> <li> <t><bcp14>MUST</bcp14> advertise an S-PMSI A-D route for theSFG:<list style="symbols">SFG:</t> <ul spacing="normal"> <li> <t>An (*,G) route if the SFG is configured for any source.</t> </li> <li> <t>An (S,G) route (where S can have any prefix length) if the SFG is configured for a source prefix.</t></list></t> <t>MUST</li> </ul> </li> <li> <t><bcp14>MUST</bcp14> include the following attributes in the S-PMSI A-Droute:<list style="symbols">route:</t> <ul spacing="normal"> <li> <t>Route Targets (RTs):theThe Supplementary Broadcast Domain Route Target (SBD-RT), if applicable, and the Broadcast Domain Route Target (BD-RT) of the Broadcast Domain receiving the traffic. The SBD-RT is needed so that the route is imported by all PEs attached to the tenant domain in an OISM solution.</t> </li> <li> <t>Multicast Flags Extended Community:that MUST<bcp14>MUST</bcp14> include the SFG flag to indicate that the route conveys an SFG.</t> </li> <li> <t>Designated Forwarder Election Extended Community:specifiesSpecifies the algorithm and preferences for the Single Forwarder election, using the Designated Forwarder election defined in <xreftarget="RFC8584"/>.</t> </list></t>target="RFC8584" format="default"/>.</t> </li> </ul> </li> <li> <t>Advertises theroute:<list style="symbols">route:</t> <ul spacing="normal"> <li> <t>Without a PMSI Tunnel Attribute if using Ingress Replication (IR), Assisted Replication (AR), or Bit Indexed Explicit Replication (BIER).</t> </li> <li> <t>With a PMSI Tunnel Attribute for other tunnel types.</t></list></t> <t>MUST</li> </ul> </li> <li> <t><bcp14>MUST</bcp14> withdraw the S-PMSI A-D route when the SFG traffic ceases. A timer isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to detect inactivity and trigger route withdrawal.</t></list></t></li> </ul> </li> <li> <t>Single Forwarder Election on the upstreamPEs<vspace blankLines="1"/>IfPEs</t> <t>If an upstream 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.<list style="symbols"></t> <ul spacing="normal"> <li> <t>Two routes are considered part of the same SFG if they are advertised for the same tenant and matchonin the followingfields:<list style="symbols">fields:</t> <ul spacing="normal"> <li> <t>Multicast Source Length</t> </li> <li> <t>Multicast Source</t> </li> <li> <t>Multicast Group Length</t> </li> <li> <t>Multicast Group</t></list></t></li> </ul> </li> <li> <t>ElectionRules:<list style="numbers">Rules:</t> <ol spacing="normal" type="1"><li> <t>A consistentDesignated ForwarderDF Election AlgorithmMUST<bcp14>MUST</bcp14> be used across all upstream PEs for the Single Forwarder election. In OISM networks, the Default Designated Forwarder Election AlgorithmMUST NOT<bcp14>MUST NOT</bcp14> be used if redundant G-sources are attached to Broadcast Domains with different Ethernet Tags.</t> </li> <li> <t>In case of a mismatch in theDesignated ForwarderDF 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).</t></list></t> </list></t></li> </ol> </li> </ul> </li> <li> <t>Reverse Path Forwarding Checks on UpstreamPEs<vspace blankLines="1"/>AllPEs</t> <t>All PEs with a local G-source for an SFG apply a Reverse Path Forwarding check to the (*,G) or (S,G) state based on the Single Forwarder electionresult:<list style="numbers">result:</t> <ol spacing="normal" type="1"><li> <t>Non-Single Forwarder PEs:MUST<bcp14>MUST</bcp14> discard all (*,G) or (S,G) packets received on local Attachment Circuits.</t> </li> <li> <t>Single Forwarder PEs:MUST<bcp14>MUST</bcp14> forward (*,G) or (S,G) packets received on one (and only one) local Attachment Circuit.</t></list></t> </list></t></li> </ol> </li> </ol> <t>Key Features of the Warm StandbySolution:<list style="symbols">Solution:</t> <ul spacing="normal"> <li> <t>The solution ensures redundancy for SFGs without requiring upgrades to downstream PEs (where no redundant G-sources are connected).</t> </li> <li> <t>Existing procedures for non-SFG G-sources remain unchanged.</t> </li> <li> <t>Redundant G-sources can be either single-homed or multi-homed. Multi-homing does not alter the above procedures.</t></list></t></li> </ul> <t>Examples of the Warm Standby solution are provided in Sections <xreftarget="sect-4.2"/>target="sect-4.2" format="counter"/> and <xreftarget="sect-4.3"/>.</t>target="sect-4.3" format="counter"/>.</t> </section> <section anchor="sect-4.2"title="Warmnumbered="true" toc="default"> <name>Warm Standby Example in an OISMNetwork">Network</name> <t><xreftarget="ure-ws-solution-for-redundant-g-sources"/>target="ure-ws-solution-for-redundant-g-sources" format="default"/> illustrates an example where S1 and S2 are redundant G-sources for the Single Flow Group (*,G1).</t> <figureanchor="ure-ws-solution-for-redundant-g-sources" title="Warmanchor="ure-ws-solution-for-redundant-g-sources"> <name>Warm Standby Solution for RedundantG-Sources"> <artwork><![CDATA[G-Sources</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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/MLD | | IGMP/MLD R1 | J(*,G1) R3| J(*,G1) ]]></artwork> </figure> <t>The Warm Standby procedure is as follows:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>Configuration of the upstream PEs (PE1 andPE2)<vspace blankLines="1"/><list style="symbols">PE2)</t> <ul spacing="normal"> <li> <t>PE1 and PE2 are configured to recognize G1 as a Single Flow Group for any source.</t> </li> <li> <t>Redundant G-sources for G1 may be attached toBroadcast DomainsBD1 (for PE1) and BD2 (for PE2).</t></list></t></li> </ul> </li> <li> <t>Signaling the location of S1 and S2 for(*,G1)<vspace blankLines="1"/>Upon(*,G1)</t> <t>Upon receiving traffic for G1 on a local AttachmentCircuit:<list style="symbols">Circuit:</t> <ul spacing="normal"> <li> <t>PE1 and PE2 originate S-PMSI A-D routes for (*,G1),including:<list style="symbols"> <t>Theincluding:</t> <ul spacing="normal"> <li> <t>the Supplementary Broadcast Domain Route Target (SBD-RT),</t><t>The</li> <li> <t>the Designated Forwarder Election Extended Community, and</t><t>The</li> <li> <t>the SFG flag in the Multicast Flags Extended Community.</t></list></t></li> </ul> </li> <li> <t>These routes indicate the presence of a Single Flow Group.</t></list></t></li> </ul> </li> <li> <t>Single ForwarderElection<vspace blankLines="1"/><list style="symbols">Election</t> <ul spacing="normal"> <li> <t>Based on the Designated Forwarder Election Extended Community, PE1 and PE2 perform Single Forwarder election.</t> </li> <li> <t>Assuming they use Preference-based Election <xreftarget="I-D.ietf-bess-evpn-pref-df"/>,target="RFC9785" format="default"/>, PE1 (with a higher preference) is elected as the Single Forwarder for (*,G1).</t></list></t></li> </ul> </li> <li> <t>Reverse Path Forwarding check on the PEs attached to a redundantG-source<list style="letters">G-source</t> <ol spacing="normal" type="a"><li> <t>Non-Single Forwarder Behavior: PE2 discards all (*,G1) packets received on its local Attachment Circuit.</t> </li> <li> <t>Single Forwarder Behavior: PE1 forwards (*,G1) packets received on one (and only one) local Attachment Circuit.</t></list></t> </list></t> <t>The outcome:<list style="symbols"></li> </ol> </li> </ol> <t>The outcome:</t> <ul spacing="normal"> <li> <t>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.</t> </li> <li> <t>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.</t> </li> <li> <t>As a result, PE2 is promoted to Single Forwarder, ensuring continued delivery of (*,G1) traffic.</t></list></t></li> </ul> </section> <section anchor="sect-4.3"title="Warmnumbered="true" toc="default"> <name>Warm Standby Example in a Single-BD TenantNetwork">Network</name> <t><xreftarget="ure-ws-solution-for-redundant-g-sources-in-the-same-bd"/>target="ure-ws-solution-for-redundant-g-sources-in-the-same-bd" format="default"/> 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 sameBroadcast Domain (BD1),BD1, and there is no Supplementary Broadcast Domain (SBD).</t> <figureanchor="ure-ws-solution-for-redundant-g-sources-in-the-same-bd" title="WSanchor="ure-ws-solution-for-redundant-g-sources-in-the-same-bd"> <name>WS Solution for Redundant G-Sources in thesame BD"> <artwork><![CDATA[Same BD</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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/MLD | | IGMP/MLD R1 | J(*,G1) R3 | J(*,G1) ]]></artwork> </figure> <t>The procedures for the Warm Standby solution in this example are identical to those described in <xreftarget="sect-4.2"/>,target="sect-4.2" format="default"/>, with the followingdistinction:<list style="symbols">distinction:</t> <ul spacing="normal"> <li> <t>Signaling the S-PMSI A-D Routes<list style="symbols"></t> <ul spacing="normal"> <li> <t>Upon receiving traffic for the Single Flow Group (*,G1), PE1 and PE2 advertise S-PMSI A-D routes.</t> </li> <li> <t>These routes include only the BD1-RT (Broadcast Domain 1 Route Target) as there is no Supplementary Broadcast Domain (SBD) in this scenario.</t></list></t> </list></t></li> </ul> </li> </ul> <t>This example represents a specific sub-case of the broader procedure detailed in <xreftarget="sect-4.2"/>,target="sect-4.2" format="default"/>, adapted to a single Broadcast Domain environment. The absence of an SBD simplifies the configuration, as all signaling remains within the context of BD1.</t> </section> </section> <section anchor="sect-5"title="Hotnumbered="true" toc="default"> <name>Hot Standby Solution for RedundantG-Sources">G-Sources</name> <t>This section specifies the Hot Standby solution for handling redundant multicast sources (G-sources). The solution supports both IPv4 and IPv6 sources.</t> <section anchor="sect-5.1"title="Specification">numbered="true" toc="default"> <name>Specification</name> <t>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:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>Configuration ofPEs<vspace blankLines="1"/><list style="symbols">PEs</t> <ul spacing="normal"> <li> <t>Upstream PEs are configured to identify Single Flow Groups in the tenant domain. This includes groups for any source or a source prefix containing redundant G-sources.</t> </li> <li> <t>Each redundant G-sourceMUST<bcp14>MUST</bcp14> be associated with an Ethernet Segment on the upstream PEs. This applies to both single-homed and multi-homed G-sources. For both, single-homed and multi-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.</t> </li> <li> <t>Unlike the Warm Standby solution, the Hot Standby solution requires downstream PEs to support the procedure.</t> </li> <li> <t>Downstream PEs:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Do not need explicit configuration for Single Flow Groups or their ESIs (since they get that information from the upstream PEs).</t> </li> <li> <t>Dynamically select an ESI for each Single Flow Group based on local policy (hence different downstream PEs may select different Ethernet Segment Identifiers) and program a Reverse Path Forwarding check to discard (*,G) or (S,G) packets from other ESIs.</t></list></t> </list></t></li> </ul> </li> </ul> </li> <li> <t>Signaling the location of a G-source for a given SFG and its association to the local EthernetSegments<vspace blankLines="1"/> AnSegments</t> <t>An upstream PE configured for Hot Standby procedures:<list style="symbols"> <t>MUST</t> <ul spacing="normal"> <li> <t><bcp14>MUST</bcp14> advertise an S-PMSI A-D route for each Single Flow Group. Theseroutes:<list style="symbols">routes:</t> <ul spacing="normal"> <li> <t>Use the Broadcast Domain Route Target (BD-RT) and, if applicable, the Supplementary Broadcast Domain Route Target (SBD-RT) so that the routes are imported in all the PEs of the tenant domain.</t><t>MUST</li> <li> <t><bcp14>MUST</bcp14> include ESI Label Extended Communities to convey the S-ESI labels associated with the Single Flow Group. TheseESI-labelsESI labels match the labels advertised by the EVPN A-D per ES routes for each S-ES.</t></list></t> <t>MAY</li> </ul> </li> <li> <t><bcp14>MAY</bcp14> include a PMSI Tunnel Attribute, depending on the tunnel type, as specified in the Warm Standby procedure.</t><t>MUST</li> <li> <t><bcp14>MUST</bcp14> trigger the S-PMSI A-D route advertisement based on the SFG configuration (and not based on the reception of traffic).</t></list></t></li> </ul> </li> <li> <t>Distribution of DCBESI-labelsESI Labels and G-source ESroutes<vspace blankLines="1"/><list style="symbols">routes</t> <ul spacing="normal"> <li> <t>Upstream PEs advertise corresponding EVPNroutes:<list style="symbols">routes:</t> <ul spacing="normal"> <li> <t>EVPN Ethernet Segment(ES)routes for the local S-ESIs. ES routes are used for regular Designated Forwarder Election for the S-ES. This document does not introduce any change in the procedures related to the EVPN ES routes.</t> </li> <li> <t>A-D per EVI and A-D per ES routes for tenant-specific traffic. If the SBD exists, the EVPN A-D per EVI and A-D per ES routesMUST<bcp14>MUST</bcp14> include the route targetSBD-RTSBD-RT, since they have to be imported by all the PEs in the tenant domain.</t></list></t></li> </ul> </li> <li> <t>ESI LabelProcedures:<list style="symbols">Procedures:</t> <ul spacing="normal"> <li> <t>The EVPN A-D per ES routes convey the S-ESI labels that the downstream PEs use to implement Reverse Path Forwarding checks for SFGs.</t> </li> <li> <t>All packets for a given G-sourceMUST<bcp14>MUST</bcp14> carry the same S-ESI label. For example, if two redundant G-sources are multi-homed to PE1 and PE2 via S-ES-1 and S-ES-2, PE1 and PE2MUST<bcp14>MUST</bcp14> allocate the same ESI label "Lx" forS-ES-1S-ES-1, and theyMUST<bcp14>MUST</bcp14> allocate the same ESI label "Ly" for S-ES-2. In addition, Lx and LyMUST<bcp14>MUST</bcp14> be different.</t> </li> <li> <t>S-ESI labels are allocated as Domain-wide Common Block (DCB) labels and follow the procedures in <xreftarget="RFC9573"/>.target="RFC9573" format="default"/>. In addition, the PE indicates that these ESI labels are DCB labels by using the extensions described in <xreftarget="sect-5.2"/>.</t> </list></t> </list></t>target="sect-5.2" format="default"/>.</t> </li> </ul> </li> </ul> </li> <li> <t>Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on the downstreamPEs<vspace blankLines="1"/>ThePEs</t> <t>The EVPN A-D per ES/EVI routes are received and imported in all the PEs in the tenant domain. Downstream PEs process received EVPN A-D per ES/EVI routes based on their configuration:<list style="symbols"></t> <ul spacing="normal"> <li> <t>The PEs attached to the same Broadcast Domain of the route target BD-RT that is included in the EVPN A-D per ES/EVI routes process the routes as in <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and <xreftarget="RFC8584"/>.target="RFC8584" format="default"/>. If the receiving PE is attached to the same Ethernet Segment as indicated in the route,<xref target="RFC7432"/>split-horizon procedures <xref target="RFC7432" format="default"/> are followed and the Designated Forwarder Election candidate list is modified as in <xreftarget="RFC8584"/>target="RFC8584" format="default"/> if the Ethernet Segment supports the AC-DF (Attachment Circuit influenced Designated Forwarder) capability.</t> </li> <li> <t>The PEs that are not attached to the Broadcast Domain identified by theroute targetBD-RT but are attached to the Supplementary Broadcast Domain of the receivedroute target SBD-RT, MUSTSBD-RT <bcp14>MUST</bcp14> import the EVPN A-D per ES/EVI routes and use them for redundant G-source mass withdrawal, as explained later.</t> </li> <li> <t>Upon importing EVPN A-D per ES routes corresponding to different S-ESes, a PEMUST<bcp14>MUST</bcp14> select a primary S-ES based on local policy, and add a Reverse Path Forwarding check to the (*,G) or (S,G) state in the Broadcast Domain or Supplementary Broadcast Domain. This Reverse Path Forwarding check discards all ingress packets to (*,G)/(S,G) that are not received with theESI-labelESI label of the primary S-ES.</t></list></t></li> </ul> </li> <li> <t>G-traffic forwarding for redundant G-sources and faultdetection<vspace blankLines="1"/><list style="symbols">detection</t> <ul spacing="normal"> <li> <t>Traffic Forwarding with S-ESILabels:<list style="symbols">Labels:</t> <ul spacing="normal"> <li> <t>When there is an existing (*,G) or (S,G) state for the 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 an S-ES. This label is allocated from a domain-wide common block as described in Step 3.</t> </li> <li> <!-- [rfced] Should "destinated" be "destined? Original: In these scenarios, the upstream PE pushes the S-ESI labels on packets not only destinated for PEs sharing the ES but also for all PEs within the tenant domain. --> <t>IfPoint-to-multipointpoint-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 <xreftarget="RFC9573"/>).target="RFC9573" format="default"/>). However, when Ingress Replication or Assisted Replication are employed, this document extends the procedures defined in <xreftarget="RFC7432"/>.target="RFC7432" format="default"/>. In these scenarios, the upstream PE pushes the S-ESI labels on packets not only destinated for PEs sharing the ES but also for all PEs within the tenant domain. This ensures that downstream PEs receive all the multicast packets from the 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.</t></list></t></li> </ul> </li> <li> <t>Handling Route Withdrawals and FaultDetection<list style="symbols">Detection</t> <ul spacing="normal"> <li> <t>If the last EVPN A-D per EVI or the last EVPN A-D per ES route for the primary S-ES is withdrawn, the downstream PE will immediately select a new primary S-ES and update the Reverse Path Forwarding check accordingly.</t> </li> <li> <t>For scenarios where the same S-ES is used across multiple tenant domains by the upstream PEs, the withdrawal of all the 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 Reverse Path Forwarding check for all tenant domains that rely on the same S-ES.</t></list></t></li> </ul> </li> <li> <t>Removal of Reverse Path Forwarding Checks on S-PMSIWithdrawal<list style="symbols">Withdrawal</t> <ul spacing="normal"> <li> <t>The withdrawal of the last EVPN S-PMSI A-D route for a given (*,G) or (S,G) that represents an SFGSHOULD<bcp14>SHOULD</bcp14> result in the downstream PE removing the S-ESI label-based Reverse Path Forwarding check for that (*,G) or (S,G).</t></list></t> </list></t> </list></t></li> </ul> </li> </ul> </li> </ol> <!-- [rfced] Since RFC 9573 uses the term "Context-Specific Label Space ID Extended Community" rather than "Context Label Space ID Extended Community", may we update to match? Note this would also update the following terms to the term on the right: context label spaces > context-specific label spaces context label space ID > context-specific label space ID --> <t>This document supports the use of Context Label Space ID Extended Communities, as described in <xreftarget="RFC9573"/>,target="RFC9573" format="default"/>, for scenarios where S-ESI labels are allocated within context label spaces. When the context label space ID extended community is advertised along with the ESI label in an EVPN A-D per ES route, the ESI label is from a context label space identified by the Domain-wide Common Block (DCB) label in the Extended Community.</t> </section> <section anchor="sect-5.2"title="Extensionsnumbered="true" toc="default"> <name>Extensions for the Advertisement of DCBLabels">Labels</name> <t>Domain-wide Common BlockLabelslabels are specified in <xreftarget="RFC9573"/>target="RFC9573" format="default"/>, and this document makes use of them as outlined in <xreftarget="sect-5.1"/>.target="sect-5.1" format="default"/>. <xreftarget="RFC9573"/>target="RFC9573" format="default"/> assumes that Domain-wide Common Block labels are applicable only to Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels. Additionally, it specifies that when a PMSI label is a Domain-wide Common Block label, the ESI label used for multi-homing is also a Domain-wide Common Block label.</t> <t>This document extends the use of DCB-allocated ESI labels with the following provisions:<list style="letters"></t> <ol spacing="normal" type="a"><li> <t>DCB-allocated ESI labelsMAY<bcp14>MAY</bcp14> be used with Ingress Replicationtunnels,tunnels and</t> </li> <li> <t>DCB-allocated ESI labelsMAY<bcp14>MAY</bcp14> be used by PEs that do not use DCB-allocated PMSI labels.</t></list>These</li> </ol> <t>These control plane extensions are indicated in the EVPN A-D per ES routes for the relevant S-ESs by:<list style="numbers"></t> <ol spacing="normal" type="1"><li> <t>Adding the ESI-DCB-flag (Domain-wide Common Block flag) to the ESI Label Extended Community, or</t> </li> <li> <t>Adding the Context Label Space ID extended community</t></list>The</li> </ol> <t>The encoding of the DCB-flag within the ESI Label Extended Community is shown below:</t><t><figure anchor="ESI-label" title="ESI<figure anchor="ESI-label"> <name>ESI Label ExtendedCommunity"> <artwork><![CDATA[Community</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure>This</figure> <t>This document defines the DCB-flag as follows:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Bit 5 of the Flags octet in the ESI Label Extended Community is defined as the ESI-DCB-flag by this document.</t> </li> <li> <t>When the ESI-DCB-flag is set, it indicates that the ESI label is a DCB label.</t></list></t></li> </ul> <t>Criteria for identifying a DCB label:</t> <t>An ESI label is considered a DCB label if either of the following conditions is met:</t><t><list style="letters"><ol spacing="normal" type="a"><li> <t>The ESI label is encoded in an ESI Label Extended Community with the ESI-DCB-flag set.</t> </li> <li> <t>The ESI label is signaled by a PE that has advertised a PMSI label that is a DCB label.</t></list></t></li> </ol> <t>As in <xreftarget="RFC9573"/>target="RFC9573" format="default"/>, this document also permits the use of 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 is from a context label space identified by the DCB label in the Extended Community.</t> </section> <section anchor="sect-5.3"title="Usenumbered="true" toc="default"> <name>Use of BFD in the HSSolution">Solution</name> <t>In addition to utilizing the state of the EVPN A-D per EVI, EVPN A-D perESES, or S-PMSI A-D routes to adjust the Reverse Path Forwarding checks for (*,G) or (S,G) as discussed in <xreftarget="sect-5.1"/>,target="sect-5.1" format="default"/>, the Bidirectional Forwarding Detection (BFD) protocolMAY<bcp14>MAY</bcp14> be employed to monitor the status of the multipoint tunnels used to forward the SFG packets from redundant G-sources.</t> <t>BFDintegration:<list style="symbols">integration:</t> <ul spacing="normal"> <li> <t>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.</t> </li> <li> <t>The procedures outlined in <xreftarget="I-D.ietf-mpls-p2mp-bfd"/>target="RFC9780" format="default"/> are followed to bootstrap multipoint BFD sessions on the downstream PEs.</t></list></t></li> </ul> </section> <section anchor="sect-5.4"title="Hotnumbered="true" toc="default"> <name>Hot Standby Example in an OISMNetwork">Network</name> <t>This section describes the Hot Standby model applied in an Optimized Inter-Subnet Multicast (OISM) network. Figures <xreftarget="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/>target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism" format="counter"/> and <xreftarget="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/>target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism" format="counter"/> illustrate scenarios with multi-homed and single-homed redundant G-sources, respectively.</t> <section anchor="sect-5.4.1"title="Multi-Homednumbered="true" toc="default"> <name>Multi-Homed RedundantG-Sources">G-Sources</name> <t>Scenario (<xreftarget="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/>): <list style="symbols">target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism" format="default"/>): </t> <ul spacing="normal"> <li> <t>S1 and S2 are redundant G-sources for the Single Flow Group (*,G1), connected toBroadcast DomainBD1.</t> </li> <li> <t>S1 and S2 are all-active multi-homed to upstream PEs (PE1 and PE2).</t> </li> <li> <t>Receivers are connected to downstream PEs (PE3 and PE5) inBroadcast DomainsBD3 and BD1, respectively.</t> </li> <li> <t>S1 and S2 are connected to the multi-homing PEs using a LAG. Multicast traffic can traverse either link.</t> </li> <li> <t>In this model, downstream PEs receive duplicate G-traffic for (*,G1) and must use Reverse Path Forwarding checks to avoid delivering duplicate packets to receivers.</t></list></t></li> </ul> <figureanchor="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism" title="HSanchor="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"> <name>Hot Standby Solution forMulti-homedMulti-Homed Redundant G-Sources inOISM"> <artwork><![CDATA[OISM</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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/MLD | | IGMP/MLD R1 | J(*,G1) R3 | J(*,G1) ]]></artwork> </figure> <t>The procedure is as follows:</t><t><list style="numbers"><ol spacing="normal" type="1"><li> <t>Configuration of thePEs:<list style="symbols">PEs:</t> <ul spacing="normal"> <li> <t>PE1 and PE2 are configured to recognize (*,G1) as a Single Flow Group.</t> </li> <li> <t>Redundant G-sources use S-ESIs: ESI-1 for S1 and ESI-2 for S2.</t> </li> <li> <t>The Ethernet Segments (ES-1 and ES-2) are configured on both PEs.ESI-labelsESI labels are allocated from a Domain-wide Common Block (DCB) <xreftarget="RFC9573"/>target="RFC9573" format="default"/> - ESI-label-1 for ESI-1 and ESI-label-2 for ESI-2.</t> </li> <li> <t>The downstreamPEs, PE3, PE4PEs (PE3, PE4, andPE5PE5) are configured to support Hot Standby mode and select the G-source with, e.g., lowest ESI value.</t></list></t></li> </ul> </li> <li> <t>Advertisement of the EVPNroutes:<list style="symbols">routes:</t> <ul spacing="normal"> <li> <t>PE1 and PE2 advertise S-PMSI A-D routes for (*,G1),including:<list style="symbols">including:</t> <ul spacing="normal"> <li> <t>Route Targets: BD1-RT and SBD-RT.</t> </li> <li> <t>ESI Label Extended Communities for ESI-label-1 and ESI-label-2.</t> </li> <li> <t>The SFG flag indicating that (*,G1) represents a Single Flow Group.</t></list></t></li> </ul> </li> <li> <t>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. The EVPN A-D per ES routes contain ESI-label-1 for ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both PEs).</t></list></t></li> </ul> </li> <li> <t>Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on DownstreamPEs:<list style="symbols">PEs:</t> <ul spacing="normal"> <li> <t>PE1 and PE2 receive each other's ES and A-D per ES/EVI routes. Designated Forwarder Election and programming of theESI-labelsESI labels for egress split-horizon filtering follow, as specified in <xreftarget="RFC7432"/>target="RFC7432" format="default"/> and <xreftarget="RFC8584"/>.</t>target="RFC8584" format="default"/>.</t> </li> <li> <t>PE3/PE4 import the EVPN A-D per ES/EVI routes in theSBD,SBD; PE5 imports them in BD1.</t> </li> <li> <t>As downstream PEs, PE3 and PE5 use the EVPN A-D per ES/EVI routes to program Reverse Path Forwarding checks.</t> </li> <li> <t>The primary S-ESI for (*,G1) is selected based on local policy (e.g., lowest ESI value), and therefore packets with ESI-label-2 are discarded if ESI-label-1 is selected as the primary label.</t></list></t></li> </ul> </li> <li> <t>Traffic forwarding and faultdetection:<list style="symbols">detection:</t> <ul spacing="normal"> <li> <t>PE1 receives (S1,G1) traffic and forwards it with ESI-label-1 in the context of BD1. This traffic passes Reverse Path Forwarding checks on downstream PEs (PE3 and PE5, since PE4 has no local interested receivers) and is delivered to receivers.</t> </li> <li> <t>PE2 receives (S2,G1) traffic and forwards it with ESI-label-2. This traffic fails the Reverse Path Forwarding check on PE3 and PE5 and is discarded.</t> </li> <li> <t>If the link between S1 and PE1 fails, PE1 withdraws the EVPN ES and A-D routes for ESI-1. S1 forwards the (S1,G1) traffic to PE2 instead. PE2 continues forwarding (S2,G1) traffic using ESI-label-2 and now also forwards (S1,G1) with ESI-label-1. The Reverse Path Forwarding checks do not change in PE3/PE5.</t> </li> <li> <t>If all links to S1 fail, PE2 also withdraws the EVPN ES and A-D routes for ESI-1 and downstream PEs update the Reverse Path Forwarding checks to accept ESI-label-2 traffic.</t></list></t> </list></t></li> </ul> </li> </ol> </section> <section anchor="sect-5.4.2"title="Single-Homednumbered="true" toc="default"> <name>Single-Homed RedundantG-Sources">G-Sources</name> <t>Scenario (<xreftarget="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/>):<list style="symbols">target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism" format="default"/>):</t> <ul spacing="normal"> <li> <t>S1 is single-homed to PE1 using ESI-1, and S2 is single-homed to PE2 using ESI-2.</t> </li> <li> <t>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.</t></list></t></li> </ul> <figureanchor="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism" title="HSanchor="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"> <name>HS Solution forsingle-homedSingle-Homed Redundant G-Sources inOISM"> <artwork><![CDATA[OISM</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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/MLD | | IGMP/MLD R1 | J(*,G1) R3 | J(*,G1) ]]></artwork> </figure> <t>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.</t><t><xref target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism"/><t>Figures <xref target="ure-hs-solution-for-multi-homed-redundant-g-sources-in-oism" format="counter"/> and <xreftarget="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism"/>target="ure-hs-solution-for-single-homed-redundant-g-sources-in-oism" format="counter"/> demonstrate the application of the Hot Standby solution, ensuring seamless traffic forwarding while avoiding duplication in the presence of redundant G-sources.</t> </section> </section> <section anchor="sect-5.5"title="Hotnumbered="true" toc="default"> <name>Hot Standby Example in a Single-BD TenantNetwork">Network</name> <t>The Hot Standby procedures described in <xreftarget="sect-5.4"/>target="sect-5.4" format="default"/> 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 suchcases:<list style="symbols">cases:</t> <ul spacing="normal"> <li> <t>The advertised routes do not include the Supplementary Broadcast Domain Route Target (SBD-RT).</t> </li> <li> <t>All procedures are confined to the singleBroadcast Domain (BD1).</t> </list>TheBD1.</t> </li> </ul> <t>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.</t> </section> </section> <section anchor="sect-6"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The same Security Considerations described in <xreftarget="RFC9625"/>target="RFC9625" format="default"/> are valid for this document.</t> <t>From a security perspective, out of the two methods described in this document, the Warm Standby method is considered lighter in terms of controlplaneplane, and therefore its impact is low on the processing capabilities of the PEs. The Hot Standby method adds more burden on the control plane of all the PEs of the tenant with sources and receivers.</t> </section> <section anchor="sect-7"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANAis requested to allocatehas allocated bit 4 in theMulticast"Multicast Flags ExtendedCommunityCommunity" registry that was introduced by <xreftarget="RFC9251"/>.target="RFC9251" format="default"/>. This bit indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is associated with an SFG. This bit is called "Single Flow Group"bitbit, and it is defined as follows:</t><texttable> <ttcol>Bit</ttcol> <ttcol>Name</ttcol> <ttcol>Reference</ttcol> <c>4</c> <c>Single<table align="center" anchor="sfg"> <thead> <tr> <th align="left">Bit</th> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">4</td> <td align="left">Single FlowGroup</c> <c>This Document</c> </texttable>Group</td> <td align="left">This Document</td> </tr> </tbody> </table> <t>IANAis requested to allocatehas allocated bit 5 in the "EVPN ESI Label Extended CommunityFlagsFlags" registry that was introduced by <xreftarget="I-D.ietf-bess-evpn-mh-split-horizon"/>.target="RFC9746" format="default"/>. This bit is the ESI-DCB flag and indicates that the ESI label contained in the ESI Label Extended Community is a Domain-wide Common Block label. This bit is defined as follows:</t><texttable> <ttcol>Bit</ttcol> <ttcol>Name</ttcol> <ttcol>Reference</ttcol> <c>5</c> <c>ESI-DCB Flag</c> <c>This Document</c> </texttable><!-- [rfced] Should "Flag" be part of the name? The other registered values do not include "Flag". It seems redundant, since it is a registry of flags. If "Flag" is to be removed, we will ask IANA to update their registry accordingly. Original Table 2: +=====+==============+===============+ | Bit | Name | Reference | +=====+==============+===============+ | 5 | ESI-DCB Flag | This Document | --> <table align="center"> <thead> <tr> <th align="left">Bit</th> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">5</td> <td align="left">ESI-DCB Flag</td> <td align="left">This Document</td> </tr> </tbody> </table> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9625.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8584.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9573.xml"/> <!-- Note to RE and AUTH48 manager draft-ietf-bess-evpn-mh-split-horizon-11 is now RFC 9764. Note: had to add this reference the long way. There was no BibXML for this RFC, so an xi:include would not work. --> <reference anchor="RFC9746" target="https://www.rfc-editor.org/info/rfc9746"> <front> <title>BGP EVPN Multihoming Extensions for Split-Horizon Filtering</title> <author initials='J' surname='Rabadan' fullname='Jorge Rabadan' role="editor"> <organization/> </author> <author initials='K' surname='Nagaraj' fullname='Kiran Nagaraj'> <organization/> </author> <author initials='W' surname='Lin' fullname='Wen Lin'> <organization/> </author> <author initials='A' surname='Sajassi' fullname='Ali Sajassi'> <organization/> </author> <date month='March' year='2025'/> </front> <seriesInfo name="RFC" value="9746"/> <seriesInfo name="DOI" value="10.17487/RFC9746"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9572.xml"/> <!-- [I-D.ietf-bess-evpn-pref-df] --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9785.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <!-- [I-D.ietf-mpls-p2mp-bfd] --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9780.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9135.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9574.xml"/> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thankMankamana Mishra, Ali Sajassi, Greg Mirsky and Sasha Vainshtein<contact fullname="Mankamana Mishra"/>, <contact fullname="Ali Sajassi"/>, <contact fullname="Greg Mirsky"/>, and <contact fullname="Sasha Vainshtein"/> for their review and valuable comments. Special thanks toGunter van<contact fullname="Gunter Van deVeldeVelde"/> for his excellent review, which significantly enhanced thedocument’sdocument's readability.</t> </section> <section anchor="sect-9"title="Contributors">numbered="false" toc="default"> <name>Contributors</name> <t>In addition to the authors listed on the front page, the followingpeople haveperson has significantly contributed to this document:</t><t>Eric<contact fullname="Eric C.Rosen</t> <t>Email: erosen52@gmail.com</t>Rosen"> <address> <email>erosen52@gmail.com</email> </address> </contact> </section></middle> <back> <references title="Normative References"> &RFC7432; &RFC6513; &RFC6514; &RFC9251; &RFC9625; &RFC8584; &RFC2119; &RFC8174; &RFC9573; &I-D.ietf-bess-evpn-mh-split-horizon; </references> <references title="Informative References"> &RFC9136; &RFC9572; &I-D.ietf-bess-evpn-pref-df; &RFC4364; &I-D.ietf-mpls-p2mp-bfd; &RFC7761; &RFC9135; &RFC3376; &RFC3810; &RFC8296; &RFC9574; </references></back> <!-- [rfced] Throughout the text, several abbreviations are introduced but not used or are repeatedly defined. Please consider whether the abbreviated form should be used in most cases once the term has been introduced. For example: Attachment Circuit (AC) Assisted Replication (AR) Bit Indexed Explicit Replication (BIER) Domain-wide Common Block (DCB) Designated Forwarder (DF) Ethernet Segment (ES) Ethernet Segment Identifier (ESI) Inclusive Multicast Ethernet Tag (IMET) Ingress Replication (IR) Supplementary Broadcast Domain (SBD) Supplementary Broadcast Domain Route Target (SBD-RT) Selective Multicast Ethernet Tag (SMET) --> <!-- [rfced] Throughout the text, the following terminology appears to be capitalized inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Downstream vs. downstream ESI Label vs. ESI label Upstream vs. upstream --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>