Comment 9 for bug 1730845

I think I understand partially the problem you are stating: the (ab)use of allowed address pairs to address a number of scenarios (e.g. VRRP with tenant instances) has been brittle at best. If you are calling for first class resources in the API to describe some of the scenarios you have in mind (e.g. container networking in virtualized environments) that would lead to a more declarative vs a more imperative/procedural approach to building the required topologies, then I am all in for it.

@Omer: do you think I am slowly getting at what you're hinting all along?

If so, I am starting to like your thinking :) but I see two issues with your current description:

a) We need a clearer/simpler use case(s) to adopt as framework to reason about the proposal of new API extensions.
b) We do not necessarily need to operate within the constraint of an existing API, such as the trunk one, unless the proposals/extensions slot in seamlessly. We should be able to judge more wisely here one we have identified cases at point a).

Thoughts?