This is a slide deck which Carl Baldwin and I presented at Linuxcon North America 2015 in Seattle.

1. Networking PTL
IRC: mestery
@mestery
What’s New In Kilo and
a Look Toward Liberty
OpenStack Networking
Kyle Mestery
Networking L3 Lead
IRC: carl_baldwin
Carl Baldwin

2. What Is OpenStack Neutron?
Neutron’s Mission:
To implement services and associated libraries
to provide on-demand, scalable, and
technology-agnostic network abstraction.

3. OpenStack Neutron
is a Community

4. Neutron: A bit of Quantum History
● April 2011: Interested parties converge to create a
common networking API for OpenStack with the moniker
Quantum
● September 2012: Quantum a part of Folsom Release
● October 2013: Quantum renamed to Neutron
● May 2015: Neutron rankings for Kilo release
● #1 for reviews
● #1 for resolved bugs
● #2 for patchsets
● #2 in email volume
● #3 in commits
● #4 in lines of code

5. Neutron Deployments
● According to the spring 2015 user survey results:
● 76% of production installations are on Neutron vs. nova-network
● OVS at 46% of production installs (up 3%)
● Linuxbridge at 19% of production installs (up 4%)
● nova-network production usage dropped from 30% to 24%

6. OpenStack Neutron Kilo Features

7. Neutron Kilo Release: By the Numbers
● 45 blueprints completed
● 544 bugs closed
● Advanced services split into separate git repositories and
release tarballs
● Plugin decomposition effort started resulting in 10+
plugin/driver decomposition efforts

8. A Plethora of Drivers and Plugins in Kilo
● Plugins
● -------
● bigswitch
● brocade
● cisco
● embrane
● hyperv
● ibm
● metaplugin
● ml2
● midonet
● nec
● nuage
● oneconvergence
● opencontrail
● plumgrid
● sriovnicagent
● vmware
● ML2 Drivers
● -----------
● arista
● brocade
● cisco apic
● cisco n1kv
● cisco ncs
● cisco nexus
● cisco ucsm/
● freescale
● hyperv
● ibm
● l2pop
● linuxbridge
● mech_nuage
● mlnx
● ovsvapp
● opendaylight
● openvswitch
● ofagent
● sriov
● Out of Tree
● -----------
● Dragonflow
● Octavia
● networking-bgpvpn
● networking-cisco
● networking-l2gw
● networking-midonet
● networking-odl
● networking-ofagent
● networking-ovn
● networking-sfc
● VMware NSX
● Service Plugins
● ---------------
● A10 LBaaS
● Brocade LBaaS
● Freescale FWaaS
● Cisco FWaaS
● Cisco VPNaaS
● Freeswan VPNaaS
● HA Proxy LBaaS
● iptables FWaaS
● KEMP Technologies
LBaaS
● Citrix Netscaler
LBaaS
● Radware LBaaS
● StrongSwan VPNaaS
● Varmour FWaaS
● Vyatta FWaaS
● Vyatta VPNaaS

9. Plugin Decomposition
● Addresses pain points: review time, iteration speed,
easier to use vendor specific modules
● Move to thin in-tree plugins and drivers, with plugin and
driver functionality maintained outside of Neutron
● Allows for fast iteration for both core Neutron as well as
plugins and drivers

10. Advanced Services Split
● Migrate out LBaaS, VPNaaS, and FWaaS into separate
git repositories
● Allow operators the flexibility of running the services they
want to offer their tenants
● Allow the services teams the chance to iterate quickly
outside the scope of core neutron
● Reduce gate testing complexity
● Optimize core parts of Neutron into a library

11. Testing
● Full-stack testing
● Functional testing of OVS, LB, DHCP and metadata
agents
● Retargetable functional tests

12. Agent Refactoring
● L2 Agent
● Scalability
● Agent functional testing
● RPC improvements
● OVSDB monitoring improvements
● L3 Agent
● Scalability
● Paying down technical debt
● Abstracting out service agents
● DHCP Agent
● Scalability
● Restart improvements
● Load based scheduling
● Dead agent rescheduling
● Functional Tests

13. Speed and Reliability Improvements
● Agent Child Process Status: Monitors agents and restarts
them when they exit
● Rootwrap Daemon Mode: High performance access to
root for commands run by Neutron agents

14. IPv6
● IPv6 networks are well-supported
● No distributed routing for IPv6
● No floating IPs for IPv6
● Creates a bit of a problem for “bring your own address”

15. Subnet Pools
● Solution to “bring your own addresses”
● Manages allocation of addresses to tenants
● Prevents duplication of addresses

16. OpenStack Neutron Liberty Features

17. Neutron Liberty Release: By the Numbers
● 35 blueprints targeted
● 522 bugs targeted
● Plugin decomposition effort continuing resulting in most
drivers and plugins being out of tree now

