Summary:

• As the spec is still unmerged, there are some bits on the API extension and DB extension that will need to change.
• Furthermore, there are some unknowns that are still not figured out and that we need to investigate into:
  • As Rodolfo mentions in the spec: Could it be possible to use the PVLAN service plugin over any network type? For example, a geneve, VXLAN or VLAN network?
  •  Would pg_drop_group be different to the general drop port group of PVLAN or
      can we use the same one?
  •  Should we disable arp_responder for LSP to be able to block that traffic too?
      Or maybe it is possible to configure OVN to respond to ARP traffic “selectively”?

Goal:

• Uncover the uncertain parts of the PVLAN service plugin implementation. Write conclusions about it.  Have a clear overview of the implementation steps for the PVLAN plugin.

Sources:

1. PVLAN spec: https://review.opendev.org/c/openstack/neutron-specs/+/975289 
2. PVLAN API: https://review.opendev.org/c/openstack/neutron-lib/+/975931 
3. Example of DB extension for the network object (QinQ property): https://review.opendev.org/c/openstack/neutron/+/937372