Summary

  • InterLAN IX told RIPE 93 that its Lighthouse system is in use with nine Nokia routers, 20 Arista switches, 197 services and 214 portal customers. Its change path previews configuration per device, validates it, checks reachability and uses a rollback timer.
  • The external API can request writes through transactions; the AI assistant has read-only diagnostic tools. InterLAN lists AI-assisted changes as a future propose-review-approve workflow. The key unanswered operational number is how often a multi-device change partially commits and how each such case is recovered.

The dangerous word in network automation is “done.” A portal can display a green check while one router has accepted a change and its neighbour has not. In his RIPE 93 Connect presentation, InterLAN IX engineer Andrei Dinu described a system built around that awkward interval. The 23-page Lighthouse deck calls the workflow an atomic multi-device transaction, then shows the actual pieces: a preview for each device, validation before commit, a reachability check, a rollback timer, confirmation or reversal, and an execution log. The label “atomic” is easy to print. The interesting engineering is what happens when the devices disagree.

InterLAN says Lighthouse is already in use. The deck’s snapshot lists nine Nokia routers, 20 Arista switches, 197 services and 214 portal customers. Those are its reported estate and portal counts, not a published number of successful automated changes. The customer sees a catalogue of services and bounded requests. Staff see the same intended state, device state, telemetry and change history. A request can cross vendors and boxes; each target gets its own generated configuration preview. That is a much better place to find a bad VLAN or an overbroad filter than after the route has moved.

The rollback timer deserves its own sentence. On the Nokia side, the deck shows a confirmation window: if the change is not confirmed, the device reverts its configuration. Lighthouse checks reachability before confirmation and logs the result. A screenshot shows four minutes and forty-two seconds remaining on one example timer. It is a screen state, not a promised timeout for every change. The architecture matters because a broken management path can otherwise strand the operator behind a successful-looking API response.

The database has a harder job than counting buttons. InterLAN compares saved configuration with live device values; manual edits remain visible as deviations. Its integrity checks flag missing SAPs and duplicate identifiers or EVIs. The operator can repair through a transaction or adopt a deviation only when allowed. This is the point where an automation product becomes an authority system. Someone must decide whether the database is stale, the engineer’s emergency edit was justified, or the router is wrong. Silently making the live box match the database would be a tidy way to erase the most important event of the night.

Lighthouse rehearses changes in a digital twin assembled from recent saved production configuration and topology. The deck names Containerlab and Nokia srsim, says the configuration is cleaned before simulation, and keeps the lab separate from production. It also says devices must already have management and routing configured, while Arista vEOS and BIRD customer simulation remain on the roadmap. This is a useful rehearsal room with a clearly marked door; it is not a magical copy of every live dependency.

Then comes the fashionable part, handled with unusual restraint. The external API can read or write, but writes still run through transactions, locks, rollback and audit. The AI assistant receives read-only MCP tools for state, logs and diagnostic operations. Its current examples are a customer report and a migration plan. The final slide puts AI-assisted changes in the planned column, with the sequence “propose → review → approve.” The assistant has a desk and a notebook. It does not have the router keys.

There is a RIPE NCC connection beyond the conference microphone: RIPE RIS lists its RRC22 collector at InterLAN-IX in Bucharest. RIPE NCC runs the collector service; InterLAN runs the exchange and Lighthouse. Keeping those roles separate matters. A registry’s measurement of routing, an exchange’s desired-state database and a router’s live configuration are three different records. One cannot certify the other by appearing on the same diagram.

The presentation does not publish a transaction sample, partial-commit count or rollback-success rate. A dated aggregate report of attempted changes, device-level outcomes and recoveries would test the safety claim. Until then, the deck’s strongest contribution is architectural honesty: every writer crosses a guarded transaction path, every manual change remains visible, and the AI sits behind glass. In a business that loves to call a dashboard “control,” those are welcome distinctions.

Sources: RIPE 93 InterLAN talk record; InterLAN Lighthouse original slide deck hosted by RIPE 93; RIPE RIS route-collector list.