Status and maturity of the Neutron in Openstack Havana release

Randy Bias from Cloudscaling organized a meetup and brought together 4 engineers who work on cloud network and Openstack Neutron:

• Juniper, Rudra Rugee
• Midokura, Ryu Ishimoto
• VMware, Aaron Rosen
• PLUMgrid, Edgar Magana

More info about the meetup can be found here:
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203

Below are some of my notes I took when watching the video.

 Key SDN components

• Network programmability (API)
• Network vitalization (responsible for creating overlay network, multi-tenancy, managing flows, gateways, virtual routers ...)

What cloud network is and what Openstack Neutron is trying to solve

Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.

The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.

Neutron

• It defines a clear public API how to interact with Openstack to create network objects.
• Provide Network as a Service (NaaS) to tenants to enable more advance deployments and configuration options. 
• Initially the goal was to remove the Nova Network from Openstack and create its won project to allow more flexibility and expand functionality (Nova network does support only a limited number of topologies: flat, flat DHCP and VLANs). 
• Platform for new future network development in Openstack.
• Neutron is promising a scalable and highly available infrastructure for tenants.
• There are some single point of failures (SPOF) in the current vanilla Havana release. This is one of the differences between the open source vanilla Neutron and vendor specific plugins.
• It provides a choice of technology and no vendor lock-in for network in Openstack. One way of looking at it is that the customer have a choice of what technology/vendor  he would like to use to build up the network infrastructure. The there benefit is access to an public  open API that is independent of the actual backed technology. But it is important to understand that various backed drivers may provide different and more reach functionality than the Openstack one. In this case you can always get access to this through API extension that Neutron exposes as well. In this sense you can gain additional way of interacting and using your new technology and still remain open and interoperable with feature versions.  
• It allows for vendor specific extension for more advance networking features that may not be present in current Neutron API.
• It is the platform to integrate all network functionality in cloud. Although its main focus is on the most common cases and what users demand.
• Openstack wants to be the the reference model for the next generation cloud data center and Neutron aims to provide support for the networking part.  By providing a common and widely acceptable platform it opens and allows multi network vendors integration. 
• Every vendor can have its own differentiate factors. In the current state of networking industry it is impossible to have a single API in Openstack to address every use case needs. It looks like there will be always space for vendor extension in Neutron for these infrastructure providers or customer who demand more specific and unique features that are not present yet. 
• Exposes network abstraction to developers, operation and devops teams who don't need to worry about the implemented details.

Would you run vanilla Openstack Neutron in production

This question was asked at about 41.50. There were different answers.

• If you want to run the vanilla Neutron configuration it is not recommend to run it in production without good knowledge of how all Openstack components work and interact together. 
• You can run Neutron with vendor plugin in production. By choosing a vendor plugin instead of the vanilla open source solution you get additional level of confidence and support.
• Maybe for private cloud depending on feature requirements and scalability but no for public cloud and enterprise network deployments.

The choice between Neutron Openstack vanilla vs vendor plugin needs to be always analyzed individual per customer.

• What level of (technical) support is required before and after implementation.
• How much expertise do you have in your company.
• What scalability do we talk about.
• What application do you want to run.
• What features do you require.

Other issues

There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.