“We do what we must, and call it by the best names.” – Ralph Waldo Emerson
In a previous post, I wrote about how the 128 Technology routing platform is configured using a service-oriented approach, allowing administrators to concentrate on the attributes their networks need to enforce in order for service delivery to succeed. In this blog we’ll talk about how these named services (and the tenants that host them) can be used to describe a new way of thinking about routing: Semantic Networking.
Semantic Networking refers to a new method for describing, exchanging, and securing routes — a method that foregoes the typical, esoteric syntax of Classless Inter-Domain Routing (CIDR) blocks and next hops, and replaces it with descriptive text. The building blocks of Semantic Networking are the services your network offers and the tenants that host those services. Each of these named entities take part in constructing what we call a Qualified Service Name, or QSN.
QSNs are to routes as URIs are to web sites; just as you don’t type https://188.8.131.52 into your web browser when you want to want to reach Facebook, we feel it shouldn’t be necessary to express routes in a similar fashion. Instead, imagine expressing routes as named entities; to provide your software development team members with a route to get to their source code repository, you create a route for the dev.engineering tenant members to the repo service. Using text labels to express networking is more than just for human readability; it affords you the ability to apply a uniform policy to discontinuous address space and different IP addressing families (IPv4 and IPv6) with a single statement. It hastens the demise of “ACL Hell,” where network architects establish everywhere-to-everywhere routing within an IGP, then systematically try to staunch undesirable traffic flows by using firewalls and IP prefix filters.
As each service is defined within the 128 Technology router, it is associated with a tenant. Hosts within the tenant (or that tenant’s hierarchy, as described in my previous blog post) are granted access to that service by default. Allowing hosts from other tenants to access a service is done using QSN-based access lists. (Yes, we also support IP prefix based ACLs, but we think you’ll like our new way a lot more.) This lets administrators see at a glance that their repo service is supplying routes to dev.engineering, backup.it, and devops.it without having to pull out the network blueprints to reverse-engineer IP blocks like 192.0.2.128/25, 198.51.100.240/27, and 203.0.113.0/28.
This extends to routing protocol behavior as well; to peer two 128 Technology routers with one another, administrators exchange routes by enumerating a set of QSNs to advertise. When exchanging traffic using these learned services, the routers include the names (of the tenant, of the service) within the “metadata” of the packets they transmit. This helps the routers make appropriate traffic forwarding decisions, particularly when receiving traffic via NATs.
Naming things is human nature. The 128 Technology router gives you the ability to use that to your advantage to make routing simpler, more supportable, and futureproofed.