EVPN Multicast RPF Prefix Advertisement

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 5 May 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

Ethernet VPN (EVPN) deployments can use a tenant Virtual Routing and Forwarding (VRF) to provide both unicast and multicast connectivity. EVPN IP Prefix routes advertise IP prefixes for tenant unicast routing ([RFC9136]). Protocol Independent Multicast (PIM) uses a Multicast Routing Information Base (MRIB) to determine the reverse-path next hop toward a source (Section 2.1 of [RFC7761]). The MRIB is typically derived from the unicast routing table, but it may instead use routes provided by a separate routing protocol that carries multicast-specific topology information, such as Multiprotocol BGP (Section 3 of [RFC7761]).¶

In some EVPN deployments (e.g., financial data centers), the unicast and multicast paths to an external network are intentionally different. For example, unicast traffic may use a border leaf connected through a firewall, while multicast traffic uses a separate border leaf because the firewall does not participate in multicast routing.¶

This document proposes a new EVPN route type, called the Multicast RPF Prefix Route, to advertise IP prefixes for multicast RPF handling. A receiving EVPN node imports the route into the tenant IP-VRF's multicast routing table for RPF resolution. The proposal applies to deployments in which Layer 3 multicast routing is performed either by the receiving EVPN node in the tenant IP-VRF or by a multicast router connected to that node through a PE-CE routing session. In the latter case, the receiving EVPN node advertises the source-prefix reachability learned through EVPN to that router for RPF lookup, for example, as a route in the BGP Multicast Address Family over the PE-CE session.¶

2. Terminology

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] and [RFC8174]) when, and only when, they appear in all capitals.¶

Border Leaf (BL):

An Ethernet VPN (EVPN) Provider Edge (PE) that acts as an exit point from the EVPN fabric.¶

Bridge Table (BT):

An instantiation of a broadcast domain on a Virtual Routing and Forwarding table for Media Access Control (MAC) addresses.¶

Broadcast Domain (BD):

In a bridged network, a broadcast domain corresponds to a Virtual LAN (VLAN).¶

C-Prefix:

An IP prefix in the tenant context.¶

DCI:

Data Center Interconnect.¶

EC:

Border Gateway Protocol (BGP) Extended Community.¶

ECMP:

Equal-Cost Multipath.¶

Ethernet Segment (ES):

A set of Ethernet links through which a customer site (device or network) connects to one or more Provider Edge (PE) devices.¶

Ethernet Segment Identifier (ESI):

A unique, non-zero identifier for an Ethernet Segment.¶

Ethernet Tag:

An identifier for a particular broadcast domain, such as a VLAN. An EVPN Instance (EVI) consists of one or more broadcast domains.¶

EVI:

EVPN Instance; an instance spanning the Provider Edge (PE) devices participating in that EVPN.¶

EVPN:

Ethernet VPN.¶

FHR:

First Hop Router.¶

LHR:

Last Hop Router.¶

MRIB:

A multicast topology table containing routes used to determine the reverse-path next hop toward a source. The information may be derived from the unicast routing table or supplied by multicast-specific routing mechanisms (Section 3 of [RFC7761]). PIM uses the MRIB to select an RPF neighbor; MVPN procedures select an upstream multicast hop from eligible UMH routes (Section 5.1.1 of [RFC6513]).¶

NVE:

Network Virtualization Edge.¶

NVGRE:

Network Virtualization using Generic Routing Encapsulation.¶

NVO:

Network Virtualization Overlay.¶

PE:

Provider Edge.¶

PIM-SM:

Protocol Independent Multicast - Sparse-Mode.¶

PIM-SSM:

Protocol Independent Multicast - Source-Specific Multicast.¶

RP:

Rendezvous Point.¶

RPF:

Reverse Path Forwarding.¶

TS:

Tenant Systems.¶

UMH:

Upstream Multicast Hop.¶

URIB:

Unicast Routing Information Base.¶

VNI:

Virtual eXtensible LAN (VXLAN) Network Identifier.¶

VRI:

VRF Route Import Extended Community; uniquely identifies the PE advertising a multicast source and the IP-VRF in which that source resides.¶

VTEP:

VXLAN Tunnel Endpoint.¶

VXLAN:

Virtual eXtensible LAN.¶

3. Problem Statement

Consider an EVPN tenant IP-VRF with two border leaves. All tenant unicast traffic to and from external networks traverses BL-U and the attached firewall, while multicast traffic between the tenant and external multicast domains traverses BL-M. The unicast and multicast paths are therefore non-congruent.¶

            +----------+                          +---------+---------+
            | Firewall |                          | External Mcast    |---- S1
            +-----+----+                          | Domain            |
                  |                               +---------+---------+
                  | BGP Unicast AFI                         |
                  | (VRF-lite)                              | BGP Multicast AFI
                  |                                         | (VRF-lite)
        +---------+---------+                     +---------+---------+
        |        BL-U       |                     |        BL-M       |
        |  (Unicast Border) |                     |   (Mcast Border)  |
        +---------+---------+                     +---------+---------+
                  |                                         |
                  +---------+-------------------------------+
                            |                               |
                       +----+----+                     +----+----+
                       |  Spine  |                     |  Spine  |
                       +----+----+                     +----+----+
                            |                               |
                                  EVPN Fabric
            +---------------+---------------+---------------+
            |               |               |               |
       +----+----+     +----+----+     +----+----+     +----+----+
       | Leaf-1  |     | Leaf-2  |     | Leaf-3  |     | Leaf-N  |
       +----+----+     +---------+     +---------+     +---------+
            |
           R1

