Vendor Lock-In in IP/MPLS: Why Interoperability Is the Hedge
Vendor lock-in is not a pricing problem. It is an interoperability problem that arrives as an invoice several years later. It costs a renewal premium you cannot benchmark, expansion that waits on one supplier's roadmap, a migration bill that has run at several times its estimate on the one national programme where the numbers are public, and a refresh programme every time a product line ends. India's own networks are built the other way: BharatNet Phase III runs IP-MPLS rings tendered across sixteen packages, and multi-vendor operation is the delivery model. Standards conformance is a claim any datasheet can make. Proven interoperation is evidence, and it is the only thing that keeps your options open after the contract is signed.
Ask a procurement team why they consolidated onto one routing vendor and you will hear a version of the same sentence: it was simpler. One NOS, one support contract, one integration cycle, one throat to choke.
That is true, and it is worth something. But look at what is actually being purchased in that sentence. It is not a router. It is an escape from integration work, achieved by guaranteeing there are never any different boxes to integrate.
Which means the discount is not really a discount. It is a loan against your future optionality, and the interest compounds quietly until the day you need to change something.
Interoperability is a financial control, not a technical checkbox
Interoperability is the property that determines how much a network costs to change. A router that carries services cleanly alongside other suppliers' platforms can be added, replaced or renegotiated on your timetable. A router that cannot becomes a permanent dependency the moment it enters production. Lock-in is not a separate risk to manage. It is what the absence of interoperability looks like on a balance sheet.
That reframing matters because it changes who owns the problem. Interoperability usually gets treated as an engineering acceptance item, tested once during trials and then forgotten. It is actually a commercial control, and the only one that stays effective after the contract is signed. Discounts expire. Support tiers get renegotiated from a position of weakness. Proven interoperation keeps a second bid possible, and a second bid is the only leverage that survives year three.
The four costs of lock-in, and what each one traces back to
You negotiate every renewal against no one. The largest recurring cost and the least visible, because it is never a line item. It is the gap between what you pay and what you would have paid with a credible alternative in the room. Support renewals, software subscriptions and expansion pricing are all quoted differently when the supplier knows there is no second bidder.
The same effect is measurable at market level. In July 2026, GSMA Intelligence modelled what happens to European networks when suppliers are removed from the market, in a study commissioned by seven operator groups. Its pricing finding is the relevant one here: reduced competition would raise transport network equipment prices by around 10%, rising to as much as 16% where most demand shifts to the largest remaining suppliers. Those figures model a regulatory exclusion rather than a procurement choice, and the study's estimates have been publicly contested, so treat the percentages as directional. The mechanism is not in dispute: competitive tension only exists where a second supplier can technically be used, which makes it an interoperability condition before it is a commercial one.
You expand at the pace of one vendor's roadmap. If your supplier has not built the capability your next expansion needs, there is no one else to buy it from. Your launch date is set by someone else's release cycle, and the cost is deferred revenue that never gets attributed back to the procurement decision that caused it.
You refresh the whole network when one product line ends. When one supplier holds the whole estate, any single event touches all of it: an end-of-life notice, a price revision, a policy change, or a commercial event you had no visibility into. The US Department of Justice sued to block a 2025 networking merger on the grounds that it would leave two companies with more than 70% of the US networking equipment market. A router refresh cycle runs seven to ten years. Inside that window, a supplier's ownership, roadmap and pricing posture can change more than once, and you get no vote. You cannot negotiate your way out of that afterwards. The only defence available is an architecture where a new supplier can be introduced without re-engineering the network around them, and that is decided in the RFP, not in the renewal meeting.
You plan an upgrade and pay for an entire migration. The largest single number, and the one operators consistently under-estimate. It deserves its own section.
Why the exit bill always beats the estimate
The most thoroughly audited public example comes from the United States, and it generalises because the mechanism does.
When regulators required rural carriers to remove equipment from two designated suppliers, the initial appropriation was $1.9 billion. After reviewing what carriers actually submitted, the FCC found that funding all reasonable and supported costs would take approximately $4.98 billion, a $3.08 billion shortfall against what had been provided.
Money turned out to be the easier half. As of June 2026, the FCC's Wireline Competition Bureau reported that close to half of recipients had completed removal, replacement and disposal, with providers hitting permit, supply chain and labour delays. A funded, legally mandated swap of one equipment class is still roughly half done six years after it began.
Now ask the interoperability question about that number. Why does removing one supplier cost nearly three times the estimate and take most of a decade? Not because routers are expensive. Because in a network built around a single vendor, nothing is individually replaceable, so everything has to move together:
- The management and assurance system, which only understands one device family
- Service templates and configurations written to one syntax
- Parallel running of old and new through cutover, paid for twice
- Stranded optics, spares and software licences tied to the retired chassis
- Site visits to every node, because nothing can be swapped selectively
- Retraining, and multi-year programme management across the whole exercise
None of that shows up in a per-port comparison. All of it is the price of a network whose parts are not independently replaceable. The trigger in this case happened to be regulatory. It could equally have been a price rise, an end-of-life notice, a merger or a sanction. The trigger is not the variable. Replaceability is.
India's networks are already built the other way
This is not a theoretical debate in the Indian market. It is the delivery model for the country's largest programmes.
BharatNet Phase III was approved in August 2023 with an allocation of ₹1,39,579 crore to extend the network across 6.40 lakh villages. The architecture is explicitly IP-MPLS: gram panchayats are connected in rings of eight to ten using IP-MPLS aggregation and access routers, and the programme was tendered across sixteen separate packages. Different packages, different implementation agencies, different equipment, one network expected to behave as one network.
The same principle shows up in BSNL's indigenous 4G stack, and more instructively. Core, radio access and integration came from three separate organisations, and the stack was commissioned across more than 100,000 sites within two years with full integration into BSNL's existing 2G and 3G infrastructure, to 3GPP standards. The government's own account stresses that the deployment is 5G-ready in a way that allows an upgrade path without replacing large parts of the deployed infrastructure.
Read that last phrase as an engineering outcome rather than a talking point. Upgrading without replacing what is already installed is the clearest possible definition of what interoperability buys. Set it against the removal programme above: same industry, opposite cost curve, and the variable is whether the parts were replaceable.
There is a regulatory layer on top. Under the National Security Directive on the Telecommunication Sector, licence conditions were amended so that from 15 June 2021 licensees may only connect trusted products to their networks, and must obtain permission from the designated authority to upgrade an existing network with equipment not designated as trusted. A later amendment extended that to expansion as well as upgrade. Supplier eligibility in India is therefore a policy variable, decided outside your commercial relationship. If your platform cannot interoperate with what is already deployed, a change in eligibility is not a swap. It is a rebuild.
Standards conformance is not interoperability
This is the distinction most multi-vendor strategies get wrong, and it is worth being precise about.
Every serious IP/MPLS platform claims conformance to the same IETF specifications. BGP, IS-IS, OSPF, LDP, EVPN and segment routing are open standards, and conformance is table stakes. What conformance does not tell you is whether two specific platforms, on two specific software versions, will carry a specific service between them under failure conditions.
There are three levels, and only the third is worth much operationally:
- Conformance. The implementation follows the RFC. Verifiable against a test set, and claimed by everyone.
- Interworking. Two named platforms, on named software versions, establish sessions and carry a service. This is where behaviour diverges, because optional TLVs, timer defaults, label handling and error cases are where implementations differ.
- Operational interoperability. The service can also be provisioned, monitored, assured and troubleshot across both platforms, through management interfaces that belong to neither vendor.
Indian regulation covers level one and points at level two. Under the Indian Telegraph (Amendment) Rules, 2017, covered telecom products must be tested for conformance to Essential Requirements by Indian accredited labs designated by TEC before sale, import or use, with the certificate issued on those reports. Routers and switches are in scope. One stated purpose of the scheme is network integrity, meaning equipment must not degrade the performance of the network it connects to. That is a regulator writing an interoperability requirement into market access.
Certification still stops short of proving your specific pair of boxes will interwork, and the industry publishes the evidence of that gap every year. Independent interoperability events run by test houses such as EANTC put dozens of platforms through multi-vendor service scenarios across thousands of result datasets, and their published methodology notes that combinations which did not pass are recorded anonymously rather than shown.
Failed combinations exist. In a purpose-built lab, with vendor engineers in the room, using the industry's most mature protocols, some pairs still do not work. That is not a scandal. It is the normal state of a large standards ecosystem, and it is exactly why "we support the standard" and "we tested this pair, here is the report" are different sentences with very different commercial value.
What to demand before you sign
None of this requires ripping anything out. It requires asking for evidence at level two and level three rather than level one.
- Accredited third-party conformance reports, naming protocols and software versions. A vendor's own test summary is marketing. A TEC-designated or NABL-accredited lab report is evidence.
- Pair testing against your incumbent, in one lab, running the services you actually sell, including L2VPN and L3VPN end to end. Interoperability is a property of a combination, never of a single product.
- Failure-case results, not happy-path results. Link failure, PE failover, label handling at domain boundaries and convergence behaviour are where mixed estates actually break.
- Live production references in named multi-vendor networks. A lab result proves capability. A production deployment proves it survives real traffic and real operations teams.
- Open management interfaces. NETCONF, YANG, gNMI and streaming telemetry keep automation portable and zero-touch provisioning workable across suppliers.
- Individually terminable contract layers. Hardware, NOS, optics, orchestration and support. A bundled discount that collapses when you unbundle is lock-in with a rebate attached.
- A priced exit. Ask what it costs, in rupees and in months, to replace the platform in year seven. A supplier who cannot answer has already answered.
How HFCL builds against this
We build IP/MPLS routers for operators who already run mixed estates. Interoperability is not a positioning claim at our end, it is the condition of deployment, and we hold it to five tests.
We carry the risk ourselves. HFCL is a Project Implementation Agency on BharatNet Phase III, not a component supplier to one. In January 2025 we received an advance work order of approximately ₹2,501.30 crore from BSNL for the Punjab Telecom Circle, and became the first company to sign a PIA agreement with BSNL under Phase III. In the same month we secured advance purchase orders of approximately ₹2,167.65 crore from Rail Vikas Nigam Limited for the Uttar Pradesh East and West circles, followed in June 2026 by a further ₹2,666.09 crore contract from RVNL for Uttar Pradesh West. That is over ₹7,300 crore of announced Phase III awards across three telecom circles.
These run on a design, build, operate and maintain basis, with ten years of maintenance after construction. We do not get to walk away from an architecture that is expensive to change. Every cost on the table above, the stranded licences, the per-node site visits, the domain-wide cutovers, lands on us for thirteen years if we get the architecture wrong. Interoperability is our cost problem before it is yours, and that alignment is worth more than any assurance in a datasheet.
Proven in production. The DCR 1100 series runs in a Tier-1 operator's live 5G transport network, interoperating with Cisco, Nokia, Juniper, ECI and Huawei router platforms already deployed there, and with multi-domain RAN integration alongside Huawei, Nokia and ZTE. Five router vendors, three RAN vendors, one live network carrying real subscriber traffic. That is level two and level three evidence, and it is the specific claim we would want interrogated.
Standards-based, independently verified. Core routing conformance across BGP4, OSPFv2 and v3, MBGP, LDP and the IPv6 suite has been tested by a third-party lab holding NABL accreditation, TEC designation and ILAC recognition. We also run a 5G lab with a working multi-vendor router setup, which is where pair testing against your incumbent actually happens.
Customisable at hardware and software level. Large vendors sell a catalogue. You take the chassis, the port mix, the feature bundle and the architectural assumptions as designed, and wherever they do not fit your network, your network is what changes. Those decisions were made in another country, for a different operator, against a roadmap you had no input into. You then pay for them twice: once in licensed capability you will never switch on, and again in the engineering effort to bend your topology around a fixed product.
We build the other way round. Hardware and software are customised to the deployment, so the router fits the network instead of the network accommodating the router. In practice that means you specify the interface mix, the scale and the feature set your design actually requires, and you are not funding capability that exists because it suited someone else's product plan. When a platform has to fit an existing multi-vendor design rather than replace it, that flexibility decides whether you are running an integration or a migration, which is the single biggest lever on the cost table above. It is also a sentence a global incumbent structurally cannot say, because their margin depends on you taking the catalogue as built.
Locally supported. Engineering and support sit in the same country and time zone as your network, which matters most in exactly the situation this article describes: a multi-vendor fault at 3am with two suppliers pointing at each other.
If you are writing a router RFP this quarter, the most valuable clause you can add is the one that forces every bidder to prove interoperation with what you already own. Talk to our IP/MPLS team and we will prove ours in the lab rather than in a slide.
FAQ
A renewal premium you cannot benchmark, expansion that waits on one supplier's roadmap, a refresh programme every time a product line ends, and a migration bill when you finally move. The migration component is routinely under-estimated because it includes management systems, service templates, parallel running, stranded assets, per-node site visits and retraining, not just routers.
Because in a single-vendor network nothing is individually replaceable, so everything moves together. In one national replacement programme, a $1.9 billion budget was later assessed at approximately $4.98 billion of reasonable and supported cost, an overrun of 162%, and the work remained roughly half complete six years after it began.
Not on its own. Conformance to IETF standards such as BGP, IS-IS, LDP, EVPN and SR-MPLS is necessary but not sufficient, because implementations differ on optional fields, defaults and error handling. What reduces risk is documented interworking between named platforms on named software versions, plus operational interoperability through vendor-neutral management interfaces.
Accredited third-party conformance reports naming protocols and software versions, pair testing against your incumbent platforms with your actual services, failure-case results rather than happy-path results, live production references in multi-vendor networks, and support for open interfaces such as NETCONF, YANG and gNMI.
BharatNet Phase III connects gram panchayats in IP-MPLS rings tendered across sixteen packages, so multi-vendor operation is the delivery model. Separately, licence conditions since 15 June 2021 restrict licensees to trusted products and require clearance to upgrade or expand with equipment not designated as trusted, which makes supplier eligibility a policy variable outside your control.
The HFCL DCR 1100 series runs in a Tier-1 operator's live 5G transport network, interoperating with Cisco, Nokia, Juniper, ECI and Huawei router platforms already deployed there, with multi-domain RAN integration alongside Huawei, Nokia and ZTE. Five router vendors and three RAN vendors, in one network carrying real subscriber traffic. That is production evidence rather than a lab result, which is the level two and level three proof described above. Core routing conformance across BGP4, OSPFv2 and v3, MBGP, LDP and the IPv6 suite has separately been tested by a third-party lab holding NABL accreditation, TEC designation and ILAC recognition.
They can, though not by every supplier. Large vendors ship fixed platforms, so the network is designed around the product's chassis, port mix and feature bundle. HFCL customises at both hardware and software level, letting operators specify the interface mix, scale and feature set the design requires rather than licensing capability the deployment will never use.
Yes. HFCL was the first company to sign a Project Implementation Agency agreement with BSNL under BharatNet Phase III, for the Punjab Telecom Circle, following an advance work order of approximately ₹2,501.30 crore in January 2025. It has also secured RVNL contracts of approximately ₹2,167.65 crore and ₹2,666.09 crore covering the Uttar Pradesh East and West circles.
