[RFE] Network segmentation support for edge deployments

This spec seems to be covering similar topic:
https://review.opendev.org/579411 (Segment Range Management of Self-service Networks)

And this one: https://specs.openstack.org/openstack/neutron-specs/specs/stein/network-segment-range-management.html

And the latter one is https://blueprints.launchpad.net/neutron/+spec/network-segment-range-management that has been implemented as of Stein

This RFE and the spec / blueprints mentioned in #2, #3 and #4 refer to different problems. The problem solved and implemented by #2, #3 and #4 was enabling a cloud admin to administer through the API the range of segments that are assigned for the creation of tenant networks. Prior to that solution, the assignment of those ranges was done using config options in neutron.conf.

This RFE refers to the edge computing scenarios defined in https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures. In those deployment scenarios, there are sites known as "Small Edge", which don't have the API components of the control plane. They only have the Neutron OVS agent and the Nova compute agent. In other words, the virtual networks instantiated those "Small Edge" sites will be created through an API that exists in a regional or centralized site.

Today, a Neutron network is assumed to be a single L2 domain that spans the entire deployment. As discussed during the PTG in Denver, the edge computing scenarios require us to be able to create networks that span only one segment that exist in a specific "Small Edge" site. In other words, each "Small Edge" site will have its own networks: This will entail:

1) Changes to the API, to be able to create a network associated with a "Small Edge"
2) Changes to the backend mechanism, to be able to instantiate a network only in a specific "Small Edge"

It is already possible to assign different physical networks to different compute nodes. This model might work for the edge networks as described (assuming that we expect the end user to set them up with appropriate address ranges if they're bridged to other networks, but that is the standing assumption for any provider network today). Basically, each edge would have a different physical network.

If we went that way, the problem is that, as you come to run a network, the nova boot fails with an error because of the port bind if the anticipated physnet is not present. Scheduling is supposed to be the gate to determine that the VM would run on the selected host, but scheduling today does not take account of available physical networks on a host.

This is not intended to solve inter-edge connectivity, which is out of scope and which is clearly ruled out in the implementation by having separate physnets per location (which says, in API terms, the locations are not interconnected).

Yes, the deployer would configure a different physnet in each "Small Edge" host and create a Neutron network associated to it. But we will still need to designate this network as associated with a "Small Edge". With this information, the Neutron server, using the placement API will be able to communicate to the Nova scheduler which "Small edge" network / physnet reside in which "Small edge" host so it can take the correct scheduling decision when a VM is created to run in that host. So the flow will be:

1) Admin associates physnet with "Small Edge" host
2) Admin creates a Neutron network associated with the "Small Edge" host
3) Neutron server creates the necessary resource providers in placement to indicate the association of of the "Small Edge" host with the network. This is similar to what we do today with routed networks, where we create resource providers associating subnets with segments
4) When a user boots a VM and specifies a network for that VM, the Nova scheduler will use the data in placement to send the VM to the correct "Small Edge" host. This of course will require that this scheduling functionality is developed in Nova

This RFE was discussed during today's Drivers meeting. It was approved. There was conversation about extending the Availability Zones concept to support this RFE. Per the agreement during the meeting, the next steps are:

1) We will write a PoC and spec to explore how to weave all the pieces that Neutron has already in place (network_availability_zone extension, physnets and bridge mappings, placement driver) together and identify gaps.

2) Since we need to involve the Nova / Placement combo to fully support this RFE, we will make progress in the PoC / spec in time to discuss it in Shanghai in the x-projects session with Nova / Placement

3) mlavalle volunteers to carry out the previous two points

Is this also related https://review.opendev.org/#/c/656885 ?

Yes if I remember correctly this was the initial attempt for the mentioned nova/placement part needed here