[Babel-users] About split horizon in Babel, and scaling the number of neighbours

[Juliusz Chroboczek]

>> Big network  .....  GW  ----  Small network

>> With split horizon, only the routing table of the small network is sent
>> over the slow link.

> split horizon only helps in the GW → "Big network" direction, but cannot
> do anything in the "Big network" → GW direction.

That's right.  We're reducing total traffic by 50%, but the resulting load
is hightly asymmetric.

> A   B   C   D ---- E
> |   |   |   |
> -------------

> If there are n neighbours, for each new or retracted route, there will be
> n broadcast messages, instead of just one with split horizon.

In principle, you're right.  But in practice, you're not setting up
routers to have just one interface:

  A'  B'  C'
  |   |   |
  A   B   C   D ---- E
  |   |   |   |
  +---+---+---+

In this case, the route flap is going to be reannounced by each router on
the other interface, and so we're back at a (roughly) 50% reduction.

> This may be significant if the shared medium is slow (emulated by a VPN)

Ah, I see.  You're performing routing both in the VPN (tinc) and in Babel,
and the two routing algorithms are interacting in unpleasant ways.
Ideally, you wouldn't do that -- you'd use the VPN for point-to-point
links only, and let Babel take care of the routing.

If for some reason you insist on routing inside tinc and want Babel to
take care of the resulting mess, you could modify Babel to send multiple
unicasts instead of a single multicast (for updates only -- hellos still
need to be multicast).  I'd be willing to accept a patch that does that
(configured by setting the maximum number of unicasts before we switch to
multicast) assuming it's clean enough and avoids code duplication.

Perhaps related, Ray Hunter said the following on the Homenet list:

  Multicast has issues on some link topologies (e.g. where it has to be
  emulated), and in situations where devices attempt to sleep for as long
  as possible. So even though link-local multicast may be part of the IPv6
  base spec, it may be desirable to avoid use of multicast traffic where
  possible. e.g. a routing protocol could perform initial neighbor
  discovery using multicast, but then switch to unicast when maintaining
  individual neighbor associations on the longer term, or for exchanging
  information with specific neighbors.

-- Juliusz