Is There an Afterlife Following the “End of Life” Notice?

What is an End of Life (EoL) notification?

First, some explanation about what an EoL notification is all about. Vendors make products that sell in the open market. In networking, these products typically are sold into a network and are expected to stay there for 5-7 years. From the hardware vendor’s perspective, this means a spike sale on day #1, followed by 5-7 years of moderate wallet share from the operator’s network expenses.

Vendor relationship with EoL

Vendors are ambivalent during this ongoing period. On one hand, they make little money compared to winning the deal; on the other hand, their business is safe (as long as they don’t fail the operator’s network somehow). Another angle to this is that these companies need to continuously update their products to win new deals, and maintaining every old product while continuously adding new ones is a growing problem.

So a product line manager (PLM) is continuously stressed by R&D looking to terminate support for old hardware revisions and old software versions. Q&A is looking to shorten its growing test cycle, while operations is looking to terminate production lines of numerous models, some of which have subcomponents that themselves are entering an EoL phase.

On the other side of this growing pressure are customers – and all they want to do is maintain “business as usual.” The EoL notification exactly ends that “business as usual” aspiration. It’s the vendor giving operators a “heads up” that the part numbers they are used to buying will soon be obsolete.

The end of a protected growth curve

One common deployment scenario is when the network is deployed in phases – both from the geographic and capacity perspectives. Operators span their deployments from dense areas and over time continue to less populated and rural areas. It’s also the case that the network’s capacity on day #1 grows over time to cater for the growing demand as it builds out. An EoL notification is the end of that protected growth curve.

I just got a new burner for my Weber BBQ set. It’s an old model and Weber doesn’t support it or sell parts for it anymore. Luckily the burner is a standard item that I can get from other vendors – and that’s exactly what I did to extend the longevity of my BBQ SET. This consumption model does not apply to traditional networking.

EoL implications for the network operator

Network equipment, though implementing standard protocols to communicate with other network elements, is in fact proprietary in its implementation. For example, port interfaces can only host optical transceivers from the same vendor. Line cards can (obviously) only come from the same chassis vendor. And, in many cases, there are some limitations on the support matrix between different components in the same network device (e.g. component A’s revision X can only work with component B’s revision Y or higher). This means that the termination of a component within a device has a lot of implications on operators and how they operate their networks moving forward.

Disaggregated network model

A disaggregated network model brings two things to the game. First is standardization – not only in routing protocols but also in interfaces. Every “former” subcomponent of a chassis now comes as a standalone element that interfaces to other devices on standard interfaces.

Second is an ecosystem with multiple vendors manufacturing such components so that they become a commodity. This means that if one vendor decides to commence with an EoL process, it can very well be that the simple alternative will be to get the same device from a different vendor. Just like my BBQ burner.

Standardization

Now, let’s touch upon the issue of standardization. As I noted, there is some interop matrix issues with new equipment entered into an old device. The reason is that the device itself (the metal enclosure and all the limitations it forces) is not flexible enough to tolerate changes, resulting in a compromise between supporting the old or new components. From the operator’s point of view, a disaggregated model prevents this potential domino effect of one component swap forcing further replacements until the entire device is eventually replaced. I have seen cases where all that remained from a product is its name while everything else was replaced.

Sustainability

The last point I’d like to make has to do with sustainability. Equipment entering a network carries embedded carbon within it. The longer the equipment is used, the less its carbon emission is counted against that device on an annual basis.

It does happen that the network exhausts its capacity and the EoL notification acts as a kind of “reminder” or “motivator” to move the network to the next level. As I commented, networks grow in geography as well as capacity. When a device exhausts its capacity and an EoL notice pushes the operator to pull the plug on it, it’s very often the case that the same device has a few more years to run in a less populated or a rural area. Disaggregation allows exactly that since every network element is constructed from standalone components, and it can build itself to fit into the PoP where it is planned for deployment.

Disaggregation give operators control

It’s worth noticing that disaggregated networking equipment also comes from hardware vendors, which also have the same considerations mentioned for incumbent network vendors. While disaggregation will not make EoL or EoL notifications disappear, it will give better control to operators as to how and when they need to introduce radical changes to their networks. Even more importantly, it will give operators control of who decides to take these actions.

So no, my conclusion is not that disaggregation will make EoL issues disappear. But it will give operators greater control and provide networks with extended longevity of quality life.