Re: [Babel-users] Route-dete:wq

[Juliusz Chroboczek]

Christof, I'm very much interested in your experiments, which are likely
to improve the quality of the Babel implementations.

> We have update-interval set to 5 minutes to reduce the load on the network
> because we are hoping to run this topology on 500+ APs with 1000+ Clients.

The protocol is very flexible, but the reference implementation is not
designed to work with such large update intervals.  The amount of data in
an update is pretty small, so I would recommend reducing the update
interval -- it should be fine with thousands of routes in your network.

The right way to reduce the amount of routing traffic in Babel is not to
increase the update interval (which can at best yield a linear reduction),
but to use aggregation and filtering (which can yield an exponential
decrease in a well designed network).  Dave Taht has been successful with
this approach, perhaps he'll want to chime in.

Note that babeld currently sends updates as a single burst when the upate
interval expires (the same is true of Toke's implementation of Babel, as
far as I'm aware).  For very large networks, it would be good to split
updates into one-packet pieces that are sent throughout the update
interval.  I'd be glad to accept a patch that does that.

> * making babel trigger updates on newly appeared routes

I've gone through different approaches for scheduling updtes, and the
current master is more aggressive with scheduling updates.  I'd need to
check to make sure, but I believe it already does what you suggest.  If
you have time, could you please check if current master improves things;
if it doesn't, we need to work together to improve the implementation (no
protocol changes will be needed).

You could also try Toke's implementation, which is very well written.

> * communicating the appearance of a route across the network outside
> babel and inserting that at the gateway

I'm not sure what you mean.

> What do you think about those approaches?

Please try current master.  If not, we'll need to think together about
redesigning our approach to sending triggered updates.

-- Juliusz