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 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
