Subject: Time to kill layer 2

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Apr 2016 08:59:29 -0400

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Apr 2016 09:48:54 -0400

> uses MAC addresses for routing.

Agreed. We have 30 years of stupid layer-2 tricks, first caused by lack of
subnet'ing before CIDR, and then caused by lack of IPv4 space afterwards.

With IPv6, we have link-local addresses which essentially do what MAC
addresses did before, and we can throw around /128 routes and the like.

My contention is that once "homenet" takes off, that layer-2 switches will
simply disappear from the home.  They will all be layer-3, just because.

    > security is an 'advanced', 'optional' or 'enterprise' feature.

Yes, and DHCPv6 is very much like that.
And ANIMA and NETCONF and Eliot's MUD proposal are doing things like what you
suggest.

The problem is that there is too little investment, and those who want to
innovate are having to fight the FCC, etc.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: <[email-masked]>
Date: Thu, 14 Apr 2016 10:15:16 -0400

> that point of contact will get most of my networking money.

...

> HTTP. But unlike the OSI presentation layer, ours does not introduce

The funny thing about mentioning OSI here is that it would probably be
very easy indeed to triage your network issue if your hosts were running
ES-IS, and your routers IS-IS. You could plug into IS-IS and see
everything. :)

Thanks,
Chris.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Apr 2016 11:21:23 -0400

This problem is solved in a multicast way with mDNS and DNSSD.   DNSSD is
working on a way to make this work better in a multiple-subnet environment.
  I'm hoping to produce a solution for homenet that allows devices to
register using unicast rather than multicast and does a better job of
actually tracking what services are connected to the network.   You can see
a bit of this in the -00 of the homenet naming architecture document.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Apr 2016 12:32:34 -0400

On Thu, Apr 14, 2016 at 11:21 AM, Ted Lemon <[email-masked]> wrote:
> This problem is solved in a multicast way with mDNS and DNSSD.

No, the problem is 'addressed'. If it was solved, it would work.

The problem is that it isn't working and I can't identify a single
point of failure. Whenever that happens, it is the standard at fault.

> DNSSD is
> I'm hoping to produce a solution for homenet that allows devices to register
> using unicast rather than multicast and does a better job of actually
> tracking what services are connected to the network.   You can see a bit of
> this in the -00 of the homenet naming architecture document.

Going to unicast should help. Multicast configuration really doesn't
work on a network with as many hubs and devices as mine has.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 14 Apr 2016 12:54:01 -0400

> work on a network with as many hubs and devices as mine has.

​multicast would work, if all the hubs/devices did multicast properly,
right? :)
it's not clear that unicast works, if the problem you are trying to solve
is service-discovery... absent some registry of 'services' for your clients
to use, of course (which is the point of the mdns thingy).​

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 14 Apr 2016 09:54:12 -0700

Hello Phillip,

Layer 2 isn't just one thing.  Do you specifically mean to eliminate 
layer-2 addresses, or something more?

Regards,
Charlie P.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Apr 2016 12:54:47 -0400

You should read the homenet naming and service discovery architecture
document. :)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Apr 2016 08:23:48 +1200

>> ​multicast would work, if all the hubs/devices did multicast properly,

Really stupid devices do multicast properly because they are genuinely
transparent to layer 2. The annoying devices are the ones that pretend
to be layer 2 + layer 3 devices but are actually half-baked layer violation
devices. (To be specific, I have recently been burned by a layer 2/3 switch
that does not perform correct MLD snooping. And I agree that you have to be
in the 1% to diagnose that.)

>> to use, of course (which is the point of the mdns thingy).​

It seems to me that doing everything unicast makes life harder for no
reason. I don't know how we could make the Anima signaling work without
multicast, but we are restricting it strictly to link-local multicast.

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Apr 2016 17:43:04 -0400

On Thu, Apr 14, 2016 at 4:23 PM, Brian E Carpenter
<[email-masked]> wrote:
>>> multicast would work, if all the hubs/devices did multicast properly,
>>> right? :)
>

As a general rule, any time a network device attempts anything
heuristic, it is going to get things wrong. The heuristic becomes a
source of error. Which was why so many of the early NATs were so
comically bad. They would attempt to patch up protocols like FTP, make
a hash of it and break things.

Sure, Homenet might solve some of these problems. But the reason for
my 'screed' is that listening to folk in Buenos Aires, I think a lot
of you are trying to build a network for yourselves and not a network
that works for someone like Jeremy Clarkson.

One of the rather more frustrating recent developments has been an
understanding of 'usability' that comes down to 'don't give the user
any information that might confuse them'. Windows and OSX both suffer
from their own particular flavors of this approach. In networking it
is the hub that is dropping the packets and not saying why or even
mentioning the fact that it did so.

>>> to use, of course (which is the point of the mdns thingy).
>

As another general rule, all protocols that rely on superfluous
communication are bad protocols.

Before talking on a network, a device should authenticate. Is the
device going to authenticate with every other device on the network?
Does anyone imagine that to be scalable? I have over a hundred devices
on my network and in ten years time, I think that will be considered
small. If we are serious about IoT then every socket, every
lightswitch is a network device, thats another couple of hundred right
there.

