Comment 5 for bug 1730845

So assume you have a container with port1 behind a VM port (or nested in the VM port) port2.

Today you'd create both ports, and then add one to the allowed address pair of the other:
openstack port create --network net1 port1
openstack port create --network net2 port2
openstack port set --allowed-address ip-address=<ip of port1> port2

In the new API, you would state explicitly that port1 is behind port2. e.g.
openstack port create --network net1 port1
openstack port create --network net2 port2
openstack nested-port create --child port2 --parent port1 --type ipvlan

ipvlan type is selected since the MAC was not specified. Otherwise, the two commands would be:
openstack port set --allowed-address ip-address=<ip of port1>,mac-address=<mac of port1> port2
and
openstack nested-port create --child port2 --parent port1 --type macvlan

Since this RFE also proposes to extend trunk's API, creating a trunk port can be rewritten as:
openstack nested-port create --child port2 --parent port1 --type vlan --segmentation-id 7

(It should go without saying that removing support for the old trunk API is *not* proposed)

The benefit is as I outlined above. Instead of the implementation having to heuristically infer the logic (and from my understanding of the DVR code, this is done specifically for lbaas), the desired behaviour is given explicitly.