📔What Problem🄪 are you solving?
The 🆂 in 🄢🄡🅛🅘🅝🅤🅧 and 🄢🄡🅞🅢
The first blog of this series explored the origins of the concept of “Service Routing”, as introduced by TiMetra in its portfolio of IP/MPLS Edge Routers back in 2003. All this happened well before my time and I cannot claim any credit or co-temporal insider insights, but looking back (e.g. through this 2002 Light Reading article) we can find many examples of vendor positioning (some might say ‘bickering’) around “services”. Even today at the end of 2021, “service” continues to be a popular concept and we can expect this to continue into the future.
I think we can say that at least originally, “Service Routing” was about the convergence of “Service Delivery” and “Edge Routing” product categories, used as part of vendor positioning and differentiation.
A 🅓ifferent way of thinking
The concept of a “service” expands beyond the boundaries of a single box or even a single vendor, putting the focus on the functionality or value that is provided/delivered to customers. From my university days I vaguely remember classes about Telecommunications and the notion of a “Service Access Point” (SAP) in the OSI model, where it represents the conceptual interface between different layers; thinking of a network in terms of the services it provides at various layers is using “service” as a disaggregation concept.
In order to see and appreciate the various services being provided, people must have some notion of what services are and how to tell them apart. Conversely, if people do not see or understand this level of detail, things become blurred and abstracted as “the network” (as in “must be the network”). People tend not to value or appreciate what they do not understand, as they cannot make the association in their mind.
From the perspective of a network equipment and software provider, it is imperative that (potential) customers see and understand the value of its products. Therefore, a vendor is motivated to educate the market on what it is that is being provided: What are the different parts and components, and how do they interoperate?
Humans learn through active experimentation
In general, humans learn by experiencing things themselves through trial and error (see e.g. figure 2.3 here). In the case of networking hardware, this quickly gets complicated as there are high costs and barriers for getting the equipment into the hands of technology consumers. As an extreme example, a fully equipped Nokia 7950 XRS20-e platform weighs over 600 kg (1300 lbs) —not to mention the recent supply chain challenges across the industry.
Virtualization and networking software is not constrained by such physical and logistical limitations; software images and scripts can be exchanged through the internet, at effectively zero cost. However, industry business licensing practices have traditionally complicated the access to network software, reducing the potential for customer learning happening through hands-on experimentation.
🏳 ᴙevolution 🏳: Truly open #SRLinux
All of this changed with the introduction of the freely available #SRLinux container image:
docker pull ghcr.io/nokia/srlinuxNo registration procedures, no license file; just running code, accessible and open to experimentation and customization.
Circling back to the question that started this article: We are solving the problem of educating potential customers (and any other interested partners/stakeholders) about the features and benefits of our networking products, by making our technology readily available for learning through hands-on experimentation.
🧪Containerlab
But wait…there is more. Networks form complex multi-vendor topologies, and a significant part of the deployment/configuration challenge is the interworking.
OK — so how do you use THAT then?
So glad you asked! In the first part of my article on BGP Anycast, I shared a solution based on a combination of SRLinux and SROS virtual devices. Given the above and the fact that SROS is not as easily available (and still requires a traditional license), I wanted to come up with a solution that is fully composed of freely available SR Linux nodes — to make it even easier: see work-in-progress here. This link will be updated in the coming days.
Usage of BGP in modern data center infrastructure
Hot off the press: Cilium just released their 1.11.0 version, including “BGP Pod CIDR Announcement: Advertise PodCIDR IP routes to your network using BGP.“
This is one example of how the BGP Anycast use case illustrated here may be closer to reality than you would have thought possible. Time to get ready for the next problem(s) to solve!👏