Note: R1 is a multicast receiver; S1 is a multicast source
      in the tenant VRF.

BL-U advertises external unicast prefixes into the EVPN fabric, and a receiving EVPN leaf imports those routes into the tenant IP-VRF for unicast forwarding. BL-M learns multicast reachability for the same prefixes. However, existing EVPN route types do not define a route for installing those prefixes as multicast-specific RPF reachability while leaving the unicast routes unchanged. Without such a procedure, a receiving leaf or a multicast router behind it that derives RPF reachability from the unicast route can select BL-U as the RPF next hop, even when the source is reachable through BL-M and the multicast path uses BL-M. This will cause a multicast traffic black hole due to incorrect RPF information.¶

Other deployments have similar requirements. An EVPN fabric may interconnect tenant networks and distribute prefix reachability between them, but EVPN currently provides no direct procedure for advertising BGP multicast address-family routes for RPF resolution in this scenario. In addition, when multiple VTEPs advertise unicast prefixes, an operator may need to control the multicast path independently of the unicast path, including steering different multicast flows to different exit points.¶

Static multicast routes on each leaf, or separate multicast BGP sessions associated with the tenant IP-VRF context to exchange routes in the BGP multicast address family defined in [RFC4760], can provide workarounds. These approaches do not scale well in large EVPN data centers.¶

4. Proposed Solution

This document proposes a dedicated EVPN route type for advertising multicast RPF prefixes. The route advertises an IP source prefix and identifies the EVPN node that provides the multicast path toward that prefix. A route originator can derive the prefix from multicast-specific routing information in the tenant VRF, for example, from a route learned through the BGP multicast address family ([RFC4760]). Alternatively, the prefix can be provided by local configuration, through policy, or as a static multicast route. The route originator advertises the prefix with the Route Target (RT) for the tenant IP-VRF.¶

The BGP best-path selection for the Multicast RPF Prefix Route follows the procedures used for EVPN Route Type 5. The selected route is installed in the tenant IP-VRF's multicast routing table for RPF resolution. The route MUST NOT be used for unicast forwarding. This enables non-congruent multicast forwarding for an IP-VRF in an EVPN network.¶

The upstream multicast hop (UMH) for a multicast source may be the advertising VTEP, a router behind the advertising VTEP, or another router in the network. The receiving node derives the UMH from the route's BGP next hop or Gateway IP Address, as applicable. When multiple devices advertise the same prefix, the receiving node applies its usual BGP ECMP procedures for prefixes. If multiple routes are installed as an ECMP set, the receiving node selects the UMH for a multicast flow using its local multicast next-hop hash selection.¶

The proposed route complements the existing EVPN IP Prefix route by distinguishing multicast RPF reachability from ordinary unicast prefix reachability. Future work will cover multihoming procedures and other use cases.¶

5. Route Encoding

   +---------------------------------------+
   | Route Distinguisher (8 octets)        |
   +---------------------------------------+
   | Ethernet Segment Identifier (10 octets)|
   +---------------------------------------+
   | Ethernet Tag ID (4 octets)            |
   +---------------------------------------+
   | IP Prefix Length (1 octet, 0 to 32)   |
   +---------------------------------------+
   | IP Prefix (4 octets)                  |
   +---------------------------------------+
   | Gateway IP Address (4 octets)         |
   +---------------------------------------+
   | MPLS Label / VNI (3 octets)           |
   +---------------------------------------+

   +---------------------------------------+
   | Route Distinguisher (8 octets)        |
   +---------------------------------------+
   | Ethernet Segment Identifier (10 octets)|
   +---------------------------------------+
   | Ethernet Tag ID (4 octets)            |
   +---------------------------------------+
   | IP Prefix Length (1 octet, 0 to 128)  |
   +---------------------------------------+
   | IP Prefix (16 octets)                 |
   +---------------------------------------+
   | Gateway IP Address (16 octets)        |
   +---------------------------------------+
   | MPLS Label / VNI (3 octets)           |
   +---------------------------------------+

6. Security Considerations

An unauthorized Multicast RPF Prefix Route could cause a receiving node to direct RPF resolution toward an unintended EVPN next hop. This could disrupt multicast delivery or redirect multicast traffic. Implementations and operators need to restrict route origination and import to authorized tenant and border leaves using appropriate BGP policy and EVPN Route Target controls.¶

7. IANA Considerations

This document requests assignment of a new value from the EVPN Route Types registry for the Multicast RPF Prefix Route. The value is TBD.¶

Appendix A. Authors' Addresses