tap flow catching unexpected traffic among trunk's parent and subports

It seems that tap-as-a-service and trunk ports are not fully orthogonal features to each other. When I tried to mirror traffic of trunk parent and subports, taas did mirror the intended traffic. However the tap flow also caught some unintended traffic: the entering-vm (IN) direction of all other (either parent or sub) ports of a trunk.

taas version: c9d0468 (8.0.0+)
neutron version: 7cbec53543
devstack version: 858aca01

The environment was an all-in-one ml2/ovs devstack, in local.conf:
ENABLED_SERVICES+=,taas
enable_plugin tap-as-a-service ...
TAAS_SERVICE_DRIVER=TAAS:TAAS:neutron_taas.services.taas.service_drivers.taas_rpc.TaasRpcDriver:default

Reproduction steps:

# vxlan networks
openstack network create net0
openstack network create net1
openstack network create net2

openstack subnet create --network net0 --subnet-range 10.0.4.0/24 subnet0
openstack subnet create --network net1 --subnet-range 10.0.5.0/24 subnet1
openstack subnet create --network net2 --subnet-range 10.0.6.0/24 subnet2

# for traffic capture
openstack port create --network net0 --disable-port-security port0
# going to be trunk parent
openstack port create --network net0 port1
parent_mac="$( openstack port show port1 -f value -c mac_address )"
# going to be trunk subports
openstack port create --network net1 --mac-address "$parent_mac" port2
openstack port create --network net2 --mac-address "$parent_mac" port3

openstack network trunk create --parent-port port1 trunk0
openstack network trunk set --subport port=port2,segmentation-type=vlan,segmentation-id=101 trunk0
openstack network trunk set --subport port=port3,segmentation-type=vlan,segmentation-id=102 trunk0

# for traffic capture
openstack server create --flavor ds1G --image u2004 --nic port-id=port0 --wait vm0
# for traffic generation
openstack server create --flavor ds1G --image u2004 --nic port-id=port1 --wait vm1

# tap services and flows (not all of them used at the same time, please see below)
openstack tap service create --port port0 --name ts0
openstack tap flow create --port port1 --tap-service ts0 --direction BOTH --name tf0
openstack tap flow create --port port2 --tap-service ts0 --direction BOTH --name tf1
openstack tap flow create --port port3 --tap-service ts0 --direction BOTH --name tf2

sudo virsh console "$( openstack server show vm0 -f value -c OS-EXT-SRV-ATTR:instance_name )"
vm0 # tcpdump -vvv -n -e -i ens2 icmp

sudo virsh console "$( openstack server show vm1 -f value -c OS-EXT-SRV-ATTR:instance_name )"
vm1 # ip link add link ens2 name ens2.101 type vlan id 101
vm1 # ip link add link ens2 name ens2.102 type vlan id 102
vm1 # dhclient -v ens2.101
vm1 # dhclient -v ens2.102

test scenarios: The tap service is always the same, but the tap flows are different. Below describing them in terms of mirror source and destination and mirrored traffic destinations. The .2 IPs are always the dhcp ports of the corresponding subnet, while other random endings are addresses of port1 (10.0.4.), port2 (10.0.5.) and port3 (10.0.6.).

tap flows:
    port2/BOTH -> port0 (tf1)
outcome:
    ping -c1 10.0.4.2
        unexpected: 10.0.4.2 > 10.0.4.232
    ping -c1 10.0.5.2 ## mirroring this
        as expected
    ping -c1 10.0.6.2
        unexpected: 10.0.6.2 > 10.0.6.98

tap flows:
    port1/BOTH -> port0 (tf0)
outcome:
    ping -c1 10.0.4.2 ## mirroring this
        as expected
    ping -c1 10.0.5.2
        unexpected: 10.0.5.2 > 10.0.5.26
    ping -c1 10.0.6.2
        unexpected: 10.0.6.2 > 10.0.6.98

tap flows:
    port1/BOTH -> port0 (tf0)
    port2/BOTH -> port0 (tf1)
outcome:
    ping -c1 10.0.4.2 ## mirroring this
        as expected
    ping -c1 10.0.5.2 ## mirroring this too
        as expected
    ping -c1 10.0.6.2
        unexpected: 10.0.6.2 > 10.0.6.98
notes:
    in mirror cannot differentiate between traffic of port1 and port2 (I expected this behavior. While it is suboptimal, I don't think this is a bug.)