rtpYUO=-TTEOxiu795sxtATg6RGdHjMhHeoYew@mail.gmail.com>
Message-ID: <CAFYkXjmMFuL0rtpYUO=-TTEOxiu795sxtATg6RGdHjMhHeoYew@mail.gmail.com>
Subject: Re: removing RIP/RIPng (routed/route6d)
To: Scott <uatka3z4zagp@thismonkey.com>, net@freebsd.org
Cc: Lexi Winter <lexi@le-fay.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Queue-Id: 4VfbVt4rvtz4Drq

On Wed, May 15, 2024 at 4:20=E2=80=AFPM Scott <uatka3z4zagp@thismonkey.com>=
 wrote:
> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
> > (..)
> > i'd like to submit a patch to remove both of these daemons from src.  i=
f
> > there's some concern that people still want to use the BSD
> > implementation of routed/route6d, i'm also willing to submit a port suc=
h
> > as net/freebsd-routed containing the old code, in a similar way to how
> > the removal of things like window(1) and telnetd(8) were handled.
>
> I use RIPv2 for it's simplicity and small memory and CPU requirements.  I=
t
> has its place and shouldn't be considered "legacy" despite its shortcomin=
gs.
> It's not uncommon for vendors like Cisco to produce "basic" feature sets =
of
> IOS that do not include any link-state protocols.
>
> Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to it=
s
> removal from FreeBSD if there were a small footprint alternative.  I've u=
sed
> FRR and VyOS a bit and they are overkill as replacements.
>
> Your email doesn't justify its removal other than to say you are unconvin=
ced
> of the value of shipping it.  As a user I definitely see the value.  I
> understand that there is always a cost to providing code, but that wasn't
> suggested as a reason.  All APIs, modules, utilities, etc. need to regula=
rly
> justify their presence in the OS.
>
> If it must be removed, is there any way to fork the FreeBSD routed and
> route6d to a port?  Or would that defeat the purpose of removing it in th=
e
> first place?

Yeah, where did that recent trend came to FreeBSD to remove perfectly
working code??

There are more and more ideas in recent times like this.

Architectures removal, drivers removal, backward compatibility
removal. While basic functions become unstable and unreliable. Looks
more like diversion and sabotage than progress.

If anything is about to be moved out from SRC for a really good reason
it should be available in ports and not in /dev/null.