openstack
/
neutron-specs
Code Issues Proposed changes

Update the subnet allocation quota mechanism 

At the recent Neutron mid-cycle, we discussed using the absolute
number of addresses for expressing IP allocation quota.  After
speaking with SMEs in IPv6 and user experience it seemed that this
would be a difficult way of handling these quotas.

First, with IPv6 the numbers are just too large for normal integer
fields.  Python seems to handle it gracefully but there are also
considerations for databases too.  Even an unsigned BIGINT in mysql is
not large enough.  I will argue that this proposal is simpler from an
implementation perspective and shares all code between IP versions.

Second, it would require some complexity around the user experience
for IPv6.  This new proposal provides a *more* common experience to
the user since the numbers will be low enough to understand in both
cases.  The only thing that the user will need to grok is the minimum
address unit for each version.  This should be spelled out clearly in
documentation.

DocImpact

Change-Id: Iae70385f4743aa824c87195a91b3fa83596ae844
This commit is contained in:
Carl Baldwin 2014-12-16 11:44:44 -07:00
parent eb5ebab286
commit 15493771a0
1 changed files with 12 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
specs/kilo/subnet-allocation.rst
View File

@ -65,10 +65,18 @@ along with the included reference IPAM implementation.
A subnet pool can be shared or not shared. Only admins can create shared pool.
A quota mechanism will be added for shared pools. Quotas will be expressed in
terms of absolute number of IP addresses. The resource quotas are applied to is
not the SubnetPool, but rather IP addresses. As such, the current quota engine
is not able to perform this operation so management and enforcement should occur
in a custom fashion.
terms of the number of minimum atomically allocatable address units. To keep
the math simple, the unit size will be hard-coded at /32 for IPv4 and /64 for
IPv6. Counting the total number of addresses with IPv6 will make things
cumbersome since even an unsigned 64 bit integer is not sufficient to express
numbers this large. It would also require extra complexity around presentation
in order to present these numbers to a user in a way that makes any sense at
all. The implementation will share code between IP versions. The only
difference will be the prefix size constant.
The resource quotas are applied to is not the SubnetPool, but rather IP
addresses. As such, the current quota engine is not able to perform this
operation so management and enforcement should occur in a custom fashion.
Operators may want to charge for allocations (hopefully not with IPv6) but the
mechanism by which they can do this is beyond this bp's scope.