Comment 13 for bug 1722842

Armando.

Yes, discussing APIs in neutron-lib is the right way to go, totally agree.

Clarifications on what I was saying above, the alternatives I see to find a resolution for what currently blocks us from implementing the bgpvpn-routes-control API extension merged in neutron-lib:
- solve the bug in the API extension framework (neutron.api.extensions), like, or similarly as, in change https://review.openstack.org/511280
- workaround the problem like how it was done for qos-bw-limit-direction; if unelegant, this roughly works mostly when one API extension adds (or possibly changes) an attribute in a sub-resource, but if more than one API extension wants to do that, each API extension definition will have to refer to the sub-resource attribute map of all the other API extensions touching this sub-resource (doing the review work in one place would allow the thing to work, but we would then pass the line between "merely inelegant" to "ugly")
- the not-a-solution-alternative: abandon the idea of having an API extension that adds or modify attributes in a sub-resource (in that case doing a "BGPVPNv2" API extension would be the only option left to go beyond the behavior we have in BGPVPN today)