{"id":"dad62858-e69c-49a5-a774-7fad360b430e","arxiv_id":"2501.16907","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A multi-vendor SDN controller for optical circuit switches was implemented, and it configured fiber paths within 1.0 second on real and emulated networks.","lead":"This paper presents an SDN controller for open optical-circuit-switched networks that manages switches from multiple vendors through one unified interface, validated on a real testbed. It shows fiber paths can be configured in under one second, including rollback on failure, and demonstrates the framework on a live metro production network.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's multi-vendor claim is load-bearing but rests on an extrapolation from four unnamed vendor OCSes to 'the majority of commercial OCSes'; OCS.yang's unidirectional, named-connection model is not shown to cover OCSes with paired/bidirectional or whole-crossconnect configuration semantics.","rationale":"The reader's weakest assumption was that OCS.yang can represent the behavior of the majority of commercial OCSes, and I agree that this is the load-bearing point. If the model is not general beyond the four tested products, the claimed multi-vendor interoperability becomes a statement about those devices, and the main novelty contribution shrinks from a vendor-neutral OCS management framework to a framework validated on a small sample. This is not a fatal flaw: the paper gives a concrete architecture, measured sub-second path setup on real equipment, rollback under simulated failures, and a live metro demonstration, all of which are credible evidence for the system as built. The concern is about representativeness, not internal consistency. A condition requiring independent evidence of OCS.yang's coverage—either the model and converters, a capability survey, or a fifth-vendor test—would resolve it. The emulation-based scalability result in Section 6.D is weaker than the real testbed results because emulated OCS drivers bypass physical devices, but it is not central to the abstract's 1.0-second claim and does not change my conclusion. The appropriate outcome remains the reader's CONDITIONAL verdict, with no adjustment needed.","tokens_in":23672,"tokens_out":8157,"duration_ms":81547,"concrete_test":"Ask the authors to release the OCS.yang YANG module and the four vendor converter implementations, then run one interoperability test with a fifth commercial OCS whose API uses paired bidirectional connection semantics or whole-crossconnect configuration. If that OCS cannot be managed through OCS.yang while preserving named per-connection create/delete and rollback, the 'majority of commercial OCSes' claim in Section 5.B.1 is falsified. Short of hardware, compile a capability matrix from datasheets and API documentation for a representative sample of commercial OCSes spanning MEMS, piezo, robotic-arm, and beam-steering types, checking three capabilities: named unidirectional connection create/delete, partial per-connection configuration, and configurable power monitoring. The generality claim survives only if the sample shows clear majority support for these operations.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 5.B.1 asserts that OCS.yang does not rely on switching mechanism and that robotic-arm, MEMS, and piezo-actuator OCSes from four vendors can be managed. This is the main evidence for requirement 4.B and for the 'multi-vendor' part of the central claim. The leap from four devices to 'the majority of commercial OCSes' is not supported by a market capability survey or by a published, machine-readable YANG module; only the tree view in Fig. 6 is given. The OCS.yang internal-connections container presumes named unidirectional connections that can be created and deleted independently. A commercial OCS whose API only exposes paired bidirectional connections, or that requires replacing the whole crossconnect matrix instead of individual named connections, could not be driven through this model without changing rollback and atomicity behavior. The four tested converters show the approach works for those products, but they do not establish the stated generality. The measured sub-second path setup on the three-vendor testbed and the field demo remain valid for the specific devices used; the concern narrows the scope of the multi-vendor contribution rather than overturning the experimental results.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an SDN controller framework, called MV-OCS, for multi-vendor optical circuit switches (OCSes). The authors identify three OCS use cases (intra-datacenter networks, WANs, and access-metro converged networks with authentication/probing), derive four controller requirements (4.A NBI for whole-network management, 4.B unified SBI, 4.C fast and safe fiber-path control, 4.D event-driven automatic path control), and present an architecture consisting of a gRPC-based NBI, a YANG data model (OCS.yang) served over NETCONF via per-vendor SBI translators, an atomic OCS renderer using a command pattern with rollback, and an event/alarm manager. The controller is implemented and evaluated on a physical testbed with five OCSes from three vendors, on emulated networks with up to 188 nodes, and in a live HEAnet metro-network field demonstration. Reported results include fiber-path establishment/release within 1.0 s, rollback within 0.90 s, automatic setup upon signal detection within 2.0 s, and restoration within 3.0 s; the authors conclude that all requirements are satisfied.","tokens_in":23924,"tokens_out":4135,"duration_ms":37228,"significance":"If the central claims hold, the paper makes a useful contribution to open optical networking by being, to my knowledge, one of the first systematic studies of a unified control plane for multi-vendor OCSes, which lack the standardized interfaces available for ROADMs and transponders. The experimental grounding is a clear strength: each experiment was repeated 10 times with reported standard deviations, the testbed uses real OCSes from three vendors, and the field demonstration on a live production metro network is an unusual and valuable validation. The use of open-source components (Sysrepo, netopeer2, NetworkX, Redis) makes the design plausibly reproducible. The main weakness is the breadth of the multi-vendor claim, which rests on an extrapolation from four unnamed vendor OCSes to 'the majority of commercial OCSes' without a market survey or a machine-readable YANG module, and on an OCS.yang model whose unidirectional named-connection semantics are not shown to cover all commercially relevant configuration models. The overhead verification for requirement 4.B is also incomplete.","major_comments":[{"comment":"The paper's central multi-vendor claim is stated as follows: 'we found that the robotic-arm, micro-electrical-mechanical-system, and piezo-actuator type commercial OCSes from four vendors could be managed by our model' and 'the majority of commercial OCSes can support such a unidirectional internal connection creation and deletion.' This generalizes from four unnamed products to a market-wide statement without supporting evidence such as a capability survey, a public OCS API taxonomy, or a published machine-readable YANG module (only the tree view in Fig. 6 is given). More importantly, the OCS.yang internal-connections container presumes named unidirectional connections that can be created and deleted independently. A commercial OCS whose API exposes only paired bidirectional connections, or that requires replacing the whole crossconnect matrix, could not be driven through this model without changing the atomicity and rollback semantics. The four-vendor converters demonstrate that the approach works for those specific products, but do not establish the stated generality. Please either provide evidence for the market coverage claim or carefully restrict it to the evaluated device classes.","section":"Section 5.B.1"},{"comment":"Requirement 4.B states that the overhead introduced by the abstraction layer should be less than half of the processing and configuration time of vendor-proprietary APIs. The evaluation reports that 'the overhead did not exceed 0.30 seconds' and 'accounted for small portions of overall configuration time of OCSes; it was at most 36.8% on all OCSes.' If 36.8% is the ratio of overhead to the total configuration time (vendor API time plus overhead), then the implied ratio of overhead to vendor API time is about 0.368/(1-0.368)=0.58, which would not satisfy the stated requirement. If, instead, 36.8% is the ratio to the vendor-proprietary API time alone, then the requirement is satisfied, but the text says 'overall configuration time' and does not provide the raw vendor times because they are confidential. The paper should report the metric that exactly matches requirement 4.B, for example by giving overhead as a fraction of vendor API time for each vendor, or by explaining why the 36.8% figure suffices. As written, the claim that requirement 4.B is satisfied is not verifiable from the presented data.","section":"Section 6.B and requirement 4.B"},{"comment":"The scalability evaluation uses emulated OCSes whose per-device configuration times are 'randomly generated from a normal distribution with a mean of 0.7 seconds and standard deviation of 0.07 in accordance with actual configuration time for path operation investigated in Section 6.C.' Section 6.C, however, reports end-to-end fiber-path completion times (about 0.5-0.8 s for routes R1-R3), which are not per-OCS configuration times and include controller processing and concurrent execution effects. It is therefore unclear how the emulation parameters were derived, and the emulated completion times of around 0.8-1.0 s for N=16..64 appear to be driven by the chosen distribution rather than by any measured scaling law. The claim that 'the completion time was always within 1.0 second under all settings' for large emulated networks is thus a property of the assumed model, not a demonstrated property of the controller on real OCSes. Please clarify the derivation of the emulation parameters or conduct a sensitivity analysis over a range of per-OCS time distributions.","section":"Section 6.D"}],"minor_comments":[{"comment":"The figure caption contains the typo 'NECTONF server'; it should read 'NETCONF server.'","section":"Section 5.B.2, Fig. 5"},{"comment":"The field demonstration is described qualitatively ('fiber paths were always set up within 1.0 second') without reporting the number of trials, standard deviations, or the distribution of measured times. Adding these details would make the field result consistent with the rigor of the lab experiments.","section":"Section 6.E"},{"comment":"There is an inconsistency in exception naming: Table 2 defines 'PathOperFailed,' but Section 5.C.2 says the renderer 'raises the PathOperFailer error.' Please use one consistent name.","section":"Section 5.A.4 and Section 5.C.2"},{"comment":"The controller recovery mechanism (reconciliation from the persistent DB after restart) is described but never experimentally evaluated. This is not a flaw in itself, but the paper should state explicitly that recovery is designed but not validated, to avoid the impression that all proposed mechanisms were tested.","section":"Section 5.E"},{"comment":"Minor formatting issues include 'A V AILABLE' / 'UNA V AILABLE' (stray spaces in the enums), 'A.A.2' and 'C.C.1' subsection references that appear to be artifacts, and 'w/-SBI' / 'w/o-SBI' labels in Fig. 9. These do not affect the technical content but should be cleaned up.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper is an extended journal version of an OECC 2024 paper; the authors acknowledge this. The editor may want to verify that the overlap with the conference paper is acceptable and that the new material (multi-vendor testbed, emulation, field demonstration) is substantial, which it appears to be. The main technical reservation is the breadth of the multi-vendor claim, which is advertised in the abstract and contributions but supported only by four unnamed vendor devices. I would like the authors to either provide publicly verifiable evidence of generality (e.g., a published YANG module, a test matrix of vendor API capabilities, or a statement narrowing the claim) or revise the contribution to be about the specific device set tested. The overhead measurement ambiguity in Section 6.B is also important because it concerns a quantitative requirement; this should be clarified before publication rather than left as an inconsistency."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a genuine engineering contribution—first multi-vendor SDN controller for OCSes evaluated on real hardware—but the 'majority of commercial OCSes' claim in Section 5.B.1 stretches past what four vendor devices can establish.\n\nWhat's new and good: The paper identifies real use cases (intra-DCN, WAN, metro-access), derives controller requirements from them, and designs a clean three-layer architecture: NBI, OCS.yang-based unified SBI, and internal components with atomic concurrent configuration and rollback via command pattern. The experimental work is credible for what it covers: ten repetitions per measurement, standard deviations reported, path setup under 1.0s, rollback under 0.9s, restoration under 3.0s, including a live production metro network demo with HEAnet. The SLOC reduction (650 to 153 lines) is a tangible, if modest, data point for vendor-neutral abstraction. This fills a gap that the ROADM-focused SDN literature leaves open.\n\nSoft spots: The main one is the generalization from four unnamed vendor OCSes to 'the majority of commercial OCSes.' OCS.yang models internal connections as named unidirectional entries. If a vendor's API only exposes paired bidirectional connections or whole-crossconnect replacement, the model would need changes that affect rollback semantics. The paper provides no market survey or machine-readable YANG module to back the breadth claim. That's a scope problem, not a fatal one: the tested vendors work, and the measured numbers stand for those devices. Secondary issues: raw configuration times are withheld as confidential, no code or artifacts shipped, and the large-scale scalability test uses emulated OCSes with latencies sampled from a normal distribution. The success thresholds (1s, 2s, 3s) are self-imposed, so 'satisfied all requirements' is an internal-consistency claim, not an external benchmark. The authors do flag several limitations themselves in Future Directions (power dynamics, unified alarm model, silent failures), which is honest.\n\nBottom line: this paper deserves a serious referee. It is a well-structured, reproducible-in-method engineering validation with a real field demonstration. The referee should push for either narrowing the generalizability claim or adding evidence (a survey, more device types, the actual YANG module). I'd cite this if I worked on OCS control planes.","headline":"Solid multi-vendor OCS controller evaluation on real hardware; the OCS.yang generality claim is broader than the four-vendor evidence supports.","tokens_in":24563,"tokens_out":2104,"would_cite":true,"duration_ms":18692,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that one SDN controller, built around a unified YANG model and an atomic concurrent switch renderer, can manage optical circuit switches from multiple vendors and configure fiber paths within one second.","keywords":["optical circuit switching","SDN controller","multi-vendor interoperability","YANG data model","NETCONF","fiber path control","metro-access converged networks","open optical networks"],"falsifier":"Take a commercial optical circuit switch whose vendor API does not allow connections to be represented as independent one-way port pairs—for example, one that only supports creating and deleting bidirectional pairs at the same time, or one whose internal fabric has port-group constraints—and attempt to manage it through OCS.yang. If the converter cannot faithfully set and read back the switch's internal connections (or the model's GET returns a different state than the switch actually holds), the universal multi-vendor claim fails.","tokens_in":23469,"feed_emoji":"🌐","tokens_out":8857,"duration_ms":75812,"temperature":0.7,"pith_summary":"Optical circuit switches (OCSes) connect fibers directly, saving power and cost, but each vendor's switch has its own management interface, so no single controller can operate a mixed-vendor fiber network. This paper proposes and tests a software-defined networking controller that hides that diversity behind one YANG-based data model served over NETCONF, and it reports that the controller satisfied every requirement they derived from real use cases. On testbeds with switches from three vendors and in emulated networks with up to 64 switches per path, fiber paths were configured within 1.0 second, failed operations were rolled back within 0.90 seconds, signal-triggered setup finished in 2.0 seconds, and signal-degradation restoration finished in 3.0 seconds. The work matters because open, interoperable control of OCSes would let operators avoid vendor lock-in and automate services like lambda provisioning in metro-access networks.","feed_headline":"One controller drives multi-vendor optical switches in under a second","feed_subtitle":"A single open interface plus automatic rollback delivers fast, safe fiber paths across switch vendors.","key_machinery":"The load-bearing mechanism is OCS.yang, a YANG data model that represents an OCS as configurable unidirectional internal connections (name, input port, output port) plus power-monitor and alarm leaves; it is served over NETCONF through an SBI translator consisting of a NETCONF server, YANG-based datastore, callback subscriber, and vendor-specific converter. Atomicity and speed come from the OCS renderer, which wraps each switch configuration as a command object with execute() and revert(), runs execute() concurrently across switches, and immediately calls revert() on all completed commands if any one fails. The event and alarm manager uses event-driven handlers to trigger path setup or restoration on signal detection or degradation without polling.","core_discovery":"The paper's central claim is that a single software-defined networking controller can operate optical-circuit-switched networks built from multiple vendors' optical circuit switches (OCSes) through one unified interface, and do so quickly, safely, and automatically. Concretely, it reports that with the implemented controller, fiber paths were established and released within 1.0 second across real three-vendor testbeds, roll-backs after a switch failure completed within 0.90 seconds, signal-detection-triggered path setup completed within 2.0 seconds, and signal-degradation-triggered restoration completed within 3.0 seconds. The controller also reduced the driver code needed for four vendors' switches from 650 to 153 lines through the OCS.yang abstraction, and a live field demonstration set up fiber paths in under a second. The claims rest on the ability of OCS.yang to represent each switch as unidirectional internal connections regardless of its internal switching mechanism.","pith_inferences":["The paper demonstrates the unified model on four vendors' switches, so the stronger claim that OCS.yang covers 'the majority of commercial OCSes' remains a hypothesis worth testing against a wider catalogue of devices.","Because the 1-second budget is dominated by NETCONF and vendor-API latency, replacing that transport with a lower-latency protocol while keeping the OCS.yang model could plausibly push path setup and restoration from seconds toward milliseconds, a direction the paper itself flags for future work.","The live metro-field demonstration shows deployment feasibility, but the paper also notes that optical power dynamics and silent equipment failures were not evaluated; those are the conditions most likely to reveal gaps between the controller's model and physical reality.","A switch that exposes only bidirectional connection pairs, or whose internal fabric has port-group constraints, may not be expressible in the current model; if such devices exist, the abstraction would need extension rather than translation."],"forward_implications":["Fiber paths spanning dozens of switches can be established or released in about one second because the controller configures all switches on the path concurrently; emulation with up to 64 switches per route stayed under the 1.0-second target.","If a switch fails while a path operation is in progress, the controller rolls back the switches it already configured, so the network returns to a consistent state instead of being left with stray connections.","Signal-detection events can trigger fiber-path setup in under 2.0 seconds and signal-degradation events can trigger restoration in under 3.0 seconds, comfortably below the 10-minute lambda-service target.","Adding a new vendor's switch requires only writing a converter between OCS.yang and that vendor's application programming interface; the unified interface cut the switch-driver code from 650 to 153 lines.","If OCS vendors adopt the same south-bound interface, operators could run mixed-vendor optical networks with a single controller, reducing development cost and operational expenditure."],"supporting_citations":[{"why":"Supplies the reference SDN-controller architecture for optical networks and reports NETCONF configuration times of hundreds to thousands of milliseconds, which set the speed baseline.","marker":"[2]"},{"why":"Defines the transport path-computation-engine style internal model and port-mapping approach that the controller's internal data models follow.","marker":"[5]"},{"why":"Provides the production OCS datacenter use case and topology-engineering workload that motivates fiber-path setup and restoration.","marker":"[7]"},{"why":"Motivates the OCS-based WAN use case in which a fiber path traverses many switches, making concurrent configuration and rollback necessary.","marker":"[8]"},{"why":"Demonstrates a microsecond-level fast control plane for OCS systems, used as the target for future speedups of the proposed controller.","marker":"[23]"},{"why":"Reports the authors' prior OCS datacenter controller, which this paper extends to multiple vendors and additional use cases.","marker":"[27]"},{"why":"Describes dynamic optical path provisioning for alien access links, the metro-access procedure the field demonstration automates.","marker":"[34]"},{"why":"Shows NETCONF-based fast failure restoration on a software-defined optical switch controller, giving the restoration latency baseline this paper builds on.","marker":"[36]"}],"fun_headline_variants":["One SDN controller tames multi-vendor optical switches in 1s","Open controller sets fiber paths across vendors in under a second","Multi-vendor OCS control: fast fiber setup in under a second","Unified SDN for optical circuits: 1-second path setup across vendors","SDN controller delivers sub-second fiber paths on multi-vendor OCS"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The core assumption is that any optical circuit switch from any vendor can be controlled through one common way of describing its fiber connections, so the same interface is not just valid for the four switch models tested.","fun_headline_variants_meta":{"raw":{"variants":["One SDN controller tames multi-vendor optical switches in 1s","Open controller sets fiber paths across vendors in under a second","Multi-vendor OCS control: fast fiber setup in under a second","Unified SDN for optical circuits: 1-second path setup across vendors","SDN controller delivers sub-second fiber paths on multi-vendor OCS"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000236,"raw_usage":{"total_tokens":1525,"prompt_tokens":985,"completion_tokens":540,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":601,"completion_tokens_details":{"reasoning_tokens":445}},"tokens_in":601,"tokens_out":540,"duration_ms":5087,"temperature":1.0,"reasoning_tokens":445,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T05:42:49.436692+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a commercial optical circuit switch whose vendor API does not allow connections to be represented as independent one-way port pairs—for example, one that only supports creating and deleting bidirectional pairs at the same time, or one whose internal fabric has port-group constraints—and attempt to manage it through OCS.yang. If the converter cannot faithfully set and read back the switch's internal connections (or the model's GET returns a different state than the switch actually holds), the universal multi-vendor claim fails.","supporting_citations":[{"cited_title":"Experimental evaluation of control and monitoring protocols for optical sdn networks and equipment [invited tutorial],","cited_arxiv_id":null,"evidence_quote":"Supplies the reference SDN-controller architecture for optical networks and reports NETCONF configuration times of hundreds to thousands of milliseconds, which set the speed baseline."},{"cited_title":"Transport pce documentation,","cited_arxiv_id":null,"evidence_quote":"Defines the transport path-computation-engine style internal model and port-mapping approach that the controller's internal data models follow."},{"cited_title":"Jupiter evolving: Transforming Google’s datacenter network via optical circuit switches and software-defined networking,","cited_arxiv_id":null,"evidence_quote":"Provides the production OCS datacenter use case and topology-engineering workload that motivates fiber-path setup and restoration."},{"cited_title":"Beyond the mega-data center: Networking multi-data center regions,","cited_arxiv_id":null,"evidence_quote":"Motivates the OCS-based WAN use case in which a fiber path traverses many switches, making concurrent configuration and rollback necessary."},{"cited_title":"A Fast Control Plane for a Large-Scale and High-Speed Optical Circuit Switch System","cited_arxiv_id":"2401.09284","evidence_quote":"Demonstrates a microsecond-level fast control plane for OCS systems, used as the target for future speedups of the proposed controller."},{"cited_title":"First demonstration of an sdn controller for optical-circuit-switched data- center networks,","cited_arxiv_id":null,"evidence_quote":"Reports the authors' prior OCS datacenter controller, which this paper extends to multiple vendors and additional use cases."},{"cited_title":"Dynamic optical path provisioning for alien access links: architecture, demonstration, and challenges,","cited_arxiv_id":null,"evidence_quote":"Describes dynamic optical path provisioning for alien access links, the metro-access procedure the field demonstration automates."},{"cited_title":"Automatic fast failure restoration on software-defined optical switch controller with netconf/restconf for all-photonics network,","cited_arxiv_id":null,"evidence_quote":"Shows NETCONF-based fast failure restoration on a software-defined optical switch controller, giving the restoration latency baseline this paper builds on."}],"review_version":1}