EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
Extracted elements (26)
It is RECOMMENDED that the default IP multicast tunnels be distinct from the BUM tunnels when P2MP tunnels are used. Using shared BUM tunnels forces PEs interested only in IP multicast to pull all BUM traffic from source BDs to which they have no local ACs, causing unnecessary bandwidth consumption.
SMET routes scoped to the SBD rather than individual BDs enable inter-subnet ASM multicast routing without requiring PIM Rendezvous Points, shared trees, or other PIM RP infrastructure, as long as all sources and receivers remain within the Tenant Domain.
The SBD concept allows a PE not provisioned with a source BD to still forward inter-subnet multicast correctly by treating all such frames as having originated from the SBD. This avoids requiring every PE to be provisioned with every BD in the Tenant Domain.
Interworking between EVPN OISM and MVPN domains is handled by an MEG (MVPN/EVPN Gateway), which must perform both OISM and MVPN Layer 3 multicast procedures. The solution must support heterogeneous tunneling, e.g., MVPN using MPLS P2MP while EVPN uses IR or VXLAN.
Interworking with external PIM domains is handled by a PEG (PIM/EVPN Gateway). The PEG manages First Hop Router / Last Hop Router responsibilities for sources and receivers crossing the EVPN boundary and must handle both ASM and SSM group models.
Interworking with non-OISM PEs (supporting only RFC 7432) requires an IP Multicast Gateway (IPMG) that interfaces OISM tunnels with the BUM tunnels of legacy PEs. The IPMG acts as the IPMG Designated Forwarder for the relevant BDs to avoid duplicate delivery when bridging between the two forwarding domains.
An EVPN PE supporting OISM MUST be provisioned with the SBD of each Tenant Domain to which it is attached. The SBD-RT MUST NOT be the same as the RT associated with any other BD; this restriction is necessary for the route-to-BD association rules to produce correct results.
An OISM PE provisioned with several BDs in the same Tenant Domain MUST originate an IMET route for each such BD. It SHOULD attach the EVPN Multicast Flags Extended Community to each such IMET route but MUST attach it to at least one.
An OISM PE SHOULD attach the Multicast Flags Extended Community with the OISM-supported flag set to all IMET routes it originates. If PE1 imports IMET routes from PE2 and at least one indicates PE2 is an OISM PE, PE1 MUST assume PE2 follows OISM procedures for all BDs in the Tenant Domain.
At an ingress PE, an IP multicast frame received from an AC is (1) tunneled unchanged to interested remote PEs, and (2) sent up the BD's IRB interface for inter-subnet forwarding. IP multicast sent down a non-SBD IRB interface goes ONLY to local ACs of that BD; remote delivery has already occurred via step 1.
If an egress PE withdraws its IMET route for a source BD, the ingress PE MUST immediately stop using the label from that IMET route and MUST use the SBD-IMET label from that egress PE instead. Implementations must handle BD-specific IMET routes arriving after the SBD-IMET route.
If receivers for (*,G) exist in a given Tenant Domain, there MUST NOT be anycast sources for group G within that Tenant Domain. Unlike PIM's RPF-based deduplication, OISM distributes all (S,G) flows with the same anycast source address independently, causing duplicate delivery to (*,G) receivers.
Link-local IP multicast traffic (IPv4 224/24 and IPv6 FF02/16) MUST always be carried on the BUM tunnels and ONLY on the BUM tunnels. Such traffic is excluded from the definition of 'IP multicast packet' for all other OISM procedures.
PEs in a Tenant Domain MUST be provisioned to know which of three SMET-origination cases applies: no BD has a multicast router (Case 1), more than one BD may (Case 2), or exactly one BD may (Case 3). In Case 2, per-BD SMET routes MUST NOT be originated to avoid duplicate ingress of externally-sourced traffic.
S-PMSI A-D routes for selective tunnels MUST carry the SBD-RT so all Tenant Domain PEs import them. Each such route MUST also carry the RT of the source BD and have the source BD's Tag ID in its NLRI. For RSVP-TE P2MP selective tunnels, the LIR flag of the PTA SHOULD NOT be set because OISM PEs know which egress PEs are interested.
The IMET route for the SBD MUST carry a Multicast Flags Extended Community in which the OISM SBD flag is set. IMET routes for non-SBD BDs SHOULD carry an EVI-RT EC constructed from the SBD-RT to indicate the BD's corresponding SBD.
To support OISM procedures, an EVPN PE MUST also support RFC 9135 (IRB) and RFC 9251 (intra-subnet selective multicast). Certain procedures in RFC 9251 are modified when OISM is supported.
Traffic originating in an actual BD MUST NOT be sent down the SBD IRB interface, as that traffic has already been distributed throughout the Tenant Domain via inter-PE tunneling. The SBD IRB interface OIF list must exclude locally-sourced intra-domain traffic to prevent duplicate delivery.
Under OISM, IMET routes for a particular BD are distributed to all PEs attached to the Tenant Domain, not just those attached to that BD. SMET routes are originated per-Tenant-Domain (for the SBD) rather than per-BD, carrying the SBD-RT so every ingress PE learns the interest of every egress PE.
When a received IMET, SMET, S-PMSI, or Leaf route contains conflicting or ambiguous Route Targets (e.g., SBD-RTs from multiple Tenant Domains, or RTs from two different ordinary BDs), the route MUST be treated as malformed and the treat-as-withdraw procedure of RFC 7606 MUST be applied.
When BIER is used and an EVPN PE may be an ingress for externally-sourced traffic, that PE MUST originate an SBD-IMET route. IMET routes for all other BDs in the Tenant Domain MUST carry the SBD-RT, and every IMET route MUST carry a PTA with an upstream-assigned MPLS label uniquely identifying its source BD.
When IR is used, each EVPN PE MUST originate an SBD-IMET route. The SBD-IMET route MUST carry a PTA whose MPLS Label field specifies a downstream-assigned label mapping uniquely to the SBD at the originating PE.
Each Tenant Domain must be associated with a Supplementary Broadcast Domain (SBD). The SBD is treated as a real BD in the control plane but has no Attachment Circuits. It serves as the apparent source BD when a receiving PE is not attached to the actual source BD of a tunneled frame.
Five cases govern how a receiving PE associates an incoming route with a BD. Case 4 covers routes carrying only the SBD-RT (route belongs to SBD regardless of Tag ID). Case 5 covers routes carrying both an ordinary BD-RT and the SBD-RT (route belongs to the ordinary BD, not the SBD).
The OISM control plane relies on BGP Route Target communities to scope route distribution; the route-validation rules in Section 2.2 require treat-as-withdraw for routes carrying ambiguous or conflicting RTs, guarding against misconfigured or malicious route advertisements that could misdirect multicast forwarding state.
For BIER encapsulation of OISM frames, a 4-octet MPLS label stack entry (RFC 3032) is prepended to the Ethernet frame with the Label field set to the upstream-assigned label for the source BD. The resulting MPLS packet is then encapsulated in a BIER encapsulation (RFC 8296) with the BIER Proto field set to indicate 'MPLS packet with upstream-assigned label at top of stack'.