Re: [Int-area] Where/How is the features innovation happening?

Dino Farinacci <farinacci@gmail.com> Tue, 18 January 2022 23:48 UTC

Return-Path: <farinacci@gmail.com>
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 8E60B3A13C8 for <int-area@ietfa.amsl.com>; Tue, 18 Jan 2022 15:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=0.001, 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=gmail.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 GsnVDeE0vVds for <int-area@ietfa.amsl.com>; Tue, 18 Jan 2022 15:48:19 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 5D7EA3A13C5 for <Int-area@ietf.org>; Tue, 18 Jan 2022 15:48:19 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id x83so875720pfc.0 for <Int-area@ietf.org>; Tue, 18 Jan 2022 15:48:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF8C18E1lHvEaDZPFU1Frib835/30RIZP6rhR0kCqZs=; b=YdsW8PpQG/rlNTSApUdta3cOxMaUY/wPjNEkghp4fnvMowf5amvXILXcYzMKtQYhT3 FGAJdobbPS9TiiiTxWv2aTvZ+7Kxf+MRD0TRL6bJHGLs1AgbB6ZKDo0rl1gvT7ZWIs1n 9ktJ5M+rCz6BpPrdEyUujTL86mjR7UZ5vtRvlP4/XSNwfDB2zaIdFFEyc6Pbbzr872Y8 4KYZWF8om0efm5xaqDVLBdVDJYqRwNaZS4YuJnOuW3T/5LHnNsVeRgkNSTjQFVPVwTcY J+kifM6hEwtmTgoyO1U3ZogVfvMN4EBxjXFVUN5Gu+3VeMw2zrrPUOhmCGLPNyVahnHD 8qnw==
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=jF8C18E1lHvEaDZPFU1Frib835/30RIZP6rhR0kCqZs=; b=wE7CTKGKKBmNP2wXgEPACHWJRpZqqmXPNBnfa21ImPPxGubL8CC76Kqlb2ZV6VJu+4 lcvhJcFJ2Rw4Epk9O6XOtxmfSwNQqg9X499Cq/VF/KoVd58WcE04UaRMQ4AvnlcpRjA5 YCv5N6weYZ/z7uEOfpmV9xOLxknM3P5m74d8Vs41YFL6E+LfScvsz60g8M2tv4eBel74 ZGSIhpE5EHiDl0FrOvOJAH9HkEARim2J4kWqX4CMm2+JLdkQBEpGWrdsULYGTGhDazop aF0CGeCS7qQ2AsGz2j89uluIulNM6kCPt1NwvPEKONcNESH5mz/F8giU2fq/RJ/rYs2I K1zw==
X-Gm-Message-State: AOAM531GpmcgK0fH1wXXhnf7ThoEJi/XwgB8gM0hnFyS129zu/Fc3GJq pGCQIvknM/fA+K125HnB7UygQKdeQcc=
X-Google-Smtp-Source: ABdhPJzbR2ak4eZeD1Oxa/eNGfKJOeTERB7X09krikqrN5GU+QmJI70Gyr94a/zAwr+lPPRL4C32JA==
X-Received: by 2002:a63:1d5:: with SMTP id 204mr14009513pgb.623.1642549697902; Tue, 18 Jan 2022 15:48:17 -0800 (PST)
Received: from smtpclient.apple ([2601:646:9600:fef0:c886:6148:4c36:4a4f]) by smtp.gmail.com with ESMTPSA id o184sm18636680pfb.90.2022.01.18.15.48.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jan 2022 15:48:17 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <346DEA9F-A4DA-49C6-9976-2E9C3C43B65C@gigix.net>
Date: Tue, 18 Jan 2022 15:48:16 -0800
Cc: Int-area@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EA7608D-E632-414F-BAB7-447ADFBD877D@gmail.com>
References: <5FEE2C71-61D3-498B-AF2F-3B8DFC5C428C@gigix.net> <346DEA9F-A4DA-49C6-9976-2E9C3C43B65C@gigix.net>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/N3Xj8Ij6XgM30hvqx1A2gyZcGC8>
Subject: Re: [Int-area] Where/How is the features innovation happening?
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: Tue, 18 Jan 2022 23:48:24 -0000

