Multicast Router State Synchronization in EVPN Networks

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 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].¶

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 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.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.¶

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].¶

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.¶

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 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.¶

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].¶

• 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.¶

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.¶

   • 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.¶

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.¶

   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.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.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 that it can act consistently with PE2. The DF generates IGMP/MLD reports on behalf of the PEs attached to the same ES).¶

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 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.¶

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 with consistent PIM parameters on the local Attachment Circuits (same IP address, DR Priority, and timers), with the exception of the Generation ID.¶

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>.

[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>.

[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>.