1. Abstract and Executive Summary

The optical transport industry has crossed a structural threshold. Networks are no longer built end-to-end from a single vendor's hardware and software; instead, operators source transponders, line systems, ROADMs, and management plane components from multiple suppliers and integrate them through open interfaces. This shift creates a planning problem that traditional vendor-supplied tools cannot solve. A planning tool tied to one vendor's hardware library cannot validate a service running over another vendor's transponder, on a third vendor's amplifier line, traversing a fourth vendor's ROADM. The operator needs a vendor-neutral planning, design, and simulation platform that treats the physical layer as a set of physically defined, calibrated components rather than as proprietary product configurations.

This article is an in-depth reference for engineers and architects building such a platform. It covers the physics that the platform must implement, the open-source GNPy library that supplies that physics, the surrounding software layers an operator-grade product needs, including project management, multi-tenant authentication, equipment library, reporting, and SDN integration. It includes the reference repository layout, the Python and JavaScript libraries to use, and the workflow an operator follows from topology entry to feasibility report. Performance benchmarks, real-world deployments, and the limits of the GN model are addressed in turn. By the end, a planning team has a complete blueprint for designing a system that supports multivendor service feasibility, accurate enough for real network deployment and flexible enough to grow with new transceivers, fiber types, and amplifier classes.

Three findings recur across the document. First, GNPy is the only credible foundation for a vendor-neutral physical layer engine; reimplementing the GN model in-house adds cost without adding accuracy or credibility. Second, GNPy is a library, not a product; the surrounding application — UI, backend services, project storage, equipment library curation, reporting — is where an operator's planning team adds its own value. Third, the multivendor problem is solved not by picking the best single tool but by combining a calibrated GN model, a curated equipment library, and disciplined margin policies that account for the irreducible uncertainty between vendor datasheets and field reality.

2. Introduction — Why This Tool, Why Now

For three decades, optical transport networks were built as monolithic single-vendor systems. The operator bought transponders, multiplexers, amplifiers, ROADMs, and a management plane from one supplier; planning was done in that supplier's proprietary tool with that supplier's equipment library. The model was effective when capacity grew predictably and one technology generation lasted a decade. It is no longer effective. As of 2026, three forces have made multivendor optical networks the dominant deployment model for new builds in the metro, regional, and data center interconnect (DCI) segments.

The first force is the rise of pluggable coherent optics. The OIF 400ZR specification, followed by the OpenZR+ multi-source agreement and now 800ZR/800LR work, separated the transponder from the line system. A 400ZR pluggable in a router or switch can light up a wavelength on any compliant open line system; the operator no longer has to buy the transponder from the line system vendor. The second force is the maturity of open APIs — TAPI, NETCONF/YANG, OpenROADM, OpenConfig — that let an operator's SDN controller talk to equipment from different vendors through the same management plane. The third force is operator economics. Buying every layer from one vendor delivers integration but at a 30 to 50 percent premium over best-of-breed multivendor. Hyperscalers proved the multivendor approach at scale; tier-1 operators followed; tier-2 and enterprise operators are following now.

The planning gap appears at the moment the operator commits to a multivendor build. The line system vendor's planner cannot model a third-party transponder properly. The third-party transponder vendor's planner cannot model the line system. Conservative spreadsheet rules of thumb produce designs that work but waste capacity — typical over-margining costs an operator 20 to 40 percent of theoretical maximum reach or capacity. To plan a multivendor network properly, the operator needs a tool that owns the physics and treats every component as a parameterized abstraction rather than a proprietary black box.

This is the problem GNPy was built to solve. Its physics engine implements the Gaussian Noise (GN) model — the consensus closed-form analytical model for nonlinear interference (NLI) in uncompensated coherent links — and produces a generalized signal-to-noise ratio (GSNR) that any transponder can be checked against. Its equipment library is a JSON file that the operator owns. Its inputs and outputs are open formats. The tool is open source under a BSD-3-Clause license, which means an operator can build commercial applications on top of it without constraint. For background on the physics, see the deep treatment of the Gaussian Noise model in modern optical systems on MapYourTech.

What GNPy does not provide, and what an operator's planning team must build, is the application around the engine. That application is the subject of this article. For a companion piece on why operators are taking this work in-house and what the build-versus-buy decision looks like in 2026, see MapYourTech's overview of in-house multivendor optical link planning, design, and simulation for operators. It includes a topology editor that lets a planner draw a network on a canvas; an equipment library that catalogs every transponder, amplifier, fiber, and ROADM the operator might use; a project management layer that handles versioning, multi-tenancy, and audit trail; a service request workflow; a simulation orchestrator that calls GNPy at scale and tracks job progress; a reporting module that produces documents engineering and operations teams can use; and an integration layer that talks to the operator's SDN controller and OSS systems.