Multicast Router State Synchronization in EVPN Networks
draft-jot-bess-evpn-mcast-router-sync-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jorge Rabadan , Olivier Dornon , Tanmoy Kundu , Nitsan Dolev Elfassy | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jot-bess-evpn-mcast-router-sync-00
BGP Enabled ServiceS J. Rabadan, Ed.
Internet-Draft O. Dornon
Intended status: Standards Track T. Kundu
Expires: 7 January 2027 Nokia
N. Dolev
Ribbon
6 July 2026
Multicast Router State Synchronization in EVPN Networks
draft-jot-bess-evpn-mcast-router-sync-00
Abstract
Ethernet VPN (EVPN) networks support multicast applications in which
multicast routers and multicast hosts are attached to the same
tenant. Existing specifications define how Provider Edge (PE)
devices synchronize the Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) membership state of multihomed
multicast hosts, and how Optimized Inter-Subnet Multicast (OISM)
forwarding interacts with multicast routers via PIM EVPN Gateways.
However, none of the existing specifications addresses the
synchronization of the state associated with a multicast router (an
IGMP/MLD Querier or a Protocol Independent Multicast (PIM) router)
when that router is multihomed to a set of EVPN PEs. This document
specifies a new EVPN route, the Multicast Router Discovery (MRD)
route, and the procedures to synchronize multicast router state
across the PEs of an Ethernet Segment, for routers attached to
multicast Broadcast Domains or to Layer 3 interfaces.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://jorabada.github.io/draft-evpn-mcast-router-synch/draft-jot-
bess-evpn-mcast-router-sync.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-jot-
bess-evpn-mcast-router-sync/.
Discussion of this document takes place on the BGP Enabled ServiceS
Working Group mailing list (mailto:bess@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/bess/. Subscribe at
https://www.ietf.org/mailman/listinfo/bess/.
Source for this draft and an issue tracker can be found at
https://github.com/jorabada/draft-evpn-mcast-router-synch.
Rabadan, et al. Expires 7 January 2027 [Page 1]
Internet-Draft EVPN Multicast Router July 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 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) 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.3. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6
2. The EVPN Multicast Router Discovery (MRD) Route . . . . . . . 6
2.1. MRD Route Encoding . . . . . . . . . . . . . . . . . . . 6
2.2. PIM Hello Options Sub-TLV . . . . . . . . . . . . . . . . 9
2.3. Route Targets and Advertisement Modes . . . . . . . . . . 10
2.4. Procedures for Advertising the MRD Route . . . . . . . . 11
2.5. Procedures for Receiving and Processing the MRD Route . . 12
3. Synchronization of PIM State on Ethernet Segments . . . . . . 14
3.1. P Flag in the EVPN Route Types 7 and 8 . . . . . . . . . 15
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. EVPN-based IGMP/MLD Proxy . . . . . . . . . . . . . . . . 15
4.2. EVPN Multihoming for Layer 3 Interfaces . . . . . . . . . 16
Rabadan, et al. Expires 7 January 2027 [Page 2]
Internet-Draft EVPN Multicast Router July 2026
4.3. EVPN Multihoming for EVPN Multicast (OISM) . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
EVPN [RFC7432] is widely deployed to provide Layer 2 and Layer 3
connectivity to tenant systems that may be either multicast hosts or
multicast routers. EVPN includes mechanisms to reduce the flooding
of control messages and to make the distribution of multicast state
efficient. In particular, [RFC9251] specifies how IGMP and MLD
membership reports are signaled across the EVPN network using the
Selective Multicast Ethernet Tag (SMET) route, and how the membership
state of a multihomed host is synchronized across the PEs of an
Ethernet Segment (ES) by means of the IGMP/MLD Join Synch and Leave
Synch routes (EVPN route types 7 and 8).
The synchronization procedures in [RFC9251] are defined for
multihomed multicast _hosts_. They do not cover the case in which the
device multihomed to the EVPN PEs is a multicast _router_ that uses
IGMP, MLD, or PIM, and whose router-level state (for example, its
role as an IGMP/MLD Querier, or its PIM neighbor adjacency and
Designated Router (DR) attributes) needs to be consistently presented
by all the PEs of the ES.
This document specifies a solution that extends the EVPN multihoming
state synchronization model from multicast hosts to multicast
routers. The solution introduces a new EVPN route, the Multicast
Router Discovery (MRD) route, that carries the information required
to synchronize the multicast router state across the PEs attached to
the same ES. The MRD route applies to multicast routers attached to
multicast Broadcast Domains (BDs), as in [RFC9251] and [RFC9625], and
to multicast routers attached to Layer 3 interfaces, as in
[I-D.ietf-bess-evpn-l3mh-proto].
1.1. Terminology and Conventions
This document uses the following acronyms and terms, listed in
alphabetical order:
AC: Attachment Circuit, as defined in [RFC7432].
BD: Broadcast Domain. A set of EVPN Attachment Circuits and
Rabadan, et al. Expires 7 January 2027 [Page 3]
Internet-Draft EVPN Multicast Router July 2026
emulated segments that belong to the same Layer 2 forwarding
domain, as used in [RFC9625].
BGP: Border Gateway Protocol.
DF: Designated Forwarder, as defined in [RFC7432].
DR: Designated Router, as defined in [RFC7761].
ES: Ethernet Segment, as defined in [RFC7432].
ESI: Ethernet Segment Identifier, as defined in [RFC7432].
EVI: EVPN Instance, as defined in [RFC7432].
EVPN: Ethernet VPN, as defined in [RFC7432].
GenID: Generation Identifier, as defined for PIM in [RFC7761].
IGMP: Internet Group Management Protocol [RFC3376].
IRB: Integrated Routing and Bridging, as used in [RFC9135] and
[RFC9625].
MLD: Multicast Listener Discovery [RFC3810].
MRD: Multicast Router Discovery route, the EVPN route defined in
this document.
NLRI: Network Layer Reachability Information.
OISM: Optimized Inter-Subnet Multicast, as defined in [RFC9625].
PE: Provider Edge device.
PEG: PIM EVPN Gateway, as defined in [RFC9625].
PIM: Protocol Independent Multicast [RFC7761].
RD: Route Distinguisher, as defined in [RFC7432].
RT: Route Target.
SMET: Selective Multicast Ethernet Tag route, as defined in
[RFC9251].
Rabadan, et al. Expires 7 January 2027 [Page 4]
Internet-Draft EVPN Multicast Router July 2026
The 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Problem Statement
This document considers multicast routers that are multihomed to a
set of EVPN PEs in an all-active or single-active Ethernet Segment.
Two attachment models are in scope:
* Multicast routers multihomed to multicast Broadcast Domains in
EVPN PEs, as described in [RFC9251] and [RFC9625].
* Multicast routers multihomed to Layer 3 interfaces, as described
in [I-D.ietf-bess-evpn-l3mh-proto].
The existing specifications leave the following gaps:
For IGMP/MLD routers, [RFC9251] assumes that the IGMP/MLD membership
state of a multihomed host is synchronized across the PEs of an ES by
means of the EVPN route types 7 and 8, and that the EVPN network acts
as a distributed IGMP/MLD Querier for the attached hosts. [RFC9251]
does not, however, cover the case where the operator wants the
Querier to be a multicast router attached to a BD, and where the PEs
of the ES need to present that router's Querier state consistently.
There is no specification today for synchronizing the IGMP/MLD
Querier state of a multihomed multicast router across EVPN PEs.
For PIM routers, [RFC9625] covers the interaction of the EVPN network
with external multicast routers through PIM EVPN Gateways (PEGs), and
also addresses single-homed PIM routers connected to OISM BDs.
[RFC9625] does not, however, specify the synchronization of PIM
neighbor state when those PIM routers are multihomed to EVPN PEs, be
it on BDs as in [RFC9625] or on Layer 3 interfaces as in
[I-D.ietf-bess-evpn-l3mh-proto]. As a consequence, the PIM neighbor
adjacency, DR Priority, and Generation ID of a multihomed PIM router
are known only to the PE(s) that received the PIM Hello on a local
AC, and cannot be presented consistently by all the PEs of the ES.
This inconsistency breaks PIM operation on the ES. A PE that did not
receive the PIM Hello has no PIM neighbor adjacency for the
multihomed router, and per [RFC7761] it SHOULD discard PIM Join/Prune
messages received from a router from which it has not seen a PIM
Hello message. Therefore, when such a PE in the ES exists, Join/
Prune messages received from the multihomed PIM router are dropped,
multicast state is not created, and the corresponding multicast flows
Rabadan, et al. Expires 7 January 2027 [Page 5]
Internet-Draft EVPN Multicast Router July 2026
are lost. Synchronizing the PIM neighbor state across all the PEs of
the ES is therefore required so that any PE, including the DF, can
process PIM messages from the multihomed router and act on its behalf
consistently.
1.3. Solution
The solution defined in this document is the specification of a new
EVPN route, the Multicast Router Discovery (MRD) route, that
synchronizes the multicast router state across the PEs attached to
the same Ethernet Segment. The MRD route was originally defined in
[I-D.skr-bess-evpn-pim-proxy] as part of a specification of PIM proxy
procedures in EVPN. This document updates the encoding of the route
with additional information and specifies its procedures for the
synchronization of multihomed multicast routers that use IGMP, MLD,
or PIM.
A PE that discovers a multicast router on a local AC of a multihomed
ES advertises an MRD route that encodes the router's IP address, the
ESI of the AC, and the router's multicast role and protocol version
in the NLRI. For PIM routers, the additional PIM Hello options (DR
Priority, Generation ID, and the secondary address list) are carried
in a BGP Tunnel Encapsulation Attribute [RFC9012] using a new PIM
Hello Options Sub-TLV. The other PEs of the ES import the route and
install the equivalent Querier or PIM neighbor state, so that any PE
in the ES has the same multicast state for the multihomed router.
In addition to synchronizing the multicast router state, this
document synchronizes the PIM Join/Prune state of receivers reached
through a multihomed PIM router across the PEs of the ES, by reusing
the EVPN route types 7 and 8 of [RFC9251], as described in Section 3.
2. The EVPN Multicast Router Discovery (MRD) Route
This document defines a new EVPN route, the Multicast Router
Discovery (MRD) route, and requests IANA to allocate a route type
value in the EVPN route type registry (see Section 6).
2.1. MRD Route Encoding
Inspired by the EVPN NLRIs defined in [RFC7432], the MRD route uses
the allocated route type and the route-type-specific field shown in
Figure 1.
Rabadan, et al. Expires 7 January 2027 [Page 6]
Internet-Draft EVPN Multicast Router July 2026
+-------------------------------------------------+
| RD (8 octets) |
+-------------------------------------------------+
| Ethernet Segment ID (10 octets) |
+-------------------------------------------------+
| Ethernet Tag ID (4 octets) |
+-------------------------------------------------+
| Originator Router Length (1 octet) |
+-------------------------------------------------+
| Originator Router Address (variable) |
+-------------------------------------------------+
| Multicast Router Length (1 octet) |
+-------------------------------------------------+
| Multicast Router Address (variable) |
+-------------------------------------------------+
| Flags (1 octet) |
+-------------------------------------------------+
Figure 1: Multicast Router Discovery (MRD) Route
The encoding of the route is defined as follows:
* The RD, ESI, and Ethernet Tag ID are defined as per [RFC7432] for
MAC/IP routes. When the route is used to synchronize a multihomed
multicast router, the ESI encodes the Ethernet Segment of the AC
on which the router was discovered, and the Ethernet Tag ID
identifies the BD in VLAN-aware Bundle scenarios or, for Layer 3
multihoming, the sub-interface, as per
[I-D.ietf-bess-evpn-l3mh-proto].
* The Originator Router Length and Originator Router Address encode
an IPv4 or IPv6 address that belongs to the advertising PE. The
Length is expressed in bits (32 for IPv4 or 128 for IPv6).
* The Multicast Router Length and Multicast Router Address encode
the primary IP address of the discovered multicast router (the
IGMP/MLD Querier address and/or the PIM neighbor address added to
the PE's database).
* The Flags field is a one-octet field structured as shown in
Figure 2. The version flags (v1, v2, and v3) use the same bit
positions as the EVPN Multicast Join Synch and Leave Synch routes
in [RFC9251].
Rabadan, et al. Expires 7 January 2027 [Page 7]
Internet-Draft EVPN Multicast Router July 2026
The remaining mandatory PIM Hello options of the discovered router
(DR Priority, Generation ID, and the secondary address list) are not
encoded in the NLRI. For PIM routers (P=1), they are carried in the
PIM Hello Options Sub-TLV of a BGP Tunnel Encapsulation Attribute, as
described in Section 2.2.
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| MBZ | Q| P| R|v3|v2|v1|
+--+--+--+--+--+--+--+--+
Figure 2: MRD Route Flags Field
The bits are defined as follows:
* v1 (bit 7, least significant bit): when set, it indicates that the
encoded router is an IGMPv1 or MLDv1 Querier.
* v2 (bit 6): when set, it indicates that the encoded router is an
IGMPv2 or MLDv2 Querier.
* v3 (bit 5): when set, it indicates that the encoded router is an
IGMPv3 Querier. For IPv6 (MLD) routes, this bit MUST be set to
zero, consistent with [RFC9251].
* R (bit 4): reserved. This bit MUST be set to zero on transmission
and ignored on reception.
* P (bit 3): when set, it indicates that the encoded multicast
router is a PIM router.
* Q (bit 2): when set, it indicates that the encoded multicast
router is an IGMP/MLD Querier.
* MBZ (Must Be Zero, bits 0-1): reserved. These bits MUST be set to
zero on transmission and ignored on reception.
The Q and P flags MAY be set simultaneously when the discovered
router is both an IGMP/MLD Querier and a PIM router. The version
bits (v1, v2, v3) are relevant only when Q is set. For IPv6 (MLD)
routes, bit 7 indicates MLDv1 support and bit 6 indicates MLDv2
support, as per [RFC9251].
For BGP processing purposes, only the RD, the Ethernet Tag ID, the
Originator Router Length and Address, and the (primary) Multicast
Router Length and Address are considered part of the route key. The
Flags are not part of the route key, consistent with
[I-D.skr-bess-evpn-pim-proxy]. The PIM Hello options carried in the
Rabadan, et al. Expires 7 January 2027 [Page 8]
Internet-Draft EVPN Multicast Router July 2026
Tunnel Encapsulation Attribute (see Section 2.2) are a BGP path
attribute and are not part of the route key either; a change in those
options updates the existing route rather than creating a new one.
Support for this route type is OPTIONAL. An EVPN implementation that
does not support this route type MUST ignore the route based on the
unknown route type value, as specified in Section 5.4 of [RFC7606].
2.2. PIM Hello Options Sub-TLV
When the MRD route synchronizes a PIM router (Flags P=1), the PIM
Hello options of the discovered router are carried in a BGP Tunnel
Encapsulation Attribute [RFC9012] attached to the MRD route. The
Tunnel Encapsulation Attribute carries a Tunnel TLV whose Tunnel Type
matches the tunnel used by the EVPN BD (for example, VXLAN), and
within that Tunnel TLV this document defines a new sub-TLV, the PIM
Hello Options Sub-TLV, shown in Figure 3.
+-------------------------------------------------+
| Type (1 octet) |
+-------------------------------------------------+
| Length (1 or 2 octets) |
+-------------------------------------------------+
| PIM Hello Option: DR Priority (Type 19) |
+-------------------------------------------------+
| PIM Hello Option: Generation ID (Type 20) |
+-------------------------------------------------+
| PIM Hello Option: Address List (Type 24) |
+-------------------------------------------------+
Figure 3: PIM Hello Options Sub-TLV
The fields of the sub-TLV are defined as follows:
* Type: a one-octet sub-TLV type, allocated by IANA from the "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry (see Section 6).
* Length: the length of the Value field, encoded as a 1-octet field
when the Type is in the range 0-127 and as a 2-octet field when
the Type is in the range 128-255, as per [RFC9012].
Rabadan, et al. Expires 7 January 2027 [Page 9]
Internet-Draft EVPN Multicast Router July 2026
* Value: a sequence of PIM Hello options, each encoded with the
OptionType, OptionLength, and OptionValue format defined in
Section 4.9.2 of [RFC7761]. This document carries the DR Priority
option (OptionType 19), the Generation ID option (OptionType 20),
and the Address List option (OptionType 24), copied verbatim from
the received PIM Hello. The Address List option carries the
secondary addresses of the multicast router and is omitted when
the router has no secondary addresses.
A PE originating an MRD route for a PIM router SHOULD include the DR
Priority and Generation ID options and MUST include the Address List
option when the router advertises secondary addresses. A PE that
receives an MRD route with a PIM Hello Options Sub-TLV processes the
contained options as if they had been received in a PIM Hello from
the multicast router on the local AC (see Section 2.5). Option types
other than 19, 20, and 24 that may be present in the sub-TLV are
ignored in this document.
2.3. Route Targets and Advertisement Modes
The MRD route MAY be advertised in either of the following two modes,
depending on the intended distribution of the multicast router
information:
* BD-wide distribution mode: the MRD route is advertised with the
Route Target of the BD, so that the multicast router information
is distributed to all the PEs attached to the EVPN BD. This is
the mode described in [I-D.skr-bess-evpn-pim-proxy] and is used
when the objective is to advertise the dynamically discovered
multicast router to the entire BD (for example, to suppress the
flooding of PIM Hellos or IGMP/MLD Queries in the BD).
* Multihoming synchronization mode: the MRD route is advertised with
the ES-Import Route Target [RFC7432], together with the EVI Route
Target carried in an EVI extended community, in the same manner as
the EVPN route types 7 and 8 in [RFC9251]. In this mode the route
is imported only by the PEs that share the Ethernet Segment, and
it is used to synchronize the multicast router state across those
PEs. This is the primary mode specified by this document.
An implementation that supports this document MUST support the
multihoming synchronization mode and MAY support the BD-wide
distribution mode. The two modes are not mutually exclusive; a PE
MAY advertise both an ES-Import-targeted MRD route (for multihoming
synchronization) and a BD-targeted MRD route (for BD-wide
distribution) for the same multicast router.
Rabadan, et al. Expires 7 January 2027 [Page 10]
Internet-Draft EVPN Multicast Router July 2026
2.4. Procedures for Advertising the MRD Route
A PE that supports this document and discovers a multicast router on
a local AC that is part of a multihomed Ethernet Segment generates an
MRD route as follows:
1. The discovery of the multicast router is performed by snooping
the IGMP/MLD or PIM control messages received on the local AC.
PIM neighbor discovery follows [RFC7761] and the PIM snooping
procedures in [RFC8220]. IGMP/MLD Querier discovery follows
[RFC3376], [RFC3810], and [RFC2236].
2. The PE advertises an MRD route encoding:
* The Originator Router Address set to an IP address of the
advertising PE.
* The Multicast Router Address set to the primary IP address of
the discovered router.
* The ESI set to the Ethernet Segment of the local AC on which
the router was discovered, and the Ethernet Tag ID set to the
BD (in case of VLAN-aware Bundle service) or sub-interface
identifier.
* The Flags set according to the discovered router's
capabilities: P set if the router is a PIM router, Q set if
the router is an IGMP/MLD Querier, and the corresponding
version bit (v1, v2, or v3) set for the Querier protocol
version.
* For PIM routers (P=1), a Tunnel Encapsulation Attribute
carrying the PIM Hello Options Sub-TLV (see Section 2.2) with
the DR Priority, Generation ID, and Address List options
copied from the received PIM Hello.
3. The route is advertised with the Route Target(s) corresponding to
the selected advertisement mode (see Section 2.3). For the
multihoming synchronization mode, the route carries the ES-Import
Route Target and the EVI extended community.
4. The PE updates or withdraws the MRD route as the discovered
router state changes:
* If the multicast router is removed from the PE's database (for
example, the PIM neighbor adjacency expires per [RFC7761], or
the router is no longer detected on the local AC), the MRD
route is withdrawn.
Rabadan, et al. Expires 7 January 2027 [Page 11]
Internet-Draft EVPN Multicast Router July 2026
* If a router stops being a PIM neighbor but continues to send
IGMP/MLD Queries, the route is updated with P=0 and Q=1.
* Changes in DR Priority, Generation ID, or the secondary
address list are reflected by re-advertising the MRD route
with an updated PIM Hello Options Sub-TLV. Because these
options are carried in a path attribute and are not part of
the route key, the re-advertisement updates the existing
route.
The PIM Hello timers and other PIM Hello parameters that are
processed locally are not propagated in the MRD route; only the
attributes encoded in the route are synchronized.
A single IGMP/MLD Querier is expected in a given Broadcast Domain. A
PE MAY advertise multiple MRD routes for the same BD when more than
one Querier is discovered, since the Multicast Router Address is part
of the route key. In practice, this is typically a transient
condition, as IGMP/MLD Querier election results in a single Querier
per Broadcast Domain. In Integrated Routing and Bridging (IRB)
deployments, the PEs themselves MAY be IGMP/MLD enabled and
participate in the Querier election on the BD.
2.5. Procedures for Receiving and Processing the MRD Route
A PE that supports this document and receives an MRD route processes
it as follows:
1. The PE imports the route based on its Route Target(s). In the
multihoming synchronization mode, only PEs that are attached to
the Ethernet Segment encoded in the ESI and that import the EVI
Route Target install the state from the route.
2. The PE installs the multicast router state associated with the
Multicast Router Address on the local AC that belongs to the same
Ethernet Segment and Ethernet Tag ID encoded in the route. The
state is kept associated with the Originator Router Address, the
ESI, and the Ethernet Tag ID.
3. For a route with P=1, the PE adds the encoded router to its PIM
Neighbor Database for the local AC on the synchronized ES, using
the DR Priority, Generation ID, and Address List options carried
in the PIM Hello Options Sub-TLV of the route's Tunnel
Encapsulation Attribute (see Section 2.2). This allows the PEs
of the ES to participate in the PIM DR election as per [RFC7761],
even on PEs that did not receive the PIM Hello directly.
Rabadan, et al. Expires 7 January 2027 [Page 12]
Internet-Draft EVPN Multicast Router July 2026
4. For a route with Q=1, the PE installs the encoded router as an
IGMP/MLD Querier for the BD or Layer 3 interface identified by
the ESI and Ethernet Tag ID. The processing depends on the
advertisement mode (see Section 2.3):
* In BD-wide distribution mode, the MRD route enables a
transparent Querier behavior. The DF of the remote ESes
generates IGMP/MLD Query messages using the Multicast Router
Address from the route and the protocol version indicated by
the version flags. The queries presented to the attached
hosts therefore use the IP address of the actual multicast
router, as opposed to a PE-generated or anycast address as in
[RFC9251]. If more than one Querier exists for the same BD,
the PE selects the Querier with the lowest IP address, as per
[RFC2236] and [RFC3810].
* In multihoming synchronization mode, the MRD route
synchronizes the IGMP/MLD Querier state and the Querier
protocol version (as indicated by the version flags) across
the PEs that share the Ethernet Segment. Each importing PE
installs the same Querier information, allowing a consistent
Querier representation on all the PEs of the ES.
5. Timers (for example, the PIM neighbor hold time and the IGMP/MLD
Querier timers) and the local PIM Generation ID are handled
locally by each PE, as per [RFC7761], [RFC3376], and [RFC3810].
They are not propagated in the MRD route.
6. The PIM neighbor hold time is not advertised in the MRD route;
each PE in the ES maintains its own hold time for the
synchronized PIM neighbor. When a PE creates a PIM neighbor in
its database based on a received MRD route (as opposed to a PIM
Hello received directly on a local AC), the hold time for that
neighbor does not expire as long as the MRD route is not
withdrawn.
When the MRD route is withdrawn, the PE MUST NOT remove the PIM
neighbor immediately; instead, it starts the locally configured
hold time for the neighbor and removes it only when that hold
time expires. If, before that hold time expires, a PIM Hello for
the neighbor is received directly on a local AC, the PE updates
the neighbor's hold time to the value carried in the received
Hello without resetting the neighbor (that is, without treating
it as a new adjacency), and the PE advertises an MRD route for
the neighbor.
Rabadan, et al. Expires 7 January 2027 [Page 13]
Internet-Draft EVPN Multicast Router July 2026
When a PIM Hello from the multihomed router is received on a
local AC in this case, the PE SHOULD NOT send a triggered PIM
Hello immediately; instead, it sends its Hello at the next
scheduled periodic interval, in order to avoid unnecessary
triggered Hellos on the synchronized ES.
7. In BD-wide distribution mode, a PE that is not part of the
Ethernet Segment normally receives a single MRD route per
multicast router. In transient situations a PE MAY receive more
than one MRD route for the same multicast router (for example,
from multiple PEs of the ES). The PE MUST recognize this
condition and MUST NOT generate duplicate IGMP/MLD Query messages
towards the local ACs for the same router.
3. Synchronization of PIM State on Ethernet Segments
[RFC9251] describes how the IGMP/MLD membership state of a multihomed
host is synchronized across the PEs of an Ethernet Segment by means
of the Multicast Membership Report Synch route (EVPN route type 7)
and the Multicast Leave Synch route (EVPN route type 8). These
routes allow all the PEs of the ES to maintain a consistent (x,G)
membership state, where x is either a wildcard (*) or a specific
source (S), so that the DF can forward multicast traffic correctly on
behalf of the multihomed receivers.
[RFC9251] does not, however, synchronize the PIM Join/Prune state
that results from PIM messages received from a multihomed PIM router
(or from receivers reached through a multihomed PIM router). As a
consequence, a PE that did not receive the PIM Join/Prune messages
directly does not have the corresponding (x,G) state and cannot
forward the multicast traffic consistently when it is the DF for the
ES.
This document allows the synchronization of the PIM Join/Prune state
across all the PEs of the Ethernet Segment by reusing the EVPN route
types 7 and 8, as follows:
* Upon receiving a PIM Join for an (x,G) on a local AC of the ES,
the PE advertises an EVPN route type 7 (Multicast Membership
Report Synch) for the corresponding (x,G), so that the PIM Join
state is synchronized to all the PEs of the ES.
* Upon receiving a PIM Prune for an (x,G) on a local AC of the ES,
the PE advertises an EVPN route type 8 (Multicast Leave Synch) for
the corresponding (x,G), with the Maximum Response Time set to
zero so that the synchronized state is removed immediately.
Rabadan, et al. Expires 7 January 2027 [Page 14]
Internet-Draft EVPN Multicast Router July 2026
* Upon receiving a PIM Prune(S,G,rpt) from the PIM router, the PE
withdraws the EVPN route type 7 previously advertised for the
(_,G), provided that the PE had previously advertised an EVPN
route type 7 for the (S,G) of the same group. This reflects that
the receiver no longer wants the traffic of source S on the shared
(_,G) tree while it continues to receive the (S,G) traffic on the
source tree.
This use of the route types 7 and 8 is in addition to their use for
IGMP/MLD membership synchronization in [RFC9251]; the two uses are
distinguished by the P flag described below.
3.1. P Flag in the EVPN Route Types 7 and 8
This document updates the Flags field of the EVPN route types 7 and 8
defined in [RFC9251] to use bit 3 as the P (PIM) flag. Bit 3 is a
reserved bit in [RFC9251] and is set to zero by implementations of
that specification.
When a route type 7 or route type 8 is triggered as a result of PIM
Join/Prune messages, as described in this section, the originating PE
MUST set the P flag (bit 3). When the route is triggered as a result
of IGMP/MLD membership reports, as in [RFC9251], the P flag MUST be
set to zero. A PE receiving a route type 7 or 8 with the P flag set
processes the synchronized state as PIM Join/Prune state; otherwise
it processes the route as the IGMP/MLD membership state defined in
[RFC9251].
The use of bit 3 as the P flag in the route types 7 and 8 is
consistent with the P flag defined for the MRD route in Figure 2.
4. Use Cases
This section describes three use cases for the synchronization of
multihomed multicast routers using the MRD route. In all three cases
a multicast router with IP address IP1 is attached to an all-active
Ethernet Segment ESI-1 that is multihomed to PE1 and PE2, and the MRD
route is used to synchronize the router state between PE1 and PE2.
4.1. EVPN-based IGMP/MLD Proxy
In this use case, depicted in Figure 4, the multicast router is an
IGMP/MLD Querier multihomed to PE1 and PE2 on a multicast BD, as in
[RFC9251]. The receiver/source is attached to the same BD on a third
PE. PE2 (the NDF) discovers the Querier on its local AC and
advertises an MRD route encoding the ESI, the multicast router
address IP1, and the version flags (for example, v2/v3). PE1 imports
the route and, as a DF in this example, installs the Querier state so
Rabadan, et al. Expires 7 January 2027 [Page 15]
Internet-Draft EVPN Multicast Router July 2026
that it can act consistently with PE2. The DF generates IGMP/MLD
reports on behalf of the PEs attached to the same ES).
IGMP/MLD Querier /
Multicast Router
(IP1)
|
+-----+
| LAG | ---------+
+-----+ GQ/GSQ |
| | |
+-------+ +-------+ |
| | |
| all-active | |
| ES-1 | v
+---------------+ +---------------+
| PE1 (DF) | | PE2 |
| +--------+ | | +--------+ |
+----| | BD1 | | | | BD1 | |----+
| | +--------+ | | +--------+ | |
| +---------------+ +---------------+ |
| MRD ESI-1,IP1 |
| <-------- v2/v3/Q |
| |
| +-------+ EVPN proxy |
| | PE3 | RFC9251 |
| | +---+ | |
+-----------------| |BD1| |-----------------+
| +---+ |
+---+---+
|
Receiver/Source
(IP2)
Figure 4: EVPN-based IGMP/MLD proxy (RFC 9251)
4.2. EVPN Multihoming for Layer 3 Interfaces
In this use case, depicted in Figure 5, the multicast router is a PIM
router multihomed to PE1 and PE2 on Layer 3 interfaces, as in
[I-D.ietf-bess-evpn-l3mh-proto]. PE1 and PE2 host the IP-VRF of the
tenant and run PIM towards the multihomed router over the L3 ES,
while multicast is distributed across the core using MVPN [RFC6513]
[RFC6514]. PE2 discovers the PIM neighbor through its PIM Hello and
advertises an MRD route with P=1, the DR Priority, and the Generation
ID. PE1 imports the route, installs the PIM neighbor on its local AC
of ESI-1, and can generate PIM Hellos and participate in DR election
for the router. It is assumed that the PEs attached to the same
Rabadan, et al. Expires 7 January 2027 [Page 16]
Internet-Draft EVPN Multicast Router July 2026
Ethernet Segment for a given multicast router are configured with
consistent PIM parameters on the local Attachment Circuits (same IP
address, DR Priority, and timers), with the exception of the
Generation ID.
PIM Router
(L3 multicast)
(IP1)
| PIM Hello
+-----+ IP1,GenID1
| LAG | ---------+
+-----+ |
| | |
+-------+ +-------+ |
| | |
| all-active | |
| ES-1 | v
+-------+-------+ +-------+-------+
| PE1 | | PE2 |
| +--------+ | | +--------+ |
+----- | IP-VRF | | | | IP-VRF | |----+
| | +--------+ | | +--------+ | |
| +---------------+ +---------------+ |
| MRD ESI-1,IP1 |
| <-------- P,GenID1 |
| |
| +-------+ EVPN L3 MH |
| | PE3 | |
| | +---+ | |
+-----------------| |VRF| |-----------------+
| +---+ |
+---+---+
|
Receiver/Source
(IP2)
Figure 5: EVPN MH for L3 interfaces (draft-ietf-bess-evpn-l3mh-proto)
4.3. EVPN Multihoming for EVPN Multicast (OISM)
In this use case, depicted in Figure 6, the multicast router is a PIM
router multihomed to PE1 and PE2 on an OISM BD, as in [RFC9625]. PE1
and PE2 host the IP-VRF and the OISM BD. PE2 discovers the PIM
neighbor on the BD and advertises an MRD route with P=1, the DR
Priority, and the Generation ID. PE1 imports the route and installs
the PIM neighbor for its local AC on ESI-1, synchronizing the PIM
state across the OISM PEs. It is assumed that the PEs attached to
the same Ethernet Segment for a given multicast router are configured
Rabadan, et al. Expires 7 January 2027 [Page 17]
Internet-Draft EVPN Multicast Router July 2026
with consistent PIM parameters on the local Attachment Circuits (same
IP address, DR Priority, and timers), with the exception of the
Generation ID.
PIM Router
(OISM BD)
(IP1)
| PIM Hello
+-----+ IP1,GenID1
| LAG | ---------+
+-----+ |
| | |
+-------+ +-------+ |
| | |
| all-active | |
| ES-1 | v
+-------+-------+ +-------+-------+
| PE1 (DF) | | PE2 |
| +--------+ | | +--------+ |
| | BD1 | | | | BD1 | |
| +--------+ | | +--------+ |
| | IP-VRF | | | | IP-VRF | |
| +--------+ | | +--------+ |
+----- | SBD | | | | SBD | |----+
| | +--------+ | | +--------+ | |
| +---------------+ +---------------+ |
| MRD ESI-1,IP1 |
| <-------- P,GenID1 |
| |
| +-------+ EVPN OISM |
| | PE3 | RFC9625 |
| | +---+ | |
+-----------------| |SBD| |-----------------+
| +---+ |
+---+---+
|
Host
(IP2)
Figure 6: EVPN MH for EVPN multicast (RFC 9625 OISM)
5. Security Considerations
This document defines a new EVPN route that is advertised, imported,
and processed using the BGP and EVPN procedures of [RFC7432]. The
security considerations of [RFC7432], [RFC9251], and [RFC9625]
therefore apply.
Rabadan, et al. Expires 7 January 2027 [Page 18]
Internet-Draft EVPN Multicast Router July 2026
The MRD route causes receiving PEs to install multicast router state
(IGMP/MLD Querier and/or PIM neighbor state) and to generate IGMP/MLD
Queries on behalf of the encoded router. A spoofed or maliciously
crafted MRD route could therefore be used to inject false multicast
router state, redirect or suppress multicast traffic, or influence
the PIM DR election. Implementations MUST rely on the Route Target
filtering and the BGP control-plane security mechanisms described in
[RFC7432] to ensure that MRD routes are accepted only from trusted
PEs that share the Ethernet Segment or the BD. The transparent
Querier behavior does not relax any of the IGMP/MLD or PIM security
checks performed locally by the receiving PE.
6. IANA Considerations
This document requests IANA to allocate a new route type from the
"EVPN Route Types" registry:
+=======+========================================+===============+
| Value | Description | Reference |
+=======+========================================+===============+
| TBD | Multicast Router Discovery (MRD) Route | This document |
+-------+----------------------------------------+---------------+
Table 1: EVPN Route Type allocation request
This document also requests IANA to allocate a new sub-TLV type from
the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry [RFC9012]:
+=======+===========================+===============+
| Value | Description | Reference |
+=======+===========================+===============+
| TBD | PIM Hello Options Sub-TLV | This document |
+-------+---------------------------+---------------+
Table 2: BGP Tunnel Encapsulation Attribute Sub-
TLV allocation request
7. References
7.1. Normative References
[I-D.ietf-bess-evpn-l3mh-proto]
Brissette, P., MacKenzie, M., Matsushima, S., Lin, W., and
J. Rabadan, "EVPN multi-homing support for L3 services",
Work in Progress, Internet-Draft, draft-ietf-bess-evpn-
l3mh-proto-00, 23 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-l3mh-proto-00>.
Rabadan, et al. Expires 7 January 2027 [Page 19]
Internet-Draft EVPN Multicast Router July 2026
[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/rfc/rfc2119>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/rfc/rfc2236>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/rfc/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/rfc/rfc3810>.
[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/rfc/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/rfc/rfc7606>.
[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/rfc/rfc7761>.
[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/rfc/rfc8174>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/rfc/rfc9012>.
Rabadan, et al. Expires 7 January 2027 [Page 20]
Internet-Draft EVPN Multicast Router July 2026
[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/rfc/rfc9251>.
[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/rfc/rfc9625>.
7.2. Informative References
[I-D.skr-bess-evpn-pim-proxy]
Rabadan, J., Kotalwar, J., Sathappan, S., Zhang, Z. J.,
Sajassi, A., and M. P. Mishra, "PIM Proxy in EVPN
Networks", Work in Progress, Internet-Draft, draft-skr-
bess-evpn-pim-proxy-02, 11 October 2023,
<https://datatracker.ietf.org/doc/html/draft-skr-bess-
evpn-pim-proxy-02>.
[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/rfc/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/rfc/rfc6514>.
[RFC8220] Dornon, O., Kotalwar, J., Hemige, V., Qiu, R., and Z.
Zhang, "Protocol Independent Multicast (PIM) over Virtual
Private LAN Service (VPLS)", RFC 8220,
DOI 10.17487/RFC8220, September 2017,
<https://www.rfc-editor.org/rfc/rfc8220>.
[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/rfc/rfc9135>.
Acknowledgments
The MRD route was originally defined in
[I-D.skr-bess-evpn-pim-proxy]. The authors thank the authors and
contributors of that document.
Rabadan, et al. Expires 7 January 2027 [Page 21]
Internet-Draft EVPN Multicast Router July 2026
Authors' Addresses
Jorge Rabadan (editor)
Nokia
United States of America
Email: jorge.rabadan@nokia.com
Olivier Dornon
Nokia
Belgium
Email: olivier.dornon@nokia.com
Tanmoy Kundu
Nokia
United States of America
Email: tanmoy.kundu@nokia.com
Nitsan Dolev
Ribbon
Email: nitsan.dolev@rbbn.com
Rabadan, et al. Expires 7 January 2027 [Page 22]