[openstack-dev] [Neutron] Too much "shim rest proxy" mechanism drivers in ML2

Mathieu Rohon mathieu.rohon at gmail.com
Fri Jun 6 13:18:11 UTC 2014

hi henry,

On Fri, Jun 6, 2014 at 10:17 AM, henry hly <henry4hly at gmail.com> wrote:
> ML2 mechanism drivers are becoming another kind of "plugins". Although they
> can be loaded together, but can not work with each other.
> Today, there are more and more drivers, supporting all kinds of networking
> hardware and middleware (sdn controller). Unfortunately, they are designed
> exclusively as chimney REST proxies.
> A very general use case of heterogeneous networking: we have OVS controlled
> by ovs agent, and  switchs from different vendor, some of them are
> controller by their own driver/agent directly, others are controlled by a
> sdn controller middleware. Can we create a vxlan network, across all these
> sw/hw switchs?
> It's not so easy: neutron ovs use l2 population mech driver, sdn controllers
> have their own population way, today most dedicated switch driver can only
> support vlan. sdn controller people may say: it's ok, just put everything
> under the control of my controller, leaving ml2 plugin as a shim rest proxy
> layer. But, shouldn't Openstack Neutron itself be the first class citizen
> even if there is not controller involved?

I totally agree. By using l2population with tunnel networks (vxlan,
gre), you will not be able to plug an external device which could
possibly terminate your tunnel. The ML2 plugin has to be aware a new
port in the vxlan segment. I think this is the scope of this bp :

mixing several SDN controller (when used with ovs/of/lb agent, neutron
could be considered has a SDN controller) could be achieved the same
way, with the SDN controller sending notification to neutron for the
ports that it manages.

> Could we remove all device related adaption(rest/ssh/netconf/of... proxy)
> from these mechanism driver to the agent side, leaving only necessary code
> in the plugin? Heterogeneous networking may become easier, while ofagent
> give a good example, it can co-exist with native neutron OVS agent in vxlan
> l2 population.

linuxbridge agent can coexist too

And with the help of coming ML2 agent framework, hardware
> device or middleware controller adaption agent could be more simplified.

I don't understand the reason why you want to move middleware
controller to the agent.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list