On the subject of LFA-FRR, @Richard Burts, I believe is asserting that "It is a basic part of the eigrp protocol and anyone who has had a feasible successor is using LFA." and "(Fast Reroute/LFA) which is the default." These assertions "correctness" may depend on exactly what we mean by LFA-FRR.
My reading of Cisco's documentation is "Loop Free Alternate (LFA) Fast Reroute (FRR)" is a specific feature mentioned in documentation going back to at least 2012.
What's unclear is whether this "feature" is one and the same as EIGRP having a feasible successor route which it can quickly use if the successor route fails (the latter I suspect has been there since the beginning of EIGRP).
The explicit Loop Free Alternate (LFA) Fast Reroute (FRR), at the least, is an optional extension/expansion of what EIGRP has supported all along.
What this feature offers, unlike classical EIGRP use of "per-link" rerouting using the feasible successor, is "per-destination" rerouting using "tie breaking" rules. There's much about this feature, that makes my fully understanding it, somewhat difficult, for example, its considerations when ECMP is in use.
Reading various sources of information on the "per-destination" optional variant, there are some explicit changes that can be seen, but assumptions are made that may not be true.
For example, when you've configure the "per-destination" optional variant, a "backup route" can be seen in the RIB and FIB. Such, is what further insures the "fast" in "fast reroute".
When "per-link" is being used, many assume an EIGRP feasible successor is not in the RIB or FIB, but only in EIGRP. Perhaps that's true, and perhaps not. IMO, It's possible that an EIGRP feasible successor, at some point in IOS's evolution, might also be in RIB and FIB, just not explicitly visible. Why not visible? Possibly because, logically, there's no change in function; beyond faster performance.
However, with "per-destination", "seeing" what prefix will go where, can be important.
As a side note, and perhaps showing how this optional feature is very much "different" from classical EIGRP feasible successor failover, Cisco has an OSPF LFA-FFR feature too! Understand, OSPF doesn't keep track of backup-routes, so this "like" feature, for OSPF, is interesting! Further, Cisco also has a BGP PIC (prefix independent convergence) feature, which also computes and saves a backup/alternate path in the RIB and FIB for very fast (50 ms?) rerouting. Hmm, sound similar?
The latter two also appear to be optional features.
All three, I suspect, have similar goals and likely similar RIB/FIB support.
So to recap, traditional EIGRP quickly using a feasible successor, likely, is much like another routing database having a higher AD, i.e. it's waiting "in the wings" to replace a failed route, with a lower AD, in the RIB/FIB.
These new fast reroute features, appear to optionally compute the best alternative route, even for routing protocols that don't do this, and have the alternate/standby route already in the RIB and FIB to very quickly take over if the current active route is withdrawn.
BTW, in classical OSPF, the "fastest" way to deal with link failure, is to have multiple ECMP paths. This so you don't need to wait for SPF recalculation (and other OSPF delays - feeding SPF). Here Rick is 100% correct, EIGRP, if it already has a feasible successor, is going to be "faster" than OSPF. I expect EIGRP and OSPF (and even BGP), if all support their version of the LFA-FFR would make the switch about equally fast.
