1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) Bin Hu
Hub and Spoke Case
------------------
Description
~~~~~~~~~~~
There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by
Vendor A, and run on host A. SDN Controller B and vRouter B are provided by
Vendor B, and run on host B.
There is 1 tenant. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24.
The network topology is shown in :numref:`l3vpn-hub-spoke-figure`:
.. figure:: images/l3vpn-hub-spoke.png
:name: l3vpn-hub-spoke-figure
:width: 100%
In L3VPN Blue, vFW(H) is acting the role of ``hub`` (a virtual firewall).
The other 3 VNFsVMs are ``spoke``. vFW(H) and VNF1(S) are spawned on host A,
and VNF2(S) and VNF3(S) are spawned on host B. vFW(H) (10.1.1.5) and VNF2(S)
(10.1.1.6) are attached to subnet 10.1.1.0/24. VNF1(S) (10.3.7.9) and VNF3(S)
(10.3.7.10) are attached to subnet 10.3.7.0/24.
Derrived Requirements
~~~~~~~~~~~~~~~~~~~~~
Northbound API / Workflow
+++++++++++++++++++++++++
Exemplary vFW(H) Hub VRF is as follows:
* RD1 10.1.1.5 IP_OVR1 Label1
* RD1 0/0 IP_OVR1 Label1
* Label 1 Local IF (10.1.1.5)
* RD3 10.3.7.9 IP_OVR1 Label2
* RD2 10.1.1.6 IP_OVR2 Label3
* RD4 10.3.7.10 IP_OVR2 Label3
Exemplary VNF1(S) Spoke VRF is as follows:
* RD1 0/0 IP_OVR1 Label1
* RD3 10.3.7.9 IP_OVR1 Label2
Exemplary workflow is described as follows:
1. Create Network
2. Create VRF Policy Resource
2.1. Hub and Spoke
3. Create Subnet
4. Create Port
4.1. Subnet
4.2. VRF Policy Resource, [H | S]
Data model objects
++++++++++++++++++
- TBD
Orchestration
+++++++++++++
- TBD
Dependencies on compute services
++++++++++++++++++++++++++++++++
- TBD
Current implementation
++++++++++++++++++++++
Different APIs have been developed to support creating a network topology and directing
network traffic through specific network elements in specific order, for example, [BGPVPN]_
and [NETWORKING-SFC]_. We analyzed those APIs regarding the Hub-and-Spoke use case.
BGPVPN
''''''
Support for creating and managing L3VPNs is in general available in OpenStack
Neutron by means of the BGPVPN API [BGPVPN]_. However, the [BGPVPN]_ API
does not support creating the Hub-and-Spoke topology as outlined above, i.e.
setting up specific VRFs of vFW(H) and other VNFs(S) within one L3VPN to direct
the traffic from vFW(H) to VNFs(S).
The [BGPVPN]_ API currently supports the concepts of network- and
router-associations. An association in principle maps to a VRF that
interconnects either subnets of a Neutron network (network association) or the
networks connected by a router (router association). It does not yet allow for
creating VRFs per VM port (port associations) as illustrated in Hub-and-Spoke use case.
The functionality of port association is needed, however, to create separate VRFs per VM
in order to implement the Hub-and-Spoke use case. Furthermore, the functionality of setting
up next-hop routing table, labels, I-RT and E-RT etc in VRF is also required to enable
traffic direction from Hub to Spokes.
It may be argued that given the current network- and router-association mechanisms,
the following workflow establishes a network topology which aims to achieve the desired
traffic flow from Hub to Spokes. The basic idea is to model separate VRFs per VM
by creating a dedicated Neutron network with two subnets for each VRF in the
Hub-and-Spoke topology.
1. Create Neutron network "hub"
:code:`neutron net-create hub`
2. Create a separate Neutron network for every "spoke"
:code:`neutron net-create spoke-i`
3. For every network (hub and spokes), create two subnets
:code:`neutron subnet-create <hub/spoke-i network UUID> 10.1.1.0/24`
:code:`neutron subnet-create <hub/spoke-i network UUID> 10.3.7.0/24`
4. Create a BGPVPN object (VRF) for the hub network with the corresponding import
and export targets
:code:`neutron bgpvpn-create --name hub-vrf --import-targets <RT-hub RT-spoke> --export-targets <RT-hub>`
5. Create a BGPVPN object (VRF) for every spoke network with the corresponding import
and export targets
:code:`neutron bgpvpn-create --name spoke-i-vrf --import-targets <RT-hub> --export-targets <RT-spoke>`
6. Associate the hub network with the hub VRF
:code:`bgpvpn-net-assoc-create hub --network <hub network-UUID>`
7. Associate each spoke network with the corresponding spoke VRF
:code:`bgpvpn-net-assoc-create spoke-i --network <spoke-i network-UUID>`
After step 7, VMs can be booted on the corresponding networks.
The resulting network topology tries to resemble our target topology as shown in
:numref:`l3vpn-hub-spoke-figure`, and achieve the desired traffic direction from Hub to Spoke.
However, it deviates significantly from the essence of the Hub-and-Spoke use case as
described above in terms of desired network topology, i.e. one L3VPN with multiple
VRFs associated with vFW(H) and other VNFs(S) separately. And this method of using
the current network- and router-association mechanism is not scalable when there are large
number of Spokes, and in case of scale-in and scale-out of Hub and Spokes.
The gap analysis in the next section describes the technical reasons for this.
Network SFC
'''''''''''
Support of Service Function Chaining is in general available in OpenStack Neutron through
the Neutron API for Service Insertion and Chaining project [NETWORKING-SFC]_.
However, the [NETWORKING-SFC]_ API is focused on creating service chaining through
NSH at L2, although it intends to be agnostic of backend implementation. It is unclear whether
or not the service chain from vFW(H) to VNFs(S) can be created in the way of L3VPN-based
VRF policy approach using [NETWORKING-SFC]_ API.
Hence, it is currently not possible to configure the networking use case as described above.
Gaps in Current Solution
++++++++++++++++++++++++
Given the use case description and the currently available implementation in
OpenStack provided by [BGPVPN]_ project and [NETWORKING-SFC]_ project,
we identify the following gaps:
* [L3VPN-HS-GAP1] The [BGPVPN]_ project lacks port-associations
The workflow described above intents to mimic port associations by means of
separate Neutron networks. Hence, the resulting workflow is overly complicated
and not intuitive by requiring to create additional Neutron entities
(networks) which are not present in the target topology. This method is also not scalable.
Within the [BGPVPN]_ project, design work on port-association has started. The
timeline for this feature is however not defined yet. As a result, creating a
clean Hub-and-Spoke topology is current not yet supported by the [BGPVPN]_ API.
* [L3VPN-HS-GAP2] Creating a clean hub-and-spoke topology is current not yet supported by the [NETWORKING-SFC]_ API.
|
