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

Jen Linkova <furry13@gmail.com> Sat, 29 August 2026 00:18 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: deepspace@mail2.ietf.org
Delivered-To: deepspace@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BB5971314E365 for <deepspace@mail2.ietf.org>; Fri, 28 Aug 2026 17:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787962727; bh=axbd9dc2L7izQJVjqHJXpHmKXF3fAgtA1pU8vWpA2SI=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=WqPUjHWI+Xj6U5XqKungQodSEN8sOpPoXJLxMvWiXcAhfy8QAYgFUSkOm/Gdv28x5 LYLMvkgbDmoFFSff2Qtits6EKLq4hMj9C6ddTV57ZZuU0V+RcQ6nohXZKc9uF3Xv0P hWs0oG3DCVBcgZ2DNV8Kv/7tWIF/Zk9fLJozUDlQ=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOu0Vyvcyb50 for <deepspace@mail2.ietf.org>; Fri, 28 Aug 2026 17:18:46 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3F9FA1314E359 for <deepspace@ietf.org>; Fri, 28 Aug 2026 17:18:46 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-52ff0eea420so9056211cf.0 for <deepspace@ietf.org>; Fri, 28 Aug 2026 17:18:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1787962726; cv=none; d=google.com; s=arc-20260327; b=cWLyWvF3zhQvx/Bpy75tq2PfFR6MwgUBzrspQLn5NyUYcw6PY+pcWOs9R0Nd3HL+Uy +1+cW33X3JWl3gRu3d0hFwti/Sx0sjBgrTZS2FZody8pNu53OBjt9WvuQFvpwVrgS3ZA aztZ0aYSTv2Qxt5DEyKmLM3o/LAvm4t2nQ1DvZ1pLrKei2ZWN4J8FinkkUZZr1sJntUp KlGyWGN0khpgm1SRSNoVeWDEw0MGzRQ+7a8AMICBhFB2o3/Q40WG9cEr1zm2aYEmEGFI ogAyvM9yB7wM1ABLiuznBeJoxgQdTwVupeSsPh/tW1UtP+DnM/1BeFfnF019L4vnj27A dBbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kxnqOk29eGMdbO3rO3ekZ3mo3Fsv+ggvOhWPAscWeLw=; fh=vmhGZ3ZHViBHbHvcdrWt9j27i++zgyCYZFKwe5PDvmU=; b=UxKyCpyFYHL5ru3W6sDuDBAtQaeTeg/ah/zOJoNQcrRnQiFOB9Mi6TZz99R7EfAQiF 5hvl2m5NQC1D3+VvAtJ1oawMjnkg1ZjVH4bzt22n8EcCzRo3kBWJyC+99fOk688Ym1gE 9xJc5WqO7+73ztB7w/5Nl1rYH/ibMcYxSct31oHFbz1DDAPW8IuJTl2C+i8bwXmdlQKn BkaBqAisd6bYwvOGM10IqWmBwh8+DgdzfEKkNKX1RlaQaV2+JW6Ury+pR5uvi/QrHRwJ 0s8GG7s2uyhWPrE2DNpnEtVbXChT0QSo8h9gwedMlx70gKrrJ5TesFgDAI00wS7x5dsS uS6Q==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787962726; x=1788567526; darn=ietf.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=kxnqOk29eGMdbO3rO3ekZ3mo3Fsv+ggvOhWPAscWeLw=; b=ObLwe3ctQxEYzfPFtPR8D9wSEH4azxtlQQO9cMa7k3bCdzp0A5IokieaU1PSBo777v 6d4y+t/CwqM8UA/go4pGt8i7d4p5VzyT42rRVRWZCcOSXFrN+Cy1FoXIQcITrjvx9+qv hn5tkI+JdULOrsgLiPmVwknqJkSB4+RZ6pj1FBgMtRLAsRclq6FTylopqIGNb62ouqsE RG1EIz2Hco8vK1hjCiBhb1DCOE4q4m3HQZO+natLcow7n6sGDJHLpohFdL9EHTZCsoqo wIUuQ1FgwJ45Cu5MeKKd4bt+Px3i21QRsPbg7q/heNyIBLur2+/bfZR6sXabYl96olZs avgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787962726; x=1788567526; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kxnqOk29eGMdbO3rO3ekZ3mo3Fsv+ggvOhWPAscWeLw=; b=ityMFi2eR3yXkDvf5pV0O6D6dMkFP4AfMdEOSgUqYmEVL06G931RbMRMN5S44bScVK FSA4nEY9SVcpHy4rkjyJHeOnayPknzMLG60ybseIpHmQaUx9y8YeC9j+MRw31w+miI+t XyKKwqE7J3dsMO0U7S4IwrZ0DL+WMOnVPWC9C63vDUg9A0koTYENYM6Ie+ONvwjipi6M IEtzH2KafWWTAsLf2JKE0r2OViyj0PbZ2bGGbDBKcf7khmhJM+yQhZNKC//k+pTEWrgU QYMykK96xS3ehQkLCiIOBcW1PVxQhHeb3RIYft1WY4qTvP8mbrOM6kl289j8Xd15N732 KZ4w==
X-Forwarded-Encrypted: i=1; AHgh+RrNmS706pvi0l7tBMyP/sIOriYFebLoEzTwpEc2e4OJ+CmcseBy13OAZd3WQS75GOrc5fV+g+y6GJM=@ietf.org
X-Gm-Message-State: AFuF++ldueMbEA4pqxo2wxlA8XwflpVLw8S41u/tiPL2tgGBQGksuuy6 RpYGAKwQJGyCiOLimn5unDivw4tV5HjiqSPzC7g/KoRcO6yQLZwShfG3Nx5O3IvCkUHd+b8zFgZ bows6r8wszRjJ0ltS0b7JCm5VUfCycHE=
X-Gm-Gg: AR+sD13Kvx0GHrr62tXe/c6/aPqCSbEf3QsjJymUWTl1jtn0DPiOC3LSiHfNt9pfXDW 6snMBYq0JD5gldYboFr+pvfF/t4YRmQLn57Xlc50wwvo1Crq7DA1Ofrwr9pasG0To0CTL9wWuh5 meP9pAVJ6E9zpPMTwarm4u4SdAfG6ymjkICM+okFy6D9EG5/bS4z6R8xKWOeeiyjaIbDVyo791c vzQHf7XQu3cPWzoN4JMyZIkaSZBSKaqoD8F32Wwwg3e6AKbsS/NymcxVUmR4jOhiTQGcm2nsZO7 YzjERBaECNf2raCg81cVhysTTM9gBmmbcZe1Knr5zRD5gxq7cbIYGxnT8xypUEFSyWVuHspL8L/ JkO0=
X-Received: by 2002:a05:622a:11ca:b0:52d:9be1:18b5 with SMTP id d75a77b69052e-52ff4da3daamr47187341cf.16.1787962725663; Fri, 28 Aug 2026 17:18:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAHw9_iKxFrW+XMi0MGTUsBUbrGbDSNOVMx-=ghgGfa0eboTBBA@mail.gmail.com> <0DC1FC77-DE4E-4383-94A1-2F4E385266D0@tony.li>
In-Reply-To: <0DC1FC77-DE4E-4383-94A1-2F4E385266D0@tony.li>
From: Jen Linkova <furry13@gmail.com>
Date: Sat, 29 Aug 2026 10:18:33 +1000
X-Gm-Features: AcwNN1XfvMyLH5Ebt3-HuHEWC2KzQCAllm_cwE8d0RLLjuT2ZYFvVHUI3ooZbcw
Message-ID: <CAFU7BAT10kNtpb_LKMfDiBUmp2sy=9QWYLwehSopeZ11x+vRUA@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: TLCYUUX6XYOKKD3BGDHTJDQLJOQLAHN5
X-Message-ID-Hash: TLCYUUX6XYOKKD3BGDHTJDQLJOQLAHN5
X-MailFrom: furry13@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Warren Kumari <warren@kumari.net>, deepspace <deepspace@ietf.org>, tiptop-chairs <tiptop-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [deepspace] Re: Understanding the difference in aggregation between a single and multiple RIR model
List-Id: IP protocol stack in space <deepspace.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/deepspace/aJvR4MPQTmRclbOYL9XsttEbBVk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/deepspace>
List-Help: <mailto:deepspace-request@ietf.org?subject=help>
List-Owner: <mailto:deepspace-owner@ietf.org>
List-Post: <mailto:deepspace@ietf.org>
List-Subscribe: <mailto:deepspace-join@ietf.org>
List-Unsubscribe: <mailto:deepspace-leave@ietf.org>

