Re: [babel] Restarting nodes and seqno requests

[Juliusz Chroboczek <[e-mail]>]

> - Node B restarts (i.e. shuts down, loses its transient state such as
>   seqnos and comes back up either immediately or after a relatively
>   short time). It will then start announcing prefix P again, but now
>   with seqno S' < S [which is unfeasible for A].

Yes.  The loop avoidance mechanism in Babel is stateful (the source table
contains the state), and if you loose your state, you're in trouble.  That
is why babeld saves its seqno into persistent storage at shutdown and
restores it at startup.

If the seqno is lost (either because a node has crashed or because you
have no persistent storage), then you need to timeout the source table entry:

  - first, the route times out, so its metric becomes infinite;
  - you start sending retractions, and retractions don't update the source
    table;
  - at some point, the source table GC timer triggers, and the source
    entry gets updated.

Note that the total time you wait for the route to become feasible again
is the sum of the route hold time and the source GC time, so its on the
order of a few minutes -- Babel is optimised for the case where links go
up and down, but routers do not reboot often.  If that's not acceptable,
you can work around the issue by changing router ids at every boot, so
that the old and new state don't interact.  Babeld implements this with
the "random-id" option, and it is useful in environments where routers
reboot oftent without saving their seqno.

> The question is, how is this supposed to be resolved?

There's no good solution.  The loop avoidance mechanism is stateful, and
that's a fact of nature.  (BGP avoids the statefulness by putting the
whole state into each update, which causes updates to have an unbounded
size.)

If you have an idea for a good mechanism to avoid the issue, I'm listening.

> Should A keep resending the seqno requests each time it gets a new
> unfeasible update - and if so, is there any limit to the frequency?

Only the usual delay on sending out updates (Section 4, "a Babel node
SHOULD buffer every TLV and delay sending a packet by a small, randomly
chosen delay").  Is that a problem in practice?

> Or should A immediately consider the update with seqno S' as feasible
> because its selected route has metric infinity?

As you mentioned, that would be unsafe.  Consider the following topology:

  ::0 --- A --- B

A loses its Internet connection, so it sets the metric of its selected
route to infinity.  Before it sends a retraction, it receives an
unfeasible update from B (with router-id A) -- routing loop.

-- Juliusz