In many cases, physical data center networks are architected with a differentiation between layers 2 and 3. Said another way, there are distinct L2 network segments which are only available to a subset of compute hosts. Routing allows traffic to cross these boundaries. These topologies are used to manage network resource capacity (IP addresses, broadcast domain size, ARP tables, etc.) to allow for large scale networks.
Operators from the Large Deployers Team (LDT) and others would like an operator-provisioned Neutron construct that is exposed to users and maps onto this kind of physical network. They would like this construct to represent an L3 domain, in general having a larger scope than each of the physical L2 segments that contribute to it. Users must be able to specify that VMs are booted anywhere in such a domain - as opposed to on a particular physical L2 segment. Consequently the only guaranteed connectivity between VMs on this construct/domain is at L3; as the data path between any two VMs may involve IP routing hops. Fortunately many workloads only require L3 connectivity.
More info can be found: https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html
and https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html
Ironic node should become L2 segment aware (we should know which L2 segments are available for particular node) to correctly pick subnet (ip address) when doing provisioning/cleaning.
@Sam,
Please read the following exchange between hjensas and kevinbenton: http://
On the Neutron side, what we need Ironic to give us is a host_id. We maintain a segments to hosts map in Neutron. So, if we get the host id, we can do the rest. No need to duplicate the mapping