[LibreQoS] routing protocols and daemons

[Juliusz Chroboczek]

> I wish I had a fancy pony with:

That's not a pony.  That's a whole herd.

> Routing based on diffserv.

That was originally supported by OSPFv2, but was removed from later
versions of the specification, to be replaced by multi-topology routing
(RFC 4915).  It's a little costly if you only have a small number of
ToS-specific routes, but I'm told it works well.

In Babel, we defined and implemented an extension for ToS-specific
routing, but found out there was no interest, so we dropped it.

  https://datatracker.ietf.org/doc/html/draft-chouasne-babel-tos-specific

> 'Hitless' adjustments to path diffserv cost.  ie, if a link has a cost change,
> propagate that out without dumping routes.

I'm not sure what you mean.

> link cost with metrics matching diffserv model.

[...]

> with some method to modify this programmatically

It's not sound engineering to implement the whole complexity of DiffServ
within the routing daemon.  On the other hand, one could envision, as you
suggest, a DiffServ daemon that dynamically tweaks route metrics.

Babeld has a simple IPC interface that allows tweaking the configuration
of the daemon at runtime, and I'd be interested in working with someone
who implements such a control daemon.

> but something along the lines of 'if a service is being used up by
> a higher class of service (enterprise...) then other routers should know
> to try to route around that side.

Again, that's not something that's likely to make it into routing
software, but it's something that could conceivably be implemented in
a separate daemon.

> Then on the client side or the client's PoP it should discover it's paths for
> each diffserv to gateways.  This could be pre-mapping 1st, 2nd, 3rd next-hops
> for each diffserv to each gateway for example, so failover for link downs is
> pretty quick.

Modern distance vector protocols do that.  For example, EIGRP maintains
three next-hops for each destination, while Babel maintains all next hops
to a given destination, and only discards them when it runs low on memory
(which never happens in my experience).

> BFD capabilities, preferably built in vs separate BFD process.

I'd have no objection to implementing BFD if there's user demand.
However, since Babel can do Hellos up to 100 times per second, our users
are not exactly clamouring for BFD.

(BFD is useful with OSPF, where Hellos are overloaded and therefore huge
data structures.  Not as much with Babel, where Hellos are tiny.  See

  https://www.rfc-editor.org/rfc/rfc8966.html#name-neighbour-acquisition

for details.)

> 'Route Oracles'.  Routers that advertise that they'll store the router's cost
> tables for all other routers to subscribe to.

I'm not sure what you mean.

> Finally, before I make this wish list too long, REDUNDANT packets.

That's a data plane feature, and therefore has little to do with the
routing protocol.  A fun little project, to be sure, the difficulty lies
in determining the right amount of FEC, which requires very accurate loss
statistics (you need to distinguish between random loss and burst loss,
and tune the amount of FEC for the former while carefully ignoring the
latter).  Hence, I suspect that it's better to do that at the application
layer, e.g. in the videoconferencing software.

-- Juliusz