Symmetric IRB with VLAN-based and VLAN-aware bundle interface

EVPN provides comprehensive services at layer 2; however, layer 2 alone is insufficient for large and complex networks, necessitating layer 3 functions. RFC 9135 introduces an Integrated Routing and Bridging (IRB) solution to manage layer 3-related services. Additionally, RFC 9136 presents a new EVPN route type specifically designed to handle IP prefix routes.
RFC 9135 defines two types of IRB solutions: symmetric and asymmetric. This section will focus on symmetric IRB. Symmetric IRB operates with a symmetric lookup process at both the ingress and egress Provider Edges (PEs). This means that both the ingress and egress PEs perform lookups on both the MAC and IP VRF tables.
To evaluate the layer 2 functionalities, we defined two service interfaces following RFC 7432: VLAN-based and VLAN-aware bundle. In the VLAN-based service interfaces, an EVPN instance consists of a single broadcast domain (e.g., a single VLAN). Thus, a one-to-one mapping exists between a VLAN ID (VID) on this interface and a MAC-VRF. In contrast, the VLAN-aware bundle service interfaces allow an EVPN instance to encompass multiple broadcast domains (e.g., multiple VLANs), with each VLAN having its own bridge table. This means multiple bridge tables (one per VLAN) are maintained by a single MAC-VRF corresponding to the EVPN instance.
We conducted a full-mesh unicast traffic (both routing and bridging traffic) test across the topology. We observed no packet loss in the VLAN-based service IRB interface, which means routing and bridging traffic were sent simultaneously. No switchover was performed during this test, and SR-MPLS and VXLAN had the same procedures and observations.

Then, we rebuilt the topology for the VLAN-aware bundle IRB interface. We verified the service by sending full-mesh unicast traffic (both routing and bridging traffic) and observed no packet loss. No switchover was performed during this test. However, we have multiple iterations with the VLAN-aware bundle service. This is because different vendors have different implementations. For example, some vendors only support single-homing this year, some follow different RFCs, and some don't support RT-5 yet. There is no absolute right or wrong here. It's just about implementation and software readiness.
Spirent TestCenter was used as the traffic generator for this test.