... | ... | @@ -24,6 +24,16 @@ In order to take advantage of the existing allocation engine code and keep the r |
|
|
|
|
|
Depending on the backend's capabilities, one or another allocator will be selected upon the server's startup or reload. The changes in the allocation engine to support the new allocator are expected to be minimal.
|
|
|
|
|
|
# BALS Allocator
|
|
|
|
|
|
The BALS Allocator, besides providing capability for lease pre-allocation, will provide the ability for free leases shuffling. This is going to fill a long standing gap in Kea implementation to hand out leases in a random order to make network scanning harder. However, both of these capabilities come with some cost for server's startup, reconfiguration and memory consumption. This is mostly a problem for large pools, mostly in IPv6 but also in IPv4 for /8 pools.
|
|
|
|
|
|
Suppose we have an IPv6 /64 pool and the BALS allocator is used. This pool is very large and pre-allocation of leases in that pool is unlikely to be beneficial, because pre-allocation is meant to improve performance of nearly exhausted pools or pools with high utilization. Using the mixture of small and large pools imposes a requirement on the BALS allocator to enable pre-allocation on selected pools and not use pre-allocation on other pools.
|
|
|
|
|
|
BALS comes with free leases shuffling capability but we should also consider whether it should be possible to use pre-allocation with incremental lease allocation.
|
|
|
|
|
|
(this is ongoing)
|
|
|
|
|
|
# New API Calls
|
|
|
|
|
|
```c++
|
... | ... | |