Multicast Source Redundancy in EVPNsNokia520 Almanor AvenueSunnyvaleCA94085United States of Americajorge.rabadan@nokia.comNokia520 Almanor AvenueSunnyvaleCA94085United States of Americajayant.kotalwar@nokia.comNokia520 Almanor AvenueSunnyvaleCA94085United States of Americasenthil.sathappan@nokia.comJuniper Networkszzhang@juniper.netJuniper Networkswlin@juniper.net
RTG
bessWarm standbyhot standbyOISMredundant G-sourceSFGSingle Flow GroupIn Ethernet Virtual Private Networks (EVPNs), IP multicast traffic
replication and delivery play a crucial role in enabling efficient and
scalable Layer 2 and Layer 3 services. A common deployment scenario
involves redundant multicast sources that ensure high availability and
resiliency. However, the presence of redundant sources can lead to
duplicate 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.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 has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Background on IP Multicast Delivery in EVPN Networks
. Intra-Subnet IP Multicast Forwarding
. Inter-Subnet IP Multicast Forwarding
. Multi-Homed IP Multicast Sources in EVPN
. The Need for Redundant IP Multicast Sources in EVPN
. Solution Overview
. Warm Standby Solution
. Hot Standby Solution
. Solution Selection
. System Support
. BGP EVPN Extensions
. Single Flow Group Flag in the Multicast Flags Extended Community
. ESI Label Extended Community in S-PMSI A-D Routes
. Warm Standby (WS) Solution for Redundant G-Sources
. Specification
. Warm Standby Example in an OISM Network
. Warm Standby Example in a Single-BD Tenant Network
. Hot Standby Solution for Redundant G-Sources
. Specification
. Extensions for the Advertisement of DCB Labels
. Use of BFD in the HS Solution
. Hot Standby Example in an OISM Network
. Multi-Homed Redundant G-Sources
. Single-Homed Redundant G-Sources
. Hot Standby Example in a Single-BD Tenant Network
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Contributors
Authors' Addresses
IntroductionEthernet Virtual Private Networks (EVPNs)
support both intra-subnet and inter-subnet IP multicast forwarding.
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. ,
on the other hand, defines the procedures for supporting inter-subnet IP
multicast within a tenant network, where the IP multicast source and
receivers of the same multicast flow are connected to different
Broadcast Domains within the same tenant.However, , , and
conventional IP multicast techniques do not provide 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 typically assume that there are no
redundant sources sending identical flows to the same IP multicast
group. In cases where redundant sources do exist, the receiver
application is expected to handle duplicate packets.In conventional IP multicast networks, such as those running Protocol
Independent Multicast (PIM) or Multicast Virtual Private Network
(MVPN) , a workaround is to configure all
redundant sources with the same IP address. This approach ensures that
each receiver gets only one flow because:
The 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 ensure that each LHR or
RP resides on at most one tree.
This workaround, which often uses anycast addresses, is suitable for
Warm Standby (WS) redundancy solutions (). However, it
is not effective for Hot Standby (HS) redundancy scenarios (), 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 be an RP router to create an (S,G) state.This document extends and to address scenarios where IP multicast source
redundancy exists. Specifically, it defines procedures for EVPN Provider Edge (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 and ;
handling redundant sources in other multicast solutions is beyond the
scope of this document.TerminologyThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
BD:
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" also refers to the instantiation of
a Broadcast Domain on an EVPN PE. An EVPN PE can be attached to one
or multiple BDs of the same tenant.
BUM:
Broadcast, Unknown Unicast, and Multicast traffic.
DF:
Designated Forwarder. As defined in , 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 document, a downstream PE is
referred to as the EVPN PE that is connected to the IP Multicast
receivers and gets the IP Multicast flows from remote EVPN PEs.
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 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 attached receivers.
IGMP:
Internet Group Management Protocol .
I-PMSI:
Inclusive Multicast Tree or Inclusive Provider Multicast Service Interface. While defined in , in this document it is only 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.
IMET route:
EVPN Inclusive Multicast Ethernet Tag route,
as in .
MLD:
Multicast Listener Discovery .
MVPN:
Multicast Virtual Private Networks, as in .
OISM:
Optimized Inter-Subnet Multicast, as in .
PE:
Provider Edge.
PIM:
Protocol Independent Multicast, as in .
P-tunnel:
The term "Provider tunnel" refers to the type
of tree employed by an upstream EVPN PE to forward multicast traffic
to downstream PEs. The P-tunnels supported in this document include
Ingress Replication (IR), Assisted Replication (AR) , Bit Indexed Explicit
Replication (BIER) ,
multicast Label Distribution Protocol (mLDP), and
Point-to-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 located in
different Broadcast Domains (BDs) within the same tenant network.
For the purposes of this document, 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 , this term refers to a multicast tree to which
only the PEs interested in a specific Broadcast Domain
belong. In the context of this document, it is specific to EVPN.
Two types of EVPN S-PMSIs are supported:
S-PMSIs with Auto-Discovery routes:
These S-PMSIs
require the upstream PE to advertise S-PMSI Auto-Discovery
(S-PMSI A-D) routes, as described in . Downstream PEs interested in the multicast
traffic join the S-PMSI tree following the procedures specified
in .
S-PMSIs without Auto-Discovery Routes:
These S-PMSIs
do not require the advertisement of S-PMSI A-D routes. Instead,
they rely on the forwarding information provided by
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):
Indicates that any source transmitting
multicast traffic to group G is considered a redundant G-source
for the SFG.
(S,G):
Indicates that S is a prefix of any
length. In this representation, a source is deemed a redundant
G-source for the SFG if its address matches the specified prefix
S.
SMET route:
Selective Multicast Ethernet Tag route, as
in .
(S,G) and (*,G):
Used to describe multicast packets or
multicast state. "S" stands for Source (IP address of the multicast
traffic), and "G" stands for the Group or multicast destination IP
address of the group. An (S,G) multicast packet refers to an IP
packet with source IP address "S" and destination IP address "G",
and it is forwarded on a multicast router if there is a
corresponding state for (S,G). A (*,G) multicast packet refers to an
IP packet with "any" source IP address and a destination IP address
"G", and it is forwarded on a multicast router based on the
existence of the corresponding (*,G) state. The document uses
variations of these terms. For example, (S1,G1) represents the
multicast packets or multicast state for source IP address "S1" and
group IP address "G1".
Upstream PE:
In this document, an upstream PE refers to
either the EVPN PE that is 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 document, wherein the upstream PEs
connected to redundant sources within the same tenant ensure that
only one source of a given flow transmits multicast traffic to the
interested downstream PEs at any given time.
This document also assumes familiarity with the terminology of
, , , , , , , and .Background on IP Multicast Delivery in EVPN NetworksIP 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".Intra-Subnet IP Multicast ForwardingWhen 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 illustrated in :Intra-Subnet IP Multicast
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- - -
Model (a):
IP Multicast Delivery as BUM TrafficThe upstream PE sends the IP Multicast flows to all
downstream PEs, even to PEs with non-interested receivers, such
as, e.g., PE4 in . To optimize this behavior, downstream PEs
can snoop IGMP/MLD messages from receivers to build Layer 2
multicast state. For instance, PE4 could avoid forwarding
(S1,G1) to R3, since R3 has not expressed interest in
(S1,G1).
Model (b):
Optimized Delivery with S-PMSIModel (b) in 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
will forward (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 will advertise an "S-PMSI Auto-Discovery (A-D)" route for
(S1,G1). Downstream PEs, such as PE2 and PE3, will then join the
corresponding multicast tree to receive the flow.
Procedures for Model (b) are specified in and .Inter-Subnet IP Multicast ForwardingWhen 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 with models (a) and (b),
respectively.Inter-Subnet IP Multicast
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- - -
As defined in , 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 .
Inclusive and Selective Multicast Trees
Model (a):
Inclusive Multicast TreeIn 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,
ensuring delivery to interested receivers.
Model (b):
Selective Multicast TreeIn 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 extends the
procedures defined in 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.
Elimination of ComplexityThe inter-subnet multicast mechanism defined in eliminates the need for:
Rendezvous Points (RPs), shared trees, upstream multicast hop
selection, or other complex conventional multicast routing
techniques.
By leveraging the EVPN framework, inter-subnet multicast
forwarding achieves efficient delivery without introducing
unnecessary overhead or dependencies on classic IP multicast
protocols.Multi-Homed IP Multicast Sources in EVPNUnlike conventional multicast routing technologies, multi-homed PEs
connected to the same source do not create IP multicast packet
duplication when utilizing a multi-homed ES. 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 ES (ES-1), with a Link Aggregation
Group (LAG) extending to PE1 and PE2.All-Active Multi-Homing and OISM
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)
When S1 transmits the (S1,G1) flow, SW1 selects a single link
within the all-active ES to forward the flow, as per
. In this example, assuming PE1 is the
receiving PE for BD1, the multicast flow is forwarded
once BD1 establishes multicast state for (S1,G1) or (*,G1). In :
Receiver R1 receives (S1,G1) directly via the IRB (Integrated
Routing and Bridging) interface, defined in , following the procedures in .
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
.
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, as the backup PE can
seamlessly take over forwarding in case of an upstream PE
failure.
This document assumes that multi-homed PEs connected to the same
source always utilize multi-homed ESes.The Need for Redundant IP Multicast Sources in EVPNWhile 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:
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.
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.
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.
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.Solution OverviewAn 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 remainder 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
Warm Standby SolutionThe 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 and .Hot Standby SolutionThe Hot Standby solution relies on downstream PEs to prevent
duplication of SFG packets. Upstream PEs, aware of locally connected
G-sources, append a unique 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:
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 . In ,
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
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
and .Solution SelectionOperators 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.
System SupportThis document does not mandate support for both solutions on a
single system. If one solution is implemented, support for the other
is OPTIONAL.BGP EVPN ExtensionsThis document introduces the following BGP EVPN extensions:Single Flow Group Flag in the Multicast Flags Extended CommunityA 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 ). 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).ESI Label Extended Community in S-PMSI A-D RoutesThe Hot Standby solution requires the advertisement of one or more
ESI Label Extended Communities 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
"0x00" on transmission and MUST be ignored on reception.
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.Warm Standby (WS) Solution for Redundant G-SourcesThis 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.SpecificationThe Warm Standby solution follows these general procedures:
Configuration of the upstream PEsUpstream 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 ():
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 (or 2001:db8::/120), with redundant
G-sources in BD1 and BD2.
Signaling the location of a G-source for an SFGUpon 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.
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 .
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 PEsIf 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
Address field of the S-PMSI A-D route).
Reverse Path Forwarding Checks on the Upstream PEsAll 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.
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.
Single Forwarder Election
Based on the Designated Forwarder Election Extended
Community, PE1 and PE2 perform Single Forwarder election.
Assuming they use Preference-based Election , 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
Non-SF Behavior: PE2 discards all (*,G1)
packets received on its local AC.
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.
Warm Standby Example in a Single-BD Tenant Network
illustrates an example where S1 and S2 are redundant G-sources for the
Single Flow Group (*,G1). In this case, all G-sources and receivers
are connected to the same BD1, and there is no
SBD.WS Solution for Redundant G-Sources in the Same BD
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)
The procedures for the Warm Standby solution in this example are
identical to those described in , with the
following distinction:
Signaling the S-PMSI A-D Routes
Upon receiving traffic for the Single Flow Group (*,G1),
PE1 and PE2 advertise S-PMSI A-D routes.
These routes include only the BD1-RT (Broadcast Domain 1
Route Target) as there is no SBD
in this scenario.
This example represents a specific sub-case of the broader
procedure detailed in , adapted to a single
Broadcast Domain environment. The absence of an SBD simplifies the
configuration, as all signaling remains within the context of BD1.Hot Standby Solution for Redundant G-SourcesThis section specifies the Hot Standby solution for handling
redundant multicast sources (G-sources). The solution supports both IPv4
and IPv6 sources.SpecificationThe 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:
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.
Signaling the location of a G-source for a given SFG and its
association to the local ESesAn 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).
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-1 and S-ES-2, PE1 and
PE2 MUST allocate the same ESI label "Lx" for S-ES-1, and
they MUST allocate the same ESI label "Ly" for S-ES-2. In
addition, Lx and Ly MUST be different.
S-ESI labels are allocated as Domain-wide Common Block
(DCB) labels and follow the procedures in . In addition, the PE indicates that
these ESI labels are DCB labels by using the extensions
described in .
Processing of EVPN A-D per ES/EVI routes and Reverse Path
Forwarding check on the downstream PEsThe
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 and
. If the receiving PE is attached to
the same ES as indicated in the route, split-horizon procedures are followed and
the DF Election candidate list is modified
as in 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.
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 ). However, when IR or AR
are employed, this document extends
the procedures defined in . 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.
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).
This document supports the use of Context-Specific Label Space ID Extended
Communities, as described in , 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.Extensions for the Advertisement of DCB LabelsDCB labels are specified in , and this document makes use of them as outlined in
. 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:
DCB-allocated ESI labels MAY be used with IR
tunnels and
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:ESI Label Extended Community
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
The ESI label is encoded in an ESI Label Extended Community
with the ESI-DCB-flag set.
The ESI label is signaled by a PE that has advertised a PMSI
label that is a DCB label.
As in , 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.Use of BFD in the HS SolutionIn 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 ,
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 are followed to bootstrap
multipoint BFD sessions on the downstream PEs.
Hot Standby Example in an OISM NetworkThis section describes the Hot Standby model applied in an Optimized Inter-Subnet Multicast
(OISM) network. Figures
and
illustrate scenarios with multi-homed and single-homed redundant
G-sources, respectively.Multi-Homed Redundant G-SourcesScenario ():
S1 and S2 are redundant G-sources for the Single Flow Group
(*,G1), connected to BD1.
S1 and S2 are all-active multi-homed to upstream PEs (PE1 and
PE2).
Receivers are connected to downstream PEs (PE3 and PE5) in
BD3 and BD1, respectively.
S1 and S2 are connected to the multi-homing PEs using a LAG.
Multicast traffic can traverse either link.
In this model, downstream PEs receive duplicate G-traffic for
(*,G1) and must use Reverse Path Forwarding checks to avoid
delivering duplicate packets to receivers.
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 are allocated from a
DCB - 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 indicating that (*,G1) represents a
Single Flow Group.
EVPN ES and A-D per ES/EVI routes are also advertised for
ESI-1 and ESI-2. These include SBD-RT for downstream PE
import. 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).
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 and .
PE3/PE4 import the EVPN A-D per ES/EVI routes in the SBD;
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 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.
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 downstream PEs (PE3 and
PE5, since PE4 has no local interested receivers) and is
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 is 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 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.
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.
Single-Homed Redundant G-SourcesScenario ():
S1 is single-homed to PE1 using ESI-1, and S2 is single-homed
to PE2 using ESI-2.
The scenario is a subset of the multi-homed case. Only one PE
advertises EVPN A-D per ES/EVI routes for each S-ESI.
HS Solution for Single-Homed Redundant G-Sources in OISM
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)
The procedures follow the same logic as described in the
multi-homed scenario, with the distinction that each ESI is specific
to a single PE.Figures
and
demonstrate the application of the Hot Standby solution, ensuring
seamless traffic forwarding while avoiding duplication in the
presence of redundant G-sources.Hot Standby Example in a Single-BD Tenant NetworkThe Hot Standby procedures described in
apply equally to scenarios where the tenant network comprises a single
Broadcast Domain (e.g., BD1), irrespective of whether the redundant
G-sources are multi-homed or single-homed. In such cases:
The advertised routes do not include the SBD-RT.
All procedures are confined to the single BD1.
The absence of the SBD simplifies the configuration and
limits the scope of the Hot Standby solution to BD1, while maintaining
the integrity of the procedures for managing redundant G-sources.Security ConsiderationsThe same Security Considerations described in are valid for this document.From a security perspective, out of the two methods described in this
document, the Warm Standby method is considered lighter in terms of
control plane, and therefore its impact is low on the processing
capabilities of the PEs. The Hot Standby method adds more burden on the
control plane of all the PEs of the tenant with sources and
receivers.IANA ConsiderationsIANA has allocated bit 4 in the "Multicast Flags Extended
Community" registry that was introduced by . 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" bit, and
it is defined as follows:
Bit
Name
Reference
4
Single Flow Group
This Document
IANA has allocated bit 5 in the "EVPN ESI Label Extended Community Flags" registry that was introduced by . This bit is the ESI-DCB
flag and indicates that the ESI label contained in the ESI Label
Extended Community is a DCB label. This bit is
defined as follows:
Bit
Name
Reference
5
ESI-DCB
This Document
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Multicast in MPLS/BGP IP VPNsIn order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNsThis document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]BGP MPLS-Based Ethernet VPNThis document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Framework for Ethernet VPN Designated Forwarder Election ExtensibilityAn alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).MVPN/EVPN Tunnel Aggregation with Common LabelsThe Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.EVPN Optimized Inter-Subnet Multicast (OISM) ForwardingEthernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple segments. Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single tenant owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter-subnet multicast traffic and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined to be external to the EVPN domain.BGP EVPN Multihoming Extensions for Split-Horizon FilteringAn Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels as well as with MPLS and Segment Routing (SR) tunnels. The multihoming procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multihoming split-horizon procedures designed to prevent looped frames on multihomed Customer Edge (CE) devices: the Ethernet Segment Identifier (ESI) Label-based procedure and the local-bias procedure. The ESI Label-based split-horizon procedure is applied to MPLS-based tunnels such as MPLS over UDP (MPLSoUDP), while the local-bias procedure is used for other tunnels such as Virtual eXtensible Local Area Network (VXLAN) tunnels.Current specifications do not allow operators to choose which split-horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoUDP, MPLS over GRE (MPLSoGRE), Generic Network Virtualization Encapsulation (Geneve), and Segment Routing over IPv6 (SRv6) tunnels. This document updates the EVPN multihoming procedures described in RFCs 7432 and 8365, enabling operators to select the split-horizon procedure that meets their specific requirements.Informative ReferencesBGP/MPLS IP Virtual Private Networks (VPNs)This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS NetworksBit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.Integrated Routing and Bridging in Ethernet VPN (EVPN)Ethernet VPN (EVPN) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.IP Prefix Advertisement in Ethernet VPN (EVPN)The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) ProceduresThis document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432.Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs)Network Virtualization Overlay (NVO) networks using Ethernet VPNs (EVPNs) as their control plane may use trees based on ingress replication or Protocol Independent Multicast (PIM) to convey the overlay Broadcast, Unknown Unicast, or Multicast (BUM) traffic. PIM provides an efficient solution that prevents sending multiple copies of the same packet over the same physical link; however, it may not always be deployed in the NVO network core. Ingress replication avoids the dependency on PIM in the NVO network core. While ingress replication provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of ingress replication trees.Internet Group Management Protocol, Version 3The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376.This document updates RFC 2236 and obsoletes RFC 3376.Multicast Listener Discovery Version 2 (MLDv2) for IPv6This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.This document updates RFC 2710 and obsoletes RFC 3810.Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in point-to-multipoint MPLS Label Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint policies with an SR over MPLS (SR-MPLS) data plane.Furthermore, this document updates RFC 8562 by recommending the use of an IPv6 address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 and discouraging the use of an IPv4 loopback address mapped to IPv6.In addition, this document describes the applicability of LSP Ping (as an in-band solution) and the control plane (as an out-of-band solution) to bootstrap a BFD session. The document also describes the behavior of the active tail for head notification.Preference-Based EVPN Designated Forwarder (DF) ElectionThe Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPNs) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device/network in the case of an All-Active multihoming Ethernet Segment (ES) or BUM and unicast in the case of Single-Active multihoming. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the default DF election algorithm. While the default algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more "deterministic" and user-controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE.This document proposes use of a DF election algorithm that meets the requirements of determinism and operation control. This document updates RFC 8584 by modifying the definition of the DF Election Extended Community.AcknowledgmentsThe authors would like to thank , , , and for their review
and valuable comments. Special thanks to for his excellent review, which significantly enhanced the
document's readability.ContributorsIn addition to the authors listed on the front page, the following
person has significantly contributed to this document:erosen52@gmail.comAuthors' AddressesNokia520 Almanor AvenueSunnyvaleCA94085United States of Americajorge.rabadan@nokia.comNokia520 Almanor AvenueSunnyvaleCA94085United States of Americajayant.kotalwar@nokia.comNokia520 Almanor AvenueSunnyvaleCA94085United States of Americasenthil.sathappan@nokia.comJuniper Networkszzhang@juniper.netJuniper Networkswlin@juniper.net