Re: [Babel-users] babel in vyos

2023-04-28 Thread Dave Taht
On Fri, Apr 28, 2023 at 1:35 PM Juliusz Chroboczek  wrote:
>
> > One place where things fall down also is in ECMP, (which babel does
> > not do presently?)
>
> It does not.
>
> ECMP improves throughput in some cases, but unless done very carefully it
> tends to improve latency (the effective latency of the aggregated link
> tends to be higher than the latencies of either of the underlying links).
> I don't currently have an algorithm that would reliably determine when
> ECMP can be used without impairing latency, but perhaps further work on
> the RTT metric could yield something useful.
>
> (There's this good friend of mine who taught me to disregard throughput,
> and optimise for latency.  His name is Dave.)

I miss ya too buddy!

I am now in a world of mikrotik and ubnt where cake and fq_codel are
becoming universal, and dealing with the kinds of problems that WISPs
deal with every day,
one of them being the inadequacies of olsr in complicated wireless
environments. One libreqos user has 10! mmwave hops that goes to hell
even in a light drizzle... others have 5Ghz fallbacks for links like
that...

Had I known it would have taken 14 years to get to this point, and
years more to *maybe* start making a dent in the routing problem(s), I
would have stayed on my beach in nicaragua, I think.

btw, libreqos is GPLd and there is a cool demo of it here:
https://payne.taht.net. One of the coolest features is a "piano roll"
of real traffic over time, however seeing that against real traffic,
as opposed to the simulation there, is most revealing. Fixing network
after network of 2k+ subscribers in a few minutes has been quite
rewarding and almost makes up for all that time spent...

Anyway, if ubiquity of fq_codel can be assumed, other things seem feasible.

>
> -- Juliusz



-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Juliusz Chroboczek
> One place where things fall down also is in ECMP, (which babel does
> not do presently?)

It does not.

ECMP improves throughput in some cases, but unless done very carefully it
tends to improve latency (the effective latency of the aggregated link
tends to be higher than the latencies of either of the underlying links).
I don't currently have an algorithm that would reliably determine when
ECMP can be used without impairing latency, but perhaps further work on
the RTT metric could yield something useful.

(There's this good friend of mine who taught me to disregard throughput,
and optimise for latency.  His name is Dave.)

-- Juliusz

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Dave Taht
well, one of your issues looks fixed, here:
https://github.com/FRRouting/frr/pull/13353

On Fri, Apr 28, 2023 at 8:37 AM Dave Taht  wrote:
>
> In the WISP markets I am in presently with libreqos, OLSR and iBGP
> dominate. vyos w/FRR is used because it is an x86 upgrade to edge
> devices more or less an upgrade from ubnt edgeOS,
> and eBGP can actually work.
>
> Most are pretty frustrated with OLSR, for the reasons that babel
> exists, notably authentication. I also long for a working RTT metric.
> One place where things fall down also is in ECMP, (which babel does
> not do presently?)



-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Dave Taht
In the WISP markets I am in presently with libreqos, OLSR and iBGP
dominate. vyos w/FRR is used because it is an x86 upgrade to edge
devices more or less an upgrade from ubnt edgeOS,
and eBGP can actually work.

Most are pretty frustrated with OLSR, for the reasons that babel
exists, notably authentication. I also long for a working RTT metric.
One place where things fall down also is in ECMP, (which babel does
not do presently?)

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Juliusz Chroboczek
Hi David!

> Unfortunately there just doesn't seem to be enough interest from the FRR
> community;  it's kinda understandable considering FRR has gotten rather
> datacenter heavy.

Where did the cool people go?  BIRD or proprietary routers?

