802.11k/v
The environment steering is used might be the most important factor. And other important question is what do you expect from the service. Some explanation is found below.
The simplest example is when you have only one AP. In this case you may set both your BSS (the 2,4 GHz and 5 GHz one) to announce each other for the STA. From this information (neighbor report) the STA may only scan the announced freqs, hence it can decide faster if to roam. From the nr report the sta doesn't have to wait until a beacon on the channel since the nr includes the bssid, the first captured packet could be used for rssi estimation. In this example the neighbor report feature was introduced.
A bit more complex situation is having two APs. In this case reporting every bssid is a nice tactic. In this case (can be in the earlier also) you may want to decide when to roam the device. For eg. one AP has more load. To do this you can do active roaming, so the BSS can send roam request to the STA. The announcement of the APs can be done via multicast or broadcast. No scan is needed (or even not possible, if the APs are far enough from each other).
An even more complex situation is the one I am using my APs in. Currently ~300 students are in the five floor dorm, the peek is 400 devices (only in-house, other interference and networks are coming the street). We have 23 OpenWRT APs for now, the other ones are unmanaged SOHO ones. This situation is tricky, since broadcasting every APs bssid and channel information could fail. @PolynomialDivision mentioned an Apple issue where the devices only take care of the first nine element of the received nr list. (https://github.com/berlin-open-wireless-lab/DAWN/commit/97e5de157fdf99651e20b0b095ce551b6fc42bc8) To resolve this problem (if there will be no other/better solutions up until then) I may develop a scenner app, so every AP scan the spectrum for adjacent BSS-es in the early hours, and use the result as a base of the NR report. DAWN can can active roam requests.
As you see the required solutions for the not so uncommon but completely different solutions, multiple steering platforms (or multiple level of feature sets?) must be available in the future to fulfill every scenario.
Answering the opening question rrm-nr-distributor works almost fine. Its only capability is to distribute every SSID with bssid and channel information through multicast. The same SSID networks will announce their neighbors as they are found via the mdns queries. Nothing else is done! My observation is that having more than 15 APs in the network the mdns query via umdns slows done for some reason to tens of seconds. If you have a lots of APs, the whole nr list will be send to the STA which could handle it or not. For small networks it is a good choice in my opinion. It also announces the APs own but other BSS's information, so helping the passive steering process.
I've tried DAWN in the Spring. The one thing I can remember is the many warning messages in syslog for NULL MAC addresses. After that many commits were contributed to the project wit many fixes and features (for eg. support for multiple SSID).
I have not tried usteer (yet).
One possible solution for steering was not mentioned. It is the one that requires a centralized controller as the OEM APs does. It could solve some problems in middle sized infrastructures. Maybe a small dockerized python script would work or some contribution with openwisp. (Haven't tried openwisp yet, but is it planned in the near future)
About 802.11r:
It works for me. Here is my config: https://github.com/simonyiszk/openwrt-rrm-nr-distributor/blob/main/example_wireless_config (also has the lines for rrm-nr-distributor). The logs indicate that fast transition is used by most of the clients in my network. I think the others do not support 802.11r.
A thing that I cannot find in the topic is the detailed description and configuration for ft-over-ds. I want to use this feature, but cannot find anything about it. As I have a mgmt network for device-device communication like this, I may send the packet on that vlan, but is not the same vlan the STAs are in. Could it be a problem, I don't know. I also don't know which port or protocol it uses. In the Summer I've found something, but cannot remember right now.
The idea of an openwrt wiki page about this topic is gap filling. I am pleased to help where I can.
i was asking what are the available steering daemons or implementations the commit is referring to.
In the beginning I had not even a single device supporting fast bss transision. Now every Android device supports it.