[RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Jo-Philipp Wich]

Hi,

> [...]
> The same feeling is still with this DSA proposal. The syntax "lan2.t
> lan2 lan3 lan5" is unstructured and it does not help too.

What is unstructured about it? The fact that it is not a uci list? That can be
easily changed.

> The use of "switch0" for cpu interface is good and I think it should
> even be used for swconfig (simply rename eth0 to switch0 by default
> and it will improve usability).

I agree but I don't think it'll ever materialize for swconfig.

> Trying to reuse the current swconfig syntax might be a curse that will
> haunt us. We could have simply 2 sections: bridge (L2) and interface
> (L3). My proposal:
> 
> config bridge br-lan <- the real bridge device name

This is invalid uci syntax, dashes are not allowed. It also duplicates "config
device" with "option type bridge".

>   option type "auto" # use the best way to merge every ports

What possible ways would there be?

>   # swconfig
>   [...] 

Skipped because I don't think there will be new syntax for swconfig anymore.

>   # DSA
>   list port lan1     # lan1, no vlan filtering (trunk mode)
>   list port lan2.1  # lan2 port, vlan 1, untagged
>   list port lan3.1t # lan3 port, vlan 1, tagged
>   list port lan3.2t # lan3 port, vlan 2, tagged

All of that except vlan/untagged are already possible using:

config interface foo
  option type bridge
  list ifname lan1
  list ifname lan2.1
  list ifname lan3.1
  list ifname lan3.2
  option proto ...

or alternatively using:

config device
  option type bridge
  option name blah0
  list ifname lan1
  list ifname lan2.1
  list ifname lan3.1
  list ifname lan3.2


> [...]
> 
> My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
> but it looks easier than current swconfig and dsa proposed
> configuration.

It might be a matter of taste but personally I don't see what is easier about
it. The main change seems to be that instead by VLAN ID, your proposal groups
the port memberships by bridge. So instead having a vlan section that attaches
ports to a bridge, you declare a bridge containing ports with their respective
VLAN IDs.

> The main points are to split L2 and L3 confs, split port list into
> individual options and let the system decide the best way to implement
> the proposed setup.

Point 1 is already doable, point 2 can be easily added (in fact changing
"option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list
ports lan3" is possible without changing any code).

I disagree with point 3. Having a network config that automagically translates
into different things on different boards makes debugging potential issues
very hard. The uci network config is too low level for that imho.


Regards,
Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200714/8928f6e4/attachment-0001.sig>