Ondrej Zajicek <santi...@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
signature.asc
Description: PGP signature
