For these experiments I used a RB750 five port router, and attached it to the RMHAM Netlab. Overall the results are getting better, but not all the problems have been resolved. Therefore, the recommendation is to NOT upgrade any devices to RouterOS 7 yet.
After upgrading the router by uploading the NPK to the router and rebooting, the router was unresponsive. I therefore did a hard reset of the router, and was able to connect to the router using WinBox over Layer 2.
Upgrading the RouterBOARD to 7 resulted in the device booting but being unresponsive. A hard reset recovered the device and rolled back the RouterBOARD to the previous version. I therefore disabled automatic upgrading of the RouterBOARD.
Once the router configuration was reset, I labeled the interfaces, installed a bridge, mapped ports to the bridge, set the bridge and WAN IP addresses, enabled DNS and enabled DHCP. This processes was straight forward and is essentially identical to how it worked in RouterOS 6.
The Router ID is shared between protocols and seems to default to the bridge. The selected ID is dynamic, so perhaps it is prudent to manually fix it to the bridge IP. However, so far the default seems satisfactory.
To enable OSPF, click Routing > OSPF to get the dialog for OSPF. First select + on the Instance tab. The defaults are fine, specifically Version 2 (for OSPF version 2), but you must add main from the Routing Table
Leave the Filter section unused. I have not had any success with the new filters which is very different in RouterOS 7. Putting anything in the filters causes OSPF to learn the routes, but never use them.
Second click the Areas tab and +. The default backbone area is fine so just click OK.
Third click the Area Ranges tab and + and add the subnets you want OSPF to route. (In RouterOS 6 this was called Networks).
Note that you need to set all the fields. Repeat this for 10.0.0.0/8, 172.16.0.0/16 and 192.168.0.0.16. What is new in RouterOS 7 is that you can set a cost along with the prefix. For the 172.16.0.0/16 we can now set a default weight of (say) 1000 which is convenient.
Finally, add the interfaces you want by going to the Interface Template tab and clicking + to enable each interface. I connected to the Lab at Squaw and Horsetooth.
Note that interfaces are no longer added automatically and that you don't have to copy the interfaces to set the cost and network type. I have not yet experimented with VPN interfaces, but I believe you will still need to make those static by copying before adding the template. However, in the OSPF interface template a second copy is not required.
Once interfaces are added, the OSPF routes show up in the routing table and routing functions as expected. Active interfaces will show up in the interfaces tab, neighbors in the neighbors tab, and the LSA in the LSA tab, which looks very similar to how it did in RouterOS 6.
If the routes show up in red in the IP Routes, OSPF knows about the routes from OSPF but is not using them. When fooling with filters and other settings, it is occasionally necessary to disable the OSPF instance and then enable it bofore the routes turn black indicating that they are being used. I do not have a definitive answer for when this is necessary or not, but try it if your changes do not seem to be taking effect.
if (dst==192.168.0.0/22 && dst-len>=22) { reject }
In WinBox, there is no help with the syntax. You pretty much have to figure out
the rules directly. The filters are executed in order, but it looks like there
may be an implied "reject everything" at the end because an empty filter seems
to reject all routes.
I am hopeful that the OSPF filters will be less quirky than in RouterOS 6 so that we can filter all the undesirable addresses at the source, instead of having to add ospf-in filters everywhere to reject, for example, the 192.168.[0-3].0/24 subnets. However, so far I have struck out adding any filters. No matter what filters I add, OSPF rejects all routes. So I have clearly screwed it up.