| 2018-02-20 15:50:06 |
Thomas Morin |
description |
Today, to realize connectivity between two OpenStack clouds (e.g. two distinct
OpenStack deployments, or two OpenStack regions, for instance) some options are
available, such as floating IPs, VPNaaS (IPSec-based), and BGPVPNs.
However, none of these options are appropriate to address use cases where all
the following properties are desired:
* interconnection consumable on-demand, without admin intervention
(possible with floating IPs, VPNaaS, but not with the BGP VPN
interconnections API extension)
* have network isolation and allow the use of private IP addressing end-to-end
(possible with VPNaaS, and BGP VPN interconnections, but not with
floating IPs)
* avoid the overhead of packet encryption
(possible with floating IPs, and BGP VPN interconnections, but by
construction not with VPNaaS)
The goal of this RFE is to propose a solution to provide network connectivity
between two or more OpenStack deployments or regions, respecting these
constraints. |
Today, to realize connectivity between two OpenStack clouds (e.g. two distinct OpenStack deployments, or two OpenStack regions, for instance) some options are available, such as floating IPs, VPNaaS (IPSec-based), and BGPVPNs.
However, none of these options are appropriate to address use cases where all
the following properties are desired:
* interconnection consumable on-demand, without admin intervention (possible with floating IPs, VPNaaS, but not with the BGP VPN interconnections API extension)
* have network isolation and allow the use of private IP addressing end-to-end (possible with VPNaaS, and BGP VPN interconnections, but not with floating IPs)
* avoid the overhead of packet encryption (possible with floating IPs, and BGP VPN interconnections, but by construction not with VPNaaS)
The goal of this RFE is to propose a solution to provide network connectivity
between two or more OpenStack deployments or regions, respecting these
constraints. |
|
