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

Scott Mitchell Johnson <scott@luna.sol.int> Mon, 31 August 2026 03:13 UTC

Return-Path: <scott@luna.sol.int>
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 C24F9131FDC4C for <deepspace@mail2.ietf.org>; Sun, 30 Aug 2026 20:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788145987; bh=ijoQx4EAJQYiE7jXMsAb2gpUsvhA1BJ8HxCgJiJZYQE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=soNcF/VHD58Lr/dVeKDE9Ta/ZV/d6S7/agDm+9Qziyv90mOB3E9WpT5ta110cvp2Q yeX/EqMXwgadFvNIUW07rOTvhL4ZaEojtGlTuGoT7Z7bTAgyNu5wYrR7bXr3ZSt/hN 484CVzyjP3erjCmNq3//suEFvBEVziUy0eLHgtAA=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 NuzSIUj3vtCx for <deepspace@mail2.ietf.org>; Sun, 30 Aug 2026 20:13:07 -0700 (PDT)
Received: from durga.spacelypackets.com (unknown [IPv6:2602:f56e:e2:1::18a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 619EA131FDC45 for <deepspace@ietf.org>; Sun, 30 Aug 2026 20:13:06 -0700 (PDT)
Received: from scott by durga.spacelypackets.com with local-bsmtp (Exim 4.98.2) (envelope-from <scott@luna.sol.int>) id 1x0sRR-000000002o1-3Cqr for deepspace@ietf.org; Sun, 30 Aug 2026 23:12:13 -0400
Received: from scott (helo=localhost) by luna.sol.int with local-esmtp (Exim 4.98.2) (envelope-from <scott@luna.sol.int>) id 1x0sRN-000000002FZ-2OTU; Sun, 30 Aug 2026 23:12:09 -0400
Date: Sun, 30 Aug 2026 23:12:09 -0400
From: Scott Mitchell Johnson <scott@luna.sol.int>
To: Tony Li <tony.li@tony.li>
In-Reply-To: <C81F1436-8C88-4785-B38E-F9AC821DC9B5@tony.li>
Message-ID: <8ff23cc4-e0eb-0e48-1944-45c688932e2c@luna.sol.int>
References: <CAHw9_iKxFrW+XMi0MGTUsBUbrGbDSNOVMx-=ghgGfa0eboTBBA@mail.gmail.com> <fa5f4b39-687a-43b9-afed-13ebd536f489@gmail.com> <D9B526B5-AE39-40E7-909F-EF5D2152D9F5@tony.li> <f3c83b69-20bc-a1f5-327e-b0944bbd8c5e@luna.sol.int> <BEA196AE-1112-4A1E-9FDD-D4BA549FABE8@tony.li> <16a05ba2-ff5f-93b5-80aa-05f896df9774@luna.sol.int> <C81F1436-8C88-4785-B38E-F9AC821DC9B5@tony.li>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1214711701-1788145929=:7897"
Message-ID-Hash: R33QQ2NK7GDASKRPT7NML42EODGNNZGX
X-Message-ID-Hash: R33QQ2NK7GDASKRPT7NML42EODGNNZGX
X-MailFrom: scott@luna.sol.int
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: Alejandro Acosta <alejandroacostaalamo@gmail.com>, deepspace@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/VLJ5e7TLp8Nixtz6EZ8V-XwfzY0>
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, 28 Aug 2026, Tony Li wrote:

> Hi Scott,
>       In the context of this hybrid BP + IP approach to Solar System
>       Internetworking, we really don't need aggregation for routing
>       purposes, because in this model, neither routes nor packets need
>       to traverse high latency space links.  What would work better,
>       under this model, is unroutable, "martian" designation for any
>       IP networks NOT deployed on the local world.  I do agree that
>       designated blocks should be set aside for off-world use, just
>       for different reasons.
> 
> 
> 
> Early into the formation of this WG, it was agreed that this was not going
> to become a BP vs IP cage fight.  I am going to respect that.

Gee, I remember it as something along the lines of "discussion of BP is 
forbidden."  If that is still the case, and nobody here can can 
countenance a discussion concerning actual viable solutions which include 
both IP and BP components, then please kick me :)  I, however, think that 
attitude is placing one's head in the sand, or failing to see the forest 
for the trees.

Further, it becomes relevant here as working solutions could be affcted by 
the requested codepoints, depending on the verbiage used to define 
network addresses designated for off-world use.

> 
> I will point out that the concept of islands of IP is contrary to Metcalfe’s
> Law.  

Ethernet is great and all, but if Bob intends on stringing CAT5 (or coax, 
if we are being period accurate concerning when Metcalfe coined the term) 
to Mars, the laws of physics will get in the way.  Similarly, many of the 
assumptions of application design used in IP based networks are not 
applicable in this environment; specifically constant, low latency 
connectivity.

> The islands will inevitably merge, sooner or later, so addressing and
> routing will be involved.

IP addressing and routing are certainly issues on the surface of worlds, 
and even in most orbits.  Between worlds, however, contact plans and node 
numbers become the relevant resources to consider.  The merging of islands 
will indeed happen, just not in the way you are considering, and that is 
already underway.

> 
> If BP is used as the link layer, so be it.  It’s more fit for purpose than
> avian carriers, but equally acceptable from a layer 3 vantage point.

Just as a point of order, BP is not a link layer protocol.  While it is 
true that one can encapsulate packets in bundles, that does not magically 
convey delay/disruption toleranance upon the applications whose data are 
so encapsulated.

Enjoy,
Scott

> 
> Regards,
> Tony
> 
> 
>