> If someone is interested (and can spare some of that "engineering
> discipline" you mention, Juliusz - it is a very limited resource...),
> I'd be happy to do that "re-port", I can probably do it much faster than
> most other people.  Just without anyone to tend to it afterwards I'd
> feel like I'd just be wasting the effort :(.

Understandable.

> FWIW, as much as it pains me, maybe we need to remove FRR's babeld.  At
> some point it just becomes harmful, and I fear we may already have
> passed that point.  If there is indeed consensus in that regard, I'll
> regretfully volunteer to take the executioner's job and axe it out :(

It would cause me unspeakable sorrow, but I'd understand.

If you decide to do that, it would be good to have a deprecation notice
that indicates that Babel is alive and well, and that users are encouraged
to migrate to BIRD.  I know that I'm asking you to advertise a competitor,
but unless you do that, you'd be harming Babel by giving the impression
that it's the protocol itself that's getting deprecated, not just FRR's
implementation.

-- uliusz



___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread David Lamparter
On Fri, Apr 28, 2023 at 12:58:40PM +0200, Juliusz Chroboczek wrote:
> > Out of interest: Is there a reason why FRR doesn't just use babeld, but
> > something of its own?
[...]
> FRR's code is derived from a port of a very old version of babeld to
> Quagga, which was done by Matthieu Boutier and myself.  Paul Jackma (the
> maintainer who ended up killing Quagga) invented a lot of spurious reasons
> not to merge our code into Quagga.  When FRR was forked from Quagga,
> Donald Sharp did a lot of good work to clean up and merge Matthieu's code.
> 
> Unfortunately, the FRR folks never got around to updating FRR's Babel code
> to either merge a more recent version of babeld or do their own updates
> with what we've learned since then.  I'm sure they'd accept a patch, but
> I'm not sure I can do the work myself (merging changes is a dull and
> error-prone job, it requires a kind of engineering discipline that
> I simply don't have).

Good summary, thanks Juliusz!

Unfortunately there just doesn't seem to be enough interest from the FRR
community;  it's kinda understandable considering FRR has gotten rather
datacenter heavy.  While we certainly get some questions and issues
regarding BABEL on FRR, there's noone putting effort into development /
maintenance.

Honestly I'm really unsure where to go with FRR's copy of babeld.  I
don't like carrying around a version that people can (and will)
mistakenly use without being aware of how outdated it is.  I did think
about putting in the effort of "re-porting" current babeld, but that's
not very helpful if noone maintains it afterwards.

If someone is interested (and can spare some of that "engineering
discipline" you mention, Juliusz - it is a very limited resource...),
I'd be happy to do that "re-port", I can probably do it much faster than
most other people.  Just without anyone to tend to it afterwards I'd
feel like I'd just be wasting the effort :(.

FWIW, as much as it pains me, maybe we need to remove FRR's babeld.  At
some point it just becomes harmful, and I fear we may already have
passed that point.  If there is indeed consensus in that regard, I'll
regretfully volunteer to take the executioner's job and axe it out :(

Sigh...


equi

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Juliusz Chroboczek
> Out of interest: Is there a reason why FRR doesn't just use babeld, but
> something of its own?

Babeld works by speaking directly to the kernel.  If multiple routing
protocols are running, they all manipulate the kernel's routing table,
which requires them to collaborate in order to decide which protocol is
the one that's going to win.

In FRR, each routing protocol speaks to the zebra deamon.  The Zebra
daemon receives routes from all routing protocols, and decides which
routes are going to be installed in the kernel.  This puts all (most)
policy in a single place, at the cost of some extra complexity.

Thus, every routing protocol need to be ported to FRR, both so that it
speaks to Zebra instead of speaking directly to the kernel, and also so it
can be configured using FRR's Cisco-like configuration language.

FRR's code is derived from a port of a very old version of babeld to
Quagga, which was done by Matthieu Boutier and myself.  Paul Jackma (the
maintainer who ended up killing Quagga) invented a lot of spurious reasons
not to merge our code into Quagga.  When FRR was forked from Quagga,
Donald Sharp did a lot of good work to clean up and merge Matthieu's code.

Unfortunately, the FRR folks never got around to updating FRR's Babel code
to either merge a more recent version of babeld or do their own updates
with what we've learned since then.  I'm sure they'd accept a patch, but
I'm not sure I can do the work myself (merging changes is a dull and
error-prone job, it requires a kind of engineering discipline that
I simply don't have).

-- Juliusz

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-28 Thread Marek Küthe
Out of interest: Is there a reason why FRR doesn't just use babeld, but
something of its own?

On Thu, 27 Apr 2023 19:22:40 +0200
Juliusz Chroboczek  wrote:

> > https://blog.vyos.io/vyos-project-april-2023-update  
> 
> That sounds like good news, but unfortunately, it appears to be based on
> the FRR version of Babel, which is old and buggy.
> 
>   https://github.com/FRRouting/frr/issues/11390
>   https://github.com/FRRouting/frr/issues/13337
> 
> -- Juliusz
> 
> ___
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 
Marek Küthe
m...@mk16.de
er/ihm he/him


pgpcoonXbz_zw.pgp
Description: OpenPGP digital signature
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


Re: [Babel-users] babel in vyos

2023-04-27 Thread Juliusz Chroboczek
> https://blog.vyos.io/vyos-project-april-2023-update

That sounds like good news, but unfortunately, it appears to be based on
the FRR version of Babel, which is old and buggy.

  https://github.com/FRRouting/frr/issues/11390
  https://github.com/FRRouting/frr/issues/13337

-- Juliusz

___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users