RE: [External] Request for information - Challenges in routing related to semantic addressing

Dirk Trossen <dirk.trossen@huawei.com> Wed, 03 March 2021 08:23 UTC

Return-Path: <dirk.trossen@huawei.com>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35AA3A1CC8; Wed, 3 Mar 2021 00:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Q2pGr0FUdJFE; Wed, 3 Mar 2021 00:23:08 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9193A1CC9; Wed, 3 Mar 2021 00:23:08 -0800 (PST)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Dr6Hp2Rn8z67vbX; Wed, 3 Mar 2021 16:15:18 +0800 (CST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 3 Mar 2021 09:22:58 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 3 Mar 2021 08:22:58 +0000
Received: from lhreml701-chm.china.huawei.com ([10.201.68.196]) by lhreml701-chm.china.huawei.com ([10.201.68.196]) with mapi id 15.01.2106.006; Wed, 3 Mar 2021 08:22:58 +0000
From: Dirk Trossen <dirk.trossen@huawei.com>
To: Tony Li <tony.li@tony.li>, Toerless Eckert <tte@cs.fau.de>
CC: "King, Daniel" <d.king@lancaster.ac.uk>, Adrian Farrel <adrian@olddog.co.uk>, "draft-king-irtf-challenges-in-routing@ietf.org" <draft-king-irtf-challenges-in-routing@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, "routing-discussion@ietf.org" <routing-discussion@ietf.org>
Subject: RE: [External] Request for information - Challenges in routing related to semantic addressing
Thread-Topic: [External] Request for information - Challenges in routing related to semantic addressing
Thread-Index: AQHXD5DsD2WqWaWC2UuHRGtz24Ylu6px26ow
Date: Wed, 03 Mar 2021 08:22:58 +0000
Message-ID: <887cb4b9dba44d4a9376a8a3cac1d2fd@huawei.com>
References: <02d401d701fd$25905a90$70b10fb0$@olddog.co.uk> <CADnDZ88mA7B_a1MUYnXSviD5wjNL3sbqaqrbK0u3NXi6OqeNAA@mail.gmail.com> <CWXP265MB2087CD3D4A4B7EB370EBD534D6889@CWXP265MB2087.GBRP265.PROD.OUTLOOK.COM> <f040717b-f099-92fb-be48-bce59a587b5b@joelhalpern.com> <B0694CCA-EADE-4EC7-BEFE-0A8E0AF3898B@tony.li> <20210302125740.GA8568@faui48f.informatik.uni-erlangen.de> <35A099CF-D39B-41A6-9C45-149ECDF26546@tony.li>
In-Reply-To: <35A099CF-D39B-41A6-9C45-149ECDF26546@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.210.165.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/routing-discussion/X-8dmOWv_kovsYRX71_P67rE7ag>
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 08:23:12 -0000

Tony,

Very well observed, while not agreeing on all points (see later). 

There seems a recurring pattern (roughly every ten years?) of discussing the continuation of the band aid model or thinking architecturally (which could lead to possible radical step sizes rather than small ones). The last recognizable discussion I can recall were the international efforts on Future Internet (NSF FIND, Europe's FI efforts, AsiaFI) with propositions like ICN and others coming from this, preceded by IPng before that. Questions on addressing and routing have always been central in those efforts. 

But it strikes me as odd when I hear about the evil of a flexible addressing structure, as you point out, while we see that we do this, effectively, in the many 'routing extensions based on some additional header information' solutions, i.e., the band aids - the separate draft at https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ discusses this. What we achieve are point solutions, which are all extending 'the semantics of routing' beyond the limited meaning of 'routing based on the IP address only', while opposing that the address structure itself should be extensible. In my view, the band aids show the desire to move beyond a narrow semantics of the Internet address, somewhat oddly aligned with the opposition to discuss more flexibility in addressing.

When you point at the pitchforks coming out when talking about this or even labeling this as 'fixing IPv6', there is a clear danger here. While I can understand and well appreciate the tussle between an engineering community that is chartered with finding 'actual' solutions with constraints like backward compatibility and preserving 'sunk costs' in existing HW, and those who cast aside those constraints to think about larger stepsizes in change, there is a challenge to preserve the right balance between those (often opposing) concerns. We may not want to end up sounding like discussions many decades ago when a 'young Internet' came around and proposed radical changes against all calls of preserving many decades of telecom investment. 

In order for the 'young child Internet' to remain young and fresh, there must be a stage where these discussions can be held. The IRTF is meant to be this place, which is where we saw this discussion could ultimately unfold - unfortunately, the draft was not accepted for the IRTF open meeting discussion at this upcoming IETF. But it cannot be a point discussion only, it should be a continuous discussion due to the central role that addressing and routing plays in the Internet - this is where I disagree with your assessment about the lacking wisdom (since we may miss on the right inputs to gain that very wisdom in this limited community). Instead, we should seek input not only from those being closer to SDOs (and the IRTF has a strong proximity to the IETF so is seen by many researchers as an SDO-type organization) but from those who really care about questioning constraints and limitations but may not be naturally drawn into the IRTF. Continuity of the discussion is key here, not recurring waves (every about 10 years).

Best,

Dirk

-----Original Message-----
From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li
Sent: 02 March 2021 19:21
To: Toerless Eckert <tte@cs.fau.de>
Cc: King, Daniel <d.king@lancaster.ac.uk>; Adrian Farrel <adrian@olddog.co.uk>; draft-king-irtf-challenges-in-routing@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>; routing-discussion@ietf.org
Subject: Re: [External] Request for information - Challenges in routing related to semantic addressing


Hi Toerless,


> You meantion locator and identifiers as unresolved. Do you think this 
> should be subject to more work in IETF and/or IRTF (routing) ? If so, how ?


Not at this point, no.

We are not yet wise enough.

We looked carefully at this. One option was fixing the architecture. The other was a band-aid. We recommended fixing the architecture. The community decided that the band-aid deserved all the effort. 

The band-aid has yet to deliver anything meaningful and the architecture is not fixed.  Pretty clearly, the pain level has not reached the threshold where we will act wisely and in our own best interests. If only there was some group that was responsible for the architectural oversight of the network. But alas, there isn’t.


> You mention architecture fundamentals and routing / addressing ties. 
> Do you think there such fundamentals that would transcend what i would 
> call different "address semantics",
> e.g.: unicast, multicast, ICN ? I am asking because if there where 
> such fundamenals of interest, maybe working on them would ease the 
> ability to operate multiple semantics, add and/or extend them.


Yes, an architecture has to define all of the uses of the addressing field and explain how routing will make use of the address in each and every case.


> You mention protocol field / address overload. I completely agree, but 
> why then have we not attempted to work to easier extend instead of overload packet header / addresses ?


Because extensibility at the network layer is seen as Evil.  We decided long ago that it was impossible to have extensible addresses, despite the fact that we had working hardware. Instead, we kludge to add more fields onto the network header, requiring MORE bits to be sucked into hardware, and much more complexity than if we had just made the address field flexible. And we do so in a way that is wholly incompatible with existing hardware AND wastes gigantic amounts of bandwidth.  Good job guys!


> E.g.: I look at TSVWG L4S carving out even more semantic out of 2 ECN 
> bits and grumble about printing a t-shirt "40 years of IP and all we have for QoS is still 8 bit".
> (alas, corona times are no fun for t-shirt junkies).


And it’s still more than is truly needed. ;-)


> Personally, i wish we would never ned to overload semantics of 
> addresses, because we are a) not wasting address space (as you point out) and can b) amend adress space, when needed for new semantics.
> Now: Why do we not amend our protocols to allow for that ?


Because touching the architecture is the third rail.  It is our sacred cow. Pitchforks and torches come out as soon as you talk about fixing IPv6.

Our grandchildren will hate us because we cannot get past our own myopia.  We ossified the inferior and declared it inviolate.

Regards,
Tony

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion