[PATCH RFC 1/1] Add the Babel routing protocol (RFC 6129) to Bird.

[Ondrej Zajicek]

On Tue, Aug 25, 2015 at 03:01:05PM +0200, Toke Høiland-Jørgensen wrote:
> > Also note that unreachable routing entries should not be propagated to
> > core.
> 
> This is actually done to satisfy a requirement of the Babel protocol:
> Temporary blackholing is used to avoid routing loops. Quoting section
> 3.5.5 of RFC6126:
> ...
> Now, if the protocol can't propagate an infeasible route to the core,
> how do I satisfy this requirement?

Didn't know that. You could propagate the unreachable route in the sense
that it will work. But usually it is not a good idea - e.g. some other
protocol could have regular routes for the same network, or there could
be some covering route.

BTW, the argumentation in 3.5.5 of RFC 6126 seems a bit strange to me.
It essentially says that unreachable routes are added to avoid transient
routing loops before Babel converges. But transient routing loops until
convergence is a common behavior for IGPs (both RIP, OSPF and IS-IS do
that), while blackholing may be far less expected behavior, esp. if it is
for several minutes, which is far longer time than usually necessary for
protocol convergence. It seems more like local policy setting than
something which should be part of protocol specification.


> > I am bit worried about liveness of neighbors and ordering of hooks.
> > Say an iface disappears. First you probably get babel_neigh_notify(),
> > which does nothing, then you get babel_if_notify(), which will do
> > kill_iface() and babel_flush_neighbor(), which unregisters data from
> > the neighbor (bn->neigh->data = NULL), but such neighbor is likely to
> > be already disposed.
> 
> Noted. Is there a description somewhere of what hooks are called on what
> events (and in what order)? Section 2.6 of the programmer's manual only
> has fairly short descriptions (in particular, what events trigger
> neighbour state changes?), and there are no ordering information.

It is true that this part is probably not described anywhere in depth.
There are some notes in nest/protocol.h that are not propagated to the
documentation. For the rest, you can use the source, but sometimes even
the source is 'wrong'.


> > Do you have any kind of multihop unicast communication in Babel, or
> > everything is single-hop to neighbors?
> 
> Babel only sends packets to link-local addresses of neighbours (and
> almost all packets can be either unicast or multicast). However, a node
> can forward seqno request packets to a different neighbour; but this is
> again only done by link-local unicast.

In that case you have always non-NULL babel_iface.iface and you could remove
some vestigial code from RIP, like:  bif->iface ? bif->iface->name : "(dummy)"

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150825/b16419d2/attachment.asc>