On Wed, Nov 13, 2019 at 11:54 AM Radu-Adrian FEURDEAN < [email protected]> wrote:
> > > On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote: > > Isn’t that as simple as “use sparse allocation”? As long as less than > > half of the remaining IXP pool has been used up, everyone can be given > > an allocation within a larger block with the ability to grow at least > > 2x. > > If "sparse allocation" is the magic word, it's OK for me. > I don't know, does that do what you want? :-) Sparse allocation would mean that each IXP assignment would be out of the block containing the greatest number of adjacent bits of unused space. That could be implemented either on an absolute basis (all allocations go into the biggest unused CIDR block available), or on a bit-shift basis. For a bit-shift sparse allocation strategy, if you have a free pool large enough to shift 4 bits, you'd assign /24s out of empty /20s, /27s out of empty /23s, etc. Then once you run out of blocks to accomplish that at 4-bit shift, you'd switch to 3 bits, and eventually down to 2 and then 1 bit before you have to give up on sparse allocation entirely. The disadvantage of sparse allocation is that it purposefully breaks up larger blocks, which may result in a lack of contiguous space for the largest IXPs sooner than would otherwise occur, in order to allow earlier IXPs to more easily grow their assignments. This is particularly acute with an absolutely sparse strategy, where the biggest blocks get broken up immediately, regardless of how tiny their allocations are. A bit-shift sparse allocation policy, or similarly a "reserved space" strategy, avoids that issue by limiting how much space is reserved for each IXP to grow into. -Scott
