Bad Ideas and Abominations
This post SHOULD have been published on April 1st, but I need to define the terminology for another upcoming post, so here it is ;)
RFC 2119 defines polite words to use when something really shouldn’t be done. Some network designs I see deserve more colorful terminology.
2014-11-02: Updated with reference to RFC 6919 (/HT to @LapTop006)
Abomination (aka Kill It With Fire)
Equivalent to RFC 2119 MUST NOT. Things that are being done in the wild, but should never have existed. Relying on unknown unicast flooding to implement scale-out load balancing (I’m looking at you, Microsoft NLB) is a prime example.
Bad Ideas
Equivalent to RFC 2119 SHOULD NOT:
There may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Stretched subnets, multi-DC firewall clusters, and long-distance live vMotion are in this category. Sometimes you’re forced to implement them because there simply is no other way (example: a tough migration project or iSCSI replication), in which case you (RFC 2119) SHOULD document all the drawbacks and have someone sign the risk acceptance form.
Really Bad Ideas
Worse than Bad Ideas, but sometimes not horrible enough to be called Abominations. Roughly equivalent to RFC 6919 REALLY SHOULD NOT:
The phrase is used to indicate dangerous behaviors that some important vendor still does and therefore we were unable to make MUST NOT.
Prime example: Live vMotion between two data centers that are 100 msec apart. Do I need to say more?
I must also mention that before accepting to implement a "bad idea" you MUST think about a way of getting rid of it, propose it even if it's known to be rejected (at this point you've really done your job), and you SHOULD make people imposing it sign that they accept the implications and drawbacks (so that you can exhibit some bad will later, when things go wrong :) )