[Babel-users] [homenet] T.M.S. proudly presents - Babel: the 2nd implementation

[Juliusz Chroboczek]

CC-ing the babel-users list.  Do we want to move this discussion over there?

> [1] https://github.com/fingon/pybabel/blob/master/rfc6126-comments.txt

Thanks for the comments.

> 'recently heard from' = ?

You mean Section 2.1?  That's in the protocol overview section, so I think
it's fine.  The actual procedure is defined in Section 3.4.2, where it's
hopefully clear that it's done for each neighbour.

The problem is elsewhere -- we don't say when to discard a neighbour.  The
answer is that it doesn't matter, but it should be said somewhere.  (The
reference implementation discards a neighbour after we've missed 16 hellos
in a row.)

> 'timer' <> 'time value' distinction is somewhat lacking in my opinion; some
> things require action at time point, and others do need just to be kept
> track of (e.g. 'hello timer''s various incarnations)

Where?

I think I tried to be consistent -- a timer is something that is set to
a value, decreases over time, and expires when it reaches zero.  I got it
wrong only once, saying that a timer "triggers" instead of "expires".

Relative times are consistently called "interval".  There are no absolute
times in this protocol.

> route table defined in 3.2.5 does not contain router id entries, yet 3.5.4
> refers to one

Yes it does.  Section 3.2.5 says that the route table includes

   o  the source (prefix, plen, router-id) for which this route is
      advertised;

Whether you implement that by actually storing these three pieces of data
in the route table (and look-up sources each time you need a seqno) or as
a pointer into the source table is an implementation detail, but in the
conceptual data model the route table contains a router-id.

> 3.5.4 what is 'id' in the updates and where is it stored?

Section 3.5.3, "Encoding of updates".  The problem is that I used "id"
here instead of "router-id".

> and what does the link cost = cost mean?

Confusing because I cannot use italics for variables.  Should have been
"over a link with cost /cost/".  Given the ASCII-only document, "cost"
should be renamed to "C".

> 3.5.5 describes what is done in 3.5.4, but to little point (imho)

I disagree.  3.5.4 says that a retracted route is kept in the route table
(the RIB).  3.5.5 says that this retracted route is actually reflected in
the forwarding table (the FIB, the kernel routing table) as a blackhole
route.  One could very well imagine that the retracted route is a purely
algorithmic data structure, that needs not be reflected in the forwarding
table.

> 3.6 'unfeasible route' = ?.. I assumed route table only contains feasible
> routes to start with?

Last point of 3.5.4 -- an unfeasible update is accepted, and a route table
entry is maintained (although it cannot be selected).  (You don't want to
be discarding a redundant route when it becomes infeasible, since seqno
numbers propagate at different speeds over different links -- there's
a good chance that it will become feasible within a jiffy or two.)

> 3.7.3: 'modified entry'; what if it was not modified? no gc reset? I
> assume so..

The GC timer is reset in all cases (except for retractions).  This should
simply say "the entry" or "the entry under consideration".

> 3.8.1.2 .. in response to a _seqno_ request, not route request

Right, typo.

> cannot parse 'no smaller'; not smaller?

I think that's correct, but then I'm not a native speaker.

> 3.8.2.1 is there necessarily seqno in the source table for all nodes?
> much easier just to use seqno from the route that is being
> retracted.. (maybe there is, but shrug)

The only place seqnos are kept is the source table (look at the data
model).  There are no seqnos associated to either nodes or routes.

The goal of this procedure is to get a seqno that will make the route
feasible.  Since feasibility is determined by the source table
(Section 3.5.1), it's the seqno in the source table that's relevant.

> SHOULD AE 1 or 3 for NH; why not 2? (ok, LL is better I guess..)

This just says that the next-hop for an IPv6 prefix should be a link-local
address.  That's consistent with both RIPng and OSPFv3.

-- Juliusz