[171639] in North American Network Operators' Group
Re: US patent 5473599
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu May 8 03:40:27 2014
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <536B00D0.1030005@direcpath.com>
Date: Wed, 7 May 2014 22:04:23 -0700
To: Robert Drake <rdrake@direcpath.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On May 7, 2014, at 20:58 , Robert Drake <rdrake@direcpath.com> wrote:
>=20
> On 5/7/2014 9:47 PM, Rob Seastrom wrote:
>> The bar for an informational RFC is pretty darned low. I don't see
>> anything in the datagram nature of "i'm alive, don't pull the trigger
>> yet" that would preclude a UDP packet rather than naked IP. Hell,
>> since it's not supposed to leave the LAN, one could even get a
>> different ethertype and run entirely outside of IP. Of course, the
>> organization that has trouble coming up with the bucks for an OUI
>> might have trouble coming up with the (2014 dollars) $2915 for a
>> publicly registered ethertype too.
>=20
> Meh.. it's open source. If I design a toaster that spits flames when =
you put bagels in it, then I put the design on github and forget about =
it, I shouldn't be held responsible for someone adding it to their =
network and setting fire to a router or two.
>=20
> A problem that the developer doesn't have isn't a problem. Oh, the =
user community noticed an interoperability issue? What user community? =
I was building this toaster for myself. I released the plans in case it =
inspires or helps others. If fire isn't what you need then maybe you =
can modify it to do what's needed.*
>=20
> Now, the bar for an informational RFC is pretty low. Especially for =
people who have written them before. Those people seem to think one is =
needed in this case so they might want to get started writing it. Then =
patches to the man pages covering the past issues can be added to =
document things, and a patch can be issued with the new OUI, ethertype, =
or port number, whichever the RFC decides to go for.
>=20
>> Must be a pretty horrible existence ("I pity the fool"?) to live on
>> donated resources but lack the creativity to figure out a way to run =
a
>> special fund raiser for an amount worthy of a Scout troop bake sale.
>> Makes you wonder what the OpenBSD project could accomplish if they =
had
>> smart people who could get along with others to the point of shaking
>> them down for tax-deductible donations, doesn't it?
>>=20
>> -r
>>=20
> The money could also be donated by parties interested in solutions.
>=20
> Open source is about people finding a problem and fixing it for their =
own benefit then giving the fix away to the community for everyone's =
benefit. I know in the past the OpenBSD community has been harsh with =
outsiders who submit patches. I honestly expect the same response in =
this case, especially because of the underlying drama associated with =
it, but without trying first it just seems like the network community is =
whining without being helpful at all.
>=20
> To be fair, we're used to dealing with vendors where we can't change =
things so we bitch about them until they fix code for us. In this case =
there is no "them" to bitch about. We (the community) wrote the code =
and it's up to us to fix it. If you don't consider yourself part of the =
OpenBSD community then you shouldn't be using their products and =
encountering problems, right?
>=20
> * yeah, that's a very insular view and not really acceptable in the =
grown up world, but everyone's been beating them down over this and =
sometimes you end up taking your ball and going home because you're =
tired of people criticizing your plays.
If they take their ball and go home, that's fine. The problem is that =
they seem to occasionally have their ball brought (by systems =
administrators) to networks where the network engineers are already =
running VRRP on routers (for example) and because:
1. The systems administrators don't necessarily have =
in-depth knowledge of what the network is doing.
2. The network administrators don't necessarily get told =
about every detail of the Systems administrators intentions.
3. There's no knowledge among the two groups that either is =
using the other protocol (CARP vs. VRRP)
4. There's even less knowledge that the two are going to =
fight with each other.
5. You encounter a network outage where the network =
engineers spend a bunch of time chasing down
rogue duplicate MAC addresses messing up the switch =
forwarding tables until they find the (recently
activated) systems CRAP^H^H^HARPing all over their =
network and breaking it for everyone.
OTOH, if the BSD folk had (or in the future did) fix CARP so that =
instead of trying to steal VRRP MAC addresses in a conflicting manner, =
it would either use a non-conflicting MAC prefix (how about one with the =
locally assigned bit set, such as the VRRP Mac | 0x02000:0000:0000) and =
make a legitimate attempt at getting CARP into an RFC with a =
legitimately assigned protocol number, everyone could get along without =
issue.
Yes, you can work around the current issue ONCE YOU KNOW ABOUT IT. =
Unfortunately, the most common way of learning about this particular =
little lovely OpenBSD time-bomb is when it explodes all over a =
previously operational network, usually rendering it non-operational =
until the problem can be identified, usually by people who had no =
knowledge of how it got created.
Owen
