[ lightning talk done during the OpenStack Summit, Sydney Nov. 2018 ] Provide network interconnections between Openstack clouds ? between regions ? DC pods ? Neutron today offers floating IPs and IPSec VPNaaS. However these are not always good enough: sometimes private addressing and network isolation is needed, but avoiding the overhead of IPSec encryption would be preferable. How to avoid the overhead of adding an orchestrator ? Solutions also exists to create interconnections in ways specific to each overlay technology or SDN backends, but they will require central coordination via an orchestrator (not always possible), and sometimes also the provisioing of network devices (not always simple). "Neutron talking to Neutron" This talk exposes and showcases a solution where Openstack projects define their network interconnection needs across regions or clouds, and Neutron endpoints in the different regions coordinate together in a simple way to setup these private isolated interconnections. Without orchestration nor network device configuration.

1. Neutron-Neutron
interconnections
Thomas Morin
VM VM VM VM VM VM
?

2. 2
How to interconnect two OpenStack deployments ?
( …… two or more OpenStack ? two regions ?)
Between datacenters or between NFV POPs,
you may want network interconnections with
the following properties:
on demandon demand
VM VM VM VM VM VM
?
… between NFV PoPs
and/or datacenters…
private addressing
& isolation
private addressing
& isolation
++
avoid the overhead of
packet encryption
avoid the overhead of
packet encryption
++

3. 3
Doing this with
an orchestrator ?
VM VM VM VM VM VM
?
… between NFV PoPs
and/or datacenters…
?
? ?
not always possible...
not always wanted...
 contexts where there isn't a
single organization involved
 need to expose an API to the
projects
 extra complexity

4. 4
“Neutron-Neutron” API:
●
check if the reverse link
is defined on the other side
●
bis: not yet 
●
bis: OK ! 
●
expose/retrieve the technical
details on how to do realize
connectivity ()
●
parameters vary depending
on the technique to use
At the end of the exchange...
Each side has the necessary
information and can setup the
interconnection ()
“User facing” API :
let a project define that a local
Router is linked to a Router on
another Openstack
=> define the link symmetrically
on both sides (,)
Let's extend
Neutron's API !
VM VM VM VM VM VM
Neutron Neutron
 

 
bis

bis

5. 5
 Trusting that the interconnection preserves isolation
 Goal:
 no interconnection setup unless explictly asked by each project/tenant
 How ?
 Interconnect if and only if both sides agree (symmetric link check)
 Each OpenStack instance has to trust the packets from the other OpenStack instances
 This proposal is for organizations/entities trusting each other,
and trusting the network used to carry interconnections
 Authenticating Neutron-Neutron API exchanges
 Each Neutron component on each side needs credentials to talk to the other side
 Not to act as the project/tenant
 Not to act as admin
 Only need creds for a specific role with read-only access to interconnection info
 Keystone federation is not strictly needed for functionality, but will be in practice necessary to
avoid too much configuration overhead
Multitenancy & need for network isolation
imply that we address trust questions

6. 6
Multiple interconnection techniques are possible...
● Requirements for a
technique to be applicable
– Provide isolated network
connectivity
● L2 and/or L3
– Interoperability preferred:
makes the solution applicable
between two OpenStack that
do not use the same SDN
controller solution
● Examples
– VLAN hand-off
– VXLAN gateway
– L2GW
– BGP VPNs
– ...
Example with BGP VPNs
● How ?
– each side provides the routing identifier which the other side
will use to import routes for this interconnection
– connectivity realized whether as an overlay over the WAN, or
with the collaboration of WAN BGP VPN routing
● Benefits ?
– Each side independently allocates identifiers
=> no need to coordinate the use of a common space of
identifiers
● (because BGP RTs have are structured, prefixed typically by
an AS number)
– Can be implemented in Neutron by reusing the existing
BGPVPN Interconnection API
● (the BGPVPN Interconnection API already allows
interconnections, but not on demand because requiring the‑demand because requiring the
admin to create resources)
● will work with Neutron ref. drivers and many SDN controllers
– Applicable to both IP and Ethernet interconnects

7. 7
Neutron-Neutron interconnections
Wrap up
● Allows interconnections
– On-demand
– No need for an orchestrator
– Light on packet dataplane (no IPSec)
● between OpenStack instances
– two OpenStack instances or more
– between trusting entities
– inter clouds, inter regions, inter DCs, between NFV POPs‑demand because requiring the ‑demand because requiring the ‑demand because requiring the
– including when these instances use a different SDN solution
● Next steps ?
– Neutron Specs being redacted
– Implementation to be proposed based on a PoC implementation by Orange
● Service composition: reusing the existing
Neutron BGPVPN Interconnection service
VM VM VM VM VM VM
?