From 0c8ccb5191a2ebb93ed7601a161461f283d85b46 Mon Sep 17 00:00:00 2001 From: Rodolfo Alonso Hernandez Date: Mon, 3 Oct 2022 10:02:30 +0200 Subject: [PATCH] Strict minimum bandwidth support for tunnelled networks The aim of the RFE is to improve the previous implemented RFE Strict minimum bandwidth support [1]. [1]https://bugs.launchpad.net/neutron/+bug/1578989 Change-Id: I21a1d9bee1d195f704a518ea3dbd3f2b1e35a357 Related-Bug: #1991965 --- ...t-minimum-bandwidth-tunnelled-networks.srt | 173 ++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 specs/2023.1/strict-minimum-bandwidth-tunnelled-networks.srt diff --git a/specs/2023.1/strict-minimum-bandwidth-tunnelled-networks.srt b/specs/2023.1/strict-minimum-bandwidth-tunnelled-networks.srt new file mode 100644 index 000000000..1d6f1dfc5 --- /dev/null +++ b/specs/2023.1/strict-minimum-bandwidth-tunnelled-networks.srt @@ -0,0 +1,173 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +======================================================= +Strict minimum bandwidth support for tunnelled networks +======================================================= + +Launchpad bug: https://bugs.launchpad.net/neutron/+bug/1991965 + +The aim of the RFE is to improve the previous implemented RFE Strict minimum +bandwidth support [1]_. + + +Problem Description +=================== + +Since [1]_, Neutron has the ability to model the available bandwidth of the +physical interfaces (ingress and egress) connected to the physical networks +(flat and VLAN networks). This information is collected by Placement and +used to spawn virtual machines with network ports on compute nodes with +enough bandwidth. That guarantees a minimum port throughput. + +This feature is currently implemented in three backends: ML2/SR-IOV, ML2/OVS +and ML2/OVN. The full list of related patches can be reviewed at [2]_. + +However, most of the current deployments do not use physical backed networks +(flat or VLAN) but overlay networs (VXLAN and Geneve). Of course those +deployments use ML2/OVS and ML2/OVN; ML2/SR-IOV does not support tunnelled +networks. That leads to an existing gap in the currently implemented feature: +there is no way to model tunnelled networks. + + +Proposed Change +=============== + +This RFE proposes a way to model the available bandwidth for tunnelled +networks in compute nodes. This implementation will be limited to ML2/OVS +and ML2/OVN backends. + +The referred backends handle the overlay traffic sending and receiving this +traffic from a host interface, that acts as a VTEP [3]_. This host interface +is identified by an IP address, known as "local_ip" in the ML2 plugin +configuration file [4]_. + +This RFE proposes to use the same configuration options provided in [1]_, +adding a static string constant to define a tunnelled network, "rp_tunnelled". +For example:: + + [ovs] + resource_provider_bandwidths = br0:EGRESS:INGRESS,rp_tunnelled:EGRESS:INGRESS + resource_provider_hypervisors = br0:compute2,rp_tunnelled:compute1 + + +This new string constant cannot be used as a physical bridge name. To avoid +any possible clash, there will be a new check when parsing the physical +network bridge mappings. + +A host with ML2/OVN backend with a physical network (mapped to the physical +bridge "br-ex") and a tunnelled network will report the following resource +provider tree:: + + $ openstack resource provider list + +--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+ + | uuid | name | generation | root_provider_uuid | parent_provider_uuid | + +--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+ + | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | u20ovn | 10 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | None | + | cb101b60-527b-5264-8e7f-213c7b88e9e1 | u20ovn:OVN Controller agent | 1 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | + | 521f53a6-c8c0-583c-98da-7a47f39ff887 | u20ovn:OVN Controller agent:br-ex | 20 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | cb101b60-527b-5264-8e7f-213c7b88e9e1 | + | dfdbf43f-f60b-577c-bae8-3dcea448c735 | u20ovn:OVN Controller agent:rp_tunnelled | 6 | 8f0e060d-bf63-42a1-85e6-710c8b2fccc8 | cb101b60-527b-5264-8e7f-213c7b88e9e1 | + +--------------------------------------+------------------------------------------+------------+--------------------------------------+--------------------------------------+ + + +A new static trait is added to this resource provider: +"CUSTOM_TUNNELLED_NETWORKS". This is what identify that this resource provider +is for tunnelled networks. E.g.:: + + $ openstack resource provider trait list $rp_tun + +----------------------------------+ + | name | + +----------------------------------+ + | CUSTOM_VNIC_TYPE_NORMAL | + | CUSTOM_VNIC_TYPE_DIRECT | + | CUSTOM_VNIC_TYPE_DIRECT_PHYSICAL | + | CUSTOM_VNIC_TYPE_MACVTAP | + | CUSTOM_VNIC_TYPE_VDPA | + | CUSTOM_VNIC_TYPE_REMOTE_MANAGED | + | CUSTOM_VNIC_TYPE_BAREMETAL | + | CUSTOM_TUNNELLED_NETWORKS | + +----------------------------------+ + + +REST API Impact +--------------- + +This RFE does not introduce any API change. + + +Data Model Impact +----------------- + +This RFE does not introduce any model change. + + +Security Impact +--------------- + +None. + + +Performance Impact +------------------ + +None. + + +Other Impact +------------ + +Currently there is no support for minimum bandwidth QoS rules for tunnelled +networks, neither in Placement nor in the ML2 backend (OVS, OVN). However, +it is possible to have ports with those type of QoS rules (maybe inherited +from the network QoS policy). With this feature, the minimum bandwidth QoS +rules won't be discarded, like now, when the port resource request is built +(that is the Placement blob to request a specific bandwidth in a specific +network). A new check will be added to inform about those ports located on +tunnelled networks with minimum bandwidth QoS rules. + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignees: + Rodolfo Alonso Hernandez (IRC: ralonsoh) + +Work Items +---------- + +* ML2 plugin update. +* Documentation. +* Tests and CI related changes. + + +Testing +======= + +* Unit/functional Tests. +* Tempest tests. + + +Documentation Impact +==================== + +User Documentation +------------------ + +Ammend the "Strict minimum bandwidth support" [1]_ documentation, adding this +new improvement. + + +References +========== + +.. [1] [RFE] Strict minimum bandwidth support (egress) + https://bugs.launchpad.net/neutron/+bug/1578989 +.. [2] https://review.opendev.org/q/%25231578989 +.. [3] https://networklessons.com/cisco/ccnp-encor-350-401/introduction-to-virtual-extensible-lan-vxlan +.. [4] https://github.com/openstack/neutron/blob/599c81767ea7aa3bde7a64ff57b20f34fb314548/neutron/conf/plugins/ml2/drivers/ovs_conf.py#L44-L50