The Dangers of Networking Terminology

Ed Koehler Distinguished Principal Engineer Published 25 Feb 2022

There is an old joke in the information technology industry. When dealing with a new acronym, folks would say, “It’s another TLA (three-letter acronym) and an FLA (four-letter acronym) world.” It certainly goes without saying that our industry has a ton of acronyms! It’s important to realize that these are labels and labels refer to concepts and terminologies. That is what we are going to discuss in this article.

Why do we need labels for everything?

Humans desire labels. In fact, we need to label things. In the book of Genesis this was one of the first things that Adam did. Labeling brings context to images and objects which can be related to subjects. Labels are very important for any type of critical intelligence and language. As a simple example, if I say the word deer, you think of a four-legged animal that may or may not have horns, depending on whether it is male or female. If I say the word cattle, you also think of a four-legged animal that may or may not have horns, but it is quite a different creature and mental image that comes to mind. As a result of these labels, we can discuss in detail about perceived reality, an essential attribute for language and critical intelligence. These concepts also hold true in the areas of science and technology. As a matter of fact, it could be said that technology could not exist without scientific terminology. But we need to realize that there are labels, and then there are labels. Some are relatively solid or hard in their definition, while others are softer and more nebulous in the interpretations of their meaning. This is particularly the case in the IT networking industry. So, it’s important to understand the difference.

What is a ‘hard’ label or term?

Hard terms or labels are best represented in our industry as set by industry standards orgs such as the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). Examples include the Open Shortest Path First (OSPF) and Border Protocol (BGP), courtesy of the IETF. Likewise, Ethernet & Shortest Path Bridging (SPB) terminology from the IEEE. The IEEE standards are particularly rigid in their definition as they deal with very tightly controlled electrical and RF characteristics. You either comply with the standard, or you don’t.

While the IETF is a bit looser as a set of standards, known as RFCs, these are implemented as common industry interpretations. In the case of OSPF, you either do it and comply with the definitions, or you don’t. You might not support certain features, but you adhere to the general industry interpretation and will hence be interoperable for most purposes. This is the same with BGP as well. While there may be differences in the attributes that vendors support, the standard is widely understood. So, these standards are relatively firm in their definition. As such, the terms are reasonably solid or hard as a result. We are more concerned with the ‘softer’ terminologies. The table below displays a comparative list of hard versus softer terminologies.

HARD                            SOFT
IEEE 802.3 (Ethernet) Software Defined Networking (SDN)
IEEE 802.1aq (SPB) Infrastructure as a Service (IaaS)
IEEE 802.11 (WLAN) Zero Trust Network/Access (ZTN/ZTA)
IETF RFC 2328 (OSPF) Software Defined WAN (SD WAN)
IETF RFC 4271 (BGP) Secure Access Service Edge (SASE)
IETF RFC 5176 (RADIUS) Software Defined Perimeter (SDP)


What’s in a term? Some are a bit softer than others

There are many other terms and definitions within the industry, and many are somewhat hazy. They often can be interpreted by a vendor’s product solution set. However, the ambiguity profoundly impacts on what this networking terminology accomplishes. In some instances, it helps to crystalize a concept into a term or label. In other cases, it serves more in causing uncertainty or even misunderstanding of the terminology. As a result, it is wise for a savvy CIO to ask specific questions regarding a particular vendor’s regarding some of these softer terms.

he best one, to begin with. is software-defined networking (SDN). This term has been around for quite some time. Originally, the term referred to white box switches that utilized OpenFlow and were controlled by a central SDN Controller. Over time as this interpretation changed, SDN has become an amorphous term that can be interpreted in multiple ways. Does it refer to access control and policy? Does it refer to traffic control and quality of treatment for services? This term has been stretched and morphed to fit a particular vendor’s portfolio. We are no different, and I am also guilty of it. It is an ‘orphaned’ term, where the original meaning and intention is no longer pertinent. However, the term is still valuable for describing solutions you may have as a vendor in the industry. There is no doubt that SDN has been used and abused as an industry term. Yet it is still a valid term to describe a solution offering or delivery.

