Die beiden tables local4 und local6 werden hier zwar deklariert, aber sonst nirgendwo in der Konfiguration verwendet. Man könnte sie daher auch weglassen.
Dieser Block importiert alle Routen aus der fff-table in die bird-internen Tabellen. Im Unterschied dazu gibt es bei der babeld-Variante aber noch redistribute-Filter, welche Einschränkungen in der Routenauswahl treffen. Es gibt aktuell in der Firmware z.B. eine Route fdff::/64 dev br-client proto static metric 1024 pref medium in der fff-table, welche dadurch in der bird2-Variante mit importiert und an andere babel-Nachbarn weitergegeben wird. Das ist vllt. nicht unbedingt gewollt und notwendig.
Die hier angegebenen Filter bestehen nur aus einem accept; Statement und keiner weiteren Funktionalität, man könnte sie daher auch überall durch import all; bzw. export all; ersetzen.
Müsste hier nicht noch eine Implementierung hin? In der babeld-Variante gibt es jedenfalls eine. Ich weiß aber auch nicht genau, wann und wie diese Funktion normalerweise aufgerufen und genutzt wird.
Im Makefile von fff-babel-bird2 gibt es an dieser Stelle noch ein CONFLICTS:=, welches das fff-babeld package ausschließen soll, das Gleiche in umgekehrt könnte man hier auch noch hinzufügen.
Ich finde es gut, bird2 als Routing-Daemon in der Firmware zu haben, vor allem wegen der Performance und der Möglichkeit des sauberen config-reloads im Betrieb. Ob es eine Unterscheidung zwischen babeld und bird2 während der Laufzeit braucht, kann ich nicht abschließend beurteilen. Mir persönlich würde bird2 als Routing-Daemon in der Firmware vermutlich ausreichen, da die meisten Use-Cases damit abgedeckt sind und der Vorteil von babeld nur darin liegen würde, dass man damit mehr Filtermöglichkeiten innerhalb des babel-Protokolls hat. Die habe ich bisher aber auch nur selten gebraucht.