Hi, On Thu, 19 Jun 2014 18:00:34 +0200 Jaume Devesa <[email protected]> wrote:
> my name is Jaume Devesa from Midokura. I have presented a *spec * for > OpenStack Juno to create a Dynamic Router agent to advertise and discover > dynamically routes from Neutron routers to upstream[1]. > > Thanks to Ryu's clean API and Takashi Yamamoto follow up of the spec, we > are considering seriously to use Ryu's BGP Speaker as the default > implementation. I want to share with you some ideas I have had after using > the example code[2] sharing routes with a Quagga's bgpd daemon. Thanks for the consideration! Our team are happy to help. > Before I start I would like to underscore a few of things: > * I am not a BGP expert. Don't take my suggestions too much seriously if > they don't make sense to you. > * Sorry if this mail is too large and some points should be reported in > another place. I will move it anywhere you ask me if it fits into your way > to work. > * I am using master branch of your repository, which I understand is in > development. But I am aware the API has changed and I want to use the > newest one. > > Ok, so: > > > 1. neighbor_add(*address*, *remote_as*, *enable_ipv4=True*, > *enable_vpnv4=False*, *enable_vpnv6=False*) does not allow to set next-hop > value, it uses the machine's ip by default. It would be good to specify as > an optional parameter. In our spec, the agent does not route packets, just > changes routes. The router would have another IP address and even be > deployed in another machine Make sense. Once I finish v6 support, I'll add the feature. > 2. AFAIK, some BGP peers are configured with tcp-md5 password. > *neighbor_add* should have a password optional parameter as well. Yeah. btw, you actually need md5 authentication feature? > 3. I seems that according to your API, all the routes are advertised to all > the neighbors. If you want distinction, you need to create another > speaker... and you can not because port 179 is already binded. I would be > great if there was a way to differentiate routes per peer. Yeah, I plan to add 'filtering' feature like other bgps implementations to do such. > 4. Mode pedantic: maybe if there is a speaker.shutdown(), in terms of > coherency it should be a speaker.start()... Yeah, I didn't add start() just because implementing start() needs some refactoring. > 5.* rib_get* method is exactly what I need! I don't want to modify the > routing table of the machine where the agent runs, but discover the routes > after the exchange. I see. Let us know if you want any changes. > 6. I would say that when the remote peer connection is lost, the prefixes > learned from aren't deleted in the rib table... Should they? You mean that the prefixes are not deleted? > That's all :) > > Thanks for your interest and for your time in the specification. > > [1]: > http://docs-draft.openstack.org/33/90833/8/check/gate-neutron-specs-docs/e81ba5b/doc/build/html/specs/juno/bgp-dynamic-routing.html > > [2]: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html > > Sincerely, > > -- > Jaume Devesa > Software Engineer at Midokura ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
