Some time back a reader sent this question in—
Is there some list of design fundamentals which were “true” or at least “good rules of thumb” in the past (2 months to 20 years and beyond) which are still proclaimed as true and good, which we need to throw out, or at least question closely today?
It’s an interesting question—the problem is, of course, that there are two sorts of answers to this type of question. The first is rather specific, and the second is rather general. Let’s try the more specific answer first, and see if we can get to the more general one.
There are several rules of thumb that are no longer useful today.
OSPF and IS-IS flooding domains should be limited to 50/100/200 routers/intermediate systems. The old “50 in an area rule” is something several of us asked to be removed from Cisco Online something like 10 years ago, as it didn’t even apply then. I’ve heard 200 more recently, but the reality is—there is no right number here. I just did a two post series on dividing up flooding domains that might be useful here (part 1 and part 2).
There are provider networks, and there are enterprise networks. I wish we could have retired this old saw ten years ago, but it seems to have a life of it’s own, like some zombie in a never ending television series. I hear this myth all the time—folks who work in service providers tell me the CCDE is an enterprise test, while folks who work on enterprise networks tell me the CCDE is a service provider test. Folks who say VXLAN is for enterprises, and MPLS is for service providers.
It’s all balderdash, of course. Nonsense on stilts. This is a myth that truly needs to die. There are technologies, and there are problems. Your job is not to say, “this is a service provider technology, so I can’t use it,” or “organization X is only for service providers,” or “conference Y is only for enterprise types.” Your job, as an engineer, is to match technology with the problem within the context of technical debt, business requirements, skill sets, and other things.
The OSI model. To make the OSI model fit what we actually deploy today, we must map multiple layers into single protocols, and multiple protocols into single layers. I have tunneling that reverses the order of layers in specific situations, as well. Even if I sort all of this out, what specifically is the OSI model even telling me? What information does it give me that I didn’t have before all this mapping? It gives me a name for a class of protocols, but it doesn’t tell me much about what those protocols actually do, nor why things are built that way.
The RINA model is much more helpful of network communications, and pipes and other constructions are much better at modeling host to host communication. Learn some new models, folks, and retire the old ones. It’s about time.
Three layer hierarchy is the right solution. Alvaro, Don, and I probably did as much to spread the three layer model as anyone in the world, starting with Advanced IP Network Design. I knew this model was in trouble when I started seeing presentations with three switched layers (don’t you know what a layer is???); we’ve ended up just forcing every network design, no matter how it actually works, into a three layer hierarchy. Stop it. The point of the three layer hierarchy is, and always has, to accomplish a specific set of goals, like separate complexity from complexity, make things modular, etc. The three layer hierarchy is a useful vehicle for examining, understanding, and explaining those goals in a concrete environment.
But once you learn them, you should learn to apply them in other ways. For instance, virtual overlays are a form of hierarchy.
What can we learn from this short list? The first point is that we need to think about the problem we’re trying to solve, and more specifically what the parameters of the problem is, rather than “what have I seen in the past?” The past is a good guide to the present, but we need to use the guide the right way. In the case of flooding domain size, why was the old rule of thumb 50/100/200—what can I learn from this old rule of thumb that I can apply to my designs today? In the case of the enterprise/provider and OSI models, what am I trying to accomplish with these sorts of divides and mental models, and how can I apply those lessons to my designs today? Models have tradeoffs like anything else; we need to look behind the curtain to see what the model is hiding from time to time, and see if it’s about time to change the curtain out, or have more than one curtain we can use to hide different sorts of information.