Re: Time to kill layer 2

[Ted Lemon <[e-mail]>]

Of course!

On Thu, Apr 14, 2016 at 5:54 PM, Dimitri Staessens <
[e-mail]> wrote:

> anyone thought of killing everything on top of layer 2?
>
>
> On 04/14/16 14:59, Phillip Hallam-Baker wrote:
>
>> This morning I spent an hour debugging the network to print out two
>> class projects that were due. Some points:
>>
>> 1) My ability to debug the network is better than 99% of the population
>> 2) The interaction of Bonjour, DHCP and auto power saving is unfortunate
>> 3) Things should still work after I have been away for a week
>> 4) If vendors want to be selling all that IoT gear, they have to solve
>> these issues.
>>
>> 5) I want someone to blame. Right now when the network doesn't work, I
>> don't know who is the cause. I want one point of contact. Whoever is
>> that point of contact will get most of my networking money.
>>
>>
>> One of the biggest headaches in debugging is that 'smart hubs' are
>> not. They are actually very stupid. They make assumptions of network
>> topology that are not true. Another is the unfortunate implementation
>> of DHCP.
>>
>> I don't use SNMP for a simple reason - it is not available to most
>> ordinary people. I want to understand networking for the 99%, not the
>> IETF 1%-ers.
>>
>> All this networking gear is presented to me as black boxes over which
>> I have absolutely no control (which is fine-ish) and no visibility.
>>
>> What we have today is the product of a historical process. I remember
>> the days when Ethernet ran on 10BaseT. But I installed my first switch
>> 30 years ago and it has been a switched protocol for 20 years now.
>>
>>
>> It seems to me that there is a business opportunity for any vendor who
>> takes the rather obvious step of simplifying the system.
>>
>> People talk about 'IP everywhere' and 'IP end-to-end' which is rather
>> odd when you think about the fact that virtually every local network
>> uses MAC addresses for routing.
>>
>> One of the reasons that IP won against OSI was that it was simpler.
>> Applications ran on top of the IP layer with only TCP inbetween. Of
>> course these days we do have a Presentation layer, Web Services run on
>> HTTP. But unlike the OSI presentation layer, ours does not introduce
>> extra moving parts.
>>
>> It seems to me that if we really believed in IP everywhere and IP
>> end-to-end we would insist that network switches be IP routers that
>> can be managed using BGP/OSPF or at least routing tables rather than
>> heuristic devices that try to guess where packets should go based on
>> goat entrails, phases of the moon or whatever they use.
>>
>>
>> What should have happened many moons ago was that DHCP should have
>> become a bidirectional protocol or a bootstrap to a bidirectional
>> protocol. So when a printer joins the network, it authenticates and
>> tells the network what it is. And this is all defined in one set of
>> specifications from one organization, none of which assumes that
>> security is an 'advanced', 'optional' or 'enterprise' feature.
>>
>> Instead we have an ad-hoc layer trying to achieve the same result in
>> peer-to-peer fashion. A similar approach works for frogs as a
>> reproductive mechanism but only at the species level. It certainly
>> does not work for the individual ova which may or may not connect to
>> the printer it is trying to use to print the kids damned homework.
>>
>>
>> Seriously, the fact that things have scaled thus far and the 1% can
>> get them to work does not mean that we can get to the next level
>> without a serious rethink of the local network architecture.
>>
>> The type of device I think we need would be first and foremost an IP
>> router. It would have ethernet plugs on the box and use ethernet layer
>> 1 specs. But when a another 'True-IP' device was plugged in, it would
>> quickly negotiate a direct IP connection, oh and with proper 64KB
>> packets. It would also, authenticate, announce and turn on link layer
>> encryption.
>>
>> Such a device would also be a legacy router. It would fake all the
>> signals necessary for a legacy ethernet device to function. It would
>> also be responsible for maintaining the local information for the
>> network service database and intercommunicating with other hubs to
>> achieve a global network view.
>>
>>
>> The net result of all this would be that I would never ever need to
>> install another printer (no, it is not actually necessary for every
>> stupid printer to have its own stupid printer driver). Opening the
>> 'printers' folder would automatically show every printer that is on
>> the network or can be woken from slumber by the hub it connects to.
>>
>>
>