18. Neutron Stadium
● In accordance with the “Big Tent” OpenStack governance
model, Neutron has also changed its governance model
● Allowing plugin backends to re-enter Neutron via the
Stadium as their own gerrit repositories
● Growing the ecosystem under Neutron as a platform

19. Neutron Governance Changes
● New Lieutenant Model allows scaling core reviewers
● New process for defining work (Request For
Enhancement or RFE) allows for streamlining the way
work is proposed

20. Plugin Decomposition: Phase 2
● Phase 1 completed during Kilo
● Phase 2 will completely remove all third-party code from
the main Neutron repository
● Split out the reference implementation plugin into it’s own
repository
● Advanced services decomposition as well
● With governance changes, most repositories are now
being added into the Neutron Stadium

21. Neutron and nova-network
● Lots of time spent cross pollinating between Neutron and
Nova teams
● Many shared sessions in Vancouver
● PTL sync points
● Neutron has supported the same deployment models as
nova-network for many years
● These are documented now
● Installation guide removed references to nova-network
● New installs are now pointed to Neutron at installation time
● Neutron part of tag “starter-kit:compute”
● https://review.openstack.org/#/c/196438/

22. DefCore and Networking
● DefCore taking on networking this cycle
● Neutron will be the networking choice for DefCore

23. Neutron QoS
● Liberty focus is to enable bandwidth limiting
● We will also layout the QoS models for future API and
model extensions introducing additional QoS concepts
● QoS policies apply either per-port or per-network
● Feature branch entered merge queue to master moments
ago!

24. Neutron LBaaS V2
● Support for Layer-7 switching (e.g. content based routing)
● Support Octavia as the default reference implementation
● Service-VM based implementation using haproxy

25. Flavor Framework
● Way for operators to offer network services to their clients
● Allows separation of driver functionality and configuration
from consumers of services
● Operators can configure additional vendor features in an
end-user agnostic way

26. NFV Work
● Working with the NFV sub-team in OpenStack to integrate
features relevant in this space
● More seamlessly connect hardware and neutron L2
segments (e.g. with Ironic)
● Unaddressed port (e.g. port without an l3-address and
subnet attachment)
● Trunk ports to virtual machines

27. Role Based Access Control
for Networks
● Currently, the shared network concept is not granular
● This work will allow for a more granular approach and
allow tenants to share network resources with other
tenants
● Allows an operator to define a network with limited
access, but also covers the case where operators pre-
create networks for tenants to connect to

28. Pluggable IPAM
● Create a pluggable IPAM system inside of Neutron
● Allows the use of third-party and vendor IPAM system
● Separates IPAM from Neutron core DB model
● Liberty
● Reference implementation available as alternative
● Enables third-party systems
● Mitaka
● Migration provided to new reference
● Old reference will be removed

29. Prefix Delegation
● Assignment of tenant IPv6 subnets from PD server
● Alternative to IPAM for IPv6
● Handles the routing next hop

30. DNS Names
● DNS name set on a port
● It will be used for local DNS lookups with dnsmasq
● In Mitaka, it can be given to an external DNS system

31. A Look Towards Mitaka

32. Address Scopes
● Subnet pools are assigned to a scope
● No Duplicate addresses
● Routing will not traverse scopes without NAT
● No NAT for routing in the same scope, even “externally”

33. Routed Networks
● Bound the L2 domain
● e.g. route to the top-of-rack
● Not solved by overlays
● For large shared and external networks
● Both “static” and “dynamic” routing
● Schedule instances where IPs are available
● Neutron API and model changes are likely

34. BGP Announcements
● Neutron to speak BGP to the datacenter
● Next hop for subnets in the same address scope
● Floating IPs
● Tenant networks

35. Service Function Chaining
● The idea is simple:
● Service VMs need to be attached at points in the network
● Traffic needs to be steered into these ports
● Create a traffic steering model for chaining which uses
Neutron ports
● Work is being done in a Neutron Stadium project
● networking-sfc project
● “release:independent”
● Expect a release later this fall

36. Container Networking in OpenStack
● Container networking and VM networking working in
harmony: Enter Kuryr
● Kuryr is a generic Docker remote driver which connects
containers to Neutron APIs
● Provides containerized images of common Neutron plugins
● Works as a translator between the Container Network Model and the
Neutron API
● A small snippet of code for “plugging” containers in is required
● Focus is to satisfy Magnum project’s networking
requirements for containers
● Being developed in Neutron stadium!

37. OVN
● OVN is Open Source virtual networking for Open vSwitch
● Provides L2/L3 virtual networking
● SGs
● L2/L3/L4 ACLs
● Multiple tunnel overlays (STT and Geneve)
● ToR and software-based logical to physical gateways
● Code is being developed in Neutron Stadium!
● OVN itself in OVS repo
● Neutron plugin in networking-ovn repo
● How is OVN different?
● No agents for simplified deployment
● SGs utilize in-kernel connection tracker support
● DPDK-based and HW accelerated gateways

38. Thank you for your support!
[Neutron] on openstack-dev mailing list
#openstack-neutron Freenode