I think it does but leave it to others to comment if complete.

Dino

> On Jan 18, 2022, at 3:27 AM, Luigi Iannone <ggx@gigix.net> wrote:
> 
> Hi All,
>  
> Thank you all for the fruitful discussion in this thread.
> I am trying to summarize a bit the discussion and here is what I see:
>  
> ·         The ”where” is a 2-dimensional space:
> o   Horizontal: Internet edge vs core. The criticality, scale, investment on the core of the Internet makes it more difficult to introduce innovation, while at the edges there is more flexibility.  At the edge of the Internet, it easier to introduce innovation for several reasons: Economics, faster ROI because of faster deployment; No need of large scale deployment (and hence less standardization effort);  less stakeholders involved (sometimes just one, see following point).
> o   Vertical: at which layer of the protocol stack. The difficulty to innovate varies as well depending at which layer the innovation takes place. One thing is to innovate at application layer where the app developer has large degree of freedom, another is to innovate at network layer, which is more constrained because of its central point in the architecture. Innovation at higher layer sometimes leads to walled gardens (aka limited domains [RFC8799]). Indeed because of the centralization phenomena, an actor offering a certain service may very well develop and deploy a custom technology that does not need to be actually standardized because it is done for its own internal usage.  
>  
> ·         Horizontal vs Vertical Innovation
> o   In the public Internet, core innovation at lower layer is harder, often reduced to app-level innovation or building an overlay limited domain (aka a walled garden).
> o   At the edges it is easier to  innovate at lower layers (more vertical flexibility) but some form of adaptation is needed if global reachability is wanted.
>  
> ·         How much unique and globally routable an address should be?
> o   With the effect of centralization, edges communicate with (rather) local DCs, hence a unique address globally routable is not a requirement anymore. Dino statement looks well summarizing this point: “We may not need globally unique addresses. But I need a unique address for anyone I want to talk to and I don't care what transmission networks my packets traverse.”
>  
> ·         Flexibility in terms of address properties with respect to the intended use
> o   Connection between my phone and my smart watch vs connection between my laptop and a forum of sensitive topics. Having multiple addresses with different properties and/or semantics, to be used depending on the purpose of the communication seems desirable.
>  
> ·         Address privacy
> o   This topic comes as a relevant question (also related to the previous point). The use of IPv6 temporary addresses brings benefits that are hard to quantify, and at the moment the best solution seems to be NAT-based. Privacy seems important since has been mentioned in the previous thread.
>  
> Do folks believe that the text above well summarizes the discussion we had?
>  
> Let me know
>  
> Ciao
>  
> L.
>> On 16 Dec 2021, at 10:09, Luigi Iannone <ggx@gigix.net> wrote:
>> 
>> Dear all,
>>  
>> We have had a very nice discussion in the previous thread about what kind of features we would want from the Internet. 
>>  
>> We wanted to come back on another interesting point that has been raised during the side meeting held during IETF 112, namely is where the innovation happening? 
>> During the discussion in the side meeting, there was a short exchange between Dino, arguing about “decentralization”, and Michael stating that we are “rebuilding the edges”; the importance of the role of overlays was also briefly mentioned.
>>  
>> This is not a simple question, and may lead to an architectural argument, in line with Dirk K.’s viewpoint that only such architecture discussion may lead to possible changes to addressing, but also something that emerged in the previous thread. However, let’s at least start from the addressing perspective.
>> Rebuilding the edges and utilizing decentralization may point to some approach to addressing that is not governed by a common addressing scheme.
>> For instance, could we instead see a diversity of limited domain specific addressing schemes with most effort in ‘addressing’ being placed into the context translation that will need to inevitably happen? Or shall we instead follow the current path that forces the same context (IP semantics) to all participating edges (which goes counter the ‘rebuilding the edges’ comment)?
>>  
>> Hence the question we would like to discuss with you on: how/where innovation, realizing the features discussed in the previous thread, should happen?
>>  
>> This can help in strengthening the conclusion of the Problem Statement document (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/), in order to provide input on which way to tackle the problem. 
>>  
>> Luigi
>>  
>> (on behalf of the co-authors)
>>  
>>  
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area