On Mon, Jun 02, 2025 at 11:08:02PM +0200, Gert Doering wrote: Hi,
On Mon, Jun 02, 2025 at 07:53:22PM +0200, Piotr Strzyzewski wrote:
That said, if I understand the DB limitations correctly, every level of SUB-ALLOCATED PA is automatically 1 bit longer - so there is an upper limit anyway.
It is not. I actually tested it using a random /24 in the TEST database. First, I created a /24 inetnum object with the ALLOCATED PA status, and then 255 inetnum objects with the SUB-ALLOCATED PA status - ranging from 192.0.2.0 - 192.0.2.254 down to 192.0.2.0 - 192.0.2.0. As a side note, the last one doesn't make much sense, since it's not possible to create any smaller inetnum object with ASSIGNED PA status.
That is not surprising - but I was talking "depth", not "breadth".
Same here. I was talking "depth" as well.
So the maximum depth of nesting in a /24 is 8, then you hit /32, and
My observation is that it was 1 allocation having 255 sub-allocations nested one in another. Like 192.0.2.0 - 192.0.2.0 nested in 192.0.2.0 - 192.0.2.1 nested in 192.0.2.0 - 192.0.2.2 nested ... in 192.0.2.0 - 192.0.2.254 (last, most outer sub-allocation) nested in 192.0.2.0 - 192.0.2.255 (allocation). So the maximum depth of nesting in a /24 is 255.
I think this is what Denis was asking about.
On a more pragmatic note - why don't we ask those who use more than one or two levels of sub-allocations about their business case? This way, we might better understand the actual problem.
Is there a problem we need to fix?
No idea. This is what I would like to find out. Best, Piotr -- Piotr Strzyżewski