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". So the maximum depth of nesting in a /24 is 8, then you hit /32, and 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? What are we gaining if we introduce an arbitrary limit "you must only nest SUB-ALLOCATED PA 2/3/4/5 levels deep" (except a bit of work for the DB engineering team, and a few more corner cases - what if you have a /24, a nested /28+/29, and then add a /26 in between?)? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279