Network design

If you haven’t found the compromise …

This week I came across an interesting article on Free Code Camp on Design Compromises. I’ll wait a while if you want to read the entire article to get the context of the play … But it’s the quote that interests me the most:

Just like how every action reacts equally and opposite, every “positive” design decision necessarily creates a “negative” compromise. To the extent that designs necessarily create compromises, these compromises are quite intentional. (And in a similar vein, unintentional compromises are a sign of poor design.)

In other words, design is about making compromises. If you think you’ve found a design without compromise, well… guess what? You haven’t looked enough. It’s something I say quite often, of course, so what’s the point? The point is, we still don’t really think about it in the network design. It appears in many different places; it’s worth taking a look at a few.

Equipment is probably where network engineers are most aware of design tradeoffs. Even so, we still tend to think of gluing a chassis into a rack as a “future proof and requirements solution” to all of our network design problems. With a chassis, of course, we can still expand the network capacity with a minimum of hassle and hassle, and since the blades can be replaced, the life cycle of the chassis should be much, much, longer than anyone else. what sort of fixed configuration unit. When it comes to the number of ports, it seems like it should always be easier to replace line cards than to replace or add a box to get more ports or higher speeds.

But is either really true? While it might “make sense” that a chassis enclosure lasts longer than a fixed configuration enclosure, is there real data to back it up? Is it really a less risky operation to replace line cards in a chassis (including the brain!) And what about complexity: is it better to eat chassis complexity or network complexity? ? Is it better to push complexity into the network device or into the network design? Turns out there are actually many tradeoffs to consider here, sometimes it takes a bit of thought to find them.

What about Software? Network engineers tend to Do not think on the tradeoffs here. After all, software is just that “stuff” you get when you buy hardware. It’s something you can’t touch, which means you’re better off buying software with all the features you think you need. There is no harm in that right? The vendor does all the testing and all the work to make sure every feature they include is working properly, right out of the box, so just throw the kitchen sink in there too.

Or maybe not. My lesson here came from an experience in Cisco TAC. My pager went off at 2 a.m. one morning because an image designed to test a feature in EIGRP had failed in production. The crash dates back to an old X.25 code. The customer did not even have X.25 enabled on their network. The truth is, when software systems get large and complex enough, the laws of leaky abstractions, large numbers, and unintended consequences take over. Defined software is not a panacea for all design problems in the world.

What about routing protocols? Clearly, it’s okay to rely on one or two routing protocols that can “do it all,” and the standards community seems to focus on the ability of each routing protocol to do it all. After all, who wants to deploy a routing protocol only to find years later that it can’t handle a task you really need? Again, maybe not. BGP itself becomes a complex ecosystem with many pieces and nested pieces. What started out as a complex idea has grown more complex over time, and now we have engineers who (seriously) only know one routing protocol, as there is enough to know in that protocol to get through all of it. a lifetime of learning it.

In all of these situations, we tried to build a universal where a particular would do just fine. There is of course another facet of this pendulum: the network of custom-made snowflakes. But the way to avoid snowflakes is not to build giant systems that seem to have all the features you can imagine.

The way to avoid landing on either extreme, in a world where every device is capable of everything, but cannot be understood by even the smartest engineers, and a world where every device is uniquely designed to adapt to its surroundings, and no other device will. do – is to consider the tradeoffs.

If you haven’t found the compromises, you haven’t looked enough.

A corollary rule, coming back to the article which launched this rant, is as follows: unintentional compromises are a sign of poor design.


Source link

Leave a Reply

Your email address will not be published.