[babel] route expiry timers for rebroadcast?

[Dave Taht <[e-mail]>]

There is a possible hole in the spec here in that it doesn't clearly
describe what should be done with forwarding route expiry timers.

https://tools.ietf.org/html/rfc6126#section-3.5.4

   When a route's expiry timer triggers, the behaviour depends on
   whether the route's metric is finite.  If the metric is finite, it is
   set to infinity and the expiry timer is reset.  If the metric is
   already infinite, the route is flushed from the route table.

   After the routing table is updated, the route selection procedure
   (Section 3.6) is run.

The corresponding 3.7 section for advertisment says:

"   If an update is for a route learned from another Babel speaker, the
   router-id and sequence number are copied from the routing table
   entry, and the metric is computed as specified in Section 3.5.2."

where it would make some sense to also bound the client router's
recieving that update to rebroadcast advertising the interval field to
some amount less than the received interval, or to the actual
bandwidth available on an interface, but still broadcast as
catch-can...

...

I ran into this issue while trying to distribute 20,000 routes over
1Mbit multicast to a dozen routers - don't do that on a production
network!

http://www.taht.net/~d/gentleremindertogetridoftheinfinitemcastqueueinlinux80211.png

Incast burp. Consider yourself warned! but "an" answer to that is to
start spreading the expiry interval out as you carry more routes than
available bandwidth and update interval can take.

Although the reference implementation lets you modify the hello
interval, it always derives the expiry timer directly from that,
rather than based on the load.


-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org