Cisco

170 West Tasman Drive San Jose CA 95134 US kethiruv@cisco.com

Cisco

170 West Tasman Drive San Jose CA 95134 US ythallas@cisco.com

Routing BGP Enabled Services (BESS) Working Group EVPN multicast RPF This document defines a new EVPN route type for advertising multicast source-prefix reachability information within an EVPN network. The route enables Reverse Path Forwarding (RPF) resolution for multicast traffic independently of the unicast routing topology, addressing the operational requirement for non-congruent unicast and multicast forwarding paths in tenant multicast deployments. The proposed route type allows an EVPN PE to advertise source-prefix reachability for multicast RPF, learned through a multicast-specific routing protocol (e.g., BGP using the Multicast Address Family) or configured locally through policy or static multicast routes.

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 (). Protocol Independent Multicast (PIM) uses a Multicast Routing Information Base (MRIB) to determine the reverse-path next hop toward a source (). 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 (). 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.

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 ( and ) 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 (). PIM uses the MRIB to select an RPF neighbor; MVPN procedures select an upstream multicast hop from eligible UMH routes ().

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.

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.

Non-congruent Multicast deployment usecase

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 , can provide workarounds. These approaches do not scale well in large EVPN data centers.

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

Route Encoding

EVPN NLRI The route is carried in BGP UPDATE messages using the multiprotocol extensions defined in . It uses AFI 25 (L2VPN) and SAFI 70 (EVPN) for the EVPN NLRI, as defined in . The EVPN route-type value is TBD. The proposed route-type-specific fields follow the encoding of the EVPN IP Prefix route in . The route type distinguishes multicast RPF use from the existing unicast route type.

Multicast RPF Prefix Route Format The Multicast RPF Prefix Route has the following form. The EVPN NLRI Length field is 34 octets for IPv4 and 58 octets for IPv6, consistent with the corresponding address-family encoding in . The BGP route key follows that specification: the RD, Ethernet Tag ID, IP Prefix Length, and IP Prefix are key fields; the ESI, Gateway IP Address, and VNI are not. The RD is unique per originating IP-VRF.

IPv4 Multicast RPF Prefix Route

IPv6 Multicast RPF Prefix Route

Route Distinguisher:

The RD of the originating IP-VRF, following EVPN IP Prefix route conventions. It distinguishes routes originated from different IP-VRFs.

Ethernet Segment Identifier:

Set to zero in this initial proposal. Use of an ESI as an overlay index for multicast RPF resolution is out of scope.

Ethernet Tag ID:

Set to zero for an IP-VRF route in this proposal.

IP Prefix Length and IP Prefix:

Identify the source-address prefix used for RPF lookup. The prefix length is from 0 through 32 for IPv4 or from 0 through 128 for IPv6. A prefix length of zero represents the IPv4 or IPv6 default route, as determined by the NLRI length. The prefix field is four octets for IPv4 and sixteen octets for IPv6.

Gateway IP Address:

For a VNF use case, the Gateway IP Address may contain a valid IP address. Otherwise, it is set to zero.

MPLS Label / VNI:

For VXLAN, carries the full 24-bit L3 VNI for the tenant IP-VRF, following .

The route MUST carry the tenant Route Target corresponding to the IP-VRF. It MAY carry a BGP Encapsulation Extended Community identifying VXLAN (). It MAY also carry a VRF Route Import (VRI) Extended Community (). The use of the BGP Encapsulation Extended Community follows the EVPN IP Prefix route procedures in ; the VRI Extended Community is defined in . This route is defined for a tenant IP-VRF. Use of this route in a MAC-VRF is outside the scope of this document.

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.

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.

Authors' Addresses Cisco

170 West Tasman Drive San Jose CA 95134 US kethiruv@cisco.com

Cisco

170 West Tasman Drive San Jose CA 95134 US ythallas@cisco.com