RFC 9856
Multicast Source Redundancy in EVPNs
Multicast Source Redundancy in EVPNs 🦋
Okay bestie, this is RFC 9856 from the IETF 🌸 It's a Standards Track document, so it's the real deal, not a draft. Written by J. Rabadan (editor), J. Kotalwar, S. Sathappan, Z. Zhang, and W. Lin. In the header, Nokia sits next to Kotalwar and Sathappan, and Juniper sits next to Zhang and Lin. It came out in September 2025, with ISSN 2070-1721 ✨ The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Abstract ✨
Okay so in Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery is literally the key to efficient, scalable Layer 2 and Layer 3 services 🌈 A super common setup has redundant multicast sources, which keeps things highly available and resilient 🫶 BUT, redundant sources can cause duplicate IP multicast traffic to show up in the network, and that means inefficiency and extra overhead 😭
This document specifies extensions to the EVPN multicast procedures so duplicate IP multicast traffic from redundant sources gets suppressed 💅 These mechanisms level up EVPN's ability to deliver multicast efficiently while keeping high availability ⭐ The extensions work across lots of different EVPN deployment scenarios and give guidelines for consistent, predictable behavior over all kinds of network topologies 🎀
Status of This Memo 🌷
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check out Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9856 🧚
Copyright Notice 💜
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License.
Table of Contents 🍓
1. Introduction
1.1. Terminology
1.2. Background on IP Multicast Delivery in EVPN Networks
1.2.1. Intra-Subnet IP Multicast Forwarding
1.2.2. Inter-Subnet IP Multicast Forwarding
1.3. Multi-Homed IP Multicast Sources in EVPN
1.4. The Need for Redundant IP Multicast Sources in EVPN
2. Solution Overview
2.1. Warm Standby Solution
2.2. Hot Standby Solution
2.3. Solution Selection
2.4. System Support
3. BGP EVPN Extensions
3.1. Single Flow Group Flag in the Multicast Flags Extended
Community
3.2. ESI Label Extended Community in S-PMSI A-D Routes
4. Warm Standby (WS) Solution for Redundant G-Sources
4.1. Specification
4.2. Warm Standby Example in an OISM Network
4.3. Warm Standby Example in a Single-BD Tenant Network
5. Hot Standby Solution for Redundant G-Sources
5.1. Specification
5.2. Extensions for the Advertisement of DCB Labels
5.3. Use of BFD in the HS Solution
5.4. Hot Standby Example in an OISM Network
5.4.1. Multi-Homed Redundant G-Sources
5.4.2. Single-Homed Redundant G-Sources
5.5. Hot Standby Example in a Single-BD Tenant Network
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🎀
Okay so Ethernet Virtual Private Networks (EVPNs) [RFC7432] support both intra-subnet and inter-subnet IP multicast forwarding ✨ [RFC9251] lays out the procedures needed to optimize delivery of IP multicast flows when both the sources and the receivers are connected to the same EVPN Broadcast Domain 🦋 Then there's [RFC9625], which defines the procedures for inter-subnet IP multicast inside a tenant network, where the IP multicast source and the receivers of the same multicast flow sit in different Broadcast Domains within the same tenant 💅
BUT, [RFC9251], [RFC9625], and conventional IP multicast techniques don't have a solution for scenarios where:
- A given multicast group carries multiple flows (i.e., multiple sources are active), and
- Each receiver should receive only from one source.
Existing multicast solutions usually assume there are no redundant sources sending identical flows to the same IP multicast group 🙈 When redundant sources do exist, the receiver application is expected to handle the duplicate packets, which is a lot to ask 😭
In conventional IP multicast networks, like the ones running Protocol Independent Multicast (PIM) [RFC7761] or Multicast Virtual Private Network (MVPN) [RFC6513], people often use a workaround: configure all the redundant sources with the same IP address 🧚 This works because:
- The Rendezvous Point (RP) in the multicast network always creates the
(S,G)state for each source. - The Last Hop Router (LHR) may also create the
(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 make sure that each LHR or RP sits on at most one tree.
This workaround, which often uses anycast addresses, is fine for Warm Standby (WS) redundancy solutions (Section 4) ✨ However, it's not effective for Hot Standby (HS) redundancy scenarios (Section 5) 🥀 It also causes problems 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 😬 And in scenarios where multiple multicast sources stream traffic to the same group using EVPN Optimized Inter-Subnet Multicast (OISM), there isn't necessarily any (S,G) state created for the redundant sources. In those cases, the Last Hop Routers may only have a (*,G) state, and there may not be an RP router to create an (S,G) state 💀
This document extends [RFC9251] and [RFC9625] to handle scenarios where IP multicast source redundancy exists 💖 Specifically, it defines procedures for EVPN Provider Edge (PE) devices/routers so receivers don't 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 🫶
Part 1 of 8 💖 more parts coming, so stay tuned bestie!
1.1. Terminology
Okay bestie, first the vocab rules 📜 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, as shown here 💖
- BD: Broadcast Domain 🏠. An emulated Ethernet, so two systems on the same BD receive each other's link-local broadcasts. In this doc, "BD" also means the instantiation of a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one or multiple BDs of the same tenant.
- BUM: Broadcast, Unknown Unicast, and Multicast traffic 📣
- DF: Designated Forwarder 👑. As defined in [RFC7432], an Ethernet Segment (ES) may be multi-homed (attached to more than one PE). An ES may also contain multiple BDs of one or more EVIs. For each such EVI, one of the PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a given segment ✨
- Downstream PE: In this doc, a downstream PE is the EVPN PE that's connected to the IP Multicast receivers and gets the IP Multicast flows from remote EVPN PEs 🎀
- EVI: EVPN Instance 🧚
- G-traffic: Any frame with an IP payload whose destination IP address is a multicast group G 🦋
- G-source: Any system sourcing IP multicast traffic to group G 🌸
- Hot Standby Redundancy: The multicast source redundancy procedure defined in this doc. The upstream PEs forward the redundant multicast flows to the downstream PEs, and the downstream PEs make sure only one flow is forwarded to the interested attached receivers 🔥
- IGMP: Internet Group Management Protocol [RFC9776] 🙈
- I-PMSI: Inclusive Multicast Tree or Inclusive Provider Multicast Service Interface. While defined in [RFC6513], in this doc it only applies to EVPN and refers to the default multicast tree for a given BD. All the EVPN PEs attached to a specific BD belong to the I-PMSI for that BD. The I-PMSI trees are signaled by EVPN Inclusive Multicast Ethernet Tag (IMET) routes 🌈
- IMET route: EVPN Inclusive Multicast Ethernet Tag route, as in [RFC7432] 💜
- MLD: Multicast Listener Discovery [RFC9777] 🍓
- MVPN: Multicast Virtual Private Networks, as in [RFC6513] ⭐
- OISM: Optimized Inter-Subnet Multicast, as in [RFC9625] 💅
- PE: Provider Edge 🫶
- PIM: Protocol Independent Multicast, as in [RFC7761] 🦋
- P-tunnel: The term "Provider tunnel" refers to the type of tree an upstream EVPN PE uses to forward multicast traffic to downstream PEs. The P-tunnels supported in this doc are Ingress Replication (IR), Assisted Replication (AR) [RFC9574], Bit Indexed Explicit Replication (BIER) [RFC8296], multicast Label Distribution Protocol (mLDP), and Point-to-Multipoint (P2MP) RSVP - Traffic Engineering (RSVP-TE) extensions 🚇
- 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 they're located in different Broadcast Domains (BDs) within the same tenant network. For the purposes of this doc, redundant G-sources are assumed to not exhibit "bursty" traffic behavior 🍬
- S-ES and S-ESI: Multicast Source Ethernet Segment and multicast Source Ethernet Segment Identifier. The ES and ESI associated to a G-source 🎯
- S-PMSI: Selective Multicast Tree or Selective Provider Multicast Service Interface. As defined in [RFC6513], this term refers to a multicast tree that only the PEs interested in a specific Broadcast Domain belong to. In the context of this doc, it's 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 don't require advertising S-PMSI A-D routes. Instead, they rely on the forwarding information provided by 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: IR, AR, and BIER 🌙
- 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): Any source transmitting multicast traffic to group G is considered a redundant G-source for the SFG 🫧(S,G):Sis 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🩷
- SMET route: Selective Multicast Ethernet Tag route, as in [RFC9251] 💌
(S,G)and(*,G): Used to describe multicast packets or multicast state. "S" stands for Source (the IP address of the multicast traffic), and "G" stands for the Group or multicast destination IP address. An(S,G)multicast packet is an IP packet with source IP address "S" and destination IP address "G", and it's forwarded on a multicast router if there's corresponding state for(S,G). A(*,G)multicast packet is an IP packet with "any" source IP address and destination IP address "G", and it's forwarded on a multicast router based on the existence of the corresponding(*,G)state. The document uses variations of these terms. For example,(S1,G1)represents the multicast packets or multicast state for source IP address "S1" and group IP address "G1" 🧁- Upstream PE: In this doc, an upstream PE is either the EVPN PE directly connected to the IP multicast source or the PE closest to the source. The upstream PE receives IP multicast flows through local Attachment Circuits (ACs) 🚀
- Warm Standby Redundancy: A multicast source redundancy mechanism defined in this doc, where the upstream PEs connected to redundant sources within the same tenant make sure only one source of a given flow transmits multicast traffic to the interested downstream PEs at any given time 🌤️
This doc also assumes you're familiar with the terminology of [RFC7432], [RFC4364], [RFC6513], [RFC6514], [RFC9251], [RFC9625], [RFC9136], and [RFC9572] 📚
1.2. Background on IP Multicast Delivery in EVPN Networks
IP multicast is the glow-up that lets a single copy of a packet go from a source (S) to a group of receivers (G) along a multicast tree 🌟 In an EVPN tenant domain, the multicast tree can be built whether the source (S) and the receivers for the multicast group (G) are connected to the same Broadcast Domain (BD) or to different Broadcast Domains. The first case is called "Intra-subnet IP Multicast forwarding", and the second is called "Inter-subnet IP Multicast forwarding" 🧠
1.2.1. Intra-Subnet IP Multicast Forwarding
When the source S1 and the receivers interested in G1 are connected to the same Broadcast Domain, the EVPN network can deliver IP multicast traffic to the receivers using two different approaches, as shown 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 MulticastModel (a): IP Multicast Delivery as BUM Traffic 📢
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 Figure 1. To optimize this, 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 hasn't 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 "IR", it forwards (S1,G1) only to downstream PEs that have issued a "SMET" route for (S1,G1), such as PE2 and PE3 🌸
- If PE1 uses a P-tunnel type other than IR (e.g., AR or BIER), PE1 advertises an "S-PMSI Auto-Discovery (A-D)" route for (S1,G1). Downstream PEs, such as PE2 and PE3, then join the corresponding multicast tree to receive the flow 🦋
Procedures for Model (b) are specified in [RFC9251] and [RFC9572] 💖
1.2.2. Inter-Subnet IP Multicast Forwarding 🦋
Okay so, when the sources and receivers live in different BDs inside the same tenant domain, the EVPN network can deliver IP multicast traffic using either Inclusive or Selective Multicast Trees. Figure 2 shows both options: model (a) is the Inclusive one and model (b) is the Selective one. 🌸
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
As defined in [RFC9625], inter-subnet multicast forwarding in EVPN gets optimized by making sure IP multicast flows are sent within the context of the source BD. 💅 If a downstream PE isn't connected to the source BD, the IP multicast flow gets 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 ACs, so interested receivers get it. 🎀
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 SMET routes. If the P-tunnel type is "IR", "AR", or "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 makes sure that every upstream PE attached to a source knows about all downstream PEs within the same tenant domain that have interest in specific flows. This happens through the advertisement of SMET routes with the SBD Route Target, which all upstream PEs import. 🔥
- Elimination of Complexity 🌈
The inter-subnet multicast mechanism defined in [RFC9625] gets rid of the need for: Rendezvous Points (RPs), shared trees, upstream multicast hop selection, or other complex conventional multicast routing techniques. No cap, it's so much less drama. 💀
By leveraging the EVPN framework, inter-subnet multicast forwarding achieves efficient delivery without adding unnecessary overhead or depending on classic IP multicast protocols. Iconic behaviour, honestly. 💖
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 they use a multi-homed ES. Ngl this is one of my favourite parts! 😭 Figure 3 shows the situation, where two multi-homed PEs (PE1 and PE2) are attached to the same source S1. The source S1 connects through a Layer 2 switch (SW1) to an all-active ES (ES-1), with a Link Aggregation Group (LAG) reaching PE1 and PE2.
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)Figure 3: All-Active Multi-Homing and OISM
When S1 transmits the (S1,G1) flow, SW1 selects a single link within the all-active ES to forward the flow, as per [RFC7432]. In this example, assuming PE1 is the receiving PE for BD1, the multicast flow gets forwarded once BD1 establishes multicast state for (S1,G1) or (*,G1). Here's what's happening in Figure 3: 🦋
- Receiver R1 receives
(S1,G1)directly via the IRB (Integrated Routing and Bridging) interface, defined in [RFC9135], following the procedures in [RFC9625]. 🎀 - 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 then 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 ESes 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 ES maintain state for the flow. This allows for immediate failover, since the backup PE can seamlessly take over forwarding if an upstream PE fails. ✨
This document assumes that multi-homed PEs connected to the same source always utilize multi-homed ESes. Bestie, this is the foundation of the whole thing. 👑
1.4. The Need for Redundant IP Multicast Sources in EVPN 🌈
While multi-homing PEs to the same IP multicast G-source gives a certain level of resiliency, multicast applications are often critical in operator networks, so they need a higher level of redundancy. This document assumes the following:
- a. Redundant G-sources: Redundant 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 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. Literally so serious and so cute. 🎀
2. Solution Overview ✨
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. In the rest of this document, some examples use (*,G) state for brevity. Wherever an SFG is represented as (*,G), it should be understood as being interchangeable with (S,G). 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 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:
- Non-Single Forwarder (Non-SF) Behavior: A Non-SF upstream PE discards all
(*,G)or(S,G)packets received over its local AC. 🎀 - Single Forwarder Behavior: The Single Forwarder accepts and forwards
(*,G)or(S,G)packets received on a single local AC for the SFG. If packets are received on multiple local ACs, the Single Forwarder discards packets on all but one. The selection of the AC 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
okay so the Hot Standby solution leans on the downstream PEs to stop SFG packets from getting duplicated 💅 Upstream PEs that know about locally connected G-sources slap a unique ESI label onto the multicast packets for each SFG 🏷️ Then the downstream PEs get SFG packets from every upstream PE attached to the redundant G-sources, and they dodge duplicates by doing a Reverse Path Forwarding 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 ACs 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 Reverse Path Forwarding 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 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. 🤏
- 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. 🍓
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. 🙈
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 has been registered as bit 4 in the "Multicast Flags Extended Community" registry (see Table 1). The SFG flag is set in S-PMSI A-D routes that carry (*,G) or (S,G) Single Flow Group information in the BGP EVPN Network Layer Reachability Information (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 [RFC7432] 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. 📣
Key considerations include: 💭
- 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. 🎯
- The Flags field within the extended community MUST be set to
0x00on transmission and MUST be 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 label values) alongside the EVPN S-PMSI A-D route. These extensions enable the precise encoding and advertisement of SFG-related information, facilitating efficient multicast traffic handling in EVPN networks. 🦋
4. Warm Standby (WS) Solution for Redundant G-Sources ✨
This section specifies the Warm Standby solution for handling redundant multicast sources (G-sources). Note that while the examples use IPv4 addresses, the solution supports both IPv4 and IPv6 sources. 🌈
4.1. Specification
The Warm Standby solution follows these general procedures: 📋
- Configuration of the upstream PEs
Upstream PEs, potentially connected to redundant G-sources, are configured to recognize:
- The multicast groups that carry an SFG in the tenant domain. 🏠
- The local Broadcast Domains that may host redundant G-sources
The SFG configuration applies to either "any" source, i.e., (*) or to a specific "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 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 BD1 and BD2. 🧚
- Alternatively, PE1 may recognize G1 as an SFG for sources within
192.0.2.0/30(or2001:db8::/120), with redundant G-sources in BD1 and BD2. 💜
- Signaling the location of a G-source for an SFG
Upon receiving the first IP multicast packet for a configured SFG on a Broadcast Domain, an upstream PE (e.g., PE1):
- MUST advertise 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.
- An
- MUST include the following attributes in the S-PMSI A-D route:
- Route Targets (RTs): The Broadcast Domain Route Target (BD-RT) of the BD receiving the traffic and, if applicable, the Supplementary Broadcast Domain Route Target (SBD-RT), which is needed so that the route is imported by all PEs attached to the tenant domain in an OISM solution. 🎯
- Multicast Flags Extended Community: MUST include the SFG flag to indicate that the route conveys an SFG. 🚩
- Designated Forwarder Election Extended Community: Specifies the algorithm and preferences for the Single Forwarder election, using the DF election defined in [RFC8584]. 🗳️
- Advertises the route:
- Without a PMSI Tunnel Attribute if using IR, AR, or BIER.
- With a PMSI Tunnel Attribute for other tunnel types.
- MUST withdraw the S-PMSI A-D route when the SFG traffic ceases. A timer is RECOMMENDED to detect inactivity and trigger route withdrawal. ⏱️
- Single Forwarder Election on the upstream PEs
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. 👑
- Two routes are considered part of the same SFG if they are advertised for the same tenant and match in the following fields:
- Multicast Source Length
- Multicast Source
- Multicast Group Length
- Multicast Group
- Election Rules:
- A consistent DF Election Algorithm MUST be used across all upstream PEs for the Single Forwarder election. 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. 🧩
- In case of a mismatch in the DF Election Algorithm or capabilities, the tie-breaker is the lowest PE IP address (as advertised in the
Originator Addressfield of the S-PMSI A-D route). 🥇
- Reverse Path Forwarding Checks on the Upstream PEs
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 election result: 🪞
- Non-SF PEs: MUST discard all
(*,G)or(S,G)packets received on local ACs. 🙅 - Single Forwarder PEs: MUST forward
(*,G)or(S,G)packets received on one (and only one) local AC. 💖
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. 👀
4.2. Warm Standby Example in an OISM Network ✨
Okay bestie, Figure 4 is giving main character energy 🎀 S1 and S2 are both 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/MLD | | IGMP/MLD
R1 | J(*,G1) R3| J(*,G1)Figure 4: Warm Standby Solution for Redundant G-Sources
Here's how the Warm Standby procedure goes 💅
- Configuration of the 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 BD1 (for PE1) and BD2 (for PE2).
- Signaling the location of S1 and S2 for (*,G1)
- Upon receiving traffic for G1 on a local AC:
- PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including:
- the 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.
- PE1 and PE2 originate S-PMSI A-D routes for (*,G1), including:
- Upon receiving traffic for G1 on a local AC:
- Single Forwarder Election
- Based on the Designated Forwarder Election Extended Community, PE1 and PE2 perform Single Forwarder election.
- Assuming they use Preference-based Election [RFC9785], PE1 (with a higher preference) is elected as the Single Forwarder for (*,G1).
- Reverse Path Forwarding check on the PEs attached to a redundant G-source
- a. Non-SF Behavior: PE2 discards all (*,G1) packets received on its local AC.
- b. Single Forwarder Behavior: PE1 forwards (*,G1) packets received on one (and only one) local AC.
The 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 AC 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.
4.3. Warm Standby Example in a Single-BD Tenant Network
Figure 5 shows S1 and S2 as redundant G-sources for the Single Flow Group (*,G1) again 🌸 This time, all G-sources and receivers live in the same BD1, and there is no SBD at all 🙈
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)Figure 5: WS Solution for Redundant G-Sources in the Same BD
The procedures for the Warm Standby solution in this example are identical to those described in Section 4.2, with one twist 💖
- 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 SBD in this scenario.
This example is a specific sub-case of the broader procedure from Section 4.2, just adapted to a single Broadcast Domain environment ✨ No SBD means the config is simpler, since all the signaling stays inside BD1 🧚
5. Hot Standby Solution for Redundant G-Sources ✨
Okay, now we're getting to the Hot Standby solution 🔥 This section specifies it for handling redundant multicast sources (G-sources), and it supports both IPv4 and IPv6 sources 🌈
5.1. Specification ✨
Okay bestie, Hot Standby is the one for when you need FAST failover 🏃💨. If a G-source or an upstream PE goes down, you want to switch over super quick. The catch is that it assumes the extra bandwidth use in the tenant network is totally fine 💅. Here's how it goes:
1. Configuration of PEs
- 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.
- Each redundant G-source MUST be associated with an ES 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. 🔥
- 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 (since they get that information from the upstream PEs). 🫶
- Dynamically select an ESI for each Single Flow Group based on local policy (hence different downstream PEs may select different ESIs) and program a Reverse Path Forwarding check to discard
(*,G)or(S,G)packets from other ESIs.
2. Signaling the location of a G-source for a given SFG and its association to the local ESes
An upstream PE configured for Hot Standby procedures:
- MUST advertise 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 SBD-RT so that the routes are imported in all the PEs of the tenant domain.
- MUST include ESI Label Extended Communities to convey the S-ESI labels associated with the Single Flow Group. These ESI labels match the labels advertised by the EVPN A-D per ES routes for each S-ES. 🌸
- MAY include a PMSI Tunnel Attribute, depending on the tunnel type, as specified in the Warm Standby procedure.
- MUST trigger the S-PMSI A-D route advertisement based on the SFG configuration (and not based on the reception of traffic). 💜
3. Distribution of DCB ESI labels and G-source ES routes
- Upstream PEs advertise corresponding EVPN routes:
- EVPN ES routes for the local S-ESIs. ES routes are used for regular DF Election for the S-ES. This document does not introduce any change in the procedures related to the EVPN ES routes.
- 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 routes MUST include the route target SBD-RT, since they have to be imported by all the PEs in the tenant domain. 🦋
- ESI label procedures:
- 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.
- All packets for a given G-source MUST carry the same S-ESI label. For example, if two redundant G-sources are multi-homed to PE1 and PE2 via
S-ES-1andS-ES-2, PE1 and PE2 MUST allocate the same ESI label "Lx" forS-ES-1, and they MUST allocate the same ESI label "Ly" forS-ES-2. In addition, Lx and Ly MUST be different. ✨ - S-ESI labels are allocated as Domain-wide Common Block (DCB) labels and follow the procedures in [RFC9573]. In addition, the PE indicates that these ESI labels are DCB labels by using the extensions described in Section 5.2.
4. Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on the downstream PEs
The EVPN A-D per ES/EVI routes are received and imported in all the PEs in the tenant domain. Downstream PEs process received EVPN A-D per ES/EVI routes based on their configuration:
- 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 [RFC7432] and [RFC8584]. If the receiving PE is attached to the same ES as indicated in the route, split-horizon procedures [RFC7432] are followed and the DF Election candidate list is modified as in [RFC8584] if the ES supports the AC-DF (AC influenced DF) capability. 🎀
- The PEs that are not attached to the Broadcast Domain identified by the BD-RT but are attached to the SBD of the received SBD-RT MUST import the EVPN A-D per ES/EVI routes and use them for redundant G-source mass withdrawal, as explained later.
- Upon importing EVPN A-D per ES routes corresponding to different S-ESes, a PE MUST 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 SBD. This Reverse Path Forwarding check discards all ingress packets to(*,G)/(S,G)that are not received with the ESI label of the primary S-ES. 👑
5. G-traffic forwarding for redundant G-sources and fault detection
- Traffic forwarding with S-ESI labels:
- 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 DCB 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 DCB as per [RFC9573]). However, when IR or AR 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 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. 🌈
- When there is an existing
- Handling route withdrawals and fault detection:
- 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.
- 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. ⭐
- Removal of Reverse Path Forwarding 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 Reverse Path Forwarding check for that(*,G)or(S,G).
- The withdrawal of the last EVPN S-PMSI A-D route for a given
This document supports the use of Context-Specific Label Space ID Extended Communities, as described in [RFC9573], for scenarios where S-ESI labels are allocated within context-specific label spaces. When the context-specific 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-specific label space identified by the DCB label in the Extended Community. 🧚
5.2. Extensions for the Advertisement of DCB Labels 🌸
DCB labels are specified in [RFC9573], and this document makes use of them as outlined in Section 5.1. [RFC9573] assumes that DCB labels are applicable only to Multipoint-to-Multipoint, Point-to-Multipoint, or BIER tunnels. Additionally, it specifies that when a PMSI label is a DCB label, the ESI label used for multi-homing is also 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 IR tunnels and
- b. DCB-allocated ESI labels MAY be used by PEs that do not use DCB-allocated PMSI labels.
These control plane extensions are indicated in the EVPN A-D per ES routes for the relevant S-ESes by:
- Adding the ESI-DCB-flag (DCB flag) to the ESI label Extended Community, or
- Adding the Context-Specific 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
This document defines the DCB-flag as follows:
- 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.
As in [RFC9573], this document also permits the use of context-specific 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-specific label space identified by the DCB label in the Extended Community. 💜
5.3. Use of BFD in the HS Solution 🔥
In addition to utilizing the state of the EVPN A-D per EVI, EVPN A-D per ES, or S-PMSI A-D routes to adjust the Reverse Path Forwarding checks for (*,G) or (S,G) as discussed in Section 5.1, the Bidirectional Forwarding Detection (BFD) protocol MAY be employed to monitor the status of the multipoint tunnels used to forward the SFG packets from redundant G-sources.
BFD integration:
- The BGP-BFD Attribute is advertised alongside the S-PMSI A-D or IMET routes, depending on whether Inclusive PMSI or Selective PMSI trees are being utilized.
- The procedures outlined in [RFC9780] are followed to bootstrap multipoint BFD sessions on the downstream PEs. 🌈
ohh the Hot Standby example, this part is so good 🧚 let's go!
5.4. Hot Standby Example in an OISM Network 🦋
okay so this section walks through how the Hot Standby model works in an Optimized Inter-Subnet Multicast (OISM) network 💅 Figures 7 and 8 show two setups: one with multi-homed redundant G-sources, and one with single-homed ones. we're giving two looks 👀✨
5.4.1. Multi-Homed Redundant G-Sources 💖
the scenario (Figure 7) goes like this:
- S1 and S2 are redundant G-sources for the Single Flow Group (*,G1), and they're both connected to BD1 🎀
- S1 and S2 are all-active multi-homed to the upstream PEs (PE1 and PE2) 🌸
- receivers hang out behind downstream PEs (PE3 and PE5) in BD3 and BD1, respectively 🧚
- S1 and S2 connect to the multi-homing PEs over a LAG 🔗 so multicast traffic can take either link
- here's the tea: downstream PEs get duplicate G-traffic for (*,G1), so they MUST use Reverse Path Forwarding checks to avoid delivering duplicate packets to receivers 😭
Wait, I need to be precise here: the original says "must", and in the RFC that is a plain lowercase word. It is not a BCP 14 keyword, so I'm keeping it lowercase in the rewrite. Here is the corrected line:
- here's the tea: downstream PEs get duplicate G-traffic for (*,G1), and they must use Reverse Path Forwarding 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/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1)
Figure 7: Hot Standby Solution for Multi-Homed Redundant
G-Sources in OISMokay, here's how the procedure goes, step by step 🫶
- Configuration of the PEs ⚙️
- 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 ESes (ES-1 and ES-2) are configured on both PEs. ESI labels get allocated from a DCB [RFC9573]: ESI-label-1 for ESI-1 and ESI-label-2 for ESI-2 🏷️
- the downstream PEs (PE3, PE4, and PE5) are configured to support Hot Standby mode and select the G-source with, e.g., lowest ESI value 🎯
- Advertisement of the 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-label-1 and ESI-label-2 💜
- the SFG flag, which says (*,G1) is a Single Flow Group 🌈
- EVPN ES and A-D per ES/EVI routes also get advertised for ESI-1 and ESI-2 📮 these include SBD-RT for downstream PE import. the EVPN A-D per ES routes carry ESI-label-1 for ESI-1 (on both PEs) and ESI-label-2 for ESI-2 (also on both PEs)
- PE1 and PE2 advertise S-PMSI A-D routes for (*,G1), including:
- Processing of EVPN A-D per ES/EVI routes and Reverse Path Forwarding check on downstream PEs 🔍
- PE1 and PE2 receive each other's ES and A-D per ES/EVI routes. DF Election and programming of the ESI labels for egress split-horizon filtering follow, as specified in [RFC7432] and [RFC8584] 🙌
- PE3 and PE4 import the EVPN A-D per ES/EVI routes in the SBD, and PE5 imports them in BD1 📥
- as downstream PEs, PE3 and PE5 use the EVPN A-D per ES/EVI routes to program Reverse Path Forwarding checks 🪞
- the primary S-ESI for (*,G1) is picked based on local policy (e.g., lowest ESI value). so packets with ESI-label-2 get discarded if ESI-label-1 is the primary label 🗑️
- Traffic forwarding and fault detection 🚦
- 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 the downstream PEs (PE3 and PE5, since PE4 has no local interested receivers) and gets delivered to receivers 🎉
- 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 gets discarded 🙅♀️
- 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 keeps 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 on PE3/PE5 🔄
- if all links to S1 fail, PE2 also withdraws the EVPN ES and A-D routes for ESI-1, and the downstream PEs update their Reverse Path Forwarding checks to accept ESI-label-2 traffic 💀
5.4.2. 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 🍓
- this 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/MLD | | IGMP/MLD
R1 | J(*,G1) R3 | J(*,G1)
Figure 8: HS Solution for Single-Homed Redundant G-Sources in OISMthe procedures follow the same logic as the multi-homed scenario, with one difference: each ESI is specific to a single PE 🧩
Figures 7 and 8 show the Hot Standby solution in action: seamless traffic forwarding with no duplication, even when you've got redundant G-sources 🦋✨
5.5. Hot Standby Example in a Single-BD Tenant Network 🎀
the Hot Standby procedures from Section 5.4 apply equally to scenarios where the tenant network has a single Broadcast Domain (e.g., BD1), whether the redundant G-sources are multi-homed or single-homed 💜 in that case:
- the advertised routes do not include the SBD-RT 🙈
- all procedures stay confined to the single BD1 🔒
no SBD means simpler config, and it limits the Hot Standby solution to BD1 while still keeping the procedures for managing redundant G-sources intact 🌈
6. Security Considerations 🚨
the same Security Considerations described in [RFC9625] are valid for this document 🔐
from a security perspective, out of the two methods in this document, the Warm Standby method is considered lighter on the control plane, so its impact on PE processing is low 🍃 the Hot Standby method adds more burden on the control plane of all the PEs in the tenant with sources and receivers 😭💀
7. IANA Considerations 📋
IANA has allocated bit 4 in the "Multicast Flags Extended Community" registry introduced by [RFC9251]. this bit indicates that a given (*,G) or (S,G) in an S-PMSI A-D route is associated with an SFG. it's called the "Single Flow Group" bit and is defined like this 🎀
+=====+===================+===============+
| Bit | Name | Reference |
+=====+===================+===============+
| 4 | Single Flow Group | This Document |
+-----+-------------------+---------------+
Table 1IANA has also allocated bit 5 in the "EVPN ESI Label Extended Community Flags" registry introduced by [RFC9746]. this is the ESI-DCB flag, and it indicates that the ESI label in the ESI Label Extended Community is a DCB label. defined like so 🧚
+=====+=========+===============+
| Bit | Name | Reference |
+=====+=========+===============+
| 5 | ESI-DCB | This Document |
+-----+---------+---------------+
Table 28. References 📚
8. References ✨
8.1. Normative References 💖
- [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC6513]: Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
- [RFC6514]: Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
- [RFC7432]: Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
- [RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8584]: Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, <https://www.rfc-editor.org/info/rfc8584>.
- [RFC9251]: Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., and W. Lin, "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, <https://www.rfc-editor.org/info/rfc9251>.
- [RFC9573]: Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", RFC 9573, DOI 10.17487/RFC9573, May 2024, <https://www.rfc-editor.org/info/rfc9573>.
- [RFC9625]: Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan, J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August 2024, <https://www.rfc-editor.org/info/rfc9625>.
- [RFC9746]: Rabadan, J., Nagaraj, K., Lin, W., and A. Sajassi, "BGP EVPN Multihoming Extensions for Split-Horizon Filtering", RFC 9746, DOI 10.17487/RFC9746, March 2025, <https://www.rfc-editor.org/info/rfc9746>.
8.2. Informative References 🦋
- [RFC4364]: Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
- [RFC7761]: Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
- [RFC8296]: Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>.
- [RFC9135]: Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, <https://www.rfc-editor.org/info/rfc9135>.
- [RFC9136]: Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, <https://www.rfc-editor.org/info/rfc9136>.
- [RFC9572]: Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures", RFC 9572, DOI 10.17487/RFC9572, May 2024, <https://www.rfc-editor.org/info/rfc9572>.
- [RFC9574]: Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and A. Sajassi, "Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574, May 2024, <https://www.rfc-editor.org/info/rfc9574>.
- [RFC9776]: Haberman, B., Ed., "Internet Group Management Protocol, Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March 2025, <https://www.rfc-editor.org/info/rfc9776>.
- [RFC9777]: Haberman, B., Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", STD 101, RFC 9777, DOI 10.17487/RFC9777, March 2025, <https://www.rfc-editor.org/info/rfc9777>.
- [RFC9780]: Mirsky, G., Mishra, G., and D. Eastlake 3rd, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025, <https://www.rfc-editor.org/info/rfc9780>.
- [RFC9785]: Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, "Preference-Based EVPN Designated Forwarder (DF) Election", RFC 9785, DOI 10.17487/RFC9785, June 2025, <https://www.rfc-editor.org/info/rfc9785>.
Acknowledgments 🎀
The authors would like to thank Mankamana Mishra, Ali Sajassi, Greg Mirsky, and Sasha Vainshtein for their review and valuable comments. Special thanks to Gunter Van de Velde for his excellent review, which significantly enhanced the document's readability. 🫶
Contributors 🌸
In addition to the authors listed on the front page, the following person has significantly contributed to this document:
- Eric C. Rosen
- Email: erosen52@gmail.com
Authors' Addresses 💜
Jorge Rabadan (editor) Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: jorge.rabadan@nokia.com
Jayant Kotalwar Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: jayant.kotalwar@nokia.com
Senthil Sathappan Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: senthil.sathappan@nokia.com
Zhaohui Zhang Juniper Networks Email: zzhang@juniper.net
Wen Lin Juniper Networks Email: wlin@juniper.net 🦋✨
📦 where this page comes from
- ietf: rfc9856 2025-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms