I’m well versed in Mikrotik, but new to MVRP. So I’m trying to solidify my grasp of things that seem odd.
In v7.16 they fixed an oversight with /interface/vlan interfaces on MVRP enabled bridges, so now the VLAN ID is dynamically added to the Bridge VLAN table. 
But this leaves me with a question. When you /interface/vlan/ add name=MyVLAN interface=bridge vlan-id=88, there is now another parameter mvrp=(yes|no). What is this for? Initially I though it controlled whether or not the VLAN interface on the bridge would create a dynamic VLAN entry, but that’s not it. My only other thought is that it controls whether or not VLANs from a MVRP enabled Bridge, configured with that VLAN interface as a slave port, could propagate to the underlying bridge the VLAN interface is connected to. Not only does that not seem to be the case, but that kind of stacked bridging is in the official list of Bad Configurations. (https://help.mikrotik.com/docs/display/ROS/Layer2+misconfiguration#Layer2misconfiguration-VLANonabridgeinabridge)
When viewing the results of MVRP in the Bridge VLAN table in WinBox, the “added by mvrp” entry is misleading. It shows a single dynamic entry listing all the VLAN IDs gathered from the device’s neighbor. This had convinced me that Mikrotik was not properly limiting the traffic to only VLANs that exist on both ends of the link. Packet sniffing quelled that worry, but it was confusing enough that I think there should be a change. I would like to see 2 entries. One that is tagged “Dynamic, Inactive” and shows all the VLAN IDs registered through MVRP, and a second tagged “Dynamic” that only lists the active VLAN IDs from MVRP.
I have never during maaaany years of networking had the need to have MVRP enabled.
Whats your usecase that you want to enable MVRP?
We have been reconfiguring our network as we move a branch of our core network to another room. The move has caused a reconfiguration of the network flow between switches. Multiple times there has been a VLAN who’s path got missed and wound up broken until we figured out where the gap was. If MVRP works, and works well, then we only need worry about the endpoints and the intervening switches will take care of themselves. It would have saved us from the accidental outages that we suffered.
You might ask why on earth I would be willing to trust this new feature? It’s only new to Mikrotik. It’s actually the evolution of GVRP from way back when. MVRP was designed more than a decade ago to correct the flaws in GVRP. And enough people saw value in it, and asked Mikrotik for it, to cause Mikrotik to choose to implement it. I fully intend to test the snot out of it before trusting it in full production. But if it passes, then it goes on my “Tool Shelf” right next to RSTP and OSPFv3.
Just tried MVRP.
My conclusion: if all devices on the network are using RouterOS v7.20+, MVRP might be useful and can be fully implemented on all devices.
This is what I found regarding MVRP:
RB5009 -> CRS309 -> CSS326 -> RB750
RB5009:
- Bridge: MVRP disabled
- /Interfaces/VLAN: Vlan-30 MVRP enabled.
CRS309:
- Bridge: MVRP enabled (Vlan-30 appears in the bridge)
CSS326:
RB750:
- Bridge: MVRP enabled (Vlan-30 not showing up)
If CSS326 removed from the line (RB750 connects directly to CRS309) Vlan-30 appears.
For now I'm enabling MVRP just to check if there are any VLANs still missing from my configuration.