The extreme bandwidth demands of AI data centers are accelerating the development of new optics that are denser, more reliable, and more power efficient than the previous optics roadmap. This talk will cover the AI optics roadmaps across the scale-up, scale-out and scale-across spectrum, and the implications for next generation switches, routers and optical line systems.

TBU

Design-driven automation treats the design of a network — its topology, roles, relationships, and constraints — as an explicit model that exists independently of any device's running configuration. That model becomes the thing you reason about: the source of intent that configuration, validation, and change all refer back to.

This talk looks at what that means once you're operating a real network, not sketching one. We'll walk through the lifecycle: expressing intent as a design, turning it into configuration, and (the hard part) keeping the two in agreement as the network drifts, as tickets land, and as people make changes out-of-band. We'll dig into how drift is detected and interpreted, why reconciliation is harder than pushing config, and how a design model changes the way operators handle refactoring and unplanned change.

The same property that makes this work for humans, an explicit statement of intent to check reality against, is also what keeps the next wave of automation honest, whether that's a script or something smarter. We'll touch on that, but the focus stays on the mechanics operators live with today.

Throughout, we'll ground the concepts in real declarative provisioning systems, including open-source NetBox, using them as concrete examples of the patterns and trade-offs: where design-driven approaches pay off, and where they still struggle in production.

You'll leave with a clear mental model of design-driven automation, a realistic view of the reconciliation problem, and a sharper sense of where these approaches earn their place in day-to-day operations.

AI is already changing how networks are operated, how traffic is generated and where infrastructure is built. But for network operators, the real question is not whether AI matters. It is where the value will move. This panel looks at AI from three angles: as an operational tool, as a new driver of traffic and infrastructure, and as a potential threat to the traditional role of the operator.

This presentation describes the journey of achieving more than 1 Tbps throughput on a single x86 server by evolving a virtualized Broadband Network Gateway (vBNG). It walks through practical lessons learned while scaling from early multi-VM designs to a high-performance, single virtual machine capable of high packet rates. The talk covers the role of SR-IOV and Intel DPDK, extensive hardware tuning, deep code-level optimizations, and major redesigns driven by CPU cache behavior and PCIe bottlenecks. Real-world performance results highlight how systematic optimization, modern hardware, and iterative engineering can unlock massive throughput gains on commodity servers.

Every connection, routing decision, and network boundary relies on a finite set of identifiers: IPv4, IPv6, and ASNs. But how did a research experiment’s addressing scheme scale to support billions of global users? This presentation will show the remarkable journey of Internet Number Resources from the early, informal days over the creation of the Regional Internet Registry (RIR) system until recent commercial developments. We will explore the critical milestones that shaped internet governance, including the exhaustion of IPv4 space, the market-driven rise of IP transfers and leasing, and the ongoing transition to IPv6. Finally, we will look ahead at the modern challenges facing the registry ecosystem, focusing on data accuracy, transparency, and the evolving geopolitical pressures on internet infrastructure.

Fortinet Secure SD-WAN combined with ADVPN enables dynamic, scalable, and secure connectivity across distributed environments, including branch offices, data centers, and cloud. By leveraging on-demand shortcut tunnels and intelligent path selection, organizations can optimize traffic flows regardless of underlay transport.

This session demonstrates how template-based deployment and automation allow rapid rollout of hundreds of sites within hours rather than months, while maintaining consistent security and performance.

Today's networks are highly virtualized large distributed systems. With network observability we monitor holistically by incorporating all 3 network planes and their dependencies. For AIOps we require network data done right. Data taxonomy, schema and semantics being preserved and ready in real-time at the Data Mesh.

In this session I describe the relevance and differences between IPFIX, BMP and YANG-Push and its integration into Message Brokers for next generation Network Analytics applications and the differences between Data Lake and Data Mesh.

I demonstrate with a real-life Network Incident Postmortem how Network Anomaly Detection is applied at Swisscom and show how symptom ontology is derived, where Knowledge Graphs will help us to obtain a statistical view, and why we intend to automate the incident and problem process by leveraging AI capabilities.

