netifd: redesigning UCI config & interfaces

[Rafał Miłecki]

Current /etc/config/network design and netifd implementation are quite a
bit messy:
1. There is no clear layer 2 vs. layer 3 distinction
2. UCI sections are inconsistent
3. For some setups there are few ways of defining them
4. A lot of netifd states are implicit (magic behaviour)
5. It's really hard to handle all above with a simple & clear UI

I'm working on network & netifd cleanup and wanted to describe my plans.
Please review my following ideas.


*** ubus objects ***

Linux uses interfaces (e.g. eth0, br-lan) for laver 2 devices as well as
layer 3 interfaces. Tools like ifconfig, brctl, ip work on top of such
interfaces.

OpenWrt tools ifup & ifdown are expected to work on Linux interfaces
just like ifconfig. They call ubus objects methods "up" & "down".

That's why we need network.interface.<foo> ubus object for every used
Linux interface. No matter if that Linux interface is layer 2 or layer
3. Even if Linux interface "lan" is a bridge (layer 2) we still need a
way to bring it up & down (so network.interface.lan is required).

Adding a new set of ubus objects (like network.device.lan) would result
in duplication. We don't want that. E.g. both commands would do the same
1. ubus call network.device.lan up
1. ubus call network.interface.lan up


*** devices (layer 2) ***

We should have designed UCI sections for layer 2 devices. Use UCI
section types instead of "option type foo". Reasons:
1. Each device requires different handling
2. Options have different meaning depending on device type

While switching to new UCI sections we should also cleanup some UCI
options and behaviour.

Example:

config bridge
	option name 'foo'
	list ports 'lan1'
	list ports 'lan2'

Above you can see new UCI section for bridge device with "ports" list
instead of "ifname" string.

Above config should result in creating "foo" bridge Linux interface and
network.interface.foo ubus object for bringing it up / down.

Other devices would work similarly, e.g. "config vlan" for vlan.


*** interfaces (layer 3) ***

To avoid implicit magic behaviour every interface should have a device
specified explicitly. Interface config *should not* result in creating
any device automatically (like the infamous option type 'bridge').

Example:

config interface
	option device 'foo'
	option proto 'static'
	option ipaddr '192.168.0.1'

config interface
	option device 'foo'
	option proto 'static'
	option ipaddr '192.168.1.1'