Another successful label is Software as a Service (SaaS). This is another term that has changed throughout the years. Consequently, it requires a clear definition of its meaning from any vendor. SaaS can be application service-focused, but it can also be extended to network services. There are a wide variety of SaaS solutions in the industry. So, it’s important to understand the offerings for each vendor in question. Infrastructure as a Service (IaaS) is another closely related wide-ranging set of solutions. Again, it is essential to understand what precisely a vendor is providing.

The term fabric is often used in the industry and can have a broad meaning. The meaning will depend on the solution. As an example, there are network fabrics, there are security fabrics, and there are also application cloud fabrics. It is important to understand what the fabric terminology means and whether it meets your requirements.

Another somewhat nebulous term is Software Defined Perimeter (SDP). The phrase was coined by the Cloud Security Alliance in 2014 and is defined in a 28-page white paper that leaves a large amount of room for interpretation. As the white paper illustrates, several embodiments can be implemented depending on how SDP is interpreted. Some may be more server-focused, while others offer more of a network-level interpretation. Again, this depends on the vendor and their product or solution portfolio.

Closely related and even vaguer in a definition is zero trust networking (ZTN). Initially coined back in 1994 by Stephen Paul Marsh and rekindled recently by John Kindervag at Forrester. The NIST organization has created a relatively comprehensive document labeled NIST.SP.800-207 in August of 2020. Reading the NIST document might give the strong impression that ZTN is more a question of practices and various technologies rather than a single technology solution. I also agree with this perception. So once again, the exact interpretation is left to the vendor in question. And once again, that interpretation will match their product and solution portfolio. I have had many debates, both externally and internally with colleagues about this subject. I have yet to revise my position. Zero Trust is a practice; it is a set of techniques. There are, of course, tools and technologies that are used. Still, they are quite useless by themselves without proper implementation and practice.

Recently there has been a surge in interest in a term Software Defined Wide Area Networking (SD-WAN). At its core it is the ability to use Internet connectivity rather than provider services such as MPLS. But there are many interpretations of what SD-WAN means and once again it is often according to the portfolio offerings of the vendor in question. So, it is important to understand exactly what the vendor means by the term. There are many features that are umbrellaed into the term, such as application optimization, traffic optimization and security.

This touches on our last term, which was coined by Gartner, known as the Secure Access Service Edge (SASE). Pronounced “sassy,” the term has become quite popular and could be considered an extension to SD-WAN. It is basically the combination of SD-WAN with a series of security-related technologies such as firewall services (FWaaS) and zero trust network access (ZNTA) at the edge. It is important to realize that SASE is a cloud-centric approach that leverages a series of subscribed services on a virtualized footprint at the service delivery edge. Again, the definition of SASE will be interpreted by the vendor and their solution portfolio. Some will be more firewall focused while others will be more network and cloud focused. It is essential to understand what the vendor means, the positive and negative impact on the overall security posture, and the OPEX model for the IT organization.

Gartner did however go farther in defining five characteristics of SASE. They are listed as follows:

1). Cloud-Native Architectures with containerized microservices-based environment

2). WAN networking and security services

3). Cloud managed on-demand services

4). Centralized policy controls

5). Local survivability

As can be seen, this creates a firmer definition of what SASE means, and this certainly helps. Still, even these characteristics are broad and are susceptible to degrees of interpretation. For example, one vendor may place more importance and emphasis on certain aspects, while another vendor may have a completely different clarification. Once again, this interpretation will be strongly influenced by the vendors’ solution portfolio and their strategic vision. Senior IT staff needs to understand how the SASE vision is interpreted by the vendor in question and whether or not there is a match with the organization’s requirements.

In the long run, many things change, but many things stay the same. While the de facto and de jure terminology has come and gone over the years, some terms have proven remarkably resilient. Others have become vogue for a while but then fade off into ignominy. My advice is not to focus on the labels but on the functionality, you require in any particular area of interest. Be careful of ‘buzzwords’ that may be hot in the industry at the time. Judge a vendor offering by their solution’s functionality and see if it matches your requirements. Keep in mind all vendors’ solutions work to some degree or another; otherwise, they wouldn’t be in business. The issue is how their solutions rank in meeting your requirements.

Do not be concerned as well. There is no end in sight for new terms and acronyms.

After all, it’s another TLA in a FLA world.

Get the latest stories sent straight to your inbox!

Related Stories