you're the only one person here who tried to help!
Maybe because it is new for everybody so no one feels competent enough yet to advise in this high-profile topic? This was at least my reason to wait for someone more competent to answer.
Also, in my opinion such a question would deserve its own topic due to the size of the answer.
So if you want my
personal understanding, which may differ from the real implementation, here you go:
The bridge concept of 6.41 was declared as a way towards uniting bridge and switch configuration in one. So the first thing to do if you start from scratch is not to do any /interface ethernet switch setings at all as they are likely in conflict with those done the new way.
Creation of a bridge interface creates both the bridge in software (as in the old way, including the ability to attach an IP configuration directly to it) and a group of swicth ports (which is empty at the beginning untill you assign some ports to it).
So the first step is to create the bridge (with any flavour of STP switched off for now and with vlan-filtering switched off as well):
/interface bridge
add fast-forward=no name=bridge1 protocol-mode=none vlan-filtering=no pvid=1
If you eventually assign an IP configuration to this bridge1, it will be using VLAN ID 1 because pvid is set to 1.
Next, you assign the member ports of that bridge, both those at the switch and those at the CPU including eventual virtual ones (like L2 tunnels). I'm not sure whether hw=yes won't cause a conflict and the manual says it is enabled automatically if possible, so let's not specify any value:
/interface bridge port
add bridge=bridge1 interface=ether2-uplink pvid=1
add bridge=bridge1 interface=ether3 pvid=1
add bridge=bridge1 interface=ether4 pvid=300
add bridge=bridge1 interface=ether5 pvid=110
Those Ethernet ports which are going to become access ports must have the corresponding PVID set.
As you want to create an IP interface to be accessed via VLAN ID 110, you have to create a corresponding virtual interface as a member of that bridge:
/interface vlan
add interface=bridge1 name=vlan110 vlan-id=110
Of course, let's assign the IP configuration to it as well:
/ip address
add address=192.168.110.211/24 interface=vlan110 network=192.168.110.0
And now - what you had to do in switch configuration before has to be done in bridge configuration now. Note that several VLAN IDs may be grouped at each line and bear in mind that all VLANs in the same group must have the same topology across the whole network if you want MSTP to work. I
assume that the configuration below only becomes necessary and relevant once you change the vlan-filtering to yes, i.e. that already the steps above should cause everything you wanted to work except the vlan-filtering, but I may be wrong:
/interface bridge vlan
add bridge=bridge1 vlan-ids=110 tagged=bridge1,ether2-uplink untagged=ether5
add bridge=bridge1 vlan-ids=200 tagged=ether2-uplink,ether3
add bridge=bridge1 vlan-ids=300 tagged=ether2-uplink,ether3 untagged=ether4
Note that for VLAN ID 110, the bridge itself is indicated as a tagged member port of itself. This seems to be necessary to allow frames to be forwarded between the virtual interfaces (bridge and vlan) and the physical interfaces, in another words, between the CPU and the switch. This is the most confusing point for me. I don't know understand why it is not done automatically.
Also note that the vlan110 virtual interface does
not need to be indicated as a member here.
With the settings above done, you can activate vlan-filtering at the bridge:
/interface bridge set bridge1 vlan-filtering=yes
After doing that, packets with VLAN IDs other than those for which a given interface is a member of the bridge will not be forwarded to/from that interface.
I thought it should work after upgrade - at least when I was testing on my home router, OSPF and VLAN were working fine.
Am doing just that, was just stating the obvious. 
:
