DLNoah’s explanation is excellent.
I have a couple of things to add to it, though.
I’ve always tried to avoid bridging physical interfaces which have vlan sub-interfaces on them. The first Mikrotik I was ever handed and told “here, manage this!” had that type of configuration (and several other really weird things) on it… Things seemed to “bleed through”
If you do “configuration 1” from the OP’s example, but with DLNoah’s addition that ether3 ether4 and ether5 are also on the bridge as ports, then you get these side effects:
Any vlan tag OTHER than 10 or 20 on ether2 will be passed through to ether3-5 with the tag intact (and the Mikrotik itself won’t interact with those VLANs on layer3).
Any traffic arriving on ether3-5 with a tag of 10 or 20 will actually be forwarded out ether2 with the tag intact also, but any replies from devices on ether2 will be swallowed by the vlan sub-interfaces, thus no bidirectional connetivity is possible on those vlans.
The best thing to do is connect the physical ports to the bridge, and create VLAN sub-interfaces on the bridge for each VLAN that the Mikrotik should interact with.
If you want total granular control over which vlans go to which interfaces, etc - then you need to create the VLAN sub-interfaces on the ethernet interfaces, and create a unique bridge per VLAN and only make attachments between the vlan sub-interfaces, and ethernet ports which have no vlans on them.
e.g.:
BridgeV5 ports = ether2.vlan5, ether3.vlan5, ether4.vlan5, and ether5
BridgeV10 ports = ether2.vlan10, ether3.vlan10, ether6, ether7
BridgeV20 ports = ether3.vlan20, ether8.vlan20
Note that I never connect ether2, ether3, or ether4 directly to any bridge because those interfaces have sub-interfaces.
Here’s the key difference in the two methods (vlan interfaces on ether interfaces vs on the bridge interface):
With the vlans on the physical interfaces, the frames within the bridge aren’t tagged* - if you bridge e1.v10 with e2.v10 and e3.v10, then the vlan sub-interfaces strip the tags as frames arrive at the Mikrotik, the bridge forwards the now-untagged frames, and then the egress vlan subinterface stamps a new tag on the frames as they leave the Mikrotik.
(note that you could actually use different VLAN id tags on the various interfaces)
Using method #2, then the Mikrotik mostly acts as a “dumb” bridge, forwarding tagged or untagged traffic between all participating interfaces, leaving the tags alone. These frames will have their vlan tags intact while they’re inside the bridge, so if you want the Mikrotik to participate in these VLANs, simply add vlan sub-interfaces to the bridge itself. The subinterfaces will remove the tags as the frames go up the stack to the CPU for local processing (like pings, winbox packets, etc), and the replies from these services will be tagged appropriately as they exit through the vlan subinterfaces onto the bridge, where layer 2 forwarding will send the frames to their various egress ports (tagged or not).
*note- qinq frames would only have the outer tag removed and leave the inner vlan tagged on the bridge- if you don’t know what qinq is, ignore this exception.