IMET Route Filtering for Ethernet VPN (EVPN) Ethernet Tree (E-Tree) with VXLAN Encapsulation

IMET Route Filtering for BUM Traffic defines how ingress filtering for known unicast traffic is performed, by attaching an E-Tree extended community to each EVPN type-2 mac-ip route that is advertised for a host with leaf classification. Any PE that imports this route is able to classify the remote host identified by the received route as a root or a leaf, based on the presence or absence of the attached E-Tree extended community. Any traffic locally originated from an attached leaf host, and destined to a remote leaf host, can then be dropped prior to encapsulation, preventing any local leaf hosts from communicating with known remote leaf hosts. A bridging domain in a VXLAN network is identified by a VXLAN network identifier (VNI). Each PE will have a mapping of VNI to local bridging domain (VLAN). In addition to advertising a type-2 mac-ip route per known local host, each PE will advertise a type-3 IMET route per-VNI. This is used by receiving PEs to construct a per-VLAN floodset of remote PEs. When BUM traffic is flooded locally in a VLAN, this traffic can also be replicated to any remote PEs contained in the floodset for that VLAN. This ensures that all BUM traffic in a bridging domain will reach all hosts, remote and local, in that bridging domain. Due to each PE advertising an IMET route per-VNI, there being a 1-1 mapping from VLAN to VNI on each PE, and the limitation that all hosts in given local VLAN must be classified as either roots or leaves (role classification methods 1 or 2 from ), it becomes possible for each advertised IMET route to be classified as either a "root" or "leaf" IMET route. On a PE with VLANs configured as leaves, for any IMET route advertised by that PE for a VNI that maps to a local VLAN configured as a leaf, the PE MUST attach the E-Tree extended community defined in with the leaf flag set to the advertised IMET route. On any PE which receives an IMET route with the E-Tree extended community with leaf flag set attached, if the local VLAN which maps to the VNI from the received route is classified as a leaf, the PE MUST NOT install the remote PE identified in the received IMET route into the local floodset for the indicated VLAN. By ensuring that both known remote hosts and remote flood targets are identified as being classified as leaves in their respective EVPN routes, it is possible for an ingress PE to prevent sending any locally sourced leaf-classified traffic to remote leaf hosts, ensuring E-Tree segmentation rules are followed. When attached to a type-3 IMET route, the E-Tree extended community is used in the same way as when attached to a type-2 mac-ip route as per . Namely, when the E-Tree extended community is advertised along with an IMET route, the Leaf-Indication flag MUST be set to one and the Leaf label SHOULD be set to zero. The receiving PE MUST ignore the Leaf label and only process the Leaf-Indication flag. A value of zero for the Leaf-Indication flag is invalid when sent along with an IMET route, and an error should be logged.

IMET Route Filtering with Ingress Replication The following examples will refer to the network topology described in .

Example E-Tree Topology The topology shown in contains 3 PE devices, each with two VLANs locally configured, with one host directly connected to each PE in each local VLAN. All of the PE devices are connected together through an underlay network, and all peer with each other over EVPN. The VLAN to VNI mappings are configured identically on each PE device as shown in VLAN to VNI Mappings on Each PE in

PE	Local VLAN	VNI
PE-A	10	10000
PE-A	20	20000
PE-B	10	10000
PE-B	20	20000
PE-C	10	10000
PE-C	20	20000

PE-A has two local VLANs configured. Each of these VLANs is classified as a leaf VLAN. PE-A advertises two EVPN type-3 IMET routes, one for VNI 10000 (mapping to local VLAN 10), and one for VNI 20000 (mapping to local VLAN 20). Because both of the local VLANs are configured as leaves, PE-A advertises both IMET routes with the E-Tree extended community with leaf flag set attached. PE-B also has two local VLANs configured, also mapping to VNIs 10000 and 20000, but on PE-B, the local VLANs are both classified as root VLANs. Because of this, neither of the IMET routes that PE-B advertises have the E-Tree extended community attached. PE-C also has two local VLANs configured, also mapping to VNIs 10000 and 20000. On PE-C, VLAN 10 is classified as a leaf VLAN, and VLAN 20 is classified as a root VLAN. Because of this, the IMET route that PE-C advertises for VNI 10000 has the E-Tree extended community with leaf flag set attached, while the IMET route that PE-C advertises for VNI 20000 does not have the E-Tree extended community attached. PE-A receives four IMET routes, 2 each from PE-B and PE-C. Neither IMET route received from PE-B has the E-Tree extended community attached, so PE-A imports both routes into its local floodsets for VLANs 10 and 20. The IMET route received from PE-C for VNI 20000 does not have the E-Tree extended community attached, so PE-A imports PE-C into the local floodset for VLAN 20, but because the received IMET route from PE-C for VNI 10000 does have the E-Tree extended community attached, and the local VLAN that maps to VNI 10000 (VLAN 10) is configured as a leaf VLAN, PE-A does not import PE-C into the local floodset for VLAN 10. PE-B receives four IMET routes, 2 each from PE-A and PE-C. Because both local VLANs on PE-B are configured as root VLANs, all received IMET routes are imported, regardless of the presence or absence of the E-Tree extended community. PE-C receives four IMET routes, 2 each from PE-A and PE-B. Both IMET routes received from PE-B do not have the E-Tree extended community attached, so PE-B is imported into the local floodsets of both VLAN 10 and VLAN 20. Both IMET routes received from PE-A do have the E-Tree extended community with leaf flag set attached, but because the local VLAN that maps to VNI 20000 (VLAN 20) is configured as a root VLAN, PE-A is still imported into the local floodset for VLAN 20. However, because the local VLAN that maps to VNI 10000 (VLAN 10) is configured as a leaf VLAN, PE-A is not imported into the local floodset for VLAN 10. The contents of each local floodset for each VLAN on each PE after all of the peer IMET routes are received are shown in Floodset Contents of Each PE in

