[address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

On Wed, Nov 13, 2019 at 11:54 AM Radu-Adrian FEURDEAN <
ripe-wgs at radu-adrian.feurdean.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20191113/e69a5ad5/attachment.html>