[RFE] Network segmentation support for edge deployments

Bug #1832526 reported by Ildiko Vancsa on 2019-06-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Miguel Lavalle

Bug Description

Edge computing use cases provide new challenges to what we already solved to support distributed systems or need some refinements.

There are different architecture models for edge some of which include a large number of small edge sites. For these edge sites we would create a network, but essentially it would be a network with a segment to provide isolation in that environment and we need Neutron to support this configuration.

Attached a drawing from the Denver PTG on the topic.

Ildiko Vancsa (ildiko-vancsa) wrote :
Miguel Lavalle (minsel) on 2019-06-12
tags: added: rfe
Changed in neutron:
importance: Undecided → Wishlist
Lajos Katona (lajos-katona) wrote :

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

Bogdan Dobrelya (bogdando) wrote :

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

Miguel Lavalle (minsel) wrote :

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"

Ian Wells (ijw-ubuntu) wrote :

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).

Miguel Lavalle (minsel) wrote :

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

tags: added: rfe-triaged
removed: rfe
Miguel Lavalle (minsel) on 2019-08-16
Changed in neutron:
status: New → Confirmed
assignee: nobody → Miguel Lavalle (minsel)
Miguel Lavalle (minsel) wrote :

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

tags: added: rfe-approved
removed: rfe-triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers