Comment 3 for bug 1730845

1. port-behind-port behaviour: A situation where one port is not bound, but is reachable by sending the packet to another port (possibly on a different network). The RFE contains three examples of this behaviour (MACVLAN, amphora, trunk ports).

2. I was thinking of extending the trunk API, and extending the segmentation type to include other values (MACVLAN, IPVLAN, etc.), and include other fields if necessary (Specifically, MACVLAN and IPVLAN can make do with no additional information, but future types might).

simpler, flexible, and more robust: Once the tenant (or other projects e.g., Octavia, Kuryr) specified what they *want* to do, rather than *how* to do it, then the API becomes simpler to understand (and us humans don't need to infer the topology as well. It will be given to us). This also allows the API to be more easily extended when new related features are needed (flexible).

Robustness comes from the implementation knowing exactly *what* needs to happen, rather than inferring it from the *how*. e.g. instead of inferring that if one port's IP/MAC is in another port's allowed address pairs, then traffic to the former should be passed to the latter, knowing that the former is 'behind' the latter allows for an implementation that is less dependant on heuristics, and therefore has less room for error.