[deepspace] Re: Understanding the difference in aggregation between a single and multiple RIR model

[Marc Blanchet <[e-mail]>]

> Le 30 août 2026 à 18:16, Tony Li <[e-mail]> a écrit :
> 
> 
> Hi Warren,
> 
>> Having all addresses for something like a celestial body also fall within contiguous ranges would be nice, but certainly not required. Yes, space craft do have limited compute, but I really don't see it as the end of the world if they have to track multiple routes per body.
> 
> 
> So you’re ok if we end up carrying around /128’s for everything?
> 
> 
>> If the compute was sufficiently limited that we can't spare the memory for a few hundred routes we'd (presumably) be looking much harder to save resources in other places (like the LWIG work, considering non-IP, or even IPv4 because addresses cost memory too). I also really don't see the need to aggregate at the planetary level — I believe that it is unrealistic to assume that when you create an X you will know exactly how much address space it needs, and having a single prefix for every X makes operations like traffic engineering, redundancy, etc harder. There are also issues around what addresses to use when things move from X to Y.
> 
> 
> Fortunately, we know we don’t need to be perfect.  There will certainly be exceptions and changes over time.  That’s not the point. The real point is that if we don’t adopt a goal of aggregation, we will end up with an unmitigated swamp again.
> 
> 
>> My primary concern, however, is that having a single RIR seems like a really bad idea - I believe that you cannot simply ignore geopolitics, especially in a "strategic" area like space. Countries and organizations, wherever they are, should be able to get addresses, and having multiple RIRs is the only way I see that happening. 
>> If the WG really wants aggregation at the [planet, colony, outpost, building, whatever ] scale they can still get it with multiple-RIRs.
> 
> 
> Do we have any examples where someone could not get an address for geopolitical reasons?  The discussions at the last IETF suggested that in fact, RIPE was bending over backwards to provide service above and beyond.  
> 
> I would like to propose a compromise: we drop all discussion of the number of RIRs and instead add text about the NRO maximizing aggregation, both at the body level and beneath it.

+1. I think that is the right approach. We shall define the technical side (which ends up as requirements for allocations), and let the RIR community do their own part.

Marc.

> 
> Thoughts?
> 
> Tony
> 
> 
> -- 
> deepspace mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]