Use-cases aside, I think the bigger question is: is it technically viable to implement UCMP in Link State Protocols? LFA, in its simplest form, is the LS’ version of UCMP, and it’s computationally intensive when you do it for 1 leaf destination. When you generalize it to calculate UCMP paths to every destination in the network, and the number of nodes gets really huge, into the thousands, this can be computationally intractable. That’s why vendors have to take shortcuts, for ex, not implementing TI-LFA for the case of node failure, only link-failure.

The architects of SPB also faced this computational problem earlier on during their design phase. SPB’s SPF calculation is way more painful than that of OSPF/ISIS, because instead of doing it once from the perspective of the computing router, a SPB switch has to do all-pair SPF calculations, once for each pair of source-destination in the whole topology. Even though they claim that the all-pair SPFs can be trivially parallelized on multi-core CPUs using B-VIDs as the tree identifiers, I don’t believe SPB has ever been tested on real topology of 1000s of nodes. And there’s a limit to multi-core, as the inter-core bus contention and the LLC become the dominating bottleneck factor. Finally, SPB is fundamentally incapable of doing UCMP because the requirement of LFA conflicts with SPB’s path congruency requirement and RPFC will make sure LFA won’t work.

So even if there are situations that require the use of UCMP, one of which brought up by Pete, I don’t think it’s worth the pain for vendors to come up with a UCMP solution for LS protocols Ivan. This is because Link-state protocols essentially work on a common LSDB of global info, and this centralized model won’t scale to very large DB sizes, just like Openflow has tried and failed. Advanced distance vector protocols handle this way more elegantly.

Come to think of it, from the very beginning, in order to scale LS, their inventors had to resort to areas, basically turning LS protocols into distance-vector ones, inter-area-wise. And RIFT, in order to scale better than existing LS protocols in flood-heavy environments, also has to resort to distance-vector principles :)). BGP, the most scalable routing protocol, is a distance-vector protocol after all.

It’s not that bad. In LS-protocols, doing UCMP scales with the number of direct neighbors a router has. If a router wants to do UCMP, it has to do one SPF-computation for itself, and one SPF-computation for each neighbor. Note, once you know all the feasible (unequal-cost) paths to all routers (nodes) in the network, computing the ip-prefixes (leafs) needs to be done only once.

I remember discussing this in 1996. The first time I read about a vendor implementing UCMP in IS-IS was in 2015. I think IOS-XR can do it (please correct me if I’m wrong). The fact that it took 20 years to implement UCMP makes me suspect that no customer has ever asked for this feature.

I second Henks experience here. Modern SPF implementations (Cache aware priority queues, O(1) 2way check and early termination (loop check) allow very quickly to determine if a neighbor provides a loop free check or not. We‘re talking about 1-2ms per neighbor for 1K node topology

I’m aware of only 2 Cisco IOS-XR customers who asked for (and used partially) UCMP for ISIS during the last 10 years. Implementation was done on CRS and ASR9k.

The first one did want to implement bundle/link aggregation (even for ECMP) and had different link speeds between 2 routers. He used UCMP instead of mixed speed bundles. The second one had almost the same use case for overseas interconnection with continent across long-distance/exotic transmission links.