Further, I will venture into the importance of network vendor, operator and academia collaboration in innovation and standards, and outline current innovation activities at the IETF NMOP working group.

Route-server looking glasses already provide valuable visibility into routing at Internet Exchange Points (IXPs). They typically collect data either by querying route-server software directly, as Alice Looking Glass does, or through dedicated BGP monitoring sessions. These tools help operators and participants inspect advertised prefixes, troubleshoot connectivity, and better understand route-server behavior.

In this presentation, we explore BMP as a complementary approach to monitoring BGP at IXPs. BMP can expose routes before and after policy application, including routes that are filtered or not selected as best paths, while also reporting peer and session state. BIRD and FRRouting can export BMP data when operating as route servers, although their current implementations have limitations and do not expose every standardized BMP view.

We then present the new bgproutes.io IXP Explorer. By combining BMP data from route servers with routing data contributed by IXP participants, it provides near-real-time and historical visibility into routes learned over both route-server and bilateral BGP sessions. The platform enriches these data with RPKI route-origin validation (ROV) and ASPA validation results. The data are openly accessible through the IXP Explorer dashboard and the bgproutes.io public API, enabling both interactive exploration and programmatic analysis.

IP engineers still view transceivers as plug & forget - something that just converts electrical to optical signal and vice versa. This talk provides a concise introduction to essential optical fundamentals for IP networking professionals, covering topics such as single-mode and multi-mode fiber and their structural and operational differences, common connector types and their usage, and a practical look at optical losses. In particular, it explains how attenuation accumulates across fibers, connectors, and splices, and how to perform optical link calculations and budgeting to ensure sufficient transmission margins. The talk also introduces wavelength-division multiplexing technologies, CWDM and DWDM, explaining their characteristics, channel spacing, use cases, and relevance in modern packet-optical networks. Each topic is illustrated with typical failure cases from transceiver support, such as single-mode optics on multi-mode fiber, contaminated MPO connectors, mismatched UPC and APC polish, and CWDM links limited by dispersion rather than attenuation.

Europe’s digital infrastructure evolves to meet growing demands for resilience and digital sovereignty, to ensure resources for AI, cloud computing, research, and secure international connectivity, the importance of geographically diverse network routes has never been more important. The Polar Connect Initiative is aiming to establish a resilient, high-capacity digital backbone through the Central Arctic Ocean, providing secure and sovereign connectivity between Europe, North America and East Asia, along the shortest viable route.
The Arctic may seem geographically distant from the Baltic region, however the Polar Connect submarine fibre cable route presents significant benefits for Northern Europe backbone network development. This new connectivity through the Arctic region positions the Nordic and Baltic countries as an international digital gateway between Europe and East Asia, creating additional opportunities for traffic exchange and interconnection, increase resilience for existing backbone networks, and support future growth opportunities for data centres, cloud services, and research infrastructure.
This presentation will provide an update on the latest progress of the Polar Connect Initiative, including pre-marine surveys from the latest mission of summer 2026, technical feasibility studies, and the level of international collaboration required to achieve this one-of-a kind project. The talk will also map how the initiative fits within the broader European strategy for digital resilience, the Cable Projects of European Interest (CPEI), and the Digital Global Gateway.
Rather than viewing Polar Connect as yet another submarine fibre cable, the presentation will focus on the opportunities for a new strategic layer of European digital infrastructure and what this means for operators, carriers, and infrastructure providers across the Baltic and Nordic region.

Many ISP use MPLS-TE auto-bandwidth to balance traffic in their network.

With transition to Segment Routing, there is a challenge of implementing a similar solution due to the stateless nature of SR.

The presentation describes challenges of auto-bandwidth implementation for SR and demonstrates a working prototype.

As AI platforms reshape global data, upend economies, disrupt workforces and challenges decades of the neutral, open Internet, a critical tension has emerged between the borderless nature of modern technology and the rising need for regional and sovereign data control. The Internet is dead! Long live the Internet!

