From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 60CF13B2A4 for ; Sat, 29 Oct 2022 10:13:18 -0400 (EDT) Received: by mail-yb1-xb36.google.com with SMTP id m125so9063531ybb.6 for ; Sat, 29 Oct 2022 07:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/gXpeECJS02o3zMhIlpMEHJ9kgK1YBL6UMczH1szUjM=; b=Ksf7du3ro6ZPZMDzsCI7HwcSCD2ph9Q/JRL4dFSwNmwhpmHP4T9ZX0qY8KB8UeBc+I xOGB0rJ/NME8wwTyGCqlHwoRK6YonMJPgtqBht70HLvRvpswrB5P3ff5C3yOQs3DA5oo X2j1E0W8kGE2hFGUjE+6uHRq/v/cRyfhjeKNivAVB1olm8zU/rJ3wtclI6BNGbrq/3vR 9Vb9lNmKL0wIwY/jSGIo8wZm/hU1MhWhD5Dbeen/VeXWkb/4ai9cJVHttsoF/OfkmBi3 a9TOXbyOyXuaSbP9MolbqBCz7fjWzekHWhNp/6eLkBG+KH08Mh+3CeukWmefYbTO1j9V 1/6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/gXpeECJS02o3zMhIlpMEHJ9kgK1YBL6UMczH1szUjM=; b=c4purDPgNaYQDjNjwQkz0zw17ohiHZikpQH0N42gTqa/xgAQwHjE01SJsC1jGnj0S3 CGACHRiVJMCfvY5ytBAVnBBTKDUA1ES3lrMsbaM+1PUQ+d85h9A9Q+PLuedSox9IwQMD aefcnfv6K+Agi1zt0UgZJdZOP1mNJ+QO0mfbr6Y8MsMQp9HnM4k8h0SZKKXP6aF5G30S 7AmZ9pLsqNKWdTT6NvBPJpiYKDaBtNQVYAis7N3LaVUlSl7XwiHJobCe1uv0HfoRP/jy 4ZwsqwA5oFsHtobdKGHhc7RxUO8IvCqgS58Ks9tOHKXEWt3Naut93EeGrBjUi3GWkpfg TFjg== X-Gm-Message-State: ACrzQf1tkOJgSw1WnIfGRDsMCbjdpSJ9i9v1ep0Np/pDIrPcNpil2a7L hcaDddndaceaKy0DFxE+cbHkTNXolGtsha9BiVI= X-Google-Smtp-Source: AMsMyM6Cm4dePuY0F2l0GUs5DJokvRAvYM8TyP8cFRlxXjkR9u4vNYvijJqssmXx/AQMVsvf6c+z+yjAtTQJF5S/iDY= X-Received: by 2002:a25:510:0:b0:6ca:3f8a:dfef with SMTP id 16-20020a250510000000b006ca3f8adfefmr4026042ybf.189.1667052797440; Sat, 29 Oct 2022 07:13:17 -0700 (PDT) MIME-Version: 1.0 References: <87sfj7vczj.wl-jch@irif.fr> <87leozuh1s.wl-jch@irif.fr> In-Reply-To: From: dan Date: Sat, 29 Oct 2022 08:13:06 -0600 Message-ID: To: Herbert Wolverson Cc: Juliusz Chroboczek , libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000d0382905ec2cf99c" Subject: Re: [LibreQoS] routing protocols and daemons X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2022 14:13:18 -0000 --000000000000d0382905ec2cf99c Content-Type: text/plain; charset="UTF-8" Keep in mind that often (wisps: mikrotik, ubiquiti) run gear that often have mediocre implementations of OSPF (and other protocols) and the products are made to be as cheap as possible so hardware issues are more likely than an enterprise vendor. I field a lot of OSPF questions in support forums and they usually come down to automatic IDs being set incorrectly because admin didn't set them.... or the big ticket item being MTU. MTU on the router's interface, MTU issues on the radio links, or radios that say one MTU and aren't passing it for some reason. Also attempts to use broadcast and that being unreliable over wireless networks. Those things kinda make OSPF 'finicky'. I would very much prefer ISIS for a number of reasons, mainly around simplicity and reduction of finicky issues and dedicated PTP subnets and configs etc. ISIS is not available on mikrotik or ubiquiti products so there you go. Ultimately though, these are just shortest hop path builders and need some other kit on top of them to do any sort of traffic engineering or load balancing. ECMP doesn't work for me, and doesn't work for a lot of wisps so much so that after they've spent the time and effort to implement, they undo it because different link characteristics make ECMP wreck their customer's experience. The 'E' for equal also is a PITA, requiring you to start stacking up VLANs for example to get a ratio of 'ECMP' across disimmilar links. On Sat, Oct 29, 2022 at 7:48 AM Herbert Wolverson via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > 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 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 >> > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > --000000000000d0382905ec2cf99c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Keep in mind that often (wisps:=C2=A0 mikrotik, ubiquiti) = run gear that often have mediocre implementations of OSPF (and other protoc= ols) and the products are made to be as cheap as possible so hardware issue= s are more likely than an enterprise vendor.

