Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)
updates
- rfc-7385 — IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points
Extracted elements (25)
Approach B (single RT per EVI with a Leaf-Indication color flag in a new extended community) is chosen over Approach A (two RTs per EVI for Root/Leaf). Both approaches require the same data-plane enhancements, but Approach B is consistent with baseline EVPN RFC 7432 RT usage and provides better generality.
E-Tree over EVPN performs filtering of unicast traffic at the ingress PE rather than sending traffic through the network to be filtered at the egress PE as in VPLS-based E-Tree (RFC 7796). This ingress filtering is possible because EVPN performs MAC learning in the control plane via BGP, making destination site type known before forwarding.
The composite tunnel bit is placed in the Tunnel Type field rather than the Flags field so that PEs that do not understand the new meaning treat the Tunnel Type as an undefined type and handle the PMSI Tunnel attribute as malformed per RFC 6514, ensuring backward-compatible behavior.
Using two MAC-VRFs (bridge tables) per VLAN for E-Tree is rejected because it would require either two MAC lookups per address or duplication of MAC entries across both tables for locally and remotely learned addresses, causing data-plane performance inefficiencies on some platforms.
By default and for backward compatibility with non-E-Tree EVPN, an AC that does not carry a Leaf designation is treated as a Root AC. Operators must explicitly configure ACs as Leaf before activation to enforce leaf-to-leaf traffic isolation.
PEs that do not understand the composite tunnel bit in the PMSI Tunnel Attribute Tunnel Type field will treat the resulting value as an undefined Tunnel Type and process the attribute as malformed per RFC 6514. This backward-compatible degradation is intentional and is why the bit is placed in Tunnel Type rather than the Flags field.
Scenario 3 (Root/Leaf per MAC address) does not support BUM traffic because Designated Forwarder (DF) filtering per RFC 7432 is incompatible with the required egress filtering; BUM traffic is dropped by the ingress PE in this scenario.
A PE MUST indicate to other PEs what kind of sites (Root or Leaf) its MAC addresses are associated with by advertising a Leaf-Indication flag via the E-Tree extended community along with each MAC/IP Advertisement route learned from a Leaf site. Absence of this flag indicates a Root site.
For BUM traffic, MPLS-encapsulated frames originating from a Leaf AC MUST be tagged with a Leaf label (as specified in Section 6.1) to enable egress PEs to perform the necessary egress filtering function.
In MAC mobility scenarios where a MAC address is advertised with different Root or Leaf-Indications, MAC mobility procedures (RFC 7432 Section 15) MUST take precedence to identify the MAC's location before associating it with a Root or Leaf site.
Reserved bits in the E-Tree extended community Flags field SHOULD be set to zero by the transmitter and MUST be ignored by the receiver.
The E-Tree extended community MUST be advertised with MAC/IP Advertisement routes learned from a Leaf site. No other EVPN routes are required to carry this extended community for known unicast traffic purposes.
Using the composite tunnel bit with Tunnel Types 0x00 ('no tunnel information present') or 0x06 ('Ingress Replication') is invalid. A PE receiving such a PMSI Tunnel attribute considers it malformed and SHOULD treat the Update as though all routes it contained had been withdrawn per RFC 6514 Section 6.
When the E-Tree extended community is advertised with an EAD-ES route (ESI=0) for BUM traffic egress filtering, the Leaf label MUST be set to a valid MPLS label (non-reserved, assigned per RFC 3032) and the Leaf-Indication flag SHOULD be set to zero. The receiving PE MUST ignore the Leaf-Indication flag.
A new composite tunnel type is defined for the PMSI Tunnel attribute by setting the high-order (most significant) bit of the Tunnel Type field. When set, the Tunnel Identifier field begins with a three-octet Ingress Replication label followed by the actual transmit tunnel identifier, allowing a Root PE to simultaneously signal a P2MP transmit tunnel and an Ingress Replication receive tunnel.
For Scenario 1 (Leaf or Root per PE), two BGP Route Targets per EVI are used: one for Root sites and one for Leaf sites. Root PEs import both Root and Leaf RTs; Leaf-only PEs import only the Root RT, preventing MAC route exchange between Leaf-only PEs.
For single-homed Leaf site BUM traffic, the ingress PE adds a per-PE Leaf label advertised using the E-Tree extended community along with an EAD-ES route with ESI=0 and RTs for all EVIs that have at least one Leaf site. Multiple EAD-ES routes are used if the RT count exceeds a single route's limit.
In PBB-EVPN, when a multihomed ES has both Root and Leaf sites, two B-MAC addresses are advertised: one per-ES B-MAC (implicitly Root, per RFC 7623) without the E-Tree extended community, and one per-PE B-MAC explicitly marking Leaf with the E-Tree extended community Leaf-Indication flag set.
IANA allocated sub-type value 0x05 in the 'EVPN Extended Community Sub-Types' registry (defined in RFC 7153) for the E-Tree Extended Community defined by this document.
This document creates a new one-octet 'E-Tree Flags' registry with RFC Required registration policy. Initial registration: bits 0-6 Unassigned; bit 7 = Leaf-Indication (this document).
This document updates RFC 7385 by reallocating PMSI Tunnel Type values: 0x0C-0x7A Unassigned (IETF Review); 0x7B-0x7E Experimental; 0x7F Reserved; 0x80-0xFA Reserved for Composite Tunnel; 0xFB-0xFE Experimental (RFC 7385); 0xFF Reserved (RFC 7385). The MSB of the Tunnel Type field is designated as the 'composite tunnel' bit.
The E-Tree extended community provides an additional security function by allowing network operators to designate ACs as Root or Leaf, preventing any traffic exchange among Leaf sites through ingress filtering for known unicast and egress filtering for BUM traffic. The operator SHOULD configure the AC role before activating the AC to avoid unintended leaf-to-leaf communication.
In PBB-EVPN BUM egress filtering: when a MAC/IP Advertisement route arrives indicating a Leaf B-MAC and the local ES is Leaf, the B-MAC is added to the egress filter (block) list. When a subsequent route indicates the B-MAC changed from Leaf to Root and the local ES is Leaf, the B-MAC is removed from the filter list (unblock).
In the composite tunnel PMSI Tunnel attribute, the Tunnel Type field has its high-order bit set as the 'composite tunnel' bit; the low-order 7 bits retain the existing tunnel type encoding. The Tunnel Identifier field begins with a 3-octet MPLS label for Ingress Replication, followed by the actual P2MP tunnel identifier.
The E-Tree Extended Community is an 8-octet BGP extended community: Type (1 octet, 0x06), Sub-Type (1 octet, 0x05), Flags (1 octet, bit 7 = Leaf-Indication 'L', bits 0-6 MBZ), Reserved (1 octet, 0), Reserved (1 octet, 0), Leaf Label (3 octets, 20-bit MPLS label value in high-order bits).