Open Stack

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.rohon at 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 <devvesa at 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 <yamamoto at 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.