I field a lot of OSPF q= uestions in support forums and they usually come down to automatic IDs bein= g set incorrectly because admin didn't set them.... or the big ticket i= tem being MTU.=C2=A0 =C2=A0MTU on the router's interface, MTU issues on= the radio links, or radios that say one MTU and aren't passing it for = some reason.=C2=A0 Also attempts to use broadcast and that being unreliable= over wireless networks.=C2=A0 Those things kinda make OSPF 'finicky= 9;.

I would very much prefer ISIS for a number of reasons, mainly ar= ound simplicity and reduction of finicky issues and dedicated PTP subnets a= nd configs etc.=C2=A0 ISIS is not available on mikrotik or ubiquiti product= s so there you go.

Ultimately though, these are just shortest hop pa= th builders and need some other kit on top of them to do any sort of traffi= c engineering or load balancing.=C2=A0 ECMP doesn't work for me, and do= esn't work for a lot of wisps so much so that after they've spent t= he time and effort to implement, they undo it because different link charac= teristics make ECMP wreck their customer's experience.=C2=A0 The 'E= ' for equal also is a PITA, requiring you to start stacking up VLANs fo= r example to get a ratio of 'ECMP' across disimmilar links.

On S= at, Oct 29, 2022 at 7:48 AM Herbert Wolverson via LibreQoS <libreqos@lists.bufferbloat.net>= ; wrote:
Juliusz, it's a pleasure to meet you. I've seen your= name quite
often in the async/await world. Admittedly, usually i= n the detailed
"how things work" part - while I tend to= be on the "teaching how to
use an implementation" side= of things.

> > Dijkstra's alg= orithm remains a very natural approach to mapping a
=
> > graph
> I'm not sure what that means.=C2=A0 Dijkstra's is a sho= rtest path algorithm,
> it's not in the business of mapping.=C2= =A0 I guess the author meant that
> representing a graph as an adjace= ncy list (the LSDB) is natural, which is
> certainly true, but i= n no way specific to OSPF.

Absolutely. Most of my development background is in game devel= opment,
I also do a lot of GIS. In both fields, Dijk= stra's algorithm - and its adaptations
(A*, = weighted flow maps, etc.) refer to mapping in the spatial sense; and conver= ting
a map to a node graph (whether grid, waypoint, = etc.) and then working with
cost-based adjacenc= y (not raw adjacency) is a very natural way to
resol= ve 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 out= performs 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 unive= rsal rules! I agree,
though - I wouldn't hand out large-scale= OSPF administration to the new
guy (although "here's th= e standard router config, plug in the numbers for
the locally att= ached 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 chicke= n-egg
problem is very real; I can't put it to use until it= 9;s widely available, but
it won't become widely available un= til enough people put it to use. (It
seems like wireless vendors = are busy trying to reinvent it at layer 2 with
proprietary meshin= g that doesn't talk to other proprietary meshing; ugh)



= On Sat, Oct 29, 2022 at 4:15 AM Juliusz Chroboczek <jch@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<= br> > graph

I'm not sure what that means.=C2=A0 Dijkstra's is a shortest path a= lgorithm,
it's not in the business of mapping.=C2=A0 I guess the author meant tha= t
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 thin= gs?

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.=C2=A0 Well-implemented OS= PF
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.=C2=A0 If two routers have the same id, OSPF is going to cre= ate
routing pathologies.=C2=A0 If a router corrupts its LSDB (for example due t= o
bad RAM), OSPF will create routing pathologies which will only go away
once the faulty LSA expires (30 minutes worst case).=C2=A0 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<= br> this case, which causes the router to become a stub router).=C2=A0 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<= br> perfectly correct to run with a partial routing table.

OSPF also requires a skilled administrator.=C2=A0 Splitting a network into<= br> 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.=C2=A0 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
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
--000000000000d0382905ec2cf99c--