<p dir="ltr">>I am in favor not to go for a least common denominator approach with the<br>
bgpvpn API. The API should cover the use case commonly acknowledged as<br>
useful and which are supported by at least one of the existing back-ends,<br>
with the aim to have various back-ends to grow in support coverage.</p>
<p dir="ltr">So then what is the goal of the bgpvpn project if every vendor-specific feature will be allowed through? Rather than being a generic way to setup BGP VPNs, it sounds to me like it will just become an HTTP proxy with Keystone authentication to vendor APIs. </p>
<div class="gmail_quote">On Aug 21, 2015 11:26 PM, "Jan Scheurich" <<a href="mailto:jan.scheurich@ericsson.com">jan.scheurich@ericsson.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I am in favor not to go for a least common denominator approach with the<br>
bgpvpn API. The API should cover the use case commonly acknowledged as<br>
useful and which are supported by at least one of the existing back-ends,<br>
with the aim to have various back-ends to grow in support coverage.<br>
<br>
Not supported features of the API could either be rejected by drivers, or<br>
a fallback behavior can be specified on API level in case a specific non-vital<br>
attribute is not supported by a backend (e.g. in the case of the RD).<br>
<br>
My preference would be to stick to the provider framework and to allow<br>
most backend-specific drivers to profit from the boilerplate code in the<br>
service plugin.<br>
<br>
BTW: The ODL plugin is planned to support both Network and Router<br>
association and the RD attribute will not be a mandatory attribute for<br>
the ODL back-end.<br>
<br>
Regards,<br>
Jan<br>
<br>
<br>
Mathieu Rohon Wed, 19 Aug 2015 06:46:45 -0700<br>
Hi,<br>
<br>
thanks for your reply irena and salvatore.<br>
<br>
Currently, we're targeting 4 backends : bagpipe (the ref impelmentations<br>
compatible with other ref implementations of neutron), ODL, contrail and<br>
nuage.<br>
Contrail and bagpipe work with networks attachments to a bgpvpn connection,<br>
while ODL and Nuage work with routers attachments. We even start thinking<br>
about port attachments [1]<br>
Moreover, ODL needs a RD attribute that won't be supported by other<br>
backends.<br>
<br>
I think that each backend should be able to manage each kind of attachment<br>
in the future, depending on the will of the backend dev team. But in a<br>
firts step, we have to manage the capacity of each backend.<br>
<br>
So, indeed, the managment of attachments to a bgpvpn connection through the<br>
use of extensions will expose backend capacity. And I agree that it's not<br>
the good way, since when moving from one cloud to another, the API will<br>
change depending on the backend.<br>
<br>
So I see two ways to solve this issue :<br>
1-In first releases, backends that don't support a feature will through a<br>
'"NotImplemented" exception when the feature will be called through the<br>
API; We still have an inconsistent API, but hopefully, this gone be<br>
temporary.<br>
2-reducing the scope of the spec [2] and having less compatible backends,<br>
and a smaller community for the bgpvpn project.<br>
<br>
[1]<a href="https://blueprints.launchpad.net/bgpvpn/+spec/port-association" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/bgpvpn/+spec/port-association</a><br>
[2]<a href="https://review.openstack.org/#/c/177740/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/177740/</a><br>
<br>
regards,<br>
<br>
Mathieu<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>