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

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> Hi, i am finally sending the first batch of comments. This time it is
> mostly general comments.

Thank you very much for the comments. I have a few follow-up questions
(below), but will otherwise revise the implementation accordingly and
resubmit :)


> The proper approach is that the protocol keeps information about
> incoming routes, choose best of incoming routes, propagate that to
> core, then core chooses the the global best route, and propagate that
> back to protocols. The protocol learn that route (which may be either
> its or external), keep it as 'outgoing' and propagate it to neighbors.

Yes, this was what I was (attempting to) do as well: Anything from the
core is treated as locally exported with metric 0.

> 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:

   To avoid this issue, whenever a prefix is retracted, a routing table
   entry with infinite metric is maintained as described in Section
   3.5.4 above, and packets destined for that prefix MUST NOT be
   forwarded by following a route for a shorter prefix. The infinite
   metric entry is maintained until it is superseded by a feasible
   update; if no such update arrives within the route hold time, the
   entry is flushed.

And see also section 2.8 of the RFC for a description of the logic behind
this.

Now, if the protocol can't propagate an infeasible route to the core,
how do I satisfy this requirement?

> 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.

> 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.

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150825/65890775/attachment.asc>