Completely off-topic, but both features are needed and long overdue.
ISIS would be a welcomed addition for many of the reasons already listed.
+1 for IS-IS
+1 for IS-IS support on RouterOS
+1 for IS-IS and SPB/SPBM in the router CCR2216-1G-12XS-2XQ switches CRS518-16XS-2XQ that have it supported in the new ASICS being used. We absolutely run our whole network as a Switch Fabric network based on SPBM. It’s more scalable than OSPF. For ISP’S it’s a must have to be faster and more scalable, small or large networks. IMO
Please mikrotik is ISIS essential of modern network deployments.
++++111111
- IS-IS, 2) VTI, 3) something equivalent to Cisco DMVPN or GETVPN or HP DVPN or Meraki AutoVPN, 4) BGP Multipath, 5) Lack of commit/rollback
Those are the five features that prevent me from recommending Mikrotik to large enterprise customers.
https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview
According to the wiki. It is on the way with snippets initial code arriving in 7.12
This makes me so happy to see!
Great news 
I am ecstatic about IS-IS making it’s way into RouterOS.
Does segment routing is inherent with IS-IS or the traffic engineering part is where it got very exciting?
ISIS is certainly a prerequisite for srv6 but it’s good for other things so I wouldn’t ready in too far. I would love to see srv6 for sure so I’ll cross my fingers for it.
Well, there probably was an important customer/prospect who insists on having IS-IS.
In general I do not like that MikroTIk embarks on so many new projects, while leaving existing ones unfinished.
I would say: first make sure all those red and yellow squares in the routing status page are removed, only THEN start adding a new protocol…
You and me both
…or implement a .npk package of FRRouting
What could be of value in the typical wireless network is to have automatic adjustment of metric values (cost) depending on values retrieved from a wireless link (via SNMP, as the link devices may be separate from the router devices).
The usual naive “prefer least number of hops” does not work well in a partly meshed WiFi-linked network, and it often surprises me that MikroTik does not offer a routing protocol that handles this case (which is typical for clients of their product gamma).
because there really isn’t one that handles this explicitly. I’ve asked for batman-adv in mikrotik which handles metric via quality measurement rather than link state but it seems there’s no interest. I’ve even posted on here to see if other users would support it because mikrotik may consider it if it’s a popular want, low response.
ospf is a hard fail here because every change recomputes everything everywhere, so even if you could poll the radios and get their capacity, updating ospf would be… rough.
ISIS is slightly better, it’ll decide if it’s a full update or a partial so you could inform it via script or something. This would rely on access to reliable capacity data from the radios which is a whole other effort for non-mikrotik radios.
SNMP is a fail here, plenty of radios… the most popular ones… don’t support this properly.
The lowest friction path would be batman-adv. it’s link quality measurement and propogation of slow/lossy paths allows data to be steared around the struggling links without taking those links offline. Further, it’s hello packets that are used to measure the link can be set to a lower QoS type so be more likely dropped ie saturated links could ‘signal’ batman-adv by dropping those packets which lowers the metric. batman-adv would also present a flat layer2 to the operator without layer2 pitfalls which would dramatically simplify networks.
Yes I know it is a difficult problem, but still it surprises me that there is no support for it at all.
I thought that “WISP” was a major business for MikroTik and would think that several customers would have asked for such a solution.
(be it a suitable standard protocol or some in-house development)
In our network we usually have separate router devices and link devices (not always MikroTik), the links are configured with transparent bridging and a /29 network is assigned to each link with an IP for each router and each link device for such a link. Then BGP is configured over that link.
But BGP only steers towards “least number of hops” and we can only handle complete link down situations (with BFD for better detection).
Indeed it would be nice when there was some handling of poor or saturated links.
I have considered running some software on an external server that polls link devices (and maybe routers, e.g. status of a netwatch) and then uses API to re-configure BGP (e.g. modifying a “local pref” or a “prepend” in a filter rule), but have not started that yet.