1
Openstack Neutron &
Interconnections with
BGP/MPLS VPNs
Thomas Morin
Orange Labs
2016-03-10
2
Why a need to interconnect Openstack and BGP/MPLS
VPNs ?
 network operators using BGP/MPLS VPNs
need to interconnect IaaS platforms with these VPNs
– public cloud
– internal cloud
– NFV platforms <-> service networks
 Openstack de-facto IaaS foundation
 what API to drive Openstack interconnections with BGP/MPLS VPNs?
 what implementation behind this API ?
3
Interconnect Openstack and BGP/MPLS VPNs
Goals and Use Cases ?
 Today, we can:
– use “SDN Controller” X,Y or Z to
create connectivity between VMs
and BGP VPNs
– (for some values of X only)
– use specific APIs of X,Y,Z to drive
these interconnections
– often tenant credentials are not
enough, need to be admin
 Goals:
– have a single controller-agnostic
API to drive these interconnections
– allow tenants to drive what these
interconnections
– (but only in their VPNs!)
– have this feature in Neutron itself
– for use in Openstack
continuous integration
– as an alternative for
deployment
4
Openstack Neutron networking-bgpvpn project
A Neutron API to drive BGP VPN interconnections
 What it is about ?
– a service plugin that inserts into Neutron and exposes
an API for BGPVPN Interconnection
– tenant “I want Network X to be interconnected with BGPVPN foo”
– how is an interconnection defined through the API realized ?
– depends on the driver ! (see next slides)
 A bit of history
– API proposal started 2+ years ago
– lead by Nachi Ueno and Pedro Marques)
– Effort re-started one year ago by Orange
– with an opensourced implementation as a starting point
– Triggered interest around Openstack Vancouver summit
– Welcome in Openstack “big tent” / Neutron “stadium”
– Creation of the Openstack networking-bgpvpn project in June 2015
5
dataplane
(vswitch/ vrouter)
Neutron BGP VPN Interconnections service plugin
Overview
Neutron
Backend X
(e.g. Neutron+Bagpipe, OpenDaylight,
OpenContrail, Nuage)
BGP
Peers
VMs… …
driver for
backend X
BGP
VPN
routes
packets carried
over MPLS
toward VPNs
API
BGPVPN
Service Plugin





driver for
X…
6
Neutron and BGP VPN Interconnections
API constructs and workflows
 Key API Constructs
– “BGPVPN” resource
– contains BGP-specific
parameters
– in particular import/export
Route Targets
– “Network Association” resource
– associates a BGPVPN with
a said Neutron Network
– “Router association” resource
– (same idea)
 Workflows
– a BGPVPN is created by the
admin, with chosen BGP
parameters, and given to a
tenant
– (tenant cannot modify nor read
BGP parameters)
– the tenant can then choose to
associate a BGP VPN it owns to
a Network or Router
API reference: http://docs.openstack.org/developer/networking-bgpvpn/api.html
7
How it works with Neutron+BaGPipe …
Neutron
compute node
BGP
Peers
VMs… …
BGP
VPN
routes
packets carried
over MPLS
towards VPNs
API
BGPVPN
Service Plugin


bagpipe
driver OpenVSwitch
Neutron OVS
agent bagpipe
BGP

Openstack
message bus

bagpipe
extension
8
Neutron
SDN Controller
BGP
Peers
driver for
backend X
BGP
VPN
routes
packets carried
over MPLS
toward VPNs
API
BGPVPN
Service Plugin

 REST


How it works with an SDN Controller…
e.g. OpenDaylight, OpenContrail, Nuage Networks …
driver for SDN
Controller X
compute node
VMs
NBI
BGP
SBI

VMs
compute node
VMs VMs
vswitch vswitch
9
Status
 First release (was in December)
– works with Openstack last release (Liberty)
– base features:
– BGPVPN, Network associations, Router associations
– Neutron CLI support
– includes drivers for:
– Neutron ML2/OpenVSwitch (with bagpipe)
– OpenDaylight
– OpenContrail
– (Nuage Networks driver is coming, out of tree)
 Available backports for two previous releases
– Juno
– Kilo
10
Diversification of Contributors!
http://stackalytics.com/?module=networking-bgpvpn&metric=patches&release=mitaka
project startup
period
(May-Oct. 2015)
now
(past 5 months)
11
What is next ?
 Next release will target Openstack Mitaka
 Already ready:
– Heat support
– bagpipe driver improvements
 Planned
– GUI in Openstack dashboard (Horizon)
– driver support for E-VPN (API already here)
– static routes
– prefix aggregation
12
Future / Radar
 intra-DC inter-tenant
 inter-DC
 inter-DC / Neutron2Neutron
13
A word on OPNFV
 Openstack networking-bgpvpn project has a peer project “SDNVPN” in OPNFV
 The Neutron BGPVPN Interconnection service plugin and the OpenDaylight
driver are part of OPNFV very recent release (Brahmaputra, March 1st)
 OPNFV triggered very useful contributions around Openstack work
– installer support
– Fuel
– APEX/RDOManager
– functional testing (Tempest, Functest)
 More to come this year
 OPNFV can be a strong catalyzer for “Telco“ work in Openstack
14
Conclusions
 Openstack networking-bgpvpn is a new service exposing an API, letting
admins give tenant control over how their Openstack networks and routers are
interconnected with BGP VPNs
 One Neutron service + API, with driver mapping toward SDN controllers
 … but also usable without a controller !
 A practical one-year illustration of a possible way to kickstart Telco-specific
