Open Stack

Salvatore Orlando <sorlando at nicira.com> writes:

> Neutron is adding a new concept of "subnet pool". [...]

> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html

I apologize for asking this question so long after this spec has been
proposed and discussed - but what is the problem that subnet allocation
solves?  Or what is it possible to do with subnet allocation, that was
not possible before?

Of course the spec has text to address this, but for me it doesn't
actually answer the above questions:

    Problem Description

    IPAM in Neutron cannot allocate subnets. Subnet details must be
    specified by the End User at the time of subnet creation.

This seems to me to be restating the premise.

    End Users may want to offload the burden of keeping track of subnets
    and which addresses are in use. In this case, the End User should be
    able to set up a private address space from which these are
    automatically allocated.

This sounds to me like what already happens.  When I launch a set of
instances, I simply specify which subnet to use for each of their
vNICs.  The Neutron DB keeps track of which addresses are in use, so I
don't see any burden here.

    For IPv4, this will often be a portion of
    the RFC1918 address space but doesn’t need to be. It might be part
    of a corporate address space which has been delegated to the
    cloud. For IPv6, the End User may want Neutron to automatically
    calculate a useable ULA subnet using a pseudo-random algorithm in
    harmony with RFC4193 [1].

This seems equivalent to configuring that usable subnet explicitly and
then launching instances that are attached to its network.

    This implies that the algorithm for the selection of subnets within
    the space is pluggable in some way.

    [1]	http://tools.ietf.org/html/rfc4193

    Deployers will set up external networks and may have a chunk of
    routable addresses that could be leased or delegated to tenants for
    use on their networks.

And that could presumably be configured as subnets?

    Neutron needs an API for creating and managaging address spaces and
    making them available to tenants.

I can certainly see the value in address spaces (or scopes) as a
distinct concept from tenants - if that is what this is saying.  But I
believe that's an independent concept from the idea of changing from
explicit subnet configuration to subnet allocation, because it would be
possible for an operator or tenant to configure a subnet within one of
the address spaces that was available to them.

Many thanks, and apologies again for asking this so late in the game.

Regards,
        Neil