PE	VLAN	Floodset Contents
PE-A	10	PE-B
PE-A	20	PE-B, PE-C
PE-B	10	PE-A, PE-C
PE-B	20	PE-A, PE-C
PE-C	10	PE-B
PE-C	20	PE-A, PE-B

Leaf to Leaf BUM Traffic Assume that Host 1 sends traffic that is classified as BUM on PE-A. The only remote host classified as a leaf in the same bridging domain (VLAN 10/VNI 10000) is Host 5 attached to PE-C. To maintain the E-Tree segmentation rules, this BUM traffic from Host 1 must not reach Host 5. PE-A will replicate the BUM traffic to all remote PEs in the local floodset for VLAN 10, which because of the filtered IMET route only contains PE-B. Therefore, BUM traffic sourced from leaf Host 1 is never replicated to PE-C on VNI 10000, and never reaches leaf Host 5.

Leaf to Root BUM Traffic Using the same scenario from the previous section, Host 1 sends BUM traffic. This traffic must reach all root-classified hosts in the same bridging domain, which in this case is Host 3 attached to PE-B. Because the IMET route from PE-B wasn't filtered on PE-A (due to no attached E-Tree extended community), PE-B is in the local floodset for VLAN 10 on PE-A. Therefore, BUM traffic sourced from leaf Host 1 is replicated to PE-B and reaches root Host 3.

Root to Leaf and Root to Root BUM Traffic Assume that Host 6 sends traffic that is classified as BUM on PE-C. Because Host 6 is classified as a root on PE-C, it must reach both remote root and leaf hosts. Because any received IMET routes are imported into a local root VLAN regardless of if the E-Tree extended community is attached or not, PE-C will import the VNI 20000 IMET routes from both PE-A and PE-B. Therefore, when Host 6 sends BUM traffic, it will be replicated to both PE-A and PE-B. It will then be received by both leaf Host 2 and root Host 4.

IMET Route Filtering with Multicast Replication When multicast replication is used in the underlay instead of ingress replication, instead of each PE managing a local floodset of remote PEs to replicate BUM traffic to, each PE defines one or more multicast groups that it advertises via IMET routes, which remote PEs will join if they want to receive BUM traffic for the VNI described by the IMET route. All of the details specified in still apply when using multicast replication, with one important limitation: each PE MUST define and advertise at minimum a separate multicast group for each E-Tree classification present on the PE. This means that PEs whose locally configured VLANs are only roots or only leaves may configure a single multicast group, but PEs that have a mix of local root and leaf VLANs must configure at least two multicast groups, a "root" and "leaf" group. The PE will still advertise one IMET route per VNI, but the IMET routes advertised for any VNI that maps to a local VLAN configured as a root will contain the root multicast group, and not attach the E-Tree extended community, while the IMET routes advertised for any VNI that maps to a local VLAN configured as a leaf will contain the leaf multicast group, and will attach the E-Tree extended community with leaf flag set. The worst case upper bound for the minimum number of required multicast groups is 2x the number of PEs with both root and leaf VLANs configured locally. PEs that have only root VLANs configured, or only leaf VLANs configured, are able to configure a single multicast group (because all of the IMET routes that they advertise will either have or not have the E-Tree extended community attached), but VTEPs that have both root and leaf VLANs configured must configure at least two multicast groups. One, the “root” multicast group, will be advertised in each IMET route that corresponds to a root VNI (without the E-Tree extended community attached), and the other, the “leaf” multicast group, will be advertised in each IMET route that corresponds to a leaf VNI (with the E-Tree extended community attached). More than 2 multicast groups can be configured per-PE (up to and including one multicast group per-VNI). The only restriction is that there must be at least one multicast group configured for each E-Tree classification present on a PE. Aside from the aforementioned limitation, IMET route filtering with multicast replication functions very similarly to IMET route filtering with ingress replication. Instead of managing a local per-VLAN floodset, PEs that receive IMET routes manage their multicast group memberships, to ensure that no remote leaf traffic is received for a local leaf VLAN. When a PE receives an IMET route with the E-Tree extended community with leaf flag set attached, it knows that any traffic received on the multicast group contained in the IMET route is leaf traffic. Therefore, if the local VLAN that maps to the VNI from the IMET route is configured as a leaf VLAN, the receiving PE MUST NOT join the multicast group contained in the received IMET route. shows the multicast groups advertised by each PE, and which remote PEs join those groups. Multicast Groups for BUM Traffic when using Multicast Replication in

