From 40f6c1663d045fbb23dcb64f4fc0227f6f063dd4 Mon Sep 17 00:00:00 2001 From: Slawek Kaplonski Date: Tue, 29 Jun 2021 17:46:46 +0200 Subject: [PATCH] Neutron VLAN networks with QinQ enabled Related-Bug: #1915151 Change-Id: I4ebac838df82a64a5a6f2c773d69050ade5668ce --- specs/yoga/qinq_networks.rst | 123 +++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 specs/yoga/qinq_networks.rst diff --git a/specs/yoga/qinq_networks.rst b/specs/yoga/qinq_networks.rst new file mode 100644 index 000000000..d8a8de253 --- /dev/null +++ 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 + +References +========== + +.. [1] https://en.wikipedia.org/wiki/IEEE_802.1ad +.. [2] https://docs.openstack.org/api-ref/network/v2/#vlan-transparency-extension