FIB compression comes with some risks. When routes churn, there are certain cases when you have to decompress the FIB. Then, the FIB must have the space, or else OOPS. If a set of compressed routes has to change to decompress some and compress a different set to improve overall compression, there is a lot of FIB programming going on. This can cause very long convergence times. Because a FIB memory cell can not forward and be programmed at the same time, forwarding takes preference and programming speed suffers. FIB programming is the slowest part of convergence, the bottleneck. If routes also have a backup path loaded, then the backup nexthops also need to be the same in order to compress. During convergence, not all routes change at the same time and there could be some very uncompressible transient route sets during convergence. Some possible sequences of compress/decompress during convergence could cause a lot of churn in FIB programming. This presents lots of opportunities for optimization and thus bugs. Regards, Jakob.