work in Openstack
 We’re happy to have be joined by others having a mutual interest in moving
this forward !
15

Openstack Neutron, interconnections with BGP/MPLS VPNs

  • 1.
    1 Openstack Neutron & Interconnectionswith BGP/MPLS VPNs Thomas Morin Orange Labs 2016-03-10
  • 2.
    2 Why a needto interconnect Openstack and BGP/MPLS VPNs ?  network operators using BGP/MPLS VPNs need to interconnect IaaS platforms with these VPNs – public cloud – internal cloud – NFV platforms <-> service networks  Openstack de-facto IaaS foundation  what API to drive Openstack interconnections with BGP/MPLS VPNs?  what implementation behind this API ?
  • 3.
    3 Interconnect Openstack andBGP/MPLS VPNs Goals and Use Cases ?  Today, we can: – use “SDN Controller” X,Y or Z to create connectivity between VMs and BGP VPNs – (for some values of X only) – use specific APIs of X,Y,Z to drive these interconnections – often tenant credentials are not enough, need to be admin  Goals: – have a single controller-agnostic API to drive these interconnections – allow tenants to drive what these interconnections – (but only in their VPNs!) – have this feature in Neutron itself – for use in Openstack continuous integration – as an alternative for deployment
  • 4.
    4 Openstack Neutron networking-bgpvpnproject A Neutron API to drive BGP VPN interconnections  What it is about ? – a service plugin that inserts into Neutron and exposes an API for BGPVPN Interconnection – tenant “I want Network X to be interconnected with BGPVPN foo” – how is an interconnection defined through the API realized ? – depends on the driver ! (see next slides)  A bit of history – API proposal started 2+ years ago – lead by Nachi Ueno and Pedro Marques) – Effort re-started one year ago by Orange – with an opensourced implementation as a starting point – Triggered interest around Openstack Vancouver summit – Welcome in Openstack “big tent” / Neutron “stadium” – Creation of the Openstack networking-bgpvpn project in June 2015
  • 5.
    5 dataplane (vswitch/ vrouter) Neutron BGPVPN Interconnections service plugin Overview Neutron Backend X (e.g. Neutron+Bagpipe, OpenDaylight, OpenContrail, Nuage) BGP Peers VMs… … driver for backend X BGP VPN routes packets carried over MPLS toward VPNs API BGPVPN Service Plugin      driver for X…
  • 6.
    6 Neutron and BGPVPN Interconnections API constructs and workflows  Key API Constructs – “BGPVPN” resource – contains BGP-specific parameters – in particular import/export Route Targets – “Network Association” resource – associates a BGPVPN with a said Neutron Network – “Router association” resource – (same idea)  Workflows – a BGPVPN is created by the admin, with chosen BGP parameters, and given to a tenant – (tenant cannot modify nor read BGP parameters) – the tenant can then choose to associate a BGP VPN it owns to a Network or Router API reference: http://docs.openstack.org/developer/networking-bgpvpn/api.html
  • 7.
    7 How it workswith Neutron+BaGPipe … Neutron compute node BGP Peers VMs… … BGP VPN routes packets carried over MPLS towards VPNs API BGPVPN Service Plugin   bagpipe driver OpenVSwitch Neutron OVS agent bagpipe BGP  Openstack message bus  bagpipe extension
  • 8.
    8 Neutron SDN Controller BGP Peers driver for backendX BGP VPN routes packets carried over MPLS toward VPNs API BGPVPN Service Plugin   REST   How it works with an SDN Controller… e.g. OpenDaylight, OpenContrail, Nuage Networks … driver for SDN Controller X compute node VMs NBI BGP SBI  VMs compute node VMs VMs vswitch vswitch
  • 9.
    9 Status  First release(was in December) – works with Openstack last release (Liberty) – base features: – BGPVPN, Network associations, Router associations – Neutron CLI support – includes drivers for: – Neutron ML2/OpenVSwitch (with bagpipe) – OpenDaylight – OpenContrail – (Nuage Networks driver is coming, out of tree)  Available backports for two previous releases – Juno – Kilo
  • 10.
  • 11.
    11 What is next?  Next release will target Openstack Mitaka  Already ready: – Heat support – bagpipe driver improvements  Planned – GUI in Openstack dashboard (Horizon) – driver support for E-VPN (API already here) – static routes – prefix aggregation
  • 12.
    12 Future / Radar intra-DC inter-tenant  inter-DC  inter-DC / Neutron2Neutron
  • 13.
    13 A word onOPNFV  Openstack networking-bgpvpn project has a peer project “SDNVPN” in OPNFV  The Neutron BGPVPN Interconnection service plugin and the OpenDaylight driver are part of OPNFV very recent release (Brahmaputra, March 1st)  OPNFV triggered very useful contributions around Openstack work – installer support – Fuel – APEX/RDOManager – functional testing (Tempest, Functest)  More to come this year  OPNFV can be a strong catalyzer for “Telco“ work in Openstack
  • 14.
    14 Conclusions  Openstack networking-bgpvpnis a new service exposing an API, letting admins give tenant control over how their Openstack networks and routers are interconnected with BGP VPNs  One Neutron service + API, with driver mapping toward SDN controllers  … but also usable without a controller !  A practical one-year illustration of a possible way to kickstart Telco-specific work in Openstack  We’re happy to have be joined by others having a mutual interest in moving this forward !
  • 15.