[Babel-users] Ability to work with massive number of routes? (global full-table)

[StarBrilliant]

Hi Babel community,

As I mentioned in another thread, I am curious about whether Babeld
can be adapted to work with global full-table.

One of my environments uses BGP full-table from 3 upstream ISPs (each
with 785k routes currently).
  +----------+  +----------+  +----------+
  |Customer A|  |Customer B|  |Customer C|
  +----+-----+  +----+-----+  +----+-----+
       |             |             |
  +----+----+    +---+---+   +-----+-----+
  |Edge Asia|----|Edge US|---|Edge Europe|
  ++-------++    +---+---+   +-----------+
   |       |         |
+--+--+ +--+--+   +--+--+
|ISP A| |ISP B|   |ISP C|
+-----+ +-----+   +-----+
Babeld would simply refuse to run on this environment, blocking the
whole network without converging, with 100% CPU utilization.

I understand Babel is an IGP, thus not designed to be as capable as
EGPs. However I see Babel possesses many great features that are
exclusive to other routing protocols:
- RTT measurement (good for tunnels)
- Packet loss measurement (good for wireless bridges)
- SADR support (so I don't have to bother with complicated MPLS to use
  policy-based routing)
These features above are exactly the reason why I love Babel.

And here are the things Babel currently lacks:
- Capability of handling 785k × 3 routes
- An extension to preserve AS Path

I am optimistic to use Babel for full-table routing. And just in case
Babel will be so successful, we might see Babel running between border
gateways in the future. But I currently can not figure out where the
bottleneck is. Is it because Babel runs on multicast? Or is it because
Babeld uses some inefficient data structures or algorithms?

Does anyone have ideas? Please discuss with me.