<div dir="ltr"><div>Juliusz, it's a pleasure to meet you. I've seen your name quite</div><div>often in the async/await world. Admittedly, usually in the detailed</div><div>"how things work" part - while I tend to be on the "teaching how to</div><div>use an implementation" side of things.<br></div><div><br></div><div>> <span class="gmail-im">> Dijkstra's algorithm remains a very natural approach to mapping a</span></div><div><span class="gmail-im"></span></div><span class="gmail-im">> > graph<br>
> </span>I'm not sure what that means.  Dijkstra's is a shortest path algorithm,<br>> it's not in the business of mapping.  I guess the author meant that<br>> representing a graph as an adjacency list (the LSDB) is natural, which is<br><div>> certainly true, but in no way specific to OSPF.<span class="gmail-im"><br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Absolutely. Most of my development background is in game development,</span></div><div><span class="gmail-im">I also do a lot of GIS. In both fields, Dijkstra's algorithm - and its adaptations<br></span></div><div><span class="gmail-im">(A*, weighted flow maps, etc.) refer to mapping in the spatial sense; and converting</span></div><div><span class="gmail-im">a map to a node graph (whether grid, waypoint, etc.) and then working with <br></span></div><div><span class="gmail-im">cost-based adjacency (not raw adjacency) is a very natural way to</span></div><div><span class="gmail-im">resolve the issue of "how do I get from X to Y" on a map. It's in no way</span></div><div><span class="gmail-im">specific to OSPF (although specific adjacency cost specification was</span></div><div><span class="gmail-im">one of many reasons OSPF outperforms RIP).<br></span></div><div><br></div><div>OSPF is where it is now because it's "good enough (for now)" and just</div><div>about everything supports it. Sure, an implementation that spits out bad</div><div>LSAs is going to break everything - you're going to get some pretty nasty</div><div>results from sending out broken destination-distance-vector data, too.</div><div>Garbage-in, garbage-out is one of the few truly universal rules! I agree,</div><div>though - I wouldn't hand out large-scale OSPF administration to the new</div><div>guy (although "here's the standard router config, plug in the numbers for</div><div>the locally attached networks here" does work). <br></div><div><br></div><div>I'd love to see good support for dynamic capacity analysis, unequal <br></div><div>cost multipath and similar. Babel looks very promising, but the chicken-egg</div><div>problem is very real; I can't put it to use until it's widely available, but</div><div>it won't become widely available until enough people put it to use. (It</div><div>seems like wireless vendors are busy trying to reinvent it at layer 2 with</div><div>proprietary meshing that doesn't talk to other proprietary meshing; ugh)<br></div><div><br></div><div><br></div><div><br></div><div><span class="gmail-im"></span></div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 29, 2022 at 4:15 AM Juliusz Chroboczek <<a href="mailto:jch@irif.fr">jch@irif.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> our toasts to the builders of Notre-Dame.<br>
<br>
...which then burnt down :-/<br>
<br>
> Dijkstra's algorithm remains a very natural approach to mapping a<br>
> graph<br>
<br>
I'm not sure what that means.  Dijkstra's is a shortest path algorithm,<br>
it's not in the business of mapping.  I guess the author meant that<br>
representing a graph as an adjacency list (the LSDB) is natural, which is<br>
certainly true, but in no way specific to OSPF.<br>
<br>
> I don't suppose you have ever had any ideas to how to improve things?<br>
<br>
Modern OSPF and IS-IS have pretty much reached a local optimum: all the<br>
low-hanging fruit has been picked, I doubt there's much that can still be<br>
done to improve them without a complete redesign.  Well-implemented OSPF<br>
and IS-IS work beautifully in a well-administered network, any other<br>
protocol is going to converge slower and give less visibility into the<br>
network.<br>
<br>
On the other hand, OSPF is extremely fragile in the presence of bad<br>
implementation.  If two routers have the same id, OSPF is going to create<br>
routing pathologies.  If a router corrupts its LSDB (for example due to<br>
bad RAM), OSPF will create routing pathologies which will only go away<br>
once the faulty LSA expires (30 minutes worst case).  If a router runs out<br>
of memory for its LSDB, it needs to stop participating in the protocol,<br>
lest it cause routing pathologies (IS-IS has the overload bit to deal with<br>
this case, which causes the router to become a stub router).  Compare this<br>
with distance vector, where a corrupt routing table entry will only<br>
interfere with the traffic to that particular destination, and where it is<br>
perfectly correct to run with a partial routing table.<br>
<br>
OSPF also requires a skilled administrator.  Splitting a network into<br>
areas without causing suboptimal routing takes significant skill, route<br>
filtering can only happen on area boundaries, and there are multiple<br>
different ways of redistributing routes into OSPF (external LSAs).<br>
<br>
In my opinion, you want to be running OSPF in parts of your network that<br>
are implemented with reliable gear and are managed by a competent<br>
administrator, but you'll prefer a modern distance-vector protocol<br>
(somebody mentioned Babel) where the hardware is cheap and the<br>
administator is busy with other things.  Fortunately, due to the<br>
flexibility of route redistribution in distance-vector protocols, you can<br>
do both: a stable backbone using OSPF, and unadministered Babel bits at<br>
the edges.<br>
<br>
-- Juliusz<br>
</blockquote></div>