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

["Templin (US), Fred L" <[e-mail]>]

Seems like a well-balanced consideration Toerless, which is definitely not
what was attempted with IPv8.

Thanks - Fred

> -----Original Message-----
> From: Toerless Eckert [mailto:[e-mail]]
> Sent: Friday, May 29, 2020 11:51 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: Ted Lemon <[e-mail]>; 6MAN <[e-mail]>
> Subject: Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> 
> 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]