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

[Toerless Eckert <[e-mail]>]

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:[e-mail]] On Behalf Of Toerless Eckert
> > Sent: Friday, May 29, 2020 10:13 AM
> > To: Ted Lemon <[e-mail]>
> > Cc: 6MAN <[e-mail]>
> > 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 <[e-mail]> 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
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > 
> > 
> > --
> > ---
> > [e-mail]
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

-- 
---
[e-mail]