[LibreQoS] routing protocols and daemons

[Herbert Wolverson]

Juliusz, it's a pleasure to meet you. I've seen your name quite
often in the async/await world. Admittedly, usually in the detailed
"how things work" part - while I tend to be on the "teaching how to
use an implementation" side of things.

> > 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.

Absolutely. Most of my development background is in game development,
I also do a lot of GIS. In both fields, Dijkstra's algorithm - and its
adaptations
(A*, weighted flow maps, etc.) refer to mapping in the spatial sense; and
converting
a map to a node graph (whether grid, waypoint, etc.) and then working with
cost-based adjacency (not raw adjacency) is a very natural way to
resolve the issue of "how do I get from X to Y" on a map. It's in no way
specific to OSPF (although specific adjacency cost specification was
one of many reasons OSPF outperforms RIP).

OSPF is where it is now because it's "good enough (for now)" and just
about everything supports it. Sure, an implementation that spits out bad
LSAs is going to break everything - you're going to get some pretty nasty
results from sending out broken destination-distance-vector data, too.
Garbage-in, garbage-out is one of the few truly universal rules! I agree,
though - I wouldn't hand out large-scale OSPF administration to the new
guy (although "here's the standard router config, plug in the numbers for
the locally attached networks here" does work).

I'd love to see good support for dynamic capacity analysis, unequal
cost multipath and similar. Babel looks very promising, but the chicken-egg
problem is very real; I can't put it to use until it's widely available, but
it won't become widely available until enough people put it to use. (It
seems like wireless vendors are busy trying to reinvent it at layer 2 with
proprietary meshing that doesn't talk to other proprietary meshing; ugh)




On Sat, Oct 29, 2022 at 4:15 AM Juliusz Chroboczek <jch at irif.fr> wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221029/653a5da0/attachment.html>