Re: [Int-area] [arch-d] Continuing the addressing discussion: what is an address anyway?

Luigi Iannone <ggx@gigix.net> Thu, 27 January 2022 11:02 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C073A097B for <int-area@ietfa.amsl.com>; Thu, 27 Jan 2022 03:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBWLO5RG4pLJ for <int-area@ietfa.amsl.com>; Thu, 27 Jan 2022 03:02:05 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4324D3A096B for <Int-area@ietf.org>; Thu, 27 Jan 2022 03:02:05 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id u15so4053614wrt.3 for <Int-area@ietf.org>; Thu, 27 Jan 2022 03:02:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kx2mLUDeAWuiNZq3cKviATPynnqxQ4OlXtS6tea2km8=; b=Zg+y49UvrcYtn05hnG0bXiyfcWm7qLTVpk/ZG3YsKwG9M0baDIyXYV8B5UCBqUr0P8 vegIAeS5qpmYrN163k7yklwQzEXOvsTum52OOIDPUTbAT8jbjvuAfkMSc7aImomD8BCk SoKDiRiTPjR1DlYCJ2QkhfjjAPzej+AM7inSF5ANSXQXXAUacY6gCvuYATwFKDfvzpDW e6xIcyvvQuglp7ydqJ5k2OCn5XVxbmfYbijtJH8jUCgEFGPjMuuFzPwYPmqi8d89pVUC gLj9vAqs77mgjvEM7/jsGqqjT0VXWEWodGLCyLib7txHDC0IqgvblBButA0p4hrmLCh0 lUAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kx2mLUDeAWuiNZq3cKviATPynnqxQ4OlXtS6tea2km8=; b=fyHrqPB/FDq8YUVmI8AqWZESc3+kq4BQD/6NzSBu9ZmPjrkTH0aRP+sjVfCTTo7tDm wy7n8M5w98NXk2YcgBfbLqknPfw3hef+qHcA5R4lOk3VI2+4JpVvhR2ZNYfZZJVBrrHL byF8T2q9DzXGFFQNJ8CV8R5uyyIn6UFZwmC9MJdEPHpJOotM2Gmo3Cgiu2J5MLHJze3P VEYebXH+IU+jNXdHGN0pczW3u2oyRCgFDt470Oz317xGKUhikKGPxrnz7Uk5IewAi2/3 fpcxmKMMARPJVhYTwvKZvq0e7yuA3U5XqT/XqcUndy7oQXhhvFvDquciFmjeUUAPr1K1 8w/w==
X-Gm-Message-State: AOAM531Oq0fEzOqluxXgPueAuTw7VmrQOjbOTedWCeL7tQW7VPXul4qa VStkgtEN/IzgpbPWaOSst24kIA==
X-Google-Smtp-Source: ABdhPJx9y38Yp7SsLR2aFoMPZGyZbksAmmgIcleF9tCGQ95YLaoUZE9/IAL9NainWxRWOOXaya/yqw==
X-Received: by 2002:a05:6000:1b07:: with SMTP id f7mr2562496wrz.548.1643281322725; Thu, 27 Jan 2022 03:02:02 -0800 (PST)
Received: from smtpclient.apple ([2a01:e0a:1ec:470:d03b:d67b:d964:a200]) by smtp.gmail.com with ESMTPSA id j15sm1986573wmq.19.2022.01.27.03.02.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jan 2022 03:02:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <004403c236e54505a9336f408d2d302b@huawei.com>
Date: Thu, 27 Jan 2022 12:02:01 +0100
Cc: Geoff Huston <gih@apnic.net>, Eliot Lear <lear@lear.ch>, "Int-area@ietf.org" <Int-area@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <56A8A419-5D1C-42FB-9606-FAACD4EDB519@gigix.net>
References: <57c643c667d94a77b9917bb17dc142a5@huawei.com> <D9F21BA9-4EFC-4AFD-8C91-B411A3289734@apnic.net> <c4ec1cce-b754-0d85-6abe-1d065349bc7f@lear.ch> <D01FC5EF-95E3-4B56-B438-300FC89EAF37@apnic.net> <004403c236e54505a9336f408d2d302b@huawei.com>
To: Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Cu1bGDS7xfmmTQFaXyxBepaqpjs>
Subject: Re: [Int-area] [arch-d] Continuing the addressing discussion: what is an address anyway?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2022 11:02:07 -0000

Hi Geoff, Dirk, 

I  wanted to add a couple of comments on your excellent points, see inline.
 (trimmed a little bit of the text)

Ciao

L.

> On 27 Jan 2022, at 08:51, Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org> wrote:
> 

[snip]
> 
> There is also a second factor, that of sunk cost. Nobody wants to pay to upgrade existing infrastructure. Nobody. So those who want to change things build around, over and tunnel through existing infrastructure. In a deregulated world where piecemeal uncoordinated actions predominate, the level of coordination and orchestration required to uplift common shared infrastructure is simply impossible. We say to ourselves that we outgrew flag days on the Internet many decades ago, and thats true, but at times we appear not to understand precisely what that implies about today. We have built an application-based superstructure of encapsulated tunnels in the network (QUIC) that neatly circumvents the entire question of infrastructure renewal. Whereas IPv6 has been head-butting against the sunk cost of existing infrastructure for more than two decades then dramatic rise of QUIC, BBR, SVCB and HTTPS, and similar application-level technologies attests to the application world’s extreme distaste to engage with the existing infrastructure.
> 

This last point is tackled in the current set of documents and also touched in the previous thread (but can certainly be improved upon this thread).
I think that we are at the stage that _no_ there is no strong reason yet to upgrade the existing infrastructure (we do not even know to what to upgrade). However, the innovation is there and is happening, raising the question:

- Up to what point we can “build on top” without risking to jeopardize the whole?  

In the long run, up to what point we can continue the way we are solving problems today? Seeing this as a possible risk, I would prefer to discuss now about what can be done (including the “is it worthwhile?” question). Up to us to answer this tough question and engineer an improved architecture that provide sufficient  benefits to be adopted in less time that IPv6 adoption.


[snip]
> 
> Then, as now, the issue was NOT “What’s the answer?” but “Whats the right question to ask?” - at least for me.

Isn’t what we are trying to do here? ;-)

I think that the discussions happening in the INTArea mailing list are very fruitful. We just need to capture the current understanding in the documents, trying to formalize the problem we face.

As other already mentioned there is an architectural discussion to be made (and happy that the architecture discuss mailing list is in this thread), but we need to start somewhere and addressing is a good starting point.

What we need is to gather the experience each and everyone of us can provide in order to shape something meaningful to move forward…..  starting from the addresses ;-)