Hi all,

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.

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

2. AFAIK, some BGP peers are configured with tcp-md5 password.
*neighbor_add* should have a password optional parameter as well.

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.

4. Mode pedantic: maybe if there is a speaker.shutdown(), in terms of
coherency it should be a speaker.start()...

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.

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?

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

Reply via email to