Something Old, Something New…

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.

Of course, some bits of this are covered in the network complexity book… Hint hint. 🙂


  1. alan.wijntje on 25 April 2016 at 3:43 am

    He Russ,

    Just wanted to drop a line to say I think you hit the nail on the head with: “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.”.

    I’m actually reminded of an older blog you wrote (thanks to twitter): which I feel does also quite nicely pointing out not fully appreciating why we deploy technology and what we are trying to solve or address (instead of relying on best-practices and lists).



    • Russ on 25 April 2016 at 8:40 pm

      Alan —

      Thanks for the insightful comment, as always… I often find myself hitting the same themes all the time when I’m blogging. I guess I’m getting old, and my memory is starting to fade… Ha!



      • alan.wijntje on 26 April 2016 at 2:55 am

        Hahaha, well possibly it’s just that in the end IT isn’t about (or as much about) technology and more about “understanding” at different ends of the spectrum (business versus people versus technology (which I guess lines up with the complexity model!?)).

        And to be fair, people need constant reminders of important principles (due to things like “the shiny new”-syndrome and unicorns and pixie dust) as we tend to forget past experiences and just trust the vendor to know best.

        Reminds me of the “dead horse principle” ( where good logic is replaced with management consultants and bad advice.


        • Russ on 26 April 2016 at 3:11 pm

          Remember to dismount and stop flogging when the horse is dead…



  2. Ethan Banks on 28 April 2016 at 10:54 am

    I appreciate your never-ending enthusiasm to erase the distinction between enterprise and service provider networks, but the distinction isn’t mythological. This is more a matter of perspective on business problems as opposed to technology issues.

    I agree that we should choose the right technology to solve a given problem, and the core business function is irrelevant. Technology options don’t get filtered out simply because a business fits into one classification or another. And yet, therein lies the typical enterprise vs. service provider network differentiator. Enterprise business problems and service provider problems tend to be different, and therefore different technologies tend to be applied. And thus, a distinction between the two is found in most cases.

    The mid-market enterprise is often overlooked in these conversations, but there’s a reason the mid-market enterprise networks making up the vast majority of the networking landscape don’t use MPLS. MPLS provides a foundation for services that the mid-market simply doesn’t need. Does it mean they can’t use MPLS, should the need arise? Of course not. But by and large, the business requirements aren’t there.

    In the world of large enterprise networks, the business problems begin to look much more like service provider problems, and therefore, it’s more common for technologies often adopted by service providers to similarly be adopted by those large enterprises. And thus the distinction between the two fades away.

    • Russ on 29 April 2016 at 11:26 am

      Ethan —

      Thanks for stopping by and commenting. 🙂 I’ll push back on a couple of thoughts, though. Your argument rests on the assumption that scale (in terms of size of network) is directly equivalent to scale (in terms of services required). I’ve worked on networks with 60k users that happen to have really complex requirements in terms of services needed. And I’ve worked on networks with millions of users with really simple requirements in terms of services needed. The point I’m making is this: requirements should drive technical solutions, not whether someone calls themselves an “Enterprise,” or a “mid market,” or a “provider.” Look at the requirements on hand, decide on a set of technology solutions that will fulfill them.

      To put it another way: can you pin down the number of routers at which you need to deploy MPLS? Why would 1000 routers need MPLS, and not 999? Or 1001? Why would you even look at a network and say, “ah, you’ve reached 1000 routers, now you’re eligible to deploy MPLS?” How does this line of reasoning hold?

      What’s really going on here is that most smaller companies generally have smaller requirement sets, while most larger companies generally have larger requirement sets. But if I’m looking at the requirements as they are, what useful information does classifying the network add? Why should I walk into a customer that has a small network and say, “you have to convince me you need MPLS,” and then into a customer with a large network and say, “you have to convince me you don’t need MPLS?” Why don’t I just walk into every customer and say, “show me your problem set,” and then proceed to find the right solution for that problem set?

      In fact, the idea that “small networks don’t need MPLS” is, IMHO, a dangerous one in this way — it says, “you should use VXLAN because you’re small, and they should use MPLS because they’re big.” But what if putting VXLAN in causes technical debt by not really addressing all the future problems as well as the present ones? Or what if MPLS causes technical debt by injecting more complexity than is really needed? Is MPLS really even more complex than VXLAN anyway?

      IMHO, there are problems, and there are technologies. You apply the second to solve the first. Restricting the technology choices based on a perception of “what the customer needs” before even looking at the problems just seems like a bad idea from a design perspective.