Re: The waist diameter (was: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00))

[Tom Herbert <[e-mail]>]

On Wed, Jun 7, 2017 at 4:35 AM,  <[e-mail]> wrote:
> John,
>
>> Innovation at the Network layer created the Internet.
>> Innovation at the Network layer has let it grow to the point it is at – including things we may not like, ex. NAT.
>> The Internet leveraged/adopted/re-architected innovation at the Network layer that occurred even outside of IP – all the other Networking protocols that existed – Appletalk, XNS/Banyan Vines, DECnet…
>>
>> Without the innovation, we’d still be talking about SONET, X.25, ATM, FrameRelay – very narrow hourglasses/wineglasses.
>>
>> How narrow of a waist spurs innovation at the layers above and below the Network layer?
>> Should we regress in order to spur even more innovation?
>> Perhaps IP itself limits innovation at the layers above and below IP?  Ex. Dual Stack – a difficult migration and operational state.
>>
>> There are “no” Network protocols other than IP today – it is very hard to justify innovation outside of IP and IPV6 is the only platform where change is even possible and worth the effort.  It takes too long and migrations are expensive.
>>
>> When there was a soup of networking protocols and no clear consensus about how Networking consolidates around a standard set of protocols for systems to communicate – “A core principle of the Internet architecture is to keep the waist of the hourglass/wineglass narrow” - because ubiquity was a major goal.  IP itself was the Major Innovation.
>>
>> I don’t think there is a basis to say that that principle is correct in today’s Internet, my belief.
>
> Of course both of us are paid to put smarts into the network layer (:-)), but if you look at it from an Internet-wide perspective, can you name any innovations at the network layer that has been successful?
>
> - IP multicast -> fail
> - IPsec -> fail
> - Mobile IP -> fail
> - Fragmentation -> partly fail
> - Path MTU discovery -> partly fail
>
Ole,

If you look at it from a protocol perspective the above are
successful. Several of these are productively used in private networks
some of which are quite large. The fact that multicast of extension
headers aren't usable in the Internet is no justification to remove
them from the protocol.

> The only thing I can think of are the various forms of tunnelling that are a raging successes.
> And NAT. I guess you can say that the network layer's territorial dispute with the transport layer, where network has permanently occupied the first 8 bytes of the transport header have been successful.
>
> The network layer is the only thing ubiquitous among all nodes on the Internet. Thereby making incredibly difficult to change.
>
> The fact that you have near infinite address space does perhaps allow for innovation.

I would hardly call 2^128 infinite and certainly wouldn't call 2^64
infinite. Like any numbering space it's likely the hierarchical
divisions will exhaust the space long before the number of actual
addressed objects hits the maximum.

Tom

> Some good some horrid. E.g. semantic addresses (put the MTU value in the address), or giving individual chunks in a video individual addresses. But the address space is part of the tussle. Where we as a community has decided that the left-most 64 bits are given to the network and the rightmost 64 bits are given to the hosts. Both groups are going to invent stuff that requires more than 64 bits for themselves. If the IETF decided to reset the playing field and withdraw from participating setting the ground rules. Where would that tussle play out?
>
> Best regards,
> Ole
>
>
>>
>> John Leddy
>>
>> On 6/7/17, 5:43 AM, "ipv6 on behalf of [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:
>>
>>> Many of the arguments against this draft seem to
>>> be of the form "this is bad because it might allow
>>> uninformed people to make bad decisions which
>>> could have bad outcomes."  I find this line of reasoning
>>> to be somewhat disturbing.
>>>
>>> Imagine, if you will, early man, out hunting for food
>>> using his typical tool, a blunt club.  Along comes Thag,
>>> with a sharpened stick, ready to join the hunt.  Early
>>> man looks at it and says "wait...that looks dangerous;
>>> someone could use that the wrong way, and hurt
>>> themselves, or potentially hurt me.  Rather than
>>> take that risk, and potentially learn new, more
>>> efficient ways of getting food, let's just ban it
>>> now, before anyone gets any new ideas."
>>> We could still be out on the plains, beating
>>> our meat with blunt clubs instead of learning
>>> new ways of hunting.  We shouldn't fear progress,
>>> even if it comes with a few roadbumps and bruises.
>>>
>>> This draft isn't saying you *have* to use a bit boundary
>>> other than /64; it's simply saying you have the *option*
>>> to do so, if you like.  It's giving people the flexibility to
>>> try new combinations out; some of them may be ill-advised;
>>> a few warriors may come back with one less limb, having
>>> discovered the _pointy_ end goes towards the prey.  But
>>> on the whole, the potential for advancement would seem
>>> to outweigh the risks of people maybe doing something
>>> stupid here and there.
>>>
>>> I support this draft for its ability to look beyond the
>>> classful box, to a world in which creative new possibilities
>>> open up before us, enabling new and unusual addressing
>>> models and the potential for discovering new network
>>> topologies we'd never considered before.
>>> We shouldn't let ourselves be ruled by the fear of what
>>> someone *might* do, and hold ourselves back from the
>>> chance to progress and expand outside of our current
>>> box.
>>>
>>> Let's bring innovation back to the Internet.
>>
>>    I believe that innovation in the IP layer hinders innovation other places in the stack (aka the Internet).
>>    A core principle of the Internet architecture is to keep the waist of the hourglass/wineglass narrow to allow for Innovation above and below.
>>
>>    Best regards,
>>    Ole
>>
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>