Quantum-sdn-controler-improvement

Overview

Numerous limitations have been identified which prevent using free/libre plugins such as OpenVSwitch or LinuxBridge for large scale deployments.

At this time, the OpenStack networking project is designed to be interfaced with a third party controller which handles the “control plane” (NVP, Midonet, Ryu, Big Switch, NEC, PLUMgrid).

The third party controllers have the following primary objectives (outside of the user directed functionality):

• scalability
• high availability
• exploitatability (monitoring, debugging, billing, capacity planning, etc...)
• efficiency of virtualization technologies (scalability, performances...)

Nevertheless, it is also possible to use OpenStack Networking as the “control plane” (with LinuxBridge, OpenVSwitch, Cisco, Brocade). But has OpenStack Networking been developed with this role in mind, or is it mostly an interface between the networking API and the SDN "control plane"?

Facts:

• the controller role is only endorsed by the OpenStack networking server through the code of the selected plugin.
• only one instance of OpenStack networking server could be run at a time
• the communication protocol between the control plane and the data place is based on AMQP (RabbitMQ, ZeroMQ, Qpid - Oslo RPC)
• a database is used to save the state of the NaaS at any specific time
• high availability: the OpenStack networking daemon can be instantiated as many time as necessary

Improvements:

• split the ‘quantum-api’ daemon in separated roles to improve scalability and security: API, scheduling and plugin.
• add exploitability functions:

• monitoring (like this bp)
• debugging
• etc

• Improve the overlay technology of the open source plugin like LinuxBridge or OVS (disabling full-mesh of OVS...)
• merge the two open source plugins LinuxBridge and OVS. We can imagine the LinuxBridge working with overlay technologies (like VXLAN implemented in Linux kernel 3.8) instead of the classic VLAN isolation. Only one open source plugin with two or more possible drivers like LinuxBridge or OVS or new one like Snabb Switch

This blueprint intended to open the discussion within the community to define more precisely the area of improvements and priorities.

Remarks:

• In slides introduced by Dan Wendlandt in Mars 2012 on slide n°30, a question was listed "Is Quantum SDN?" with the answers "It depends..."

Interrogations

• Is improving OVS or LinuxBridge outside of the scope of OpenStack ? Should OpenStack networking be a SDN controller?
• If monitoring and debugging are the only missing points, they are not the blockers and the real blocker is the lack of scalable/production ready free software SDN. i.e. the problem is only loosely related to OpenStack : implementing a blueprint such as this one would help when the situation improves but it's only marginally useful. It follows that only few people/companies will have the incentive to work on tools supporting a free software implementation that cannot be used in production/at scale.