Summary

  • InterLAN IX’s Lighthouse design lets members request changes while the exchange keeps an intended-state database, per-router previews, timed rollback and a human handoff when recovery cannot be shown safe.
  • The striking AI rule is gloriously unglamorous: the assistant may inspect and write a report, but it cannot write configuration. The power to change the shared fabric stays with the operator’s controlled process.

The button that does not own the router

A self-service portal can make a network change look like ordering lunch. Choose an option, press a button, wait for the confirmation. The kitchen, in this case, consists of routers carrying other people’s traffic. A misplaced order can spoil considerably more than the soup.

That is the tension in InterLAN IX’s Lighthouse presentation abstract for RIPE 93. Andrei Dinu describes a portal for members of a Romanian Internet exchange whose network runs Nokia SR OS routers and Arista EOS switches. A single member request may reach several devices. Lighthouse previews the configuration for each, starts a rollback timer, and asks for confirmation one router at a time. If safe recovery cannot be demonstrated, a human takes over. The database holds intended state; an engineer’s manual change on a device appears as drift rather than quietly becoming the new official plan.

The abstract is a design statement. It contains no published change log, recovery exercise or adoption count. Those records would tell us how often the stop rules have actually been invoked. The design itself is worth examining now because it draws a sharp line around a fashionable word: self-service. The member can ask. The portal can assemble a proposal. The exchange still controls which proposal becomes its network.

InterLAN’s own service description makes that boundary commercially relevant. Its platform offers public peering through two route servers, private VLANs, backup ports and related interconnection services. These are shared facilities. A VLAN change for one participant, for example, may require consistent state across more than one device; the exact request types supported by Lighthouse have not been listed publicly. A portal that merely sends each configuration command faster would put a polished front desk on an inconsistent machine room. The per-router preview and confirmation steps are an attempt to keep the transaction visible at the point where partial application becomes possible.

Partial application is the awkward guest at every distributed-change party. Router A may accept a new configuration while router B rejects it. A timer may restore the first device, yet the network may have spent minutes in an in-between state. Lighthouse’s abstract does not claim a universal atomic rollback. It says each router has a rollback timer and individual confirmation, with human takeover when recovery cannot be proved safe. That modesty is a governance feature. An operator who cannot establish a safe automatic recovery path must name the person who inherits the problem; “the automation handled it” is not a person.

The database has a better memory than the shift log

A second choice carries more institutional weight than the interface. Lighthouse treats its database as the owner of intended state. A command typed directly into a router is visible as a deviation. The alternative would be to let whatever the box currently says become policy by accident. Then a midnight workaround, perhaps useful for a few hours, could be laundered into the next automated rollout as if somebody had approved it for the whole exchange.

This is where Heng Lu’s question about attendance and mandate becomes useful outside the meeting room. Access to a button is participation; authority lies in the record that the system treats as binding. A member’s request does not make the member the custodian of the exchange. An engineer’s emergency keystroke does not make the keystroke the permanent rule. The intended-state database may sound like dull plumbing, which is exactly why it deserves scrutiny. It decides which human actions count as authorized network policy after the excitement fades.

InterLAN says a digital twin built from production snapshots rehearses changes before they reach live devices. That gives the process another useful checkpoint: compare a proposed state with a recent model of the real one. A snapshot can go stale and a rehearsal can miss traffic conditions, so the evidence that matters is the timestamp, fidelity and result of each rehearsal paired with the final device diff. The public abstract does not publish those artifacts.

A member or auditor asking whether Lighthouse is dependable should ask for a representative chain: request, preview, rehearsal, approval, device confirmation, drift result and rollback record. One glossy dashboard screenshot is a poor substitute for that sequence.

The AI assistant gets the least dramatic job in the room. According to the same RIPE abstract, its tools are read-only; it writes reports and migration plans and cannot touch configuration. Good. A model can produce plausible instructions with the confidence of a junior engineer who has never been on call. Keeping its hands off the switches makes any human decision to use its plan attributable and testable. The firewall here is a permission boundary, not a marketing adjective.

The exchange’s own FAQ says route-server sessions are optional and members retain their own peering policies. That distinction completes the picture. InterLAN controls its shared exchange equipment; participants control their separate decisions to peer. Lighthouse governs changes to the former. It does not turn a self-service portal into an owner of everybody’s routing choices. RIPE NCC’s RIS documentation lists RRC22 at InterLAN-IX in Bucharest, an independent way to observe some BGP routing information. Route observations can reveal effects worth investigating, while the Lighthouse change log would explain who requested and approved a configuration. Those records answer different questions.