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
|
.. 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.
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
VRF Lets us do:
1. Overlapping Addresses
2. Segregation of Traffic
Derrived Requirements
~~~~~~~~~~~~~~~~~~~~~
- TBD
Northbound API / Workflow
+++++++++++++++++++++++++
- TBD
Data model objects
++++++++++++++++++
- TBD
Orchestration
+++++++++++++
- TBD
Dependencies on compute services
++++++++++++++++++++++++++++++++
- TBD
Potential implementation
++++++++++++++++++++++++
- 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
|
