en.le-fay.org (ilythia.eden.le-fay.org [IPv6:2001:8b0:aab5:106:3::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by iris.eden.le-Fay.ORG (Postfix) with ESMTPSA id 8B3CA2C04D7; Thu, 16 May 2024 14:02:53 +0100 (BST) Date: Thu, 16 May 2024 14:02:52 +0100 From: Lexi Winter To: Scott Cc: net@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) Message-ID: Mail-Followup-To: Scott , net@freebsd.org References: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dhq8335QEg/pPl2I" Content-Disposition: inline In-Reply-To: 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:20712, ipnet:81.187.0.0/16, country:GB] X-Rspamd-Queue-Id: 4Vg9Hq55nsz4sC3 --dhq8335QEg/pPl2I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Scott: > I use RIPv2 for it's simplicity and small memory and CPU requirements. I= t=20 > has its place and shouldn't be considered "legacy" despite its shortcomin= gs. =20 > It's not uncommon for vendors like Cisco to produce "basic" feature sets = of=20 > IOS that do not include any link-state protocols. =20 i imagined there are still people using RIP, so i only proposed removing it since there are several alternatives available. > Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to it= s=20 > removal from FreeBSD if there were a small footprint alternative. I've u= sed=20 > FRR and VyOS a bit and they are overkill as replacements. Cy has already created ports for these (although i haven't tested them yet): https://cgit.freebsd.org/ports/tree/net/freebsd-routed https://cgit.freebsd.org/ports/tree/net/freebsd-route6d so if you like routed/route6d, you can continue using them even after their removal. that said, i'd also suggest considering net/bird2; it's smaller than FRR and (imo) nicer to manage, not to mention much more maintained than routed is. > Your email doesn't justify its removal other than to say you are unconvin= ced=20 > of the value of shipping it. As a user I definitely see the value. I=20 > understand that there is always a cost to providing code, but that wasn't= =20 > suggested as a reason. All APIs, modules, utilities, etc. need to regula= rly=20 > justify their presence in the OS. =20 let me turn this around and ask the opposite question: if FreeBSD didn't currently ship RIP/RIPng in the base operating system, would a request to add an implementation of it be considered? almost anything would be useful for someone, somewhere. for example, i'd quite like to see a basic Wayland compositor (such as hikari) and a terminal emulator in the base system, because that's a bit nicer to use than vt(4) if you just need to occasionally manage a system via the framebuffer console. i feel fairly confident to say that this would be useful to a greater number of people than an implementation of RIP. =20 but i wouldn't propose actually doing this in base, because i can fairly easily install this from ports, and the cost of maintaining the code in base would outweight the advantage of not having to type 'pkg install hikari'. similarly for RIP/RIPng, if routed were currently in ports and not in base, there would be very little justification for integrating it into base when someone can just install it from the port. this was different back in the days when routed was first created, because there was no ports system and RIP was common enough that it was useful to users -- along with the fact that 4BSD was effectively the reference implementation of IP and sockets, so shipping RIP was reasonable in that context. so the question for me is not whether it should be in base at all (it clearly shouldn't be, by today's standards), but does the inconvenience to users of removing it outweigh the cost of maintaining the code forever? i don't claim to have any particular expertise here, so people might reasonably disagree, but in my opinion, given the small number of users, the advanced notice period (15.0-RELEASE) and the ease of addressing the problem (pkg install freebsd-routed) the answer is yes. someone elsethread mentioned that they expect FreeBSD to be a "complete operating system". what does this mean in practice? many people expect a complete operating system to include a GUI, yet FreeBSD hasn't shipped X in the base system for quite a while. should we put X back into base? the most sensible way to address this, to me, seems to be that the base OS should include things which are a) widely used, b) not available elsewhere, and c) worth the maintenance cost. for example, the kernel is in base, because there's no FreeBSD without the kernel. /bin/sh is in base because the OS would be unusable without it, even though you can install other shells from ports. /etc/rc is in base because an rc-system is required and /etc/rc is the only one that exists for FreeBSD. fetch(1) is in base even though you can install equivalent software (e.g., cURL) from ports, so you could make an argument that it should be moved to ports. however, fetch is useful for both bsdinstall and for many custom post-installation tasks that need an HTTP client, and attempting to remove it would be very disruptive. cron(8) is in base even though there are other cron implementations, because widely-used parts of the the base system (e.g., periodic(8)) depend on cron for basic functionality; removing cron would also require removing this functionality, and that would be a significant loss to users with no obvious replacement. but routed is not widely used in general, either by users or by the OS itself; there are many implementations of RIP available elsewhere; and the code is both old, barely maintained, and a network server, making it a potential security risk among other maintenance costs. i think a good example here, similar to routed, would be window(1). 30 years ago, i used window(1) all the time; it was very useful and an obvious candidate for a base utility considering how (relatively) common text terminals were. but since then, the world changed: text consoles are less common (in favour of GUIs) and people nowadays are more likely to use screen(1) or tmux(1), modern utilities which do the same thing better. so while window(1) had enough remaining users to justify moving it to a port, it failed to meet the requirements a) and c) above. would people objecting to the removal of routed also advocate for putting window(1) back into base? (this is not a rhetorical question, 'yes' is a perfectly reasonable answer.) --- a couple of people also mentioned pkgbase and i think this is likely to have an effect on this sort of discussion, especially because it makes the current hard divide between src and ports more permeable: there's not much difference between typing 'pkg install FreeBSD-routed' (pkgbase) or 'pkg install freebsd-routed' (ports), for example. i like pkgbase and use it on all my systems, so i'm very interested to see where this leads. in fact, i originally intended to submit a patch to move routed into a new pkgbase package, as i've recently done with some other base utilities. in the ended i decided, based on the reasoning above, that it made more sense to simply remove it. my guess is that if/when pkgbase does become the default, it will make it easier to justify removals like these, because if you already have to install routed (or whatever) from a pkgbase package, it's not much of a change to install it from a ports package instead. --dhq8335QEg/pPl2I Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEuwt6MaPcv/+Mo+ftDHqbqZ41x5kFAmZGA/oACgkQDHqbqZ41 x5nOlwwAnemsSVz9kGVzYC2hC2uU7lurapV5Ng5CAXvb8FQ+dtOvP6QvpYUVp0ar I1LLylQhTMCczOBS+PNNVkgPEiWJv+PU3V9YXsGk+hAe1IujEzdox8eE6sDPd9pn qoyPiMEYIQ1tbY1zQfPpg47JY3vepgFCImr22lk1yjkfgUuwCyuPMIMpL8YONvvK MRA+Y0iEonyzTcX6eLJZrQUAIcLCBr+3fBCrApHFd0K37Npq4RCn2HvUSr5MU+ou 3mZj/BUed8kIo0BhplwgmIRMiPFly2FhkKjKlTdYnHuBXxbAJz7zWd+8yw3dkvcK Pii/7DPUulMx4hmjO+jLn/L+SLbu8bEEaQySvUcDt9At/jAOpfwUYBYHW2kCciD3 0rK43TtL/3eG+7XcJSb6L0WtYo9NHk0HIgi7CBoy8tjSaYZU+/ERsS973K2iuboc 1b/iG/jL876+PWeplHQ3/PSQi1Cmw6GnRdTnIRfZ+UmIu1ZIHGJCFW+2PGe+1wP/ vns8i5CV =vXWD -----END PGP SIGNATURE----- --dhq8335QEg/pPl2I--