1. Introduction

A greenfield optical build starts with a blank request for proposal. A brownfield estate starts with a decade of Transaction Language 1 (TL1) sessions, per-vendor element managers, and an operations team that already knows how to run the network by hand. Both need the same thing from an automation program: a controller that can read state and push configuration without a technician typing commands into a terminal. What differs is what that controller has to talk to underneath.

On a greenfield build, the operator writes OpenConfig and gNMI into the procurement specification before a single chassis ships, so every element speaks the same vendor-neutral YANG model over NETCONF for configuration and gNMI for streaming telemetry from the first day of commissioning. On a brownfield estate, the network already exists, the elements already speak whatever northbound interface their vendor shipped in the year they were purchased, and the automation team has to build a mediation layer that translates that interface into something the controller can consume.

This article works through both paths at the protocol level: what greenfield lets an operator skip, what brownfield forces an operator to build, where the added engineering effort actually lands, and how most operators end up running a deliberate hybrid of the two rather than choosing one outright.

2. Two Starting Lines, One Controller-Facing API

In optical automation, greenfield means a new build — a metro ring, a data center interconnect (DCI) mesh, a long-haul segment — procured with automation requirements written into the RFP before award. Brownfield means the installed base: reconfigurable optical add-drop multiplexers (ROADMs), in-line amplifiers, transponders, and the element managers that predate the automation program, some of them running firmware and management interfaces chosen a decade before OpenConfig existed.

Both paths converge on the same controller-facing southbound interface — OpenConfig or OpenROADM YANG models carried over NETCONF for configuration and gNMI for telemetry — because that is what the orchestration layer, the path computation engine, and the analytics pipeline are built to consume. The difference is not the interface the controller sees. It is what sits underneath that interface. On greenfield elements, the device itself speaks OpenConfig or OpenROADM natively. On brownfield elements, a mediation shim sits between the controller and the legacy device, translating in both directions.

A typical legacy network management system is organized into domain-specific element management: a packet-domain EMS for routers and switches, a transport-domain EMS for the ROADMs and OTN elements, and an access-domain EMS for optical line terminals and network terminations. Each domain historically shipped with its own vendor-specific northbound interface. That domain structure is exactly what a brownfield mediation shim has to sit in front of, absorb, or bypass — one shim per legacy vendor family is the realistic unit of work, not one shim per element.

3. What Greenfield Buys You

Mandating OpenConfig and OpenROADM at the RFP stage turns model compliance into a vendor-selection criterion rather than a retrofit project. Every element that wins the bid arrives already able to accept configuration over NETCONF's candidate datastore, which stages a change, validates it, and commits atomically — the mechanism that removes the partial-configuration failures a raw command-line interface leaves behind when a multi-step change fails halfway through.

The telemetry side compounds the same advantage. gNMI Subscribe pushes only changed values on-change or on a defined sample interval, instead of the full-object reads a polling protocol repeats on every cycle. A controlled benchmark published in 2026 in the Journal of Optical Communications and Networking, evaluating OpenConfig- and OpenROADM-driven control of a multi-vendor IP-over-DWDM and transponder testbed, measured gNMI streaming telemetry reducing controller CPU load by 52 percent and improving throughput efficiency by 38 percent relative to NETCONF-based polling for the equivalent state (evidence class: measured, single controlled study — not a universal guarantee, but the direction matches the mechanism). The same study measured average end-to-end service creation and deletion at roughly 198 and 76 seconds respectively under its benchmark conditions.

None of this removes the need to test. Vendors that both claim OpenConfig compliance still implement leaf paths and augmentations differently, so "vendor-neutral" means "compatible with substantially less translation effort," not "identical out of the box." Interoperability testing at the bake-off stage is still mandatory on a greenfield build — it is simply testing a shared model instead of reverse-engineering a proprietary one.

4. What Brownfield Costs You

A brownfield mediation shim exposes OpenConfig or gNMI northbound, toward the controller, while speaking whatever the legacy element or its EMS actually understands southbound — TL1, SNMP, or a proprietary REST or SOAP interface. TL1 and SNMP arrived decades before YANG-modelled management and were never built for transactional, model-driven configuration at scale; a shim has to compensate for that gap in both directions.

Each proprietary model behind the shim needs its own adapter, and that adapter has to be regression-tested against every firmware release the vendor ships, because an undocumented field change on the vendor side breaks the translation silently rather than loudly. Operators building this kind of shim commonly report the added engineering and testing effort landing in the range of 25 to 50 percent above a vendor-neutral OpenConfig or gNMI baseline (evidence class: operator-reported estimate, not a standards-body figure) — the cost of adapter development, per-firmware regression suites, and keeping a translation layer synchronized with two independently evolving models on either side of it. Analysys Mason has reported a slowdown in network-automation software revenue growth in radio-access domains, attributing part of it to integration complexity in disaggregated, multi-vendor environments — a pattern that generalizes to optical brownfield estates carrying the same proprietary-to-open translation burden.

The polling ceiling compounds the cost. TL1 and SNMP cap monitoring cadence at multi-second or multi-minute intervals depending on load, against gNMI's sub-second streaming. A device that can only be polled every few minutes and reconfigured by hand caps whatever closed-loop automation sits above it, no matter how capable the analytics layer is — awareness needs streaming telemetry, and execution needs model-driven write access, before a loop can move past partial autonomy.

5. Architecture: Where the Extra Hop Lives

The diagram below lines up the two paths against the same controller-facing API. On the greenfield side, the controller's southbound interface reaches native OpenConfig and OpenROADM elements directly. On the brownfield side, the same southbound interface terminates at the shim, which then carries a second, independent southbound leg — TL1, SNMP, or a proprietary northbound interface — down through the legacy EMS domains to the actual network elements. Each additional hop is a place where state can drift between what the controller believes and what the device is actually doing, or where a translation can fail without raising an alarm.

6. The Hierarchical Controller Problem in Mixed Estates

A dual-vendor optical network is a common brownfield pattern: an IP network with its own router controller sits above an optical layer where each optical vendor's controller wants to drive the pluggables running through its own domain by talking directly to the router. Layer a new automation program onto that installed base and the router ends up with three separate systems asking for read and write access to the same device — the IP controller, and one optical controller per vendor in the line system. Nothing coordinates who has priority, none of the three necessarily stay in sync with what the other two just wrote, and each additional open door with write access is a larger exposed surface for a configuration conflict or a credential compromise.

The pattern used in production to resolve this is a hierarchical controller architecture: the IP controller acts as the single point of coordination for the routers, and the optical controllers feed intent to it rather than writing to the router directly. That removes the contention because there is only one system with write authority on the device, and it stays flexible because more optical or IP controllers can be added later without introducing a new point of conflict.

The connection back to brownfield integration cost is direct: a mediation shim in a mixed estate is not only a protocol translator. It also has to negotiate write ownership with whatever controller already has a hand on the device from a previous automation phase, which is a coordination problem a purely greenfield build — with one controller architecture specified from the outset — does not inherit.

7. Decision Framework

The table below lines up the two paths across the dimensions that actually drive a budget and a timeline. Use it as a checklist against a specific segment of the network rather than the network as a whole — most estates are brownfield in some segments and greenfield in others, and the framework applies per segment.

8. A Phased Path for Hybrid Estates

Most operators are neither purely greenfield nor purely brownfield. They run an installed ROADM and amplifier base alongside new metro or DCI builds landing every budget cycle, and the practical path treats the two differently rather than forcing one automation strategy across both.

Prioritizing which legacy element to wrap first matters as much as the decision to wrap at all. If the immediate automation goal is line-system fault correlation, wrapping ROADM and amplifier telemetry first delivers more value per engineering hour than wrapping access-layer provisioning on the same estate — the closed loop that actually reduces mean time to repair sits at the line-system layer for most fault classes, and the adapter for that layer can be scoped and tested independently of the rest of the shim.

9. Conclusion

Neither path is free, and neither is permanently avoidable. Every greenfield network eventually becomes someone's brownfield estate as vendors ship new firmware, models evolve, and today's mandate becomes tomorrow's mediation problem on the next automation program. The realistic goal is not to eliminate the shim — it is to keep it as thin, well-tested, and narrowly scoped as the legacy estate allows, while each new procurement cycle shrinks the fraction of the network that needs one. Built correctly, the shim is a bridge with a planned retirement date, not a permanent fixture bolted underneath the controller.

10. References

• IETF, RFC 6241 — Network Configuration Protocol (NETCONF), Internet Engineering Task Force.
• OpenConfig Working Group — Vendor-Neutral, Model-Driven Network Management, OpenConfig.
• OpenROADM MSA — Multi-Source Agreement for Open and Disaggregated Optical Networks, OpenROADM.org.
• M. Kamalzadeh, A. Gomathinayakam Latha, T. Zhang, L. J. Horner, V. Gudepu, A. Fumagalli, R. Manzotti, S. Kai, and M. Hara, "Experimenting with OpenROADM and OpenConfig to Control Multi-Vendor IPoDWDM and Xponder-Based Transport Networks," Journal of Optical Communications and Networking, Optica Publishing Group.

Sanjay Yadav, "Optical Network Communications: An Engineer's Perspective" – Bridge the Gap Between Theory and Practice in Optical Networking.