Recourse to multicast is the network equivalent of suck it and see
programming. Instead of having a concept of fault tolerant network
control with failover, every device on the network is constantly
yammering to the network as a whole just to tell people its there.
When people do that, we call in a psychologist.

In process control, networks are much quieter because the plant
managers want to be able to tell why every packet on their network
appeared. Noisy protocols that talk for the sake of talk are severely
frowned on.

---

From: Dimitri Staessens <[email-masked]>
Date: Thu, 14 Apr 2016 23:54:58 +0200

anyone thought of killing everything on top of layer 2?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Apr 2016 17:56:38 -0400

Of course!

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 14 Apr 2016 23:47:51 -0300

All the way up to the user ? Many times.

On 4/14/16 6:56 PM, Ted Lemon wrote:
> Of course!
> 
> On Thu, Apr 14, 2016 at 5:54 PM, Dimitri Staessens
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Chaitanya D <[email-masked]>
Date: Fri, 15 Apr 2016 09:00:04 +0530

The BOFH way - kill the user and let the network be.... ;)

Kidding of course

From: Carlos M. Martinez
Sent: 15 April 2016 08:18
To: Ted Lemon;Dimitri Staessens
Cc: ietf
Subject: Re: Time to kill layer 2

---

From: Dimitri Staessens <[email-masked]>
Date: Fri, 15 Apr 2016 08:36:35 +0200

If you killed the user, Layer 3 would stop working...

On 04/15/16 05:30, Chaitanya D wrote:
> *From: *Carlos M. Martinez
> *Sent: *15 April 2016 08:18
> *To: *Ted Lemon;Dimitri Staessens
> *Cc: *ietf
> *Subject: *Re: Time to kill layer 2
>
> >         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
>
> >         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
>
> >         topology that are not true. Another is the unfortunate
>
> >         implementation
>
> >         of DHCP.
>
> >
>
> >         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
>
> >         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
>
> >         It seems to me that there is a business opportunity for any
>
> >         vendor who
>
> >         People talk about 'IP everywhere' and 'IP end-to-end' which is
>
> >         rather
>
> >         course these days we do have a Presentation layer, Web Services
>
> >         run on
>
> >         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
>
> >         packets. It would also, authenticate, announce and turn on link
>
> >         layer
>
> >         encryption.
>
> >
>

---

From: Dimitri Staessens <[email-masked]>
Date: Fri, 15 Apr 2016 08:55:38 +0200

Upss. I meant Layer 4 of course ;)

---

From: Time Warner Cable <[email-masked]>
Date: Fri, 15 Apr 2016 11:07:42 -0400

>I have absolutely no control (which is fine-ish) and no visibility.

What visibility do you want? Error messages on the printer's console?
Syslog messages?
SNMP traps? Oh, apparently not, since "SNMP isn't available most ordinary people."

>takes the rather obvious step of simplifying the system.

If a vendor tries to solve the problem, they'll just add more intelligence, which will neither simplify nor stabilize the system.

>security is an 'advanced', 'optional' or 'enterprise' feature.

See Homenet.

Lee

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Apr 2016 11:29:20 -0400

> SNMP traps? Oh, apparently not, since "SNMP isn't available most ordinary people."

What I would like is something like a WiFi certification scheme that
means 'there is a collection of technology here that is sufficient and
complete'.

Right now I would have to pay a ridiculous amount of money to get SNMP
support because it is positioned as a differentiator between SOHO and
'enterprise' class devices.

Getting the feedback necessary to make it work should not be an
'enterprise' feature.

>>security is an 'advanced', 'optional' or 'enterprise' feature.

That seems to be premised on the assumption that the home network will
be a simplified version of today's enterprise network rather than
having far more moving parts.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Apr 2016 11:36:28 -0400

There's a very interesting discussion about NetJSON as a management
strategy for homenets going on on the babel mailing list right now.   There
is a very cool but not very informative demo here:
http://ninux-graph.netjson.org/topology/e384464c-d1d2-4af3-aae1-4e852a28d956/

The thread is here:
https://mailarchive.ietf.org/arch/search/?email_list=babel&gbt=1&index=MSVfepqNBnEahhioJocbbCqHODg

(Subject line: NetJSON outreach)

On Fri, Apr 15, 2016 at 11:29 AM, Phillip Hallam-Baker <
[email-masked]> wrote:

> > On 4/14/16, 8:59 AM, "ietf on behalf of Phillip Hallam-Baker" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Apr 2016 15:56:00 -0400

Any time you eliminate use of ASN.1, it is a win.

On Fri, Apr 15, 2016 at 11:36 AM, Ted Lemon <[email-masked]> wrote:
> There's a very interesting discussion about NetJSON as a management strategy
> for homenets going on on the babel mailing list right now.   There is a very
> cool but not very informative demo here:
> On Fri, Apr 15, 2016 at 11:29 AM, Phillip Hallam-Baker
> <[email-masked]> wrote:
>>
>> > On 4/14/16, 8:59 AM, "ietf on behalf of Phillip Hallam-Baker"
>> > <[email-masked] on behalf of [email-masked]> wrote:
>>