Neutron as SDN controller ?

That was probably to hottest topic during the summit. Beyond this topic the question was: neutron shouldn’t be responsible of all the things related to the API and delegated the management of flows to an external SDN controller. Some of neutron’s sessions attendees think that it is too complex to address things like scalability and High Availability directly in neutron. The question is open and the answer will come maybe during the next six months with the incoming of the ml2 mechanism driver for OpenDayLight.

SDN / L2population

Here at eNovance with some engineers from Cloudwatt and Orange, we are involved into the development of Neutron and especially the problem of scaling. That’s why we developed the L2 population mechanism drivers for the ml2 plugin. The main purpose of the L2 population mechanism driver is to manage the partial mesh and also to pre-populate the forwarding tables in order to limit L2 broadcasts in the overlay. There was a good session about the ml2 plugin and the l2 population mechanism driver during the summit made by Robert Kukura and Kyle Mestery. The L2 population driver is a step in the direction of the high scalability of Neutron with open source plugins. Some vendors think about the possibility to leverage the L2 population to populate Hardware switches.

Here is the full recorded session: ML2 Deep Dive

Here is the L2 population blueprint: L2 Population

DVR, distributed virtual routers

The goal of this proposal is to create distributed routers, which allow one-hop forwarding for east-west traffic in virtualized networks. The first implementation will be limited to the OVS plugin. Once again DVR could leverage L2 population and the ARP responder based on Ebtables which is being implemented and is currently in review.

Here is the proposal blueprint: Distributed virtual router

L3 HA VRRP

Friday we did a session about the possibility to add a new kind of vrouter with High Availability capabilities. Currently we are able to spawn many l3 agents, however each l3 agent is a Single point of failure, so the idea is to be able to spawn multiple instances of a same router on many agents. Keepalived will be used to manage the Virtual IP interfaces, and Conntrackd will be used to maintain the TCP sessions going through the router. This feature could be used with the DVR for north/south traffic.

Here is the proposal blueprint: L3 HA

Neutron Ml2 Multiple Layer2 Backend Support

Finally the solution will maybe come from one of the last session of this summit. With the ml2 we could potentially supports multiple backend technologies. The idea of this proposal is to be able to manage the same agent with both neutron and an external SDN controller in order to bring the best of the both universes.

Other interesting proposals

Framework for advanced services in virtual machines

The goal here is to be able to launch and insert network services implemented as Virtual Machine into the network on demand. These services may be supplied by third party vendors for several purposes like Load-Balancer, Firewall, IDS (Intrusion Detection System), etc. The session was about the framework definition.

Here is the proposal blueprint: Service VM

Neutron QoS

This session was a follow-up from a previous one in Portland. The idea is to add QoS features to Neutron. After this session, It has been decided to start with a simple API to manage QoS at port level so no QoS at the tenant level for now. A first implementation of reference will be for the OpenvSwitch agents.

Layer2 VPN

The session was an introduction to a future blueprint about the possibility to add VPN capability at Layer 2 to Neutron. There were many discussions around tunneling solutions, GRE, VXLAN, MLPS, finally a first proof of concept implementation will be implemented for the types that the host kernel supports.

There were lot of others interesting topics in the Hong Kong summit, I only took the most interesting… in my point of view