TNC26 (GÉANT research networking conference)#

June 8, 2026 – June 12, 2026 Program

Core#

This is the end of the network as we know it, and we feel fine #

Abstract Slides

Aleksandr Kurbatov, Karel van Klink (GÉANT)

Why: GÉANT has finished migrating its backbone packet layer to a new equipment vendor — and the interesting part is that the orchestration stack (the GÉANT Service Orchestrator, grown out of the Workflow Orchestrator programme) is what made a vendor swap of a pan-European backbone tractable. For anyone building network automation, the hard-won modeling decisions here transfer directly.
What: A migration retrospective plus the orchestration model it enabled. The core of the presentation (per the slides) is how GÉANT models commercial peers: each peer is a single entity (ASN, prefix limit) that can hold multiple connections to different placement port types — IX port, private peering port, or transit port — explicitly avoiding a data-duplication anti-pattern. The same operator workflow produces different router configurations (communities, policies, BGP groups, prefix-limit handling) depending only on which port type the connection targets.
How: A layered model in the orchestrator where connection Type is derived automatically from the target placement port; Ansible extracts the type, pulls the correct variables, and translates the orchestrator abstraction (one Peering Connection grouping IPv4+IPv6) into two independent BGP neighbor statements on the router. Per-connection Session States (Provisioning → Active → Disabled) act as predefined configuration shortcuts — e.g. Provisioning establishes BGP without route exchange, Disabled keeps all config in place but shuts down the neighbors. "One update, one workflow" propagates a peer change (e.g. prefix limit) across all of that peer's connections while leaving co-located peers untouched.
Where applicable: GÉANT-specific backbone and orchestrator, but the patterns — model per organization not per port, port-type-derived config, session-state shortcuts, safe scoped deletion in multi-peer environments — are broadly applicable to any operator automating multi-site peering across IX, private, and transit contexts.

Building AI That Works: ESnet's Pragmatic Approach to AI-Driven Operational Excellence #

Abstract Slides

Edward Balas, Jon-Paul Herron (ESnet)

Why: One of the few AIOps talks with deployed results rather than demos. ESnet built ORBIT (Operations Response & Business Intelligence Toolkit) to address growing scale with fixed NOC staffing, and reports what actually worked — including the unglamorous lessons.
What: Two production applications: Intelligent Resolution Guidance, which proactively surfaces relevant documentation for incoming alarms/tickets, and Adaptive Incident Summarization, which generates audience-tailored ticket summaries. A concrete example in the slides: an operator asks what to do about a "Span Loss Out of Range – High" alarm and gets guided resolution. Future roadmap items include Drishti (early-alpha unsupervised log analysis: identify interesting events, cluster, generalize into behavioral sequences, summarize) and off-the-shelf Elasticsearch anomaly detection — multivariate for data movement (limited dimensionality, weak explainability) and univariate for predicting resource exhaustion ("preserves our engineers' weekends").
How: Unified data access fusing ticketing (ServiceNow), Slack chatter (context that never made it into tickets), documentation, live metrics, and logs, with LLM agents and semantic search over semi-structured data via MCP. A representative query — "customers in Chicago report unstable service, summarize what might be responsible" — has the agent walk the customer database, backbone topology, ticket history, metrics, and operations chats before synthesizing an answer. Humans stay in the loop throughout.
Where applicable: ESnet-scale research WAN, but the architecture (chat + tickets + docs + telemetry into one agent environment, semantic search/MCP over ops data) is general. Key lessons are stated plainly: treat prompts as code (version, QA — 25% speedup from refinement alone), plan for stochastic outputs, your first use cases won't be your strongest, and develop organizational policies for AI data access before capability sprawl.

Machine Learning for Anomaly Detection in RNP Network Operations #

Abstract Slides

Guilherme Branco Ladvocat (RNP)

Why: A realistic template for ML adoption in network operations by a team with no data scientists — increasingly the default situation, and a useful counterweight to the ESnet approach.
What: RNP (Brazilian NREN, ~1800 connected sites, MPLS-TE full-mesh between PoPs) applied ML anomaly detection to interface metrics, ping loss/latency, netflow, and syslog categorization (standard vs. rare message groups). The deliberately pragmatic choice: Elastic's ELSER v2, an out-of-domain model requiring no fine-tuning, running inside the Elastic observability stack they already stood up in 2024 — avoiding "reinventing the wheel" and the need for ML expertise.
How: Baseline learning on telemetry time series flags deviations where static thresholds fail (interface delay, utilization, netflow anomalies, latency); dashboards group anomalies so the algorithm does the first pass of analysis and engineers interpret. The observability journey started in 2018 with push-model, high-resolution telemetry.
Where applicable: RNP-specific stack (Elastic), but the incremental, no-data-scientist adoption path is broadly replicable. The stated limitations are honest and important: the model doesn't reason about values, root-cause analysis isn't achieved by a single anomaly-detection job, and engineers still have to interpret the output.

