Colleagues Maybe I asked too many questions in one email, so I'll take it bit by bit. Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1? Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite. cheers denids
Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1?
Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite.
is there a technical or business reason for this? otherwise it appears to be bikeshedding. if so, magenta please. randy
Hi Randy This is a good question. The whole purpose of the "status:" attribute is to describe and document real world networks from an administrative point of view. Also to 'impose' some structure on the networks with a set of rules. There are some gaps in those rules, like allowing an infinite number of levels in a legacy network or with sub-allocations. This doesn't make sense from either a real world or an administrative perspective. My suggestion is that we fill those gaps. cheers denis On Fri, 2 May 2025 at 17:58, Randy Bush <randy@psg.com> wrote:
Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1?
Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite.
is there a technical or business reason for this? otherwise it appears to be bikeshedding. if so, magenta please.
randy
Hi, On Fri, May 02, 2025 at 12:05:49PM +0200, denis walker wrote:
Maybe I asked too many questions in one email, so I'll take it bit by bit.
Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1?
Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite.
I do not have a factual answer to your question, like "5". All *I* personally have ever envisioned is the need for "1 or 2" levels of hierarchy. 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. Truly excercising this, like having 16 levels in an IPv4 /16, or "many many" in an IPv6 /32, would not make very much sense to me - but doing so is not going to endanger anything or crash the RIPE database. No? So, I see no compelling need to put a smaller hard limit onto the level of nesting. 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
On Wed, May 14, 2025 at 12:27:13PM +0200, Gert Doering wrote: Hi,
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. $ whois -h whois-test.ripe.net -rL 192.0.2.0 | grep status: | wc -l 257 $ whois -h whois-test.ripe.net -rL 192.0.2.0 | grep status: | head -n 3 status: ALLOCATED UNSPECIFIED status: ALLOCATED PA status: SUB-ALLOCATED PA 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. Best, Piotr -- Piotr Strzyżewski
On Mon, 2 Jun 2025 at 10:53, Piotr Strzyzewski <piotr@internetsailor.net> wrote: [...]
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.
Yes. Everything else is just guessing.
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.
Yes. Everything else is just guessing.
as a programmer, i was taught to count "zero, one, many." i am a bit slow, but i don't get that there is a problem here. randy
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
So the maximum depth of nesting in a /24 is 8, then you hit /32
i am less sure of that. i am currently dealing with a prefix which rgnet holds. but the entire prefix is currently under the control of a research team with whom we are associated. NCC/ARC wants If it is effectively in use by the same entity, even partially, please consider registering the related assignments underneath the prefix's allocation in the RIPE Database i.e. they want the whole prefix to be assigned. i.e. it can be turtles a long way down and even if this scenario were not in play, do we need depth 24 because there are /8s out there? at that point, why bother with limits? randy
Hi, On Mon, Jun 02, 2025 at 02:23:23PM -0700, Randy Bush wrote:
and even if this scenario were not in play, do we need depth 24 because there are /8s out there? at that point, why bother with limits?
This is my point. Nobody can answer if the really needed limit is "2" or maybe "3", or some really complex business structure might need "5" at some point. On the other hand, nobody has explained what the problem is in "just not having a hard limit, besides the built-in hard limit of the number of bits". I'm a strong believer of the "unless there is an agreed-upon problem, let's not waste human lifetime in building a solution" school of things. 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
and even if this scenario were not in play, do we need depth 24 because there are /8s out there? at that point, why bother with limits?
This is my point. Nobody can answer if the really needed limit is "2" or maybe "3", or some really complex business structure might need "5" at some point.
On the other hand, nobody has explained what the problem is in "just not having a hard limit, besides the built-in hard limit of the number of bits".
I'm a strong believer of the "unless there is an agreed-upon problem, let's not waste human lifetime in building a solution" school of things.
i think at least you and i have converged randy
Hi guys On Tue, 3 Jun 2025 at 01:21, Randy Bush <randy@psg.com> wrote:
and even if this scenario were not in play, do we need depth 24 because there are /8s out there? at that point, why bother with limits?
This is my point. Nobody can answer if the really needed limit is "2" or maybe "3", or some really complex business structure might need "5" at some point.
On the other hand, nobody has explained what the problem is in "just not having a hard limit, besides the built-in hard limit of the number of bits".
I'm a strong believer of the "unless there is an agreed-upon problem, let's not waste human lifetime in building a solution" school of things.
i think at least you and i have converged
If it was a week's work for 2 engineers to build some complex solution I would probably agree with you. But in reality, to set a limit would probably be a couple of lines of code and maybe 2 test cases in the test suite. You can always make a case for "why bother to set limits on anything?" But do we want anyone to be able to mess up the DB intentionally, or with a script that went wild, and create hundreds of these objects? When a couple of lines of code would cap it at a reasonable level. I see it as tidying up loose ends while reviewing the status rules. cheers denis
randy ----- 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/
Hi, On Tue, Jun 03, 2025 at 02:51:54AM +0200, denis walker wrote:
If it was a week's work for 2 engineers to build some complex solution I would probably agree with you. But in reality, to set a limit would probably be a couple of lines of code and maybe 2 test cases in the test suite. You can always make a case for "why bother to set limits on anything?" But do we want anyone to be able to mess up the DB intentionally, or with a script that went wild, and create hundreds of these objects? When a couple of lines of code would cap it at a reasonable level. I see it as tidying up loose ends while reviewing the status rules.
I find it very unlikely that a script-went-wild would create "hundreds" of *deeply nested* objects. Now, a script-went-wild that creates thousands of leaf-level inetnum: objects ("let's just sync all IPv4 /32 from our IPAM to the RIPE DB") is somewhat likely - but this won't be stopped by introducing limits on the nesting level of sub-allocations. 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
On Mon, 2 Jun 2025 at 14:27, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jun 02, 2025 at 02:23:23PM -0700, Randy Bush wrote:
and even if this scenario were not in play, do we need depth 24 because there are /8s out there? at that point, why bother with limits?
This is my point. Nobody can answer if the really needed limit is "2" or maybe "3", or some really complex business structure might need "5" at some point.
On the other hand, nobody has explained what the problem is in "just not having a hard limit, besides the built-in hard limit of the number of bits".
I'm not sure whether there's a real problem but I am confident that speaking with users and asking why is never a bad idea. Explaining internal processes and their reason in public can be challenging. But a quick, friendly chat can't do any harm.
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
Hi, On Mon, Jun 02, 2025 at 11:35:24PM +0200, Piotr Strzyzewski wrote:
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.
No :-) 192.0.2.0/24 192.0.2.0/25 192.0.2.0/26 ... 192.0.2.0/32 ... this is what I called "nesting in depth", and the limit is 8. Filling each level (192.0.2.0/32, 192.0.2.1/32, 192.0.2.2/32, ... .255/32) is what I called "width" - and of course, you can add hundreds of object that way, without mentioning "SUB-ALLOCATED" at all (just tag the /32s as "ASSIGNED"). The former ("limit=8") would be capped by introducing a limit to the nexting level ob sub-allocations. The latter not so much. 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
On Tue, Jun 03, 2025 at 07:52:48AM +0200, Gert Doering wrote: Hi,
On Mon, Jun 02, 2025 at 11:35:24PM +0200, Piotr Strzyzewski wrote:
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.
No :-)
Yes ;-)
192.0.2.0/24 192.0.2.0/25 192.0.2.0/26 ... 192.0.2.0/32
... this is what I called "nesting in depth", and the limit is 8.
Fine with me. But this is not what I was trying to explain. The inetnum object is not limited to bit boundaries.
Filling each level (192.0.2.0/32, 192.0.2.1/32, 192.0.2.2/32, ... .255/32) is what I called "width" - and of course, you can add hundreds of object that way, without mentioning "SUB-ALLOCATED" at all (just tag the /32s as "ASSIGNED").
Sure, but that's not what I did. These weren't /32s. Since I probably wasn't very clear, which led to the misunderstanding, let me explain one last time using a small diagram what I've done: 192.0.2.0 - 192.0.2.255 (/24 ALLOCATION) |-> 192.0.2.0 - 192.0.2.254 (255 addresses; SUB-ALLOCATION) |-> 192.0.2.0 - 192.0.2.253 (254 addresses; SUB-ALLOCATION) ... |-> 192.0.2.0 - 192.0.2.1 (2 addresses; SUB-ALLOCATION) |-> 192.0.2.0 - 192.0.2.0 (the only /32 in my example; SUB-ALLOCATION) In this scenario, there are 255 levels. Hope that's clearer now. Best, Piotr -- Piotr Strzyżewski
Hi, On Tue, Jun 03, 2025 at 12:53:26PM +0200, Piotr Strzyzewski wrote:
Since I probably wasn't very clear, which led to the misunderstanding, let me explain one last time using a small diagram what I've done:
192.0.2.0 - 192.0.2.255 (/24 ALLOCATION) |-> 192.0.2.0 - 192.0.2.254 (255 addresses; SUB-ALLOCATION) |-> 192.0.2.0 - 192.0.2.253 (254 addresses; SUB-ALLOCATION) ... |-> 192.0.2.0 - 192.0.2.1 (2 addresses; SUB-ALLOCATION) |-> 192.0.2.0 - 192.0.2.0 (the only /32 in my example; SUB-ALLOCATION)
In this scenario, there are 255 levels. Hope that's clearer now.
Okay, I'm not creative enough on the "how to insert non-useful objects into the RIPE DB", it seems - thanks for enlightening me. It does not truly answer "would this be a problem that needs a technical solution?", though. 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
participants (5)
-
denis walker -
Gert Doering -
Leo Vegoda -
Piotr Strzyzewski -
Randy Bush