Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

Toerless Eckert <tte@cs.fau.de> Fri, 10 April 2020 00:09 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0D3A15A5 for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 17:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.872
X-Spam-Level:
X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 iluIf0h5mDqc for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 17:09:42 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4643A15A3 for <architecture-discuss@ietf.org>; Thu, 9 Apr 2020 17:09:41 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 699A6548015; Fri, 10 Apr 2020 02:09:37 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5DC2A440040; Fri, 10 Apr 2020 02:09:37 +0200 (CEST)
Date: Fri, 10 Apr 2020 02:09:37 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tony Li <tony.li@tony.li>, architecture-discuss@ietf.org
Message-ID: <20200410000937.GJ44502@faui48f.informatik.uni-erlangen.de>
References: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <C758BDF2-8CD6-4C22-90CA-6ED98DACD740@eggert.org> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> <FCAB9CB5-32C6-4B03-A36B-29E83C4E8774@tony.li> <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/9IhXbVeZsvpdcdnRlL30pnU-gfY>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 00:09:47 -0000

On Thu, Apr 09, 2020 at 03:07:14PM -0700, Dino Farinacci wrote:
> > I was the one who asked the embarassing question about SRv6.
> 
> And I was the won who said ???are we going to leave any data for the user???. Where I heard a loud Tony Li laugh from the audience.  ;-)

Btw. There are interesting hybrid optical/electrical research
network architectures, where optical packets arriving are
passed through an optical delay loop and the packet header
spoofed into the electrical side to make packet
processing decisions, which can then happen when the packet
header starts to appear at the end of the optical delay loop.

Given how these optical networks will be many orders of
magnitudes faster than the electrical processing
capability, we may end up with networks that just scream
to get larger packets to max out performance. 100 Kb minimum.
And then we can waste all the header space we ever wanted.
SIDs in URL encoding, x86 BIER replication function !!!!

Cheers
    Toerless