Allow redistribution of kernel routes (not main table) into isis database

[Bert-Proesmans]

Request

Make adjustments to the ISIS routing instance so routes from any kernel routing table (1-254) can be redistributed into either L1 or L2 database.

Context

I'm attempting to make the simplest (in configuration and mindshare) implementation of intra-site routing with ISIS. The setup consists of 3 meshed routing devices; 2 mikrotik routers and the third is a linux machine with tailscale. The tailscale program acts as a subnet router.

ISIS works as expected, neighbors come up and routes from attached interfaces redistribute.
What doesn't work is redistributing my routes for VPN devices, and subnets advertised by other tailscale subnet routers, into the ISIS database.

The tailscale program creates one ethernet interface and one routing table(52). All visible/allowlisted VPN devices and subnets are put into the routing table(52). Correct routing (wrapped traffic vs non-wrapped traffic etc) is achieved through additional routing rules injected between local and main table lookup.

What I tried and doesn't work;

1. redistribute ipv4 table 52 level-1(isisd) rules within ISIS router => only proto connected/kernel/static/bgp/.. is working syntax
2. putting the ISIS instance in a VRF and redistributing kernel routes => the instance still selects routes from main table instead of the routing table linked to the VRF
3. ip import-table 52(zebra) => only works for ipv4 or doesn't seem to do anything for me, also this duplicates routes into the main routing table and makes correctly routing between gateway and tailscale dev more complex
4. script to mirror routes from kernel table 52 into FRR => eventually only works if imported into main table with same issues as 3.
5. coupling interface to instance (including up to VETHs and bridges) between different VRFs => ISIS not functioning

What I didn't try;

1. Redistributing other routing protocol => i want to keep the implementation simple and ISIS acting as an "underlay"
2. Assign /32 addresses to the tailscale interface for each route using a script => would work only for VPN clients, not advertised subnets. Also messes up routing due to entry into routing table local and very dynamic
3. moving the ISIS interface into the same VRF as the tailscale interface => i expect this to mess up routing due to the inserted L3 rule, but the rule ordering could be manually adjusted outside FRR to make it work. also see issues with failed attempt 2.
4. install static routes in all routers => well, that's not very dynamic..

It's possible I could have overlooked something, my experience about the documentation is not so positive and I resorted to lots of trial and error on the vtysh (which also accepts constructs that do not actually work).