Neutron VLAN networks with QinQ enabled

Related-Bug: #1915151 Change-Id: I4ebac838df82a64a5a6f2c773d69050ade5668ce
2021-06-29 17:46:46 +02:00
parent 21b6188e86
commit 40f6c1663d
1 changed files with 123 additions and 0 deletions
--- a/specs/yoga/qinq_networks.rst
+++ b/specs/yoga/qinq_networks.rst
@@ -0,0 +1,123 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+=======================================
+Neutron VLAN networks with QinQ support
+=======================================
+
+Launchpad Bug:
+https://bugs.launchpad.net/neutron/+bug/1915151
+
+Neutron supports networks with vlan transparency but in case where it is used
+with VLAN networks, there is no way to use it as QinQ which is different
+ethertype (e.g. 0x8a88) than regular vlan ethertype (0x8100).
+
+Problem Description
+===================
+
+Networks with enabled vlan transparency can be of any type available in Neutron
+(vxlan, vlan, flat, etc.). In most cases it is fine when packets sent from the
+node and have ethertype 0x8100 (802.1q).
+But in such case as we have 2 vlans already (S-Tag and C-Tag) there are some
+use cases where it should be sent as QinQ which is slightly different standard
+and have different ethertype (0x8a88) [1]_.
+
+Proposed Change
+===============
+
+Add new API extension to extend ``network`` resource in Neutron with ``qinq``
+attribute. This new attribute would be valid only for ``vlan`` networks and in
+case of that networks would work similary to what current ``VLAN transparency``
+extension [2]_. The difference between vlan transparency and new qinq extensions
+would be in the ethertype configured for packets in such network send from the
+node.
+In case of ``qinq=True`` S-Tag and C-Tag will work in same way like it is now
+for the networks with enabled vlan transparency. C-Tag is configured directly in
+the instance by user and S-Tag is configured and controlled by Neutron. The
+difference will be that ethertype of the packets sent from the node will be
+0x8a88.
+Attributes ``vlan_transparent`` and ``qinq`` will be mutually exclusive. Only
+one of them can be set to ``True`` for the network.
+
+Server side changes
+-------------------
+
+A new API extension of Neutron will be added with new attribute for the
+``network`` resource. This new attribute will be called ``qinq``:
+
+::
+
+    RESOURCE_ATTRIBUTE_MAP = {
+        network.COLLECTION_NAME: {
+            "qinq": {
+                'allow_post': True,
+                'allow_put': False,
+                'convert_to': converters.convert_to_boolean,
+                'default': constants.ATTR_NOT_SPECIFIED,
+                'is_visible': True,
+                'is_filter': True
+            }
+        }
+    }
+
+.. note:: Attribute ``qinq`` will have effect only for ``vlan`` networks.
+
+.. note:: Attributes ``vlan_transparent`` and ``qinq`` would be mutually
+   exclusive. Only one of them can be set to ``True``.
+
+Agent side changes
+------------------
+
+Currently ``linuxbridge``, ``ovn`` and ``SR-IOV`` backends supports VLAN
+transparency and QinQ will be supported by the same backends.
+In case of ``linuxbridge`` and ``ovn`` backends correct ethertype will need to
+be set on the nodes so correct ethertype will be set for the packets.
+In case of the ``SR-IOV`` backend support for that feature will depend on the
+hardware and its driver and that will need to be tested separately.
+
+DB Impact
+---------
+
+Extend the ``networks`` table with boolean column ``qinq``.
+
+REST API Impact
+---------------
+
+None.
+
+Client Impact
+-------------
+
+Relevant changes in osc and openstacksdk to add support for new network's
+attribute. To enable it for network, it should be something like:
+
+::
+
+    openstack network create --qinq
+
+and to disable it:
+
+::
+
+    openstack network create --no-qinq
+
+Testing
+-------
+
+* Unit tests.
+* Fullstack test.
+* Tempest tests in neutron-tempest-plugin.
+
+Assignee(s)
+-----------
+
+* Slawek Kaplonski <skaplons@redhat.com>
+
+References
+==========
+
+.. [1] https://en.wikipedia.org/wiki/IEEE_802.1ad
+.. [2] https://docs.openstack.org/api-ref/network/v2/#vlan-transparency-extension