Re: [LibreQoS] routing protocols and daemons

[Juliusz Chroboczek <jch@irif.fr>]

> our toasts to the builders of Notre-Dame.

...which then burnt down :-/

> Dijkstra's algorithm remains a very natural approach to mapping a
> graph

I'm not sure what that means.  Dijkstra's is a shortest path algorithm,
it's not in the business of mapping.  I guess the author meant that
representing a graph as an adjacency list (the LSDB) is natural, which is
certainly true, but in no way specific to OSPF.

> I don't suppose you have ever had any ideas to how to improve things?

Modern OSPF and IS-IS have pretty much reached a local optimum: all the
low-hanging fruit has been picked, I doubt there's much that can still be
done to improve them without a complete redesign.  Well-implemented OSPF
and IS-IS work beautifully in a well-administered network, any other
protocol is going to converge slower and give less visibility into the
network.

On the other hand, OSPF is extremely fragile in the presence of bad
implementation.  If two routers have the same id, OSPF is going to create
routing pathologies.  If a router corrupts its LSDB (for example due to
bad RAM), OSPF will create routing pathologies which will only go away
once the faulty LSA expires (30 minutes worst case).  If a router runs out
of memory for its LSDB, it needs to stop participating in the protocol,
lest it cause routing pathologies (IS-IS has the overload bit to deal with
this case, which causes the router to become a stub router).  Compare this
with distance vector, where a corrupt routing table entry will only
interfere with the traffic to that particular destination, and where it is
perfectly correct to run with a partial routing table.

OSPF also requires a skilled administrator.  Splitting a network into
areas without causing suboptimal routing takes significant skill, route
filtering can only happen on area boundaries, and there are multiple
different ways of redistributing routes into OSPF (external LSAs).

In my opinion, you want to be running OSPF in parts of your network that
are implemented with reliable gear and are managed by a competent
administrator, but you'll prefer a modern distance-vector protocol
(somebody mentioned Babel) where the hardware is cheap and the
administator is busy with other things.  Fortunately, due to the
flexibility of route redistribution in distance-vector protocols, you can
do both: a stable backbone using OSPF, and unadministered Babel bits at
the edges.

-- Juliusz