Date: Wed, 13 Apr 2005 21:36:48 +0200 (CEST) From: Lars Erik Gullerud <lerik@nolink.net> To: Claudio Jeker <cjeker@diehard.n-r-g.com> Cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status Message-ID: <20050413212349.P22243@electra.nolink.net> In-Reply-To: <20050413181931.GA16696@diehard.n-r-g.com> References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Apr 2005, Claudio Jeker wrote: > On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: >> >> ...and can't safely be deployed in a lot of datacenter scenarios where >> the providers gear is running VRRP, since the OpenBSD-folks didn't bother >> to read up on how the process of obtaining a protocol number works, and >> hence used the one assigned to VRRP after a half-baked attempt at getting >> one themselves. Hence making CARP pretty much useless for ISPs, no matter >> how good it may or may not be otherwise. >> > > This is not true. First of all the "OpenBSD-folks" asked IANA for protocol > numbers for CARP and pfsync but IANA denied it. The reason was that CARP Which is exactly what I said, they didn't bother to read how the process works and accordingly made a half-baked attempt only. You don't just fire off a mail to IANA and say "hi, can I get a protocol number", that's just not how things work, except in OpenBSD-land, obviously. :) > was not developped through an official standards organization. Which is balony, you do however need to take the PROCESS through the correct "organization" (i.e. the IETF and friends, although the protocol itself can be developed through my grandma's knitting club). So, I stand by my initial statement (but hey, I'm a network engineer at an ISP, not a BSD developer - yes, us people the OpenBSD guys don't like much because we like to point out the glaring problems in things like CARP and OpenBGPd). However, this is all very much beside the point, so further IETF/IANA-bashing or OpenBSD-bashing can be taken somewhere more appropriate than this list. (Feel free to flame me privately) My point is that this very unwise decision to reuse the VRRP protocol number, makes CARP mostly undeployable for ISP datacenter environments, and hence there is an obvious need for a working VRRP implementation, it doesn't help that CARP is now available in FreeBSD, because it is not a viable alternative in a lot of scenarios. /leg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050413212349.P22243>