PE	VLAN	Multicast Group	Multicast Group Members
PE-A	10	Group A1	PE-B
PE-A	20	Group A2	PE-B, PE-C
PE-B	10	Group B1	PE-A, PE-C
PE-B	20	Group B2	PE-A, PE-C
PE-C	10	Group C1	PE-B
PE-C	20	Group C2	PE-A, PE-B

Leaf to Leaf BUM Traffic Assume that Host 1 sends traffic that is classified as BUM on PE-A. The only remote host classified as a leaf in the same bridging domain (VLAN 10/VNI 10000) is Host 5 attached to PE-C. To maintain the E-Tree segmentation rules, this BUM traffic from Host 1 must not reach Host 5. Because the IMET route advertised by PE-A for VNI 10000 will have the E-Tree extended community with leaf flag set attached, PE-C will not join multicast group A1 advertised in this IMET route. Therefore, when PE-A sends any VLAN 10 BUM traffic to multicast group A1, it will not reach PE-C, and not reach remote leaf Host 5.

Leaf to Root BUM Traffic Using the same scenario from the previous section, Host 1 sends BUM traffic. This traffic must reach all root-classified hosts in the same bridging domain, which in this case is Host 3 attached to PE-B. PEs where the local VLAN that maps to a received IMET route VNI are roots will join the advertised multicast group regardless of whether or not the IMET route has the E-Tree extended community attached. Therefore, PE-B will join multicast group A1, and will receive all leaf BUM traffic sourced from PE-A, including from leaf Host 1.

Root to Leaf and Root to Root BUM Traffic Assume that Host 6 sends traffic that is classified as BUM on PE-C. Because Host 6 is classified as a root on PE-C, it must reach both remote root and leaf hosts. Because the IMET route that PE-C sends for VNI 20000 does not have the E-Tree extended community attached, both PE-A and PE-B will join multicast group C1 advertised in this IMET route. Therefore, when root Host 6 sends BUM traffic, it will be received by both PE-A and PE-B, and in turn by leaf Host 2 and root Host 4.

Multihoming Considerations The proposals in this document are fully compatible with EVPN multihoming as described in , with one caveat. For the BUM ingress filtering approach described in this document to work properly, all PE devices that share an ethernet segment (ES) must configure their root/leaf VLAN classifications identically. In other words, any VLANs configured as leaves on one PE must also be configured as leaves on any other PEs in the same ES, and any VLANs configured as roots on on PE must be configured as roots on any other PEs in the same ES. If a VLAN is configured as a root on one PE and a leaf on another PE in the same ES, the ingress filtering behavior for BUM traffic will depend on the VLAN classification on the elected designated forwarder (DF) (which may change during normal network operation), leading to instability in the network. Furthermore, a host multihomed to two or more PEs with different root/leaf classifications for the same VLAN will effectively have a different E-Tree classification depending on which PE its traffic gets load-balanced to, breaking the E-Tree segmentation rules.

Optional Tradeoffs in PE Hardware Resource Utilization vs. Network Traffic One additional advantage of performing ingress filtering for BUM traffic instead of egress filtering as defined by is that it allows for a more compelling tradeoff between ingress filtering for known unicast traffic and converting known unicast traffic to BUM traffic for the purpose of potentially saving PE hardware resources. While performing ingress filtering for known unicast leaf-to-leaf traffic is optimal in terms of network traffic (prohibited traffic is never allowed to leave the PE on which it originated), it is potentially suboptimal with respect to PE hardware resources and scaling. Depending on hardware implementation, ingress filtering for known-unicast traffic may require per-host resource utilization (in the form of drop routes or similar), which may be prohibitive depending on host scale. To avoid this per-host resource utilization, a PE could simply not install a local unicast route for a known remote leaf if the local VLAN is also configured as a leaf. This would have the effect of converting all remote-destined known-unicast traffic to BUM traffic, and when combined with E-Tree BUM filtering rules, would still ensure that E-Tree segmentation rules are respected. However, if only egress filtering is used for BUM traffic, this could result in a prohibitive amount of new BUM traffic, making this tradeoff unappealing. By performing ingress filtering for BUM traffic (as defined in this proposal), a much smaller amount of extra BUM traffic is generated when treating all prohibited leaf-to-leaf known unicast traffic as BUM traffic. While all remote root PEs will still receive unnecessary flooded traffic for this "known unicast as BUM" traffic, no remote leaf PEs will receive a copy of the traffic and have to perform egress filtering. In network topologies with few root PEs (or topologies in which there is expected to be only a small amount of leaf-to-leaf traffic that must be blocked), the tradeoff between local hardware resources for known-unicast ingress filtering vs. extra flooded traffic due to treating prohibited leaf-to-leaf traffic as BUM traffic becomes much more tractable when ingress replication is used for BUM traffic as opposed to egress filtering.