Browse Source

Merge "Changing segmentation ID of existing network should be allowed"

Zuul 1 month ago
parent
commit
a097bd8bce
1 changed files with 197 additions and 0 deletions
  1. 197
    0
      specs/stein/change-segmentation-id-vlan-provider-network.rst

+ 197
- 0
specs/stein/change-segmentation-id-vlan-provider-network.rst View File

@@ -0,0 +1,197 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+================================================
8
+Change the segment ID of a VLAN provider network
9
+================================================
10
+
11
+Launchpad bug:
12
+https://bugs.launchpad.net/neutron/+bug/1806052
13
+
14
+This spec proposes a method to change the segmentation ID of a VLAN-type
15
+network, which is the external VLAN ID of the network. The implementation
16
+described is limited to only the OVS back-end and to single-segment
17
+provider networks.
18
+
19
+
20
+Problem Description
21
+===================
22
+
23
+Currently, Neutron does not allow the segmentation ID parameter of a provider
24
+network to change, regardless of the status of the network (active or not) or
25
+if ports exist on the network (or not). In order to change the segmentation ID,
26
+the administrator needs to delete the network, first un-binding any bound
27
+ports, then create a new network with the required segmentation ID, and
28
+finally bind the ports back to the network.
29
+
30
+
31
+Proposed Change
32
+===============
33
+
34
+The proposed solution is to be able to change the segmentation ID of a VLAN-
35
+type network, using one single command ("openstack network set") in an atomic
36
+operation.
37
+
38
+In order to implement this, several changes are needed:
39
+
40
+* The CLI, to allow to update the segmentation ID in an existing network.
41
+* The Neutron server, to allow writing those changes in the database.
42
+* The networking back-end. In this spec only OVS is covered and the
43
+  implementation will be limited to it.
44
+
45
+
46
+OpenStack Client
47
+----------------
48
+
49
+Currently, the OpenStack Client allows updating the segmentation ID of an
50
+existing network. No changes are needed.
51
+
52
+
53
+Neutron server
54
+--------------
55
+
56
+Currently, when a network update message is sent to the Neutron server, if any
57
+provider attribute is present in this message, for example 'segmentation ID',
58
+this command is rejected. The new implementation will allow updating the
59
+segmentation ID:
60
+
61
+* If the segmentation ID is the only provider parameter to be updated. No other
62
+  provider parameters (network type, physical network) are allowed.
63
+* If the network has only one segment. In multi provider networks the server
64
+  doesn't know which one of the segments should be updated.
65
+* If the provider segment type is 'vlan'. No other types are allowed.
66
+* If all ports bound to this network belong to a compatible network driver. A
67
+  compatible network driver is one which has implemented this change. In
68
+  this spec, the OVS agent implementation is described. For example, with OVS,
69
+  ports with VIF type 'vhostuser' and 'ovs' are accepted, and 'unbound' or
70
+  'binding_failed' are also allowed because they are not yet bound to any
71
+  network driver.
72
+
73
+If the above conditions are all met, the Neutron server will execute the
74
+following actions (in order):
75
+
76
+* Validate the new segment, to know if the segmentation ID falls inside the
77
+  minimum and maximum VLAN tags.
78
+* Reserve a new provider segment. This will ensure the segmentation ID is not
79
+  used in this network.
80
+* Create a new provider segment in the database.
81
+* Release the old provider segment.
82
+* Delete the old provider segment from the database.
83
+
84
+All these operations will be executed inside a write context, to provide
85
+concurrency and enable rollback in case of failure. If any of these database
86
+operations fail, including subsequent ones, the context will prevent the old
87
+segment from being deleted and the new one will not be created.
88
+
89
+
90
+Mechanism driver
91
+----------------
92
+
93
+The agent mechanism driver interface will be extended with a new function. This
94
+function will return a list of provider network attributes that can be modified
95
+in a network with ports bound to this networking back-end.
96
+
97
+By default, this function will return an empty list.
98
+
99
+
100
+Neutron OVS agent
101
+-----------------
102
+
103
+In the OVS agent, VLAN provider networks can access the provider network
104
+outside the host through the physical bridges. Each provider network has a
105
+single physical bridge assigned. A physical bridge can host the traffic of
106
+multiple provider networks, but each provider network can only send and receive
107
+traffic through one physical bridge. There is a N:1 (network:physical bridge)
108
+relationship.
109
+
110
+Inside the integration bridge, the tenant networks are isolated using virtual
111
+networks. These virtual networks have their own VLAN ID mapping, different from
112
+the provider networks VLAN ID mapping. Both VLAN maps are related through the
113
+"LocalVlanManager", which is in charge of correlating both mappings. When a
114
+packet from a tenant exits the integration bridge to the corresponding physical
115
+bridge, a flow changes the VLAN tag from the tenant VLAN ID to the provider
116
+segmentation ID. The opposite process happens in the physical bridge::
117
+
118
+  br_int:
119
+  cookie=0xb46613524bd0de42, duration=23646.484s, table=0, n_packets=0,
120
+    n_bytes=0, priority=3,in_port="int-br-phy",dl_vlan=1074
121
+    actions=mod_vlan_vid:1,resubmit(,60)
122
+
123
+  br_phy:
124
+  cookie=0x43209f9280b7fc88, duration=23666.003s, table=0, n_packets=10,
125
+    n_bytes=788, priority=4,in_port="phy-br-phy",dl_vlan=1
126
+    actions=mod_vlan_vid:1074,NORMAL
127
+
128
+When a network segmentation ID is updated, the only change needed is to update
129
+the new segmentation ID in both flows. This could be done by deleting both
130
+flows and then creating them again with the new segmentation ID. For example::
131
+
132
+  phys_br.reclaim_local_vlan(port=phys_port, lvid=lvid)
133
+  phys_br.provision_local_vlan(
134
+      port=phys_port, lvid=lvid,
135
+      segmentation_id=new_segmentation_id,
136
+      distributed=self.enable_distributed_routing)
137
+  self.int_br.reclaim_local_vlan(port=int_port,
138
+      segmentation_id=old_segmentation_id)
139
+  self.int_br.provision_local_vlan(
140
+      port=int_port, lvid=lvid,
141
+      segmentation_id=new_segmentation_id)
142
+
143
+
144
+Limitations
145
+-----------
146
+
147
+As commented, this solution will be available only for:
148
+
149
+* Single segment networks.
150
+* VLAN type networks.
151
+* Only OVS (kernel OVS or DPDK OVS) bound ports to this network.
152
+
153
+
154
+Data Model
155
+----------
156
+
157
+No changes.
158
+
159
+
160
+REST API
161
+--------
162
+
163
+A new ML2 RPC call, requested from the agent side, is needed. This new call
164
+will provide information about the updated network. With this information the
165
+agent will know if the network has changed the segmentation ID (as commented,
166
+the "LocalVlanManager" singleton stores this information).
167
+
168
+
169
+CLI impact
170
+----------
171
+
172
+No changes.
173
+
174
+
175
+Operation Impact
176
+----------------
177
+
178
+The segmentation ID change implies two actions:
179
+
180
+* To change the segmentation ID of a Neutron network without unbinding the
181
+  attached ports. Once this process is done in Neutron, the traffic from those
182
+  ports will be tagged with the new VLAN ID and transmitted through the
183
+  provider network.
184
+* To change the provider network segmentation. This process is external to
185
+  Neutron (and OpenStack).
186
+
187
+Because those processes cannot be done at the same time, the administrator
188
+should decide, depending on the site network infrastructure, the order of
189
+execution. Until both the segmentation ID of the Neutron network and the
190
+VLAN ID of the external provider network are synchronized, there will be a
191
+networking disruption.
192
+
193
+
194
+References
195
+==========
196
+
197
+None.

Loading…
Cancel
Save