Re: So where have all these new 6man WG people come from?

Toerless Eckert <tte@cs.fau.de> Sun, 31 May 2020 22:35 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8F83A0528 for <ipv6@ietfa.amsl.com>; Sun, 31 May 2020 15:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 FyWDA4pDYKT4 for <ipv6@ietfa.amsl.com>; Sun, 31 May 2020 15:35:46 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 2E8433A0484 for <6man@ietf.org>; Sun, 31 May 2020 15:35:46 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E759D548067; Mon, 1 Jun 2020 00:35:38 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DF93C440043; Mon, 1 Jun 2020 00:35:38 +0200 (CEST)
Date: Mon, 1 Jun 2020 00:35:38 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, 6MAN <6man@ietf.org>
Subject: Re: So where have all these new 6man WG people come from?
Message-ID: <20200531223538.GE62020@faui48f.informatik.uni-erlangen.de>
References: <CAO42Z2yxPvG6R_e3LUV1FkxPthgrAQ=Hq4f82k==o=TLXhZi5g@mail.gmail.com> <81825E36-1872-48D0-A2F1-9653BFB665C0@employees.org> <B3D88427-049E-46B7-A936-18469ED87A31@gmail.com> <6FD66AF5-2ACB-463A-80E2-278DF11CC86B@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6FD66AF5-2ACB-463A-80E2-278DF11CC86B@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/omJtIeyJ9rbRd8Zo2J6uz4_o6i4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2020 22:35:49 -0000

Carsten,

Not sure if you have followed the ongoing backpressure from IRTF
and IESG leadership to bless any form of forum/WG for discussions
about longer term network layer architecture. We did discuss this
a bit on architecture-discuss around the IETF leaderhip response
to some liaison with ITU-T, if you remember. And direct responses
from IRTF chair re evolution of network protocols where even more
rejecting: "That is not research ... or after chopping it up into
sub-problems it should fit into some set of WG/RGs".

And that thinking of chopping larger architectural discussions into
smaller pieces fitting into existing RG/WGs is IMHO the root of
our (IETF/IRTF) problems to do anything strategic.

For example: We have two WGs (6man, Spring), that argue how many hundreds
of bytes in header space can be spent on primarily steering, and
at the same time, we did not increase the header space for path
QoS for more than 40 years from its original 8 bit. Just look at the pain
with ECT(1) for L4S. How ridiculous is that. And thats just the latest
of frustration about QoS being handled in network headers like,
oh, i don't know, a leper? for lack of better term.

In QoS you can run around multiple TSV groups to argue functionality
and then multiple RTG groups to argue encoding of such functionality
in network headers whose groups mostly do not care or know about QoS.
That is IETF friendlyness for newcomers. Or should i say newipcomers ?

And whatever we do, if we wanted it to be efficient, we would have
to do it for MPLS, IPv4 and IPv6, unless we really had a version of
a network layer protocol that could really superceed MPLS and IPv4
without taking away their benefits, which unfortunately is what
current IPv6 does, at least in the eyes of those who will continue
to use IPv4 and MPLS, and we know what those markets are.

I think an evolution of IPv6 could be built to be backward compatible
and interoperable with IPv4/MPLS and then we would only have to bother
about defining new functionality like better QoS once.
Did i say variable lengh addresses ?

IMHO the next generation network layer really should be a "Unified IP".

Cheers
    Toerless

On Sun, May 31, 2020 at 10:27:28AM +0200, Carsten Bormann wrote:
> On 2020-05-31, at 10:20, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> > 
> > Perhaps it is time we set up an IP development working group?
> 
> That would be an IRTF research group, no?
> 
> Grüße, Carsten
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
tte@cs.fau.de