OpenStack: Networking Roadmap, Collaboration and Contribution
2 likes529 views
The document provides an overview of OpenStack networking and Neutron. It discusses Neutron's architecture and history. It describes several Neutron sub-projects like Midonet, OpenDaylight, OVN, and services like firewall-as-a-service and service function chaining. The document outlines Neutron roadmaps and focus areas. It discusses various working groups and collaboration efforts between OpenStack and other communities like OPNFV and the telecom industry. The document promotes involvement in OpenStack development, events, and training.
Ad
More Related Content
What's hot (20)
Similar to OpenStack: Networking Roadmap, Collaboration and Contribution (20)
Ad
More from Open Networking Summit (19)
Ad
Recently uploaded (20)
OpenStack: Networking Roadmap, Collaboration and Contribution
- 1. OpenStack: Networking Roadmap, Collaboration and Contribution Open Networking Summit 06 April 2017 Santa Clara, CA Paul Carver, AT&T Armando Migliaccio, SUSE Ildiko Vancsa, OpenStack Foundation
- 2. Agenda • Who are we and why should you care • OpenStack Networking Overview • Q & A Intermission • OpenStack Networking Deep Dive • Q & A Intermission • OpenStack, Product WG, LCOO, Telco involvement • Final Q & A
- 3. Introductions Where are our perspectives coming from?
- 4. OpenStack
- 5. 2010 2011 2012 2013 2014 2015 2016 OpenStack is born Diablo Neutron is born Essex Neutron is incubated Folsom Neutron is core L4/L7 are experimental Grizzly ML2 is born Havana ML2 is default OpenDaylight is born Icehouse OPNFV is born Tacker is born Liberty Neutron SFC is born History ETSI NFV ISG is born DPDK is born Mitaka Neutron SFC 1.0.0 Newton Neutron OVN 1.0.0
- 6. What is Neutron anyway? • Neutron – API exposing logical abstractions for consuming the networking service – One or more backend implementations of that API • Why? – Networking constructs baked into Nova (OpenStack compute) – No tenant control over network topology and service insertion – Multi-tenancy and scalability
- 7. Neutron architecture Inception tenets ● Any network abstraction as as Service ● L2 as overlays ● Extension capabilities ● Technology agnostic Stadium ● A collection of components to provide a networking solution ● Tight governance to preserve sanity of the project ● Gaps vetted by Neutron Drivers
- 8. Neutron Server ML2 Plugin Type Manager Mechanism Manager VXLAN TypeDriver VLAN TypeDriver … OVS API Abstraction LinuxBridge SDN Controller … L3 Plugin OVS/DVR+HA SDNController … LBaaS HAProxy SDNController … FWaaS IPTables SDNController … … … Neutron architecture Quota management Policy enforcement SchedulingState and notifications
- 9. Topologies
- 10. Topologies
- 11. Topologies
- 12. Topologies
- 13. Topologies
- 15. 15 A Proposed Target Stack with Evolvability A “Nirvana” SDN Stack? Data Plane Interface VPP Automated Test Applicable Projects Neutron (+Gluon Innovations) Diverse Innovation Happens Here! Data Plane Acceleration (SW/HW) Specs Install South Bound Interface North Bound Interface 1 2 3 4
- 16. Neutron and Gluon • Similarities • Differences • How do they interact • Opinions
- 17. Q & A #1
- 18. A glance at neutron sub-projects • Midonet • OpenDaylight • OVN • BAGPIPE • BGPVPN • Dynamic Routing • Firewall as a Service • Service Function Chaining
- 19. Midonet • Midokura SDN solution • Feature rich Neutron backend • L2 gateways • Firewall • Dynamic Routing • QoS • Load Balancing • Tap-as-a-Service • https://docs.openstack.org/releasenotes/networking-midonet/
- 20. OpenDaylight •SDN controller backend • Neutron integration gone through a couple of architectural iterations • Features • L2 gateways • Firewall • QoS • Load Balancing • Service Function Chaining •https://docs.openstack.org/releasenotes/networking-odl/
- 21. Open vSwitch OVN •Open vSwitch scope expansion • Neutron features done the “OVS way” • Similar integration to other SDN controllers e.g. ODL • Features • Scale and performance • L2/L3/DHCP • Trunking • QoS • Integration with Container Orchestrators •https://docs.openstack.org/releasenotes/networking-ovn/
- 22. BaGPipe • Set of Neutron drivers developed initially by Orange Telecom • ML2 driver for tenant isolation through BGP BGP VPNs • Building block for creating reachability between Neutron ports (typically VMs) and BGP VPNs outside the cloud •https://docs.openstack.org/releasenotes/networking-bagpipe/
- 23. BGPVPN •Interconnect neutron networks with WAN BGP-based VPNs •Multi-vendor API • OVS driver • OpenDaylight • OpenContrail • Nuage •https://docs.openstack.org/releasenotes/networking-bgpvpn/
- 24. Firewall as a Service •Neutron zero-trust security model (as opposed to security groups) • v1 (Router-oriented API) • v2 (Port-oriented API) • Enforcement applied on specified router port • Consistent API for applying policies to VM ports • https://docs.openstack.org/releasenotes/neutron-fwaas/
- 25. Service Function Chaining •API to define a neutron port chain to connect SFs that consume classified traffic •Multi-vendor API • OVS driver • OpenDaylight • ONOS • OVN •https://docs.openstack.org/releasenotes/networking-sfc/
- 26. Kuryr • Container networking in Openstack • Leverages Neutron as building block • Started as Docker libnetwork driver
- 27. Kuryr • Container networking in Openstack • Leverages Neutron as building block • Started as Docker libnetwork driver
- 28. Kuryr • Container networking in Openstack • Leverages Neutron as building block • Started as Docker libnetwork driver • Extends network capabilities to Kubernetes
- 29. Kuryr • Container networking in Openstack • Leverages Neutron as building block • Started as Docker libnetwork driver • Extends network capabilities to Kubernetes
- 30. Ironic • Shared networking • Multi-tenant networking • Some limitations: e.g. ACLs, Trunking, hardware routing
- 31. Ironic • Shared networking • Multi-tenant networking • Some limitations: e.g. ACLs, Trunking, hardware routing
- 32. Ironic • Shared networking • Multi-tenant networking • Some limitations: e.g. ACLs, Trunking, hardware routing
- 33. Roadmap • Ocata (Feb 2017), Pike (Sep 2017), Queens (~Apr 2018) • Midonet • Ironic, IPv6, Container integration • OpenDaylight • Scalability improvements, incremental refinements • OVN • ML2 OVS migration, metadata API, L3 HA, Distributed SNAT, DNS • Bagpipe/BGPVPN • Finer-grained control over routing • FWaaS • SFC integration, rules logging and counters, OpenDaylight integration • SFC • NSH, Service Graph, Chaining of L2 SFs
- 34. Q & A #2
- 35. OpenStack Product Working Group • Creating Development Proposals • Development Proposals • Reflect the voice of end-users/operators • Requiring cross-community coordination • Spanning multiple releases • Maintaining a multi-release roadmap https://wiki.openstack.org/wiki/ProductTeam
- 36. User Survey Sneak Peek • More than 1400 completed surveys • Nearly 600 deployments • Two-thirds of the deployments are in production • 16% of the users are in the Telecommunications area • Online dashboard - http://www.openstack.org/analytics Next survey results are by the 19th of April https://www.openstack.org/user-survey
- 37. OpenStack Roadmap • Creation and maintenance is lead by the Product Working Group • Mid-term planning • Items are grouped into themes Latest version is planned to be released in May https://www.openstack.org/software/roadmap/
- 39. Telecom/NFV Related Working Groups • Telecom/NFV Operators Functional Team • Group formed by Telecom operators • Experience with running OpenStack in production • Focus on pain points and missing functionality • https://wiki.openstack.org/wiki/Ops-telecom-nfv • LCOO • Use cases of • Network service providers • Massively distributed cloud operators • Focus on end-to-end feature implementation upstream • https://wiki.openstack.org/wiki/LCOO
- 40. Cross-community Collaboration • Full stack CI/CD pipeline in OPNFV • Deploy the latest code base • Fast feedback on new development • NFV Interoperability testing • NFV specific testing in RefStack • In collaboration with OPNFV Functest and CVP • Feature development activities • Neutron integration • ODL • FD.io • ...
- 41. Community Involvement • Write code • New features • Bug fixes • Write documentation • OpenStack Manuals • Developer documentation • Participate in Working Groups • Attend/organize User Group meet-ups
- 42. OpenStack Upstream Institute • Upstream collaboration training • 1.5 days long • Interactive, hands-on course • Face to face training • Held before the OpenStack Summits Next training - May 6-7, 2017, Boston https://docs.openstack.org/upstream-training/
- 43. Events - OpenStack Summit • Open Infrastructure Event • Conference • Forum • Open Source Days • Meet related open source communities • See OpenStack as part of a bigger picture Upcoming Summit: May 8-11, 2017, Boston https://www.openstack.org/summit/boston-2017/
- 44. Events - PTG • Developer focused event • First PTG was held in February, 2017 in Atlanta • Cross-project discussions • Per project design discussions Save the date - September 11-15, 2017, Denver https://www.openstack.org/ptg/
- 45. Q & A #3