Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)

Toerless Eckert <tte@cs.fau.de> Fri, 29 May 2020 18:51 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 4CB7E3A0F38 for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 11:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.77
X-Spam-Level:
X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 aoxI0tw_N51d for <ipv6@ietfa.amsl.com>; Fri, 29 May 2020 11:50:58 -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 8EFBD3A0945 for <6man@ietf.org>; Fri, 29 May 2020 11:50:58 -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 12AE954804C; Fri, 29 May 2020 20:50:53 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 09F04440043; Fri, 29 May 2020 20:50:53 +0200 (CEST)
Date: Fri, 29 May 2020 20:50:53 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Ted Lemon <mellon@fugue.com>, 6MAN <6man@ietf.org>
Subject: Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
Message-ID: <20200529185052.GA62020@faui48f.informatik.uni-erlangen.de>
References: <CAO42Z2xDygUXTGwVunGSTMkZGMF8VePrPaXLSAJg14vAJdca5A@mail.gmail.com> <6DB604C0-2C29-44A8-AB01-DA697552C7DA@employees.org> <1C1F0496-33A8-4646-B356-369EA9ABAD33@gmail.com> <DM6PR05MB6348501B266FF51DD805C25DAE8F0@DM6PR05MB6348.namprd05.prod.outlook.com> <70CDD965-C9B4-4A15-9ACA-FFE685D97129@gmail.com> <7AC15DBA-17DD-4CF7-95C1-0F1C6775BF30@fugue.com> <20200529171234.GY62020@faui48f.informatik.uni-erlangen.de> <780e1c824e204003a944d152415278f8@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <780e1c824e204003a944d152415278f8@boeing.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/59wfZJsetZNBKIHnKynu2q5H6dM>
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: Fri, 29 May 2020 18:51:01 -0000

On Fri, May 29, 2020 at 05:36:11PM +0000, Templin (US), Fred L wrote:
> Sounds like another call for IPv8 - we had that same discussion back around
> Y2K. It seems in keeping with networking technologies in general that it takes
> about two decades for history to repeat itself.

IMHO Not quite. IPv4 in the mid-90th was like a global pandemic that triggered
a mass extinction event for almost all other network layers. AppleTalk, DecNET,
CLNP, X.25/CONP, XNS, SNA, ...  ("IPv4, the best pandemic ever" ;-)

IPv6 was designed to kill & replace IPv4, and even tried to enforce
it with sunsetv4 later on, aka: follow your "history repeats itself" model.
That was well intentioned but in hindsight unrealistic. I think we learned
that what happened with IPv4 will never repeat itself and can not be engineered
by standards decree. 

Therefore, I don't think we could be successfull with periodic "kill & replace"
IMHO we should have a strategy for evolution more like how e.g.: window 10 is
managed, instead of repeating microsofts experience with the failing
kill&replace through win7 and win8. Maybe first think about expansion
through market segment profiles.

I for once wouldn't bother changing the Internet profile (RFC8200)
right now, but just think what the best incremental additional profile
for e.g.: controlled inter-networks would be that could be added incrementally
to networks where Internet profile is already running. This friendly
co-existance is already standard practice for hundreds of millions
of users anyhow for the parts of network technology where we do not
 need new standards.

Cheers
    Toerless

> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert
> > Sent: Friday, May 29, 2020 10:13 AM
> > To: Ted Lemon <mellon@fugue.com>
> > Cc: 6MAN <6man@ietf.org>
> > Subject: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> > 
> > To me the main issue is that all the discussions about possible
> > improvements of IPv6 steering headers (all the options out there)
> > do nothing but monopolize precious industry cycles into tactical
> > issues instead of also addressing the strategic problems with IPv6
> > that go way beyond optimizing steering header encoding.
> > 
> > IMHO, it is a misguided dogma to think that RFC8200 128 bit
> > addresses IPv6 is a one-size-fits-all solution not only for
> > what it was built for, the Internet, but also all arbitrary controlled
> > networks - for the infinite future!
> > 
> > IoT with IPv6 is an extreme pain (header compression, MTU).
> > Most controlled networks do not even want global addresses (security,
> > segment based app-gateway architectures, ...).
> > 16-bit/32-bit/48-bit address sizes would be highly desirable.
> > Even the 1980'th CLNP network protocol had variable sized addresses.
> > IPv6 has not solved core problems to be even equal to L2 switching:
> > plug routers together, get automatic connectivity, no bother about addresses.
> > CLNP was a lot closer to that goal too.
> > 
> > We have no "maintenance-only" constraint in IETF multicast,
> > yet for unicast network layer we only permit maintenance or
> > else you need to create another WG for just a sub-problem.
> > How silly of a structure is that ?  And please do not create
> > an IPv6.00001 working group, but think really about another
> > instance of IPv6-NG, but this time backward compatible.
> > 
> > And do not let a vendor force the hand of the IETF by developing
> > and deploying proprietary solutions first. We know how bad that works from
> > ongoing work in other layers, as well as historic examples.
> > 
> > If we continue to proliferate this "one-size-fits-all" myth,
> > then we are just continuing to extend our own version of
> > a winchester mystery house and kill our industry.
> > 
> > On Fri, May 29, 2020 at 10:30:01AM -0400, Ted Lemon wrote:
> > > On May 29, 2020, at 10:17 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> > > > My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF
> > is normally a better approach. Indeed resolving issues like this is exactly why we meet F2F at IETF.
> > >
> > > My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and
> > really tend not to take responsibility for doing that on the mailing list. This produces the effect you???ve observed, that it???s easier
> > to get consensus in-person than on the list.
> > >
> > > This is unfortunate; if the chairs took a more active role on the list, considering the cost of the time it takes for participants with
> > coding jobs to follow multi-hundred-post repetitive arguments, we would probably do a better job of reaching consensus on-list.
> > >
> > > Of course, this is a lot of work, and it???s sort of understandable that it doesn???t happen; my point is simply that if we want to be
> > an effective _online_ organization, maybe we need to start doing things a bit differently.
> > >
> > 
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > 
> > 
> > --
> > ---
> > tte@cs.fau.de
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

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