Discovering a DWDM network with Tomography #

Abstract

Annalisa Morea (Nokia), Jani Myyry (CSC/Funet), Kurosh Bozorgebrahimi (Sikt), Magnus Bergroth (SUNET)

Why: Turns the coherent transponder from a transmission component into a sensing device that infers the physical network topology with no prior knowledge — directly relevant to anyone operating optical plant whose documentation drifts from reality. (from abstract only; the programme page was not retrievable)
What: Nokia Bell Labs' "Tomography" method estimates fiber types, span lengths, and amplifier types from data the DSP already computes. In a February 2026 field trial on a multi-vendor Scandinavian network (CSC, Sikt, SUNET), a signal ran Tromsø→Espoo over two routes with characteristics unknown to the Nokia team, in C-band alongside live traffic, three wavelengths measured per route, using PSE-Vs (SFM6) transponders. Results: fiber length estimated with less than 4% error, good amplifier-type match, operators corrected erroneous database entries, and a path commissioning error was detected.
How: The DSP analyzes received symbols to determine accumulated chromatic dispersion and nonlinearities; an algorithm exploits the non-commutative property between CD and nonlinear effects to convert this into power-versistance distance maps, and from those into span/topology estimates — no additional hardware, coexisting with revenue traffic.
Where applicable: Requires coherent DSP transponders (Nokia PSE-Vs in the trial); the fiber plant itself was multi-vendor and heterogeneous. It's a partner (Nokia) session, but the field trial is independently hosted by three NRENs with named, verifiable outcomes — not a pitch.

Churn: GÉANT's Next Iteration in Network Monitoring and Reporting #

Abstract Slides

Erik Reid (GÉANT)

Why: A rare, well-argued reference architecture for telemetry pipelines. GÉANT redesigned its monitoring/reporting stack after hitting three predictable walls: duplicated collector configuration across SNMP/NETCONF/gRPC, no unified picture of what talks to the devices, and tech-stack coupling (every debate about Influx vs. ClickHouse vs. Elastic vs. Telegraf vs. gNMIc stalling progress).
What: Churn is not another monitoring tool or datastore — it consolidates device access and ingestion (gNMI, SNMP, NETCONF, SSH, ICMP) behind small, repeatable message processors, and deliberately keeps storage/visualization choices at the processing level rather than the architecture level. A deliberate "middle path" between a premature framework and per-service pipelines: share only what converges, keep internals explicit (no "metadata" trap), accept some per-integration effort.
How: Processors follow a consume → filter → transform → publish pattern over RabbitMQ exchanges, with strict internal consistency via Pydantic validation; internal Churn models never leave Churn. Horizontal scaling via round-robin task queues over shared exchanges. Notably, Prometheus is used as a lightweight data-sharing tool (via ROBIN to NRENs and the community) rather than as a monitoring platform — a trick worth stealing. EuroHPC reporting needs were absorbed by reusing the same pipelines.
Where applicable: GÉANT-scale backbone, but the processor pattern and the design reasoning transfer to any observability pipeline rebuild. Source code and documentation are publicly available (GÉANT GitLab).

Network Flow Monitoring: An Evaluation of Modern Collector Software #

Abstract Slides (PDF) Slides (PPTX)

Yannick Huber (BelWü / University of Stuttgart), with Benjamin Steinert, Lukas Pietzschmann, Gabriel Paradzik, Michael Menth (Tübingen, Ulm)

Why: Firmly substantiated, quantitative tool evaluation — exactly the kind most teams never have time to do. Benchmarks six actively maintained, self-hostable open-source flow collectors (Akvorado, GoFlow2, IPFIXcol2, nfdump, pmacct, SiLK) for sFlow and IPFIX.
What: Combines a feature/usability matrix (protocol support, enrichment, anonymization, Kafka/file outputs, telemetry endpoints) with sustainable-throughput benchmarks in a controlled testbed (synthetic generator, 20 flows per packet, 4 CPU cores / 12 GB RAM). Headline numbers: to Kafka, pmacct sustains ~186–209k flows/s, IPFIXcol2 ~375–446k, GoFlow2 ~13–15k (JSON) vs. ~77–86k (protobuf), Akvorado ~510–548k (raw forwarding); to file, nfdump reaches up to ~842k flows/s (IPFIX) and IPFIXcol2 ~680k. Main findings: input format matters (IPFIXcol2 and nfdump do best on IPFIX; SiLK and pmacct lag on sFlow), output serialization is crucial (GoFlow2's JSON path is an order of magnitude slower than protobuf), and message brokers enable horizontal scaling and redundant deployments.
How: Found the sustainable processing rate by ramping packet rate while verifying flows in equals flows out; also documents production drop-detection tactics (canary flows, indirect CPU/memory/interface monitoring) since most collectors lack adequate telemetry endpoints.
Where applicable: Results are dimensioned to a specific testbed (4 cores, 20 flows/packet — decapsulation overhead rises with fewer flows per packet) and the authors flag open questions (custom IPFIX fields, resource scaling). The load-testing tool is open-sourced (go-nflow-stresstest on Codeberg), so the benchmark is reproducible. No single winner — the value is the selection/dimensioning guidance.

AI, American Science Cloud, and the Genesis Mission #

Abstract Slides

Chin Guok (ESnet)

Why: The clearest public statement of how AI workloads are rewriting the requirements for a national-scale research WAN. AmSC is a congressionally mandated (OBBB Act/H.R.1) DOE project — an AI-focused, federated, science-optimized cloud integrating data, models, and HPC across DOE facilities, as a cornerstone of the Genesis Mission (doubling US R&D productivity within a decade, 26 named S&T challenges).
What: Beyond the program overview, the talk gives concrete networking consequences: ESnet7 is expected to deploy 50–70% above the current historical growth trend to accommodate AI workflows; benchmark models can spend over 50% of time in networking; emerging AI science (autonomous labs, fast-feedback experiments, interactive agents) needs negotiable service guarantees and QoS, not best-effort pipes. Supporting work: NetBurst event-centric forecasting of bursty traffic, SENSE for secure application-driven multi-domain programming, EJFAT load balancing and real-time streaming at 100 Gbps+, in-network caching showing ~70% data reuse, High-Touch per-packet visibility, and netFound (a network-security foundation model with UCSB).
How: AmSC treats the network as a co-designed fabric with compute/storage/accelerators (explicitly citing hyperscaler practice), exposing AmSC and IRI APIs as a common framework to incorporate disparate resources into frictionless multi-cloud science workflows.
Where applicable: US DOE-specific program; the traffic forecasts are cited from third-party analyses (Cisco, Gartner) and should be treated as directional rather than measured. Still, this is the requirements document that will shape ESnet7 — and a preview of the "AI WAN" demands every large operator is starting to face.

Distributed Active Network Monitoring with nmaas – Insights from an NREN production deployment #

Abstract Slides

Firat Koyuncu (GIP RENATER), Vojdan Kjorveziroski (UKIM)

Why: A production case of multi-cluster Kubernetes used to solve a real fleet problem — plus one of the better-documented VMware→Kubernetes migration rationales you'll find.
What: RENATER's perfSONAR estate had decayed: 40 servers acquired in 2017 had shrunk to ~10 deployed with no software alignment, heterogeneous local credentials (iDRAC, OS), and a perfSONAR service that "globally was not working." After the Broadcom/VMware licensing changes destroyed trust in the hypervisor path, RENATER rebuilt on Kubernetes (Talos Linux immutable nodes with KubeVirt on bare-metal servers) and used nmaas — an open-source multi-tenant PaaS with multi-cluster support — to deploy perfSONAR nationwide, with webhook-driven automation for centralized lifecycle management of edge measurement nodes.
How: Foundations: NetBox as source of truth, consolidated via Maat; declarative GitOps deployment; Apache Airflow as the workflow engine gluing source-of-truth, ticketing, and the platform ("no significant development required — integration only"). nmaas onboards remote K8s clusters per domain so applications run on-premise at the edge — eliminating site-to-site VPNs and giving local plus external vantage points.
Where applicable: RENATER/nmaas-specific deployment, but both the platform (open-source nmaas) and the stack pattern (SoT + GitOps + Airflow + immutable K8s at the edge) are directly reusable. The "fleet of identical clusters" observation is the transferable design principle.

Federated Network Troubleshooting: Deploying HAWAT and Looking Glass Across the R&E Community #

Abstract Slides

Karl Newell, Matt Mullins (Internet2)

Why: Federated troubleshooting is a collective-goods problem no single operator can solve alone, and this is one of the first working examples — plus an Agent-to-Agent (A2A) cross-organization diagnostic PoC that previews where AIOps goes next. (from abstract only; slides were not extractable)
What: HAWAT has moved from experimental to production on Internet2's network, with open-source containers available. The breakthrough is federation: a Looking Glass service lets each organization independently deploy and control which commands it exposes, and HAWAT queries multiple instances to diagnose cross-network issues — isolating packet loss between universities or tracing BGP behavior across peers. An A2A interoperability PoC with SURF demonstrated AI agents from independent NRENs collaborating on network diagnostics across organizational boundaries.
How: Each org runs its own Looking Glass instance under its own policy; HAWAT aggregates queries across instances; demonstrations ran in a multi-network virtual environment, with a participation path for other networks.
Where applicable: R&E community context and requires peer organizations to actually deploy instances (the perfSONAR-style network-effect problem). The A2A piece is proof-of-concept stage, not production.

Coordinating BGP Policy and Tooling Across the Global R&E Infrastructure #

Abstract

Brenna Meade, Jeff Bartig, Steve Wallace (Internet2)

Why: Community-scale BGP hygiene tooling with concrete deliverables — a model for turning fragmented, per-operator filtering policy into shared infrastructure. (from abstract only; this is a BoF with no paper)
What: An Internet2 + CAIDA toolset (NSF-sponsored) covering four pieces: a Global R&E BGP Route Report giving route-level views across participating infrastructure — IRR consistency (with visibility into membership in the IRR AS-SETs used for R&E filtering), RPKI ROV status, inferred path preference (R&E vs. commodity transit), and signals of route leakage in both directions between R&E and commodity paths; an authoritative Global R&E Prefix Registry (~12,000 prefixes) that Internet2 will itself use for filtering and publish for community use; an AS Topology Observatory showing primary and backup interconnect structure; and an interactive IRR AS-SET planning tool for building customer-cone AS-SETs.
How: Aggregation of routing data with RIR attribution (organization/contact context) into route-level reports; the prefix registry becomes a filterable community dataset.
Where applicable: R&E-specific datasets, but the toolset design (leak detection between constrained communities and commodity paths, authoritative prefix registries) is a pattern any closed community of networks could replicate. It's a BoF: tools are in progress and the session is explicitly soliciting feedback on priorities, data quality, and governance.

Procurement of dark fiber and optical spectrum for the new research network in Norway. Strategies and learnings #

Abstract Slides

Olaf Schjeldrup (Sikt)

Why: Physical WAN infrastructure strategy with real numbers and two years of negotiation scar tissue — squarely relevant to anyone whose job includes DC/WAN interconnect economics. Norway's NREN renewal covers ~13,000 km of renewed optical long-haul topology across punishing geography (3,000 km north–south, 103,000 km of coastline), with geopolitical tension explicitly cited as a driver for higher validated redundancy.
What: Requirements: national coverage, terabit capacities with a preference order of dark fiber > optical spectrum (1–1.2 THz, flexigrid, license-free) > waves; 20-year IRU matching Open Line System lifetime; fiber sensing and bidirectional time-and-frequency transfer capability; extra fiber pairs reserved for research (quantum, sensing). Process: RFI spring 2023, RFQ end-2023, award criteria 60% quality / 40% TCO, 10 tenderers (3 hybrid fiber+spectrum, 7 fiber-only), negotiated procedure running over two years with six offer/negotiation phases, BAFO May 2025, award January 2026 to 8 sub-providers, main contracts May 2026, rollout 2026–28 — with "huge cost savings, increased optical footprint and redundancy."
How: The evaluation complexity (choosing one path alters preferences for many others) was made manageable by dividing the country into 5 regions, evaluating inter-regional legs with add/drops at essential locations, backed by purpose-built evaluation models. Tactical tips: dark-fiber monopolies are consolidating and prices are rising on datacenter-industry demand; asking for both fiber and spectrum widens real competition; spectrum providers with greenfield DWDM plans will install L-band sensing and bidirectional T&F channels for you; multi-subprovider strategies cost more effort but save money and add diversity.
Where applicable: Norwegian market and geography, but the procurement playbook (competition structure, evaluation decomposition, IRU terms, research fiber pairs) transfers to any large fiber buyer. Explicitly org-specific in outcomes; the strategy is the export.

Time Travels in the L-Band: Deploying a National White Rabbit Infrastructure over Active DWDM Networks #

Abstract Slides

Michal Hazlinsky (CESNET)

Why: A blueprint for running nanosecond-grade time distribution on an active, revenue-carrying DWDM network instead of dedicated dark fiber — plus one of the best examples of real NetDevOps automation at the optical layer (L0).
What: CESNET distributes time traceable to UTC(TP) with better than 1 ns stability to 22 locations, with White Rabbit running in the L-band (1570/1571/1572 nm) coexisting with 8 C-band data channels on the same fiber of its 5,700 km multivendor network (Cisco, Ribbon/ECI, CzechLight). Spectrum-sharing was designed in from procurement: custom channel filters per line (8 C + 4 L channels, <1 dB insertion loss), bidirectional single-fiber transmission to defeat WR's path-asymmetry problem, and CzechLight SDN bidirectional EDFAs for long-haul.
How: Open-source SDN-controlled BiDi amplifiers (NETCONF/RESTCONF, YANG model, IETF YANG-Push streaming telemetry with sub-second latencies) managed via Ansible with a NetBox inventory — actual DevOps playbooks at the photonic layer. Calibration is treated as a first-class engineering problem: measuring Tx/Rx filter delay asymmetry, chromatic-dispersion asymmetry per line, and a field procedure using the Safran Z16's port-mode survey plus switched Tx/Rx wavelengths so a second WR switch and external counter aren't needed on site. Lessons: transceiver Tx-power variance means power budgets must be recalculated on replacement (keep fixed attenuators in reachable locations), and logical topology reconfiguration can require WRS reboots.
Where applicable: Requires a spectrum-sharing design (reserved L-band channels and filters) — cheapest on greenfield builds — and CESNET's own CzechLight hardware, but the hardware designs and software are open. The calibration methods and the L-band coexistence technique are broadly reusable; "standard APIs are MUST HAVE" is the summary lesson.

Streamlining Multi-Vendor Automation: Auto-generated RESTCONF Clients from YANG Models #

Abstract Slides

Matteo Colantonio (GARR)

Why: Attacks a tax every multi-vendor automation team pays: hand-written RESTCONF/NETCONF clients per device family. (from abstract only; lightning talk, slides not extractable)
What: A GARR-built tool that converts YANG models into developer-friendly, type-safe Python RESTCONF clients (Pydantic-based), giving runtime validation of network configurations before they hit devices.
How: Code generation from the device's own YANG schemas rather than hand-maintained bindings — the schema is the contract, and validation falls out of the generated types.
Where applicable: General technique for any YANG-speaking fleet; five-minute lightning format, so expect depth to be limited, but the idea is directly stealable.

Saz: Engineering Safe Agentic Workflows for Real-World Operations #

Abstract Slides

Fariman Torkashvand (GÉANT)

Why: Agentic AI that plans actions, calls tools, and triggers real network automation is arriving in operations; this is a concrete architecture for doing it without losing control. The risk framing — hallucinated decisions, escalating costs, unclear accountability — matches what any operator planning agent deployment should be worrying about.
What: Saz, a self-hosted agentic workflow engine designed to embed AI in operational environments through structured workflows, human-authored instructions, and strict policy enforcement. Its distinguishing feature is a dual-agent safety model: a verifier agent evaluates the planner agent's output before execution. (from abstract only; slides not extractable)
How: Constraints over autonomy — workflows are structured and authored by humans, policy is enforced engine-side, and the verifier/planner split provides an internal check step. The output is patterns for AI-driven workflows that remain controlled, auditable, and human-governed.
Where applicable: General pattern, GÉANT-flavored implementation. Self-hosted, which matters for the sovereign-AI theme of the session. Early-stage work rather than a long-production retrospective.

Exploring nmaas Platform Use Cases – Beyond network and service monitoring (Plugged-in)#

Abstract Slides

Lukasz Lopatowski (PCSS), Vojdan Kjorveziroski (UKIM)

Why: The companion to the RENATER deployment talk, showing where the nmaas multi-tenant, multi-cluster Kubernetes platform is heading beyond perfSONAR.
What: A demo-format Community Hub session around the core nmaas use cases: Virtual NOC (vNOC) as the central point from which business workflows are triggered, Virtual Lab (vLAB — educational network exercises at scale), Metrics, and Active Monitoring (including the EdgePL project), plus web-service health monitoring and backups as run at PCSS. The slides also flag two forward items: sharing GPU resources on edge nodes, and extending nmaas with generative AI via an nmaas MCP server (new application addition).
How: Same mechanism as the monitoring talk — catalogue applications deployable onto any onboarded remote Kubernetes cluster, centrally managed, edge-resident.
Where applicable: Open-source platform, directly reusable; note this is a demo showcase rather than a results paper, and the source slides are mostly screenshots, so judge the depth accordingly.

Adjacent#

Digital Global Gateway: Shaping the Future of Global R&E Connectivity #

Abstract

Helga Spitaler (GÉANT), Sabine Jaume (NORDUnet), with panellists from the European Commission (DG ENEST, DG INTPA), the EIB, GÉANT, NORDUnet, and UbuntuNet Alliance

Why: Intercontinental connectivity is entering a strategic era where submarine cable projects (Medusa, Blue Raman, Polar Connect, EurAfrica Gateway) sit at the intersection of geopolitics, digital sovereignty, and hyperscaler influence — relevant context for anyone reasoning about long-haul DC/WAN interconnect economics. (from abstract only)
What: A panel examining who shapes the architecture of international connectivity, who benefits, and how publicly supported infrastructure can remain open, trusted, and sustainable versus commercially driven models — including equitable partnerships with partner regions and the long-term sustainability of connectivity investments.
How: Discussion format with EC, EU financing, RREN and NREN perspectives.
Where applicable: European policy context; strategic rather than technical content.

The Journey: From Cloud Complexity to Platformisation #

Abstract Slides

Joao Pedro Milhome, Alberto Viana (RNP)

Why: A candid platform-engineering story: adopting containers and cloud tooling made RNP's service delivery more complex, not less — a failure mode most cloud platform teams will recognize.
What: RNP's response is an Internal Developer Platform organized around four pillars (Speed, Safety, Efficiency, Scalability), treating the platform as a product with golden paths that reduce cognitive load while leaving flexibility for service teams. The slides narrate the diagnosis: fragmented tools, inconsistent environments, split responsibilities, and days spent configuring plumbing instead of writing code.
How: Paved roads as product strategy — the safe, observable path is made the easiest path; declarative intent replaces manual fulfillment (their database-provisioning example); observability and security are built into the road rather than being separate ticket queues.
Where applicable: NREN service-organization context (small expert teams, public-interest services, governance requirements), but the platform-as-product approach is the standard enterprise pattern applied honestly — useful as validation rather than novelty.

The CERN experiments' network journey to IPv6-only #

Abstract Slides

Tim Chown (Jisc)

Why: The best-documented large-scale argument that dual-stack is a waypoint, not a destination — with measured traffic shares to back it.
What: The WLCG (170 sites, 40 countries; LHCOPN private optical Tier-0/Tier-1 links, LHCONE L3VPN/VRF, NREN catch-all) IPv6 program: Phase 2 dual-stack is complete at data servers and 75% complete at worker nodes (ticket campaign running since December 2023); Phase 3 — removing IPv4 from WAN links — is underway, starting with CERN–Tier-1 LHCOPN links. Measured shares: >99.5% IPv6 on the KIT OPN link, >93% in FTS logs (including non-WLCG transfers), >99.9% of SciTags flows into RAL.
How: HEPiX IPv6 WG methodology — readiness/gap analysis (2011), dual-stack enable-and-prefer (2018–), then active IPv4 decommissioning on WANs, motivated by simpler operation, simpler security, no NAT.
Where applicable: Research-grid context, but the phased playbook and the "plan where and when you can turn off IPv4" message apply to any distributed infrastructure that has finished dual-stack and is wondering what's next.

Below the Sky: Presentations #

Abstract Slides (PDF) Slides (PDF)

Chairs: Raimena Veisllari (Sikt), Domenico (Dom) Vicinanza (GÉANT), Guy Roberts (GÉANT); talks from GÉANT, RENATER, and Sikt/Nordic partners

Why: The engineering follow-through to the CESNET talk — a BoF on building terrestrial, GNSS-independent time networks across Europe, grounded in the GÉANT C-TFN Incubator report (Zenodo).
What: Substantiated results, not just a roadmap: a 498 km Prague–Vienna field-installed loop using five bidirectional amplifiers achieved ±100 ps time-transfer stability — well inside the 1 ns target — with 1 Gbps WR signals sharing fiber with 400G coherent channels at no measurable BER impact given a suitable guard-band. The report compares three regeneration architectures with performance data and an interactive cost calculator: 1R bidirectional amps (best timing, fixed wavelength per span), 2R OEO (good cost-performance trade-off), 3R WR switches (full flexibility, more jitter in cascade). Plus spectrum planning guidance (L-band is amplifiable but typically unused for data — an attractive WR home; placing WR at the C-band edge halves guard-band cost) and operational design requirements (dual PSUs, SNMP traps, OSC channel, support model) — including the candid gap that SNMP management of open-source WR switches is still being defined by the consortium.
How: White Rabbit over long-haul DWDM with careful calibration (any Tx/Rx asymmetry measured and compensated, recalibration after every fiber repair); roundtables organized by deployment challenge (optical layer vs. economics/OAM).
Where applicable: European NREN context and DWDM-platform-dependent (built-in L-band filters help), but the whitepaper's comparison data and cost model are directly consumable by any operator considering sovereign terrestrial time.

Traffic at 3am: Armed with a Toothpick against AI Scrapers #

Abstract Slides

Cheryl Andrea Fernando (SURF)

Why: AI training scrapers are now an operational cost and risk problem for anyone serving public content — and the defensive landscape is fragmenting fast. Lightning-talk depth, but a useful map.
What: A survey of mitigation strategies: robots.txt (voluntary, widely ignored), Cloudflare's AI Labyrinth (trapping non-compliant crawlers), monetization via Cloudflare Pay-per-Crawl and Akamai's Tolbit/Skyfire, open-source countermeasures like Anubis (proof-of-work gating that makes bot traffic expensive) and tarpits (Nepenthes, Quixotic, Iocane — feeding Markov babble to poison training data, with real caveats: SEO damage and self-inflicted resource costs). The genuinely hard problem: residential proxies, which defeat datacenter-IP blocklists because the IPs are real home connections, often resold without their owners' knowledge.
How: The promising detection thread is TLS fingerprinting (JA4+ from FoxIO, already adopted by Cloudflare and DataDome): deprecated cipher suites and odd extension combinations flag scraper clients, complementing approaches like the Amadeus research on TCP-vs-TLS round-trip-time differences for detecting residential proxy use. The recommended posture is modular — combine robots.txt, experimental setups, and fingerprinting to fit your risk tolerance.
Where applicable: General web-serving context, NREN-specific only in the tension between openness (discoverability) and protection (research data).

From Public Cloud AI to National Infrastructure: Lessons from Sunet Scribe #

Abstract Slides

Erik Lundberg (Sunet)

Why: A rare, fully-costed-in-public view of running a national AI inference service on a small GPU fleet — the operational reality behind "sovereign AI services."
What: Sunet Scribe, a self-hosted, Whisper-based speech-to-text service inside the Swedish NREN, born because institutions didn't trust commercial providers with sensitive recordings and commercial STT wasn't optimized for Nordic languages (the fine-tuned Swedish model comes from the Royal Library). Timeline: community request mid-February 2026 → prototype and first GPU machines in May → institutional pilot October 1 → national launch December 1. Traction: 30 universities, ~3,000 users, ~650,000 minutes transcribed in 2026 (3–4× the 2025 baseline) — handled by three GPU servers.
How: Deliberate architecture choices: self-hosted with federated login, zero-access model, automatic retention; integrated with Kaltura (and NextCloud in 2026) with a published API; open-source, modular, with swappable models and components — consolidating what had been parallel commercial/secure/internal STT pipelines into one operational platform.
Where applicable: Nordic-language and trust context is specific, but the pattern — small GPU fleet, open models, platform integration, one year from request to national service — is a transferable template for institutions weighing public-cloud AI vs. self-hosted.

Wildcard#

Toward Scalable Quantum Networks: Lessons from InterQnet #

Abstract Slides

Rajkumar Kettimuthu (Argonne National Laboratory)

Why: Not the PM's daily bread, but a two-year progress report on the US DOE's full-stack quantum networking program that frames quantum networks as an operations problem — and argues NRENs already own the prerequisites (deployed fiber, automation, synchronization, optical-channel engineering).
What: InterQnet runs two tightly coupled goals. InterQnet-Achieve: a three-node heterogeneous quantum network (Yb atom arrays, Er³⁺ ions, superconducting qubits) over deployed campus fiber with dark-fiber paths toward Fermilab, UChicago, and StarLight, using frequency conversion and microwave-to-optical transduction, under centralized SDN-style orchestration with automated calibration. InterQnet-Scale: architecture studies via SeQUeNCe, Argonne's ~7-year-old quantum network simulator, with device-faithful simulations checked against real measurements. Hardware progress cited: 0.95 spin–photon fidelity with parallelized entanglement demonstrated on a 5-atom Yb array at 1389 nm; 1000× linewidth narrowing and telecom-band emission for Er; improved resonator yield for transducers.
How: The co-design loop is the point — devices inform simulation, simulation guides architecture, architecture feeds back into hardware requirements — explicitly because the field's gap is between lab experiments and scalable architecture (no interoperable abstractions, no standard way to request entanglement, no common scalability metrics).
Where applicable: Research program, not deployable today — but the framing that quantum networking resembles early classical networking (manual setup, static config, platform-specific interfaces) and that scale requires architecture, abstraction, and operations is exactly the signal to watch.

Honeypots and beyond – LLMs in cyberdefence #

Abstract Slides (PDF) Slides (PDF)

Maciej Miłostan, Michał Ślusarczyk (PCSS)

Why: An unusual, operationally grounded intersection of LLMs and security: LLMs inside the honeypot, engaging attackers — and the new attack surface that creates.
What: Threat-intel collection from the GN5-2 honeynet (T-Pot based, with Kibana visualizations and sandboxing pipelines), plus the synergy of pairing honeypots with LLMs. Crucially, they instrument the failure modes: LangFuse monitoring tracks session abandonments caused by LLM failures (e.g. unrealistic interaction), and they compare robust, secure system prompts against poorly crafted ones that leak system details or allow instruction hijacking — showing prompt quality directly influences both detection accuracy and resistance to prompt injection.
How: LLM-driven interactive decoys produce richer attacker behavioral data than static honeypots, at the cost of becoming a prompt-injection surface themselves; the evaluation methodology (tracking abandonment, comparing prompt classes) is the transferable part.
Where applicable: Self-hosted LLM stacks in defensive security operations; findings are from a live NREN honeynet rather than a lab.

Instant Data Structures via Shared Memory #

Abstract Slides

Roman Janota (CESNET)

Why: A small systems idea with an outsized, verified result — and it generalizes well beyond network tooling.
What: The boot-up bottleneck of network management systems: every tool re-parses hundreds of device configuration files to build its structural map of the network, serially, on every start. CESNET's answer: parse once, share the result. The first program to start builds the data structure, publishes a handle ("link") to it in a shared-memory region; every subsequent program checks for an existing link and skips parsing entirely. Changes (e.g. a new node) are published by generating a new link to the changed structure and atomically replacing the old one, with consumers checking for a newer link on access — a copy-on-write publication pattern.
How: Plain shared memory plus handle indirection; no exotic infrastructure. Benchmarks show boot-up times up to 400×+ faster than re-parsing, with the gap so large the improved bars are barely visible on the charts.
Where applicable: General technique for any tool family that re-derives the same large, mostly-static data structure from source files at startup — network inventory, config linting, query engines. Linux-centric; the pattern is cheap to adopt.

Themes#

AI is moving from demo to production ops, with safety architecture as the differentiator: ESnet's ORBIT (prompts-as-code, human-in-the-loop), GÉANT's Saz (verifier-agent-over-planner-agent), Internet2/SURF's A2A agent federation, and RNP's no-data-scientist anomaly detection all share a stance: modest, auditable, incrementally-adopted AI that augments operators rather than replacing them.
The optical layer is becoming a multi-service, programmable substrate: coherent DSPs doing topology tomography, White Rabbit coexisting with 400G in the L-band, fiber sensing and T&F channels written into procurement requirements (Sikt), and a 498 km ±100 ps field trial — the physical plant is being asked to do sensing, timing, and data at once.
Kubernetes (and licensing shock) is reshaping NREN service platforms: RENATER's VMware→Talos/KubeVirt migration, nmaas multi-cluster edge orchestration, and RNP's Internal Developer Platform — with Broadcom's ESXi licensing changes explicitly cited as the trust-breaking trigger.
AI workloads are rewriting WAN requirements: ESnet7 planning 50–70% above historical growth trend, negotiable service guarantees for agentic/interactive science, traffic classification and congestion prediction as first-class network functions — the "AI WAN" problem arriving from the science side, not just hyperscaler DCs.
Federated, open, community-owned tooling as the response to scale: flow-collector benchmarking, HAWAT's federated Looking Glass, the Internet2/CAIDA BGP toolset and prefix registry, and open-source throughout (Churn, nmaas, CzechLight, Sunet Scribe) — collective infrastructure no single operator could justify building alone.
Sovereignty as an engineering constraint: terrestrial time as GNSS backup, national self-hosted AI services, dark-fiber/spectrum procurement strategy, and EU-backed submarine cables — trust and geopolitical redundancy are now design inputs, not afterthoughts.

About this digest

ToFaRev picked and wrote this digest on Nebius Token Factory, from the conference's published program. A person reviewed it in a pull request before it was published. Write-ups marked "from abstract only" had no fuller source to read. Source: digests/tnc-2026.md · prompt: prompts/tnc-2026.md