multiple service drivers can't coexist

currently, we use the service type framework [1] which means, AFAIU, that :
-several service providers can coexist;
-the end user can select the service provider to create and manage the bgpvpn connection.

From an implementation POV, the typical workflow for other service plugins is :
- it receives API calls;
- it stores data in the DB;
- it forwards the call to the service provider selected by the end user;

Our workflow is quite different since not all service providers want to store datas in the Neutron db.
OpenContrail wants to forward the call directly to its controller which stores datas in its own DB.
So our service plugin :
- receives the API call;
- forwards it to the service provider driver;
- the service provider driver will be in charge of storing datas in the neutron DB if needed.

Currently, a bgpvpn connection is not coupled with a provider. This is the main reason why mutliple service providers can't coexist.

But I wonder if we really need to manage several service providers? Do we have any use cases where one wants to mix some bgpvpn connections managed by ODL, others by bagpipe, and others by OpenContrail, or nuage?

If the answer is no, I think we could simplify the code by only using one service plugins with no service providers.
We would have one plugin per implementation.
Those plugins could load extensions depending on what they support. For instance we would have the current bgpvpn extension, but also the RD extension that the ODL plugin would load.
This way, we leverage the native neutron extension framework without having to create a framework that loads extensions per drivers, has proposed in [2].

If the answer is yes, we want to provide the end user the ability to manage its bgpvpn connections with different service providers, then we have to add a the service provider information to the bgpvpn connection datas, and we have to implement the framework to load extensions from service providers. This kind of implemention already exists in ML2 [3].

[1]https://wiki.openstack.org/wiki/Neutron/ServiceTypeFramework
[2]https://review.openstack.org/206536
[3]https://github.com/openstack/neutron-specs/blob/master/specs/juno/neutron-ml2-mechanismdriver-extensions.rst