<p dir="ltr">Right now we force tenants choose a CIDR even if they don't care what address they get. This allows them to skip that required input. </p>
<p dir="ltr">More importantly, if the network is fully routed, not only do tenants not know which CIDR to configure, allowing them to choose arbitrary CIDRs can disrupt the entire network. </p>
<p dir="ltr">This workflow isn't stopping the old one from working, it's just enabling new deployments that basically weren't feasible before since we had an implicit requirement that the tenants could configure whatever addresses they wanted.</p>
<div class="gmail_quote">On Mar 26, 2015 10:23 AM, "Neil Jerram" <<a href="mailto:Neil.Jerram@metaswitch.com">Neil.Jerram@metaswitch.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> writes:<br>
<br>
> Neutron is adding a new concept of "subnet pool". [...]<br>
<br>
> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html" target="_blank">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html</a><br>
<br>
I apologize for asking this question so long after this spec has been<br>
proposed and discussed - but what is the problem that subnet allocation<br>
solves? Or what is it possible to do with subnet allocation, that was<br>
not possible before?<br>
<br>
Of course the spec has text to address this, but for me it doesn't<br>
actually answer the above questions:<br>
<br>
Problem Description<br>
<br>
IPAM in Neutron cannot allocate subnets. Subnet details must be<br>
specified by the End User at the time of subnet creation.<br>
<br>
This seems to me to be restating the premise.<br>
<br>
End Users may want to offload the burden of keeping track of subnets<br>
and which addresses are in use. In this case, the End User should be<br>
able to set up a private address space from which these are<br>
automatically allocated.<br>
<br>
This sounds to me like what already happens. When I launch a set of<br>
instances, I simply specify which subnet to use for each of their<br>
vNICs. The Neutron DB keeps track of which addresses are in use, so I<br>
don't see any burden here.<br>
<br>
For IPv4, this will often be a portion of<br>
the RFC1918 address space but doesn’t need to be. It might be part<br>
of a corporate address space which has been delegated to the<br>
cloud. For IPv6, the End User may want Neutron to automatically<br>
calculate a useable ULA subnet using a pseudo-random algorithm in<br>
harmony with RFC4193 [1].<br>
<br>
This seems equivalent to configuring that usable subnet explicitly and<br>
then launching instances that are attached to its network.<br>
<br>
This implies that the algorithm for the selection of subnets within<br>
the space is pluggable in some way.<br>
<br>
[1] <a href="http://tools.ietf.org/html/rfc4193" target="_blank">http://tools.ietf.org/html/rfc4193</a><br>
<br>
Deployers will set up external networks and may have a chunk of<br>
routable addresses that could be leased or delegated to tenants for<br>
use on their networks.<br>
<br>
And that could presumably be configured as subnets?<br>
<br>
Neutron needs an API for creating and managaging address spaces and<br>
making them available to tenants.<br>
<br>
I can certainly see the value in address spaces (or scopes) as a<br>
distinct concept from tenants - if that is what this is saying. But I<br>
believe that's an independent concept from the idea of changing from<br>
explicit subnet configuration to subnet allocation, because it would be<br>
possible for an operator or tenant to configure a subnet within one of<br>
the address spaces that was available to them.<br>
<br>
Many thanks, and apologies again for asking this so late in the game.<br>
<br>
Regards,<br>
Neil<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>