Hi Tony,

On Fri, Aug 28, 2026 at 10:31 AM Tony Li <tony.li@tony.li> wrote:
> Ok, let’s try an example.  Let’s suppose that there is a future colony on Mars.  It is a joint project between NASA, JAXA, and ESA.  The colony is physically and topologically co-located, so for routing purposes, we would like it to be one prefix.
>
> In your scheme, you have three agencies going to three RIRs, each of whom makes an allocation.  I can see one of two things happening.
>
> In one case, the RIRs do not cooperate.  While they allocate from the block for Mars, they each allocate from their own private pools.  We effectively lose any aggegation for the colony.
>
> In the other case, the RIRs must closely cooperate.  They need a coordinated plan whereby they all collaboratively sit down, extract a prefix for the colony from the Mars block, and then subdivide that prefix to the three agencies.  Even the non-participating RIRs must be part of this coordination because the Mars block is a shared resource.  This seems like it has multiplied the administrative costs by a factor of five, for no benefit.
>
> Of these two schemes, I suspect that the RIRs are not going to be willing to absorb this amount of overhead, so they will end up choosing the first scheme.  Routing will suffer.
>
> I will also point out that your scheme requires that you approach all five RIRs and get them on-board with this policy.  This quintuples your work.
>
> In my scheme, one RIR is responsible for doing this allocation.  Done and dusted, very straightforward.

I'm sorry, I've not gotten my coffee yet, I need more help to
understand how things work in your example.
So 3 companies are building a joint colony on Mars. Are all 3 of them
going to the RIR, each asking for a netblock, and the RIR would
allocate 3 netblocks from a larger supernet? And all 3 netblocks will
be used for the colony network? What would happen if one company
decides to leave or 2 other companies join? More netblocks (not
necessarily aggregatable with the original one) would need to be
allocated, right? What happens if the new company, which has joined
the party, wants to use their addresses for their network? Is the
'BYOIP' model explicitly prohibited by the architecture?

Or do those 3 companies form a new legal entity which would become an
LIR and would ask for one netblock? In that case - in both your and
our proposal - it will be one LIR going to one RIR asking for a block.
That LIR would act as an ISP for whoever uses the colony network.

I'd really appreciate it if you could elaborate a bit. I feel like we
might not be on the same page regarding some implicit things..

> Repeat this scenario and you end up with no aggregation below the level of a celestial body.  IMHO, this is a nightmare.

There will be some aggregation, and, again, I'm not sure your example
leads to a fundamentally different.

> I remind you of Rekhter’s Law:  Addressing can follow topology, or topology can follow addressing.

Yes, let's choose ;)

-- 
Cheers, Jen Linkova