]> Nokia

United States of America jorge.rabadan@nokia.com

Nokia

Belgium olivier.dornon@nokia.com

Nokia

United States of America tanmoy.kundu@nokia.com

Ribbon

nitsan.dolev@rbbn.com

HPE

wen.lin@hpe.com

Cisco

mankamis@cisco.com

Routing BGP Enabled ServiceS EVPN Multicast IGMP MLD OISM 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the BGP Enabled ServiceS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction EVPN 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, 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 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 and , and to multicast routers attached to Layer 3 interfaces, as in .

Terminology and Conventions This document uses the following acronyms and terms, listed in alphabetical order:

AC:

Attachment Circuit, as defined in .

BD:

Broadcast Domain. A set of EVPN Attachment Circuits and emulated segments that belong to the same Layer 2 forwarding domain, as used in .

BGP:

Border Gateway Protocol.

DF:

Designated Forwarder, as defined in .

DR:

Designated Router, as defined in .

ES:

Ethernet Segment, as defined in .

ESI:

Ethernet Segment Identifier, as defined in .

EVI:

EVPN Instance, as defined in .

EVPN:

Ethernet VPN, as defined in .

GenID:

Generation Identifier, as defined for PIM in .

IGMP:

Internet Group Management Protocol .

IRB:

Integrated Routing and Bridging, as used in and .

MLD:

Multicast Listener Discovery .

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 .

PE:

Provider Edge device.

PEG:

PIM EVPN Gateway, as defined in .

PIM:

Protocol Independent Multicast .

RD:

Route Distinguisher, as defined in .

RT:

Route Target.

SMET:

Selective Multicast Ethernet Tag route, as defined in .

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 when, and only when, they appear in all capitals, as shown here.

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 and .
• Multicast routers multihomed to Layer 3 interfaces, as described in .

The existing specifications leave the following gaps: For IGMP/MLD routers, 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. 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, 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. 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 or on Layer 3 interfaces as in . 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 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.

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 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 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 , as described in .

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

MRD Route Encoding Inspired by the EVPN NLRIs defined in , the MRD route uses the allocated route type and the route-type-specific field shown in .

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 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 .
• The Originating Router's IP Address Length and Originating Router's IP Address encode an IPv4 or IPv6 address that belongs to the advertising PE, as defined in . 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 . The version flags (v1, v2, and v3) use the same bit positions as the EVPN Multicast Join Synch and Leave Synch routes in .

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 .

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 .
• 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 . For BGP processing purposes, only the RD, the Ethernet Tag ID, the Originating Router's IP Address Length and Originating Router's IP 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 . The PIM Hello options carried in the Tunnel Encapsulation Attribute (see ) 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 .

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

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 ).
• 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 .
• Value: a sequence of PIM Hello options, each encoded with the OptionType, OptionLength, and OptionValue format defined in Section 4.9.2 of . 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 ). Option types other than 19, 20, and 24 that may be present in the sub-TLV are ignored in this document.

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

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 and the PIM snooping procedures in . IGMP/MLD Querier discovery follows , , and .
2. The PE advertises an MRD route encoding:
   • The Originating Router's IP 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 ) 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 ). 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 , 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.

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 Originating Router's IP 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 ). This allows the PEs of the ES to participate in the PIM DR election as per , 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 ):
   • 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 . If more than one Querier exists for the same BD, the PE selects the Querier with the lowest IP address, as per and .
   • 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 , , and . 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.

Synchronization of PIM State on Ethernet Segments 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. 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.
• 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 ; the two uses are distinguished by the P flag described below.

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 to use bit 3 as the P (PIM) flag. Bit 3 is a reserved bit in 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 , 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 . 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 .

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.

EVPN-based IGMP/MLD Proxy In this use case, depicted in , the multicast router is an IGMP/MLD Querier multihomed to PE1 and PE2 on a multicast BD, as in . 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. Although this is implicitly assumed in the EVPN IGMP/MLD proxy model, this document states explicitly that:

• IGMP/MLD Query packets are not forwarded to other EVPN PEs across the overlay EVPN network.
• Remote PE3 sends IGMP/MLD Queries toward its access side based on the information carried in the MRD route (for example, the Multicast Router Address and the Querier version flags), rather than by forwarding Query packets received over the EVPN overlay.

EVPN-based IGMP/MLD proxy (RFC 9251)

EVPN Multihoming for Layer 3 Interfaces In this use case, depicted in , the multicast router is a PIM router multihomed to PE1 and PE2 on Layer 3 interfaces, as in . 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 . 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.

EVPN MH for L3 interfaces (draft-ietf-bess-evpn-l3mh-proto)

EVPN Multihoming for EVPN Multicast (OISM) In this use case, depicted in , the multicast router is a PIM router multihomed to PE1 and PE2 on an OISM BD, as in . 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.

EVPN MH for EVPN multicast (RFC 9625 OISM)

Security Considerations This document defines a new EVPN route that is advertised, imported, and processed using the BGP and EVPN procedures of . The security considerations of , , and therefore apply. 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 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.

IANA Considerations This document requests IANA to allocate a new route type from the "EVPN Route Types" registry: EVPN Route Type allocation request

Value	Description	Reference
TBD	Multicast Router Discovery (MRD) Route	This document

This document also requests IANA to allocate a new sub-TLV type from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry : BGP Tunnel Encapsulation Attribute Sub-TLV allocation request

Value	Description	Reference
TBD	PIM Hello Options Sub-TLV	This document

References Normative References In 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. RFC 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. This 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)". 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). Ethernet 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. According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. 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. The 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. This 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. This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK] Informative References This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain. This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices. In 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] This 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] 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. Cisco Systems Cisco Systems Softbank Juniper Nokia This document describes the use of EVPN Ethernet Segment Link Aggregation Group (ES-LAG) technology to provide multi-homing redundancy for Layer 3 services. The solution synchronizes ARP/ND, multicast state, and IGP routes between redundant PEs without requiring Layer 2 constructs or proprietary Inter-Chassis Communication protocols. Nokia Nokia Nokia Juniper Networks Cisco Systems Cisco Systems Ethernet Virtual Private Networks are becoming prevalent in Data Centers, Data Center Interconnect (DCI) and Service Provider VPN applications. One of the goals that EVPN pursues is the reduction of flooding and the efficiency of CE-based control plane procedures in Broadcast Domains. Examples of this are Proxy ARP/ND and IGMP/MLD Proxy. This document complements the latter, describing the procedures required to minimize the flooding of PIM messages in EVPN Broadcast Domains, and optimize the IP Multicast delivery between PIM routers.

Acknowledgments The MRD route was originally defined in . The authors thank the authors and contributors of that document.