[PATCH] Add the Babel routing protocol to Bird

[Ondrej Zajicek]

On Fri, Oct 09, 2015 at 11:57:37AM +0200, Toke Høiland-Jørgensen wrote:
> > Default metric probably should be more than zero (zero makes sense
> > for /128 local address, while more than zero for locally reachable
> > network prefix).
> 
> Hmm, but if it's a prefix locally reachable prefix, no more routing is
> needed, so the *routing* metric is surely 0?

Generally, routing metric represents distance to the final destination
(hosts in the network prefix) not just to the last router, so it should
also contain the cost of the last hop from the router to the host.

Usually this is not much important, but there are cases where it is.

E.g. WLAN in infrastructure mode with two attached routers, one is AP,
the other is a regular station, both connected by ethernet links to the
rest of the network. In such case the station router should propagate the
prefix of the WLAN with higher cost (say two times) than the AP router,
so the AP router is a preferred way to reach the hosts on the WLAN for
the rest of the network.


> There will still be path
> cost added at the neighbours... What else would you suggest it should
> be?

Well, for RIP it is 1, for OSPF it is the same as the configured cost of
the interface.

The simple answer would be the same as the default cost of a regular link
(BABEL_RXCOST_WIRED).

Perhaps a better heuristic would be to try to find the iface associated
with the route in list of babel_ifaces and then use the configured cost
of that iface, BABEL_RXCOST_WIRED if not found.


> > 3) Documentation of functions. It is true that for protocols this is
> > less important than for public lib or nest functions, but in the case
> > of non-trivial / non-obvious functions it is a good idea. I would
> > suggest to document esp. functions manipulating with internal
> > structures, implementing some protocol processes and timer/event
> > hooks. It is usually useless to document the usual protocol glue (e.g.
> > babel_start, babel_make_tmp_attrs, babel_get_route_info), unless it
> > does some nontrivial things (like babel_rt_notify()).
> 
> Right, will make sure there are appropriate comments in the code, of
> course. But should these be formatted so as to be picked up by the
> documentation extractor?

Not for regular comments inside functions, but the initial 'block'
documentation of function should use the format, i.e.:

/**
 * rip_announce_rte - announce route from RIP routing table to the core
 * @p: RIP instance
 * @en: related network
 *
 * The function takes a list of incoming routes from @en, prepare appropriate
 * &rte for the core and propagate it by rte_update().
 */
static void
rip_announce_rte(struct rip_proto *p, struct rip_entry *en)
{
  struct rip_rte *rt = en->routes;
  ...


> >> Not sure what you mean here? Are you referring to htobe64() being
> >> glibc-specific? An how do you suggest to handle it? :)
> >
> > Well, according to man page, these functions are not standardized
> > (although widely available), be64toh is named betoh64 on OpenBSD, and
> > different header file should be included on Linux and BSDs.
> >
> > We could have lib/endian.h, which can include appropriate headers and
> > define aliases.
> 
> Okay, I'll give it a shot. You may have to tweak it for other systems,
> though... :)

Well, if you use get_uXX, put_uXX, you would not need it. Just use these:

static inline u64
get_u64(void *p)
{
  u32 xh, xl;
  memcpy(&xh, p, 4);
  memcpy(&xl, p+4, 4);
  return (((u64) ntohl(xh)) << 32) | ntohl(xl);
}

static inline void
put_u64(void *p, u64 x)
{
  u32 xh, xl;
  xh = htonl(x >> 32); 
  xl = htonl((u32) x); 
  memcpy(p, &xh, 4);
  memcpy(p+4, &xl, 4);
}

(they are not part of lib/unaligned.h in the master branch, but they are
from one of my branches)


> > Is that true or the routes in e->routes may later turn infeasible?
> 
> Yes, because the feasibility distance can change. For example in this
> scenario:
> 
> We receive route X from routers A and B with metrics 50 and 100,
> respectively. We then add the path cost of 20 to each of those, so we'll
> be announcing it with metric 70, making the route towards B infeasible
> (feasibility distance is 70 < 100). Now, if router B gets a better route
> and re-announces with metric 20 (this could also be a from a new router
> C), that route will turn feasible. We will then pick that, and
> re-announce with metric 40, turning that into our new feasibility
> distance. This makes the route towards A infeasible even though nothing
> changed in A's announcement.

Thanks.


-- 
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/20151009/07b1de7a/attachment.asc>