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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) Bin Hu
L3VPN Use Cases
===============
Service Providers' virtualized network infrastructure may consist of one or more
SDN Controllers from different vendors. Those SDN Controllers may be managed
within one cloud or multiple clouds. Jointly, those VIMs (e.g. OpenStack instances)
and SDN Controllers work together in an interoperable framework to create L3 services
in Service Providers' virtualized network infrastructure.
Three use cases of creating L3VPN service by multiple SDN Controllers are described
as follows.
Any-to-Any Base 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 are 2 tenants. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24.
Tenant 2 creates L3VPN Red with 1 subnet, overlapping address space: 10.1.1.0/24.
The network topology is shown in :numref:`l3vpn-any2any-figure`:
.. figure:: images/l3vpn-any2any.png
:name: l3vpn-any2any-figure
:width: 100%
In L3VPN Blue, VMs G1 (10.1.1.5) and G2 (10.3.7.9) are spawned on host A, and attached to 2 subnets
(10.1.1.0/24 and 10.3.7.0/24) and assigned IP addresses respectively. VMs G3 (10.1.1.6) and
G4 (10.3.7.10) are spawned on host B, and attached to 2 subnets (10.1.1.0/24 and 10.3.7.0/24)
and assigned IP addresses respectively.
In L3VPN Red, VM G5 (10.1.1.5) is spawned on host A, and attached to subnet 10.1.1.0/24. VM G6
(10.1.1.6) is spawned on host B, and attached to the same subnet 10.1.1.0/24.
VRF Lets us do:
1. Overlapping Addresses
2. Segregation of Traffic
Derrived Requirements
~~~~~~~~~~~~~~~~~~~~~
- TBD
Northbound API / Workflow
+++++++++++++++++++++++++
Exemplary workflow is described as follows:
1. Create Network
2. Create Network VRF Policy Resource ``Any-to-Any``
2.1. This sets up that when this tenant is put on a HOST that:
2.1.1. There will be a RD assigned per VRF
2.1.2. There will be a RT used for the common any-to-any communication
3. Create Subnet
4. Create Port (subnet, network vrf policy resource). This causes controller to:
4.1. Create vrf in vRouter's FIB, or Update vrf if already exists
4.2. Install an entry for Guest's HOST-Route in FIBs of Vrouters serving this tenant Virtual Network
4.3. Announce Guest HOST-Route to WAN-GW via MP-BGP
Data model objects
++++++++++++++++++
- TBD
Orchestration
+++++++++++++
- TBD
Dependencies on compute services
++++++++++++++++++++++++++++++++
- TBD
Potential implementation
~~~~~~~~~~~~~~~~~~~~~~~~
Support for creating and managing L3VPNs is available in OpenStack Neutron by
means of the BGPVPN project (add REF). In order to create the L3VPN network
configuration described above using the API BGPVPN API, the following workflow
is needed:
1. Create a Neutron network "blue"
:code:`neutron net-create blue`
2. Create the first Neutron subnet of the network "blue"
:code:`neutron subnet-create <blue network UUID> 10.1.1.0/24`
3. Create the second Neutron subnet of the network "blue"
:code:`neutron subnet-create <blue network UUID> 10.3.7.0/24`
4. Create a L3VPN by means of the BGPVPN API
:code:`neutron bgpvpn-create --route-targets 64512:1 --tenant-id <tenant-id> --name blue`
5. Associate the L3VPN with the previously created network
:code:`neutron bgpvpn-net-assoc-create blue --network <network-UUID>`
This command associates the given Neutron network with the L3VPN. The semantic
of this operation is that all subnets bound to the network are getting
interconnected through the BGP VPN and hence VMs located in either subnet can
communicate with each other.
Gaps in the current solution
~~~~~~~~~~~~~~~~~~~~~~~~
TBD
Conclusion
~~~~~~~~~~
TBD
ECMP Load Splitting Case (Anycast)
----------------------------------
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 subnet 10.1.1.0/24.
The network topology is shown in :numref:`l3vpn-ecmp-figure`:
.. figure:: images/l3vpn-ecmp.png
:name: l3vpn-ecmp-figure
:width: 100%
In L3VPN Blue, VNF1.1 and VNF1.2 are spawned on host A, attached to subnet 10.1.1.0/24
and assigned the same IP address 10.1.1.5. VNF1.3 is spawned on host B, attached to
subnet 10.1.1.0/24 and assigned the same IP addresses 10.1.1.5. VNF 2 and VNF 3 are spawned
on host A and B respectively, attached to subnet 10.1.1.0/24, and assigned different IP
addresses 10.1.1.6 and 10.1.1.3 respectively.
Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to **Anycast 10.1.1.5**
can be load split from either WAN GW or another VM like G5.
Derrived Requirements
~~~~~~~~~~~~~~~~~~~~~
- TBD
Northbound API / Workflow
+++++++++++++++++++++++++
- TBD
Data model objects
++++++++++++++++++
- TBD
Orchestration
+++++++++++++
- TBD
Dependencies on compute services
++++++++++++++++++++++++++++++++
- TBD
Potential implementation
++++++++++++++++++++++++
- TBD
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.
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]
Derrived Requirements
~~~~~~~~~~~~~~~~~~~~~
- TBD
Northbound API / Workflow
+++++++++++++++++++++++++
- TBD
Data model objects
++++++++++++++++++
- TBD
Orchestration
+++++++++++++
- TBD
Dependencies on compute services
++++++++++++++++++++++++++++++++
- TBD
Potential implementation
++++++++++++++++++++++++
- TBD
|
