Hi all, We've just released our implementation of BGP VPN extensions (called 'BaGPipe'), under a opensource license : https://github.com/Orange-OpenSource/bagpipe-bgp
It reuses some code from ExaBGP, but with a dedicated engine for VPN instance creation through a rest API, and a modular architecture to drive a dataplane (e.g. OpenVSwtich). It is based on an internal development we did to address IaaS/IP VPN interconnection issues; although still young the project was the basis for a few working lab prototypes. There is more info in the README. I filled-in a column for BaGPipe on the wiki page ( https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison ), to give an idea where it stands, and let people think how that could address needs in Openstack. I also added a line to specify support for Route-Target-constrained distribution of VPN routes (RFC4684), because it is a real need beyond VPNv4/v6 routes for some VPN interconnection use deployments. Best, -Thomas Nachi Ueno : > Hi folks > > ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. > Ryu is supporting it, however they have no internal api to binding > neutron network & route target. > so I think contrail is a only solution for BGPVPN implementation now. > > > > 2014-05-30 2:22 GMT-07:00 Mathieu Rohon <mathieu.ro...@gmail.com>: >> Hi, >> >> I was about mentionning ExaBGP too! can we also consider using those >> BGP speakers for BGPVPN implementation [1]. >> This would be consistent to have the same BGP speaker used for every >> BGP needs inside Neutron. >> >> [1]https://review.openstack.org/#/c/93329/ >> >> >> On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa <devv...@gmail.com> wrote: >>> Hello Takashi, >>> >>> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing >>> blueprint[2], I've added a new column for this speaker in the wiki page. I >>> plan to fill it soon. >>> >>> ExaBgp was our first choice because we thought that run something in library >>> mode would be much more easy to deal with (especially the exceptions and >>> corner cases) and the code would be much cleaner. But seems that Ryu BGP >>> also can fit in this requirement. And having the help from a Ryu developer >>> like you turns it into a promising candidate! >>> >>> I'll start working now in a proof of concept to run the agent with these >>> implementations and see if we need more requirements to compare between the >>> speakers. >>> >>> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>> [2]: https://review.openstack.org/#/c/90833/ >>> >>> Regards, >>> >>> >>> On 29 May 2014 18:42, YAMAMOTO Takashi <yamam...@valinux.co.jp> wrote: >>>> as per discussions on l3 subteem meeting today, i started >>>> a bgp speakers comparison wiki page for this bp. >>>> >>>> https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>>> >>>> Artem, can you add other requirements as columns? >>>> >>>> as one of ryu developers, i'm naturally biased to ryu bgp. >>>> i appreciate if someone provides more info for other bgp speakers. >>>> >>>> YAMAMOTO Takashi >>>> >>>>> Good afternoon Neutron developers! >>>>> >>>>> There has been a discussion about dynamic routing in Neutron for the >>>>> past few weeks in the L3 subteam weekly meetings. I've submitted a review >>>>> request of the blueprint documenting the proposal of this feature: >>>>> https://review.openstack.org/#/c/90833/. If you have any feedback or >>>>> suggestions for improvement, I would love to hear your comments and >>>>> include >>>>> your thoughts in the document. >>>>> >>>>> Thank you. >>>>> >>>>> Sincerely, >>>>> Artem Dmytrenko >>>> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
