Recently, I had the privilege of attending a meetup with some like-minded networking professionals, organized by the fine folks at BOSNOG. (The same folks that organized the “Rethinking Routing” presentation I delivered in September 2016.) The topic of this recent meetup was “Evolution of the Design Mindset,” in which Michael “Zig” Zsiga spoke about how the profession of network engineering has changed over time, and his opinions on how it may evolve going forward.
Zig stepped us through the early days of networking, where the nascent engineers built networks based upon the lessons they learned from their mentor or vendor. (Note: vendor, not vendors.) The next stage of evolution saw the establishment of industry-wide best practices. Engineers had blueprints (such as validated design documents) to help inform their network frameworks. In this stage, networking started to transition from “art” to “science,” although admittedly there is still a healthy amount of art involved.
For me, the most thought-provoking portion of the meetup was when we opined about the future of network design. (The subtext of the presentation was advocating for Cisco Certified Design Expert (CCDE) Certification, a topic on which Zig contributed to a recently-published book.) In a cost-conscious and application-driven world, Zig’s thesis is that network design must evolve to be based around designing to business requirements. This means accommodating latency-sensitive applications on the same physical plumbing that accommodates best effort traffic, nightly database backups, and mission-critical CRM systems. Making it resilient to failure, and architected to account for anticipated growth. I couldn’t agree more with Zig’s vision.
There’s a new(ish) buzz in the networking industry: intent-based networking. One of the key components to intent-based networking is that it translates business policy into network configuration. This is also the premise behind the construction of 128 Technology’s data model, as I previously described in Service-Oriented Networking. (tl;dr: our routing platform configuration is a “top down” approach where you describe your network by way of the services it conveys.)
The one significant difference with the 128T Platform is that we sidestep the policy translation. Administrators describe the relationship that user populations (e.g., “branch_office”) have with network services (e.g., “CRM”) directly in the configuration, not in an orchestration platform that “somehow, some way” interprets your intent into cryptic configuration that looks like it time traveled from the Reagan administration.
Anyone that speaks more than one language (or has dabbled with an online language translation service) knows that translations are an inexact science. Languages have nuance, they have regional dialects, and they have idiomatic expressions. Our aim at 128 Technology is not to adopt a subpar lingua franca, but to let you describe your network’s requirements in your own words. This is the power of semantic networking.