This is a continued presentation around Artificial Intelligence (AI) from the BalticNOG 2025 where I covered the fundamental difference between AI for Networks and AI Networks - the intent of this talk is to cover more details around the challenges posed by AI workloads in data center infrastructure for TRAINING and INFERENCE, as these workloads pose some challenges around the data center infrastructure. This talk will cover fundamentals around how data is collected and structured/cleaned up for training usage as well as once the training is done how the model will be used for inference. It will look at data center design including AI Fabrics, scale-up vs. scale-out designs, challenges, and protocols used and provide some future guidelines around enhancements to such challenges under works within the UEC (Ultra Ethernet Consortium). UEC goal is to deliver a complete architecture that optimizes Ethernet for high performance AI and HPC networking, exceeding the performance of today’s specialized technologies.  UEC specifically focuses on functionality, performance, TCO, and developer and end-user friendliness, while minimizing changes to only those required and maintaining Ethernet interoperability

The network engineering and interconnection industry is facing a critical challenge: the decline of experienced engineers and a growing shortage of new talent. In this presentation, I will share our project aimed at making it easier for new entrants to find the right resources and streamline their career paths in interconnection and peering. Recognizing that we cannot tackle this alone, we are partnering with universities and industry experts to build a more accessible, structured, and collaborative learning ecosystem. Together, we can ensure that the next generation of engineers is equipped to carry forward the essential work of interconnection and peering.

A random friday evening during July. - A BGP update with our customer prefix, and a correct AS-path. But it's not coming from our network. - Then a few minutes later, it's gone.

40 minutes later, there it was again - only to quickly disappear.
Over and over again.

AI networking discussions often stop at the GPU cluster. But a single inference task may increasingly cross devices, agents, models, tools, data sources, networks and providers—turning one user interaction into a dynamic distributed execution graph.

This talk explores what that could mean for network architecture and interconnection. It examines how latency, compute availability, policy and state may influence where parts of a task execute, and why explaining performance becomes difficult across organisational boundaries.

It maps existing observability building blocks and introduces FOX, a deliberately exploratory model for exchanging selected, policy-controlled evidence. The talk concludes by connecting observability with security and resilience, including agentic amplification, inference exhaustion, hidden dependencies and stateful failover.

Running diversely connected DNS servers requires that the list of zones and zone contents are synchronized on all servers. There are many approaches to handle this challenge, and many of them use mechanisms outside DNS. Catalog Zones are a newish mechanism that aims to do it all in-band in DNS.

2 years with an AI engineer on shift: what it fixed, what it almost broke, and the rules we wrote afterwards

We run a managed NOC for ISPs, data center operators and hosting providers worldwide. About two years ago we noticed that our engineers were doing the same investigation on every shift and on every customer network, regardless of vendor or topology: interface state, optics, neighbor tables, routing adjacencies, prefix reachability, logs, then a manual correlation across four or five terminals before anyone could say what broke and who was affected. So we built an internal AI NetOps assistant that uses the same tools our engineers already use, runs them in parallel across the stack, correlates the output and hands the on-call engineer a root cause hypothesis with the evidence attached, together with an assessment of which services are affected.

This talk is the operational report after two years of running it inside a real NOC, not a product pitch and not a lab demo.

We will cover the trust ladder we enforced and why each step existed. The agent started with no CLI access at all, reading only from monitoring, logs, flow data, BGP telemetry and the source of truth. It was then allowed a whitelist of operational show commands. Only later, and only for a narrow set of actions, was it permitted to propose changes, each gated by explicit human approval and a recorded audit trail. We will be honest about where that ladder stalled and which rungs we deliberately never climbed.
We will then walk through the kind of production alerts every NOC sees in its NMS and show how the agent actually behaves on them: a BGP session that will not establish, an IGP topology change, an OSPF adjacency dropping, a Layer 2 circuit going down. These are real cases from networks we operate, with the agent's investigation shown step by step: which data it pulled, how it correlated it, what root cause it proposed, and how it assessed impact at the same time. Among the cases we have already presented: a BGP failure the agent traced to a malformed attribute list while confirming in parallel that redundant paths carried the traffic; an IGP link failure it reasoned about from BGP-LS data without polling a single router; an OSPF adjacency loss that came down to mismatched BFD timers; a PE-CE link failure where the system separated a transceiver fault from a fiber cut and mapped the affected services within minutes. The NOC keeps running, so the final selection will favor the most interesting cases we see between now and the conference. Across these workflows, median time from alert to identified root cause dropped from 22 minutes to under 4.

We will also cover the cases where it was wrong. Some of them are the kind of mistake any engineer would catch instantly and the model did not, and those are the most instructive, because each one turned into a rule, a data fix or a guardrail. We will close with the numbers across [N] production infrastructures of different types: [X] alerts processed, [Y] percent resolved without escalation, plus screenshots of real investigations so the audience can judge the output for themselves.

Kimwolf and Aisuru represent a new scale of volumetric DDoS aimed squarely at ISPs. Built on millions of compromised IoT devices, they capitalize on the idle bandwidth provisioned for residential customers, at a volume that crushes networks well beyond the intended target.

This talk looks at where these botnets came from, how they operate, and why the mitigation playbook most operators rely on struggles to keep up. We will discuss what failed, what helped, and what ultimately made the difference, from the perspective of a team that's been in the middle of the response.

Internet blocking is part of the operational reality of running an ISP in Italy.

What looks like a simple requirement becomes considerably more complex when it reaches the network. Blocking orders come from several authorities, for different purposes and through different procedures, while courts can impose additional restrictions.

There is no single system behind them. Yet an ISP has to identify what must be blocked, keep the information up to date and translate it into reliable network behaviour.

This talk looks at how we deal with this at Airbeam, where we have built a largely automated DNS-based approach to handle these obligations. I will also share some real cases that show what can happen when regulatory requirements meet day-to-day network operations.

Volumetric DDoS protection can run on a host that terminates TCP connections, on a router protecting downstream networks, or on a scrubbing node receiving redirected traffic.

These deployments differ in traffic visibility: a router-based filter may see mostly attack traffic or only client-to-server traffic. There are always-on, on-demand, and hybrid deployment models, and modern “hit-and-run” attacks challenge these architectures.

Despite the differences in network architecture, these volumetric DDoS filtering approaches share a lot of functionality, which can be implemented in Linux eBPF.

eBPF programs run at commodity Linux systems with capable yet standard network adapters. These programs run close to the network adapter driver and process traffic at 100+ Gbps on commodity servers.

In this talk, we:

1. consider open-source eBPF implementations of filters for TCP SYN, ACK and RST floods, DNS reflection and random UDP floods, ICMP floods

2. discuss how to mitigate attacks with spoofed source addresses

3. cover deployment safety and monitoring

4. evaluate performance of filtering eBPF programs running on an x86-64 server with 200Gps NIC.

For network operators, ISPs and Telcos in the Baltics, DDoS risk is changing - and the biggest attack is not necessarily the most dangerous one.
Drawing on 12 months of DDoS data observed across RETN’s network, this presentation challenges the industry’s continued focus on peak attack size as the primary measure of threat. A 24.9 Tbps attack observed in November 2025 was almost nine times larger than any other monthly peak in the dataset - yet its size alone tells us little about the potential impact on a network or its customers.
This talk touches on how smaller, distributed and deliberately low-volume attacks can be more disruptive than record-breaking floods. Carpet-bombing, precision attacks and evolving attack techniques can target multiple prefixes, place pressure on network infrastructure or evade traditional detection thresholds without producing headline-grabbing traffic volumes.
For Baltic operators, the challenge is knowing what to look for and how to prepare. Andrejs will examine how the threat is evolving around the region, including risks from compromised network equipment and distributed attack sources, and why operators need to look beyond bandwidth - measuring detection speed, affected targets, root-cause clarity and the time it takes to understand and contain an attack.

Inside the very "center" of the internet is a set of networks run by companies who have a special arrangement with each other that the rest of us do not have, These are sometimes called the "tier ones" or "transit free networks"

However, are all of these "transit free networks" actually free of transit, and what does that actually mean?

In this talk will go over some of the bgp.tools data that I have been analysing that will show have some of the T1 peering issues, where gaps exist, and how certain networks are getting closer to becoming a them, and what are the problems they will probably face, and finally does a network even want to be in this situation