Mathias Handsche; Talk
Since 18 August 2026, a prosecutor in another EU country can demand your users' data directly from you — ten days to comply, eight hours if they're in a hurry. No mutual legal assistance, no local court in between: just an order in your inbox and a clock. This talk is the E-Evidence Regulation for the people who actually run the infrastructure: which data you can be forced to produce, how fast, and whether the systems you already operate could even answer in time. A few months in, we'll look at what's working, what's on fire, and what you should have built before the first order arrives.
Falk Bachmann; Talk
This talk examines latency as an end-to-end property of enterprise networks, not just a wireless problem. While wireless networks often receive the most attention, the actual user experience is shaped by the interaction between radio conditions, roaming, access layer design, switching behavior, QoS handling, and overall WAN & LAN architecture.
Using Wi-Fi 7 as a current reference point, the session shows why bandwidth alone is not a meaningful success metric and why latency, jitter, and responsiveness must be evaluated across the full network path. The goal is to provide network operators and engineers with a practical lens for understanding where user experience breaks down — and how to design networks that behave well under real operational conditions.
Mario Jurcevic; Talk
Modern telco operators increasingly require continuous active performance monitoring across thousands or even tens of thousands of access nodes. While TWAMP has become the de facto standard for active IP performance measurements, implementing it at carrier scale is far from trivial.
This presentation explains how a carrier-scale TWAMP monitoring platform can be built using commodity x86 servers together with DPDK-based userspace packet processing that completely bypasses the Linux networking stack.
The talk discusses the architectural decisions required to support massive numbers of concurrent TWAMP sessions, including packet processing, session scheduling, timer management, CPU affinity, NUMA awareness and resource optimization.
Real benchmark results and operational experience from large-scale deployments demonstrate the achievable scalability and identify the practical limitations of this approach.
Attendees will gain practical insight into designing highly scalable active monitoring systems without relying on proprietary hardware appliances.
Thomas Weible, Dr. Gerhard Stein; Talk
As network architectures transition towards open, disaggregated hardware, Open Source Switch Operating Systems (like SONiC) have unlocked unprecedented access to hardware telemetry. Concurrently modern transceivers offer advanced Vendor Digital Monitoring (VDM) capabilities that go far beyond classic Digital Diagnostic Monitoring (DDM). However the industry still struggles to utilize this data for proactive operations.
This presentation demonstrates how to leverage open VDM interfaces within Open Source Switch OS architectures to establish a continuous, high-frequency telemetry pipeline. By analyzing realtime physical layer metrics - such as pre-FEC bit error rates, laser bias current shifts and optical signal degradation - we showcase how to move from reactive troubleshooting to predictive maintenance. Attendees will learn how open software paradigms enable operators to detect impending Layer 1 failures before packet loss occurs ensuring maximum network uptime without vendor lock-in.
Robin Christ; Talk
EVPN is everywhere, be it datacenter, service provider or campus - and every vendor says you need it. But EVPN rightfully has a reputation problem. It is rarely truly understood, even by vendors themselves, and often treated as a black box. The RFCs read like tax law, and the quality of vendor documentation doesn’t help either.
This talk aims to be nothing less than a gentle introduction and a deep dive into EVPN at the same time.
We‘ll explore the abstract concepts and frequently misused terminology in order to build an intuitive mental model.
We will also look into the often overlooked origins of EVPN, which explain many of its design decisions and behaviours.
Finally, we’ll take a look at tricky mechanisms like Anycast Gateways and Multihoming, so your next EVPN debugging session doesn’t become another unplanned nightshift.
Patrick Prangl; Talk
Modern service provider networks are evolving rapidly: transports like VXLAN, MPLS, Segment Routing and SRv6 are being used while many legacy control plane protocols are still in operation. This often results in unnecessary complexity, multiple signalling mechanisms and operational overhead.
In this talk, I’ll explore how BGP EVPN has evolved into a transport-agnostic control plane capable of unifying services across MPLS, VXLAN, SR, and SRv6. The goal is simple: move away from fragmented legacy protocols and toward a single, scalable control plane for L2 and L3 services.
We’ll look at recent EVPN innovations and discuss how service providers can benefit from simplifying their architectures while preparing their networks for future transport technologies.
Dominik Bay; Talk
KML, KMZ, DXF - hat wahrscheinlich schon jede:r mal in der Hand gehabt, nach dem man redundante Leitungen bestellt hat. Aber was macht man eigentlich sinnvolles damit?
KML, KMZ, DXF - everyone knows or used those file formats, at least after asking the carrier where the redundant circuits are. But is there anything useful you can do with those files?
Gabor Adam, Holger Thösink, Adam Orosz; Talk
Physical points of presence (PoPs) are expensive to deploy and often limit how quickly service providers can respond to customer demand in new regions. To address this challenge, Deutsche Telekom developed a virtual PoP architecture that extends carrier-grade MPLS L3VPN services into AWS.
This talk presents the technical architecture behind the solution, including AWS Direct Connect Gateway, Cisco 8000v virtual routers, MP-BGP, and VPNv4/VPNv6 integration. We explain the design decisions, operational considerations, and routing principles that enabled the realization of a cloud-based PoP.
Attendees will learn how cloud infrastructure can be integrated into a traditional service provider network while maintaining routing control, operational standards, and rapid service deployment.
Tobias Fiebig; Talk
Routing IPv4 packets using IPv6 next-hops has been around for some time now. It offers great opportunities to reduce IPv4 address usage in the distribution and access layer, and enables providing IPv4 as a pure add-on, keeping a clean IPv6 address structure underneath.
Despite its benefits, major challenges for deploying IPv4-with-IPv6 next-hops in practice persist. While, e.g., BGP supports such routes using RFC8950, many other IGPs still lack support. Other major issues are 'the last mile', i.e., auto-configuring clients (or, for this use-case, more likely servers), and the impact of IPv4-with-IPv6 next-hop usage on traceroutes.
In this talk, we will go over some current developments in these areas, which should make IPv4-with-IPv6 next-hops a viable option for practical deployments in the coming years. We will also expand further on possible deployment scenarios, where IPv4-with-IPv6 next-hops can remove further legacy Layer-2 infrastructure, e.g., LACP.
sinuscosinustan; Talk
Every server depends on firmware to boot and most also rely on firmware for remote management. U-Boot, EDK2 (UEFI), OpenBMC, you name it. And they all share the same issue: IPv6 support ranges from half-baked to non-existent. Why is this still the case in 2026?
In this talk I'll go into two areas of server firmware that operatores rarely look at closely: the one that boots the server, and the one that allows out-of-band management via the Baseboard Management Controller (BMC).
On the boot side: Do PXE and HTTP boot actually work over IPv6? And what unexpected side effects do you might see?
On the management side: How does IPv6 support look on a BMC today, and what's still broken?
Nobody's going to fix what nobody complains about. Let's find out how broken this is and what we can do about it.
Remco van Mook; Talk
What actually changes in your network when you stop treating IPv4 as infrastructure and start treating it as a service?
draft-vanmook-intarea-ipv6-resolved-gateway (presented at IETF 126, WG adoption call pending) defines a single sentinel gateway address, provisionally 192.0.0.11 (requested from the IANA Special-Purpose Registry, not yet assigned), handed out as the ordinary DHCPv4 default gateway. Updated hosts resolve their first hop from the IPv6 neighbour cache; unmodified hosts ARP for the sentinel once and the router answers. That's the whole mechanism. Everything downstream of it is the interesting part.
This talk is about what that does to a running network: no IPv4 subnets anywhere, no ARP, no FHRP, IPv4 address pools that go flat — any /32 works anywhere in the footprint, nothing stranded by subnet sizing. The core forwards v4-via-v6 (RFC 8950) with no IPv4 configured on any router interface.
On the implementation side: host implementations for Linux (userspace daemon and native systemd-networkd), FreeBSD, macOS and Windows, with prebuilt packages; a namespace conformance lab with a zero-ARP assertion; verified unmodified-host behaviour across seven operating systems; and vendor configuration examples for IOS XR, JunOS, SR OS, EOS and RouterOS. On the router side, three working deployment models: a single-gateway reference, an active/active anycast VRRP pair, and a BGP-orchestrated multi-gateway fabric — fungible gateways, host /32s injected from inventory, and the entire DHCPv4 path carried as IPv4 values over IPv6 next-hops, with no IPv4 management network at all.
Plus the failure modes, the ND health prerequisites, and what breaks when you get it wrong.
No tunnels. No translation. No flag day. Keep the shape, change what it means.
James Rice; Talk
Internet exchanges have presented as shared layer 2 networks for thirty years. I will show the mechanisms that silently blackhole exchange traffic or forward it to the wrong port: missing or incorrect neighbour entries, and unknown unicast flooding. In each case BGP stays established to the route servers and nothing reports a fault.
A large exchange stated in writing that it gives no guarantee traffic sent to a peering LAN goes to, and only to, the port of the network it was meant for, and that it knows of no exchange that does. I do not know how many members expect that answer.
The rest of the industry has spent years dismantling large layer 2 domains in favour of routed ones. Perhaps it is time for internet exchanges to forward at layer 3, rather than running a layer 2 forwarding domain with a route server making routing decisions.
In many cases this needs no new hardware. The switches already used to build exchange fabrics forward at layer 2 and at layer 3 at line rate. Route scale is where careful consideration is needed.
The shape of a layer 3 internet exchange switch is already commonplace: each PNI switch a CDN or ISP operates is a routed exchange with several settlement-free peers and one customer on it.
Running at layer 3 gives participants complete isolation between ports, the same model that already applies to every other upstream connection that networks buy. RTBH works at the exchange rather than depending on a peer to honour it. Debugging becomes possible from the participant side, because traceroute shows the exchange hop.
Jennifer Graul; Talk
Existing automation solutions are usually monolithic and require you to migrate all of your existing infrastructure at once to the automation. I wanted to introduce automation step by step and wanted to continue to use our existing sources of truth. So I have built a modular automation solution that allows us to build a completely separated automation module for everything we want to automate in our network.
Veit Heller, Marcus Stoegbauer; Talk
In the last two decades network automation has gone from a fringe concept reserved for global players to the industry standard at almost every system size. The tooling and concepts have evolved and grown, and an ecosystem has formed and normalized around a few core systems.
In this talk, we want to propose a natural next step in the evolution from manual work over templating to driving the system with sources of truth. As the technological and business complexity of networks grows, the data model becomes more and more of a focal point of how we look at the reality of our system. We need to understand our data and our models better than ever before, and make our decisions based on how we model the world, without being constrained by the limits of our pre-fabricated documentation systems.
We will speak about what it means for an automation to be driven by your actual data model and how you conceptualize the network, motivated by an actual software system. Over the course of the talk, we will not just talk about concepts, but anchor our ideas in concrete implementation.
Nonetheless, this is not a talk about a solution. It’s a talk about an idea and an approach, and, hopefully, the start of a conversation.
Lara Hallaczek; Talk
Securing our Infrastructure against Cryptoanalysis with Quantum Computers
This talk gives an overview of the topic of post quantum cryptography. It explains the problem these algorithms try to solve, shows underlying mechanisms and takes a look at developments of the past few years. The presentation is intended as a summary of the of the topic from a network engineer's point of view: what's going to be on our schedules in the not too distant future? Which solutions are already available, which topics are still under discussion, and what will be required from our infrastructure by industry standards and regulatory bodies?
Maria Matejka; Talk
Configuring a router via text CLI and configuration file editing is not very 2026. In BIRD, we are trying to catch the departing train and implement a CORECONF variant of an IETF-standardized YANG-based API. We've created a prototype but getting things right is harder than it seems. This is a report on what has already gone wrong and what is expected to fail in the future.
Fedor Vompe, Sebastian Becker; Talk
BGP routing security relies on many technologies, both old and new, such as IRR-based Route Filters and RPKI Technologies like Route Origin Authorizations (ROAs) or Autonomous System Provider Authorization (ASPA-s). While these technologies are well-known, they are still used together, and accurate route filter generation remains a challenging task with significant operational implications for large-scale router filter generation at major tier-1 ISPs.
We show that AS-Set documentation in RIR databases is still critical yet systematically overlooked. We evaluate the scope and patterns of these issues - including missing documentation, AS-Set explosive expansion, and cyclic dependencies - demonstrating that accurate AS-Set documentation remains a foundational requirement for operational filtering.
We present the toolchain and technologies like Route Query Specification (RQSpec) we use for route filter generation at scale, compensating for the complexity introduced by poor documentation.
Enric Pujol, Sebastian; Talk
Network operators share a vocabulary built on VRFs, EVPN-VXLAN, and BGP underlays. What doesn't travel is how it gets written down. Every vendor and orchestrator has its own dialect, and most automation tools still push device-specific config from an orchestrator down to all involved devices. Translation, not domain-specific problems, becomes a bottleneck.
We build Wire-API with a different model in mind: Instead of targeting devices, operators declare the state they want and controllers work out which devices are affected and what config to push. In the case of an EVPN fabric for example: describe it with objects like Network, RoutingDomain, and ExternalConnection, and adding a network becomes one object rather than a coordinated change across every leaf and firewall that participates. The shift is in what gets declared: desired state instead of a device's running config. From there, drift correction and HA-aware maintenance stop being separate runbooks and become properties of the reconcile loop, and the same model extends to anything else on the network expressed as intent.
The core is Kubernetes. Wire-API is a set of CRDs and controllers that reuse the contract that made Kubernetes work in "compute"—declared state, continuous reconciliation, honest status—and apply it to the network domain.
The presentation argues for the Wire-API model and walks through a live EVPN-VXLAN example—one intent object, vendor-specific config on Cisco NX-OS and Nokia SR Linux—then covers design decisions and partial-failure handling. Wire-API already operates production fabrics across multiple availability zones; the model works today even as the framework continues to grow.
Wire-API is Apache-2.0 and is being contributed to the NeoNephos Foundation (Linux Foundation Europe) as part of the ApeiroRA workstream under the EU IPCEI-CIS program.
Jan Zorz; Talk
Anycast is easy to explain and notoriously difficult to observe. Announce the same IP address from multiple locations, allow BGP to choose a path, and traffic should reach the "nearest" instance, although BGP's idea of nearest often has little to do with geography.
ProVision (formerly 6connect) operates an anycast DNS platform spanning six prefixes, 39 BGP nodes, 13 regions, and five continents. For years, we knew the platform worked because queries were answered. What we could not prove was how it worked: which users reached which nodes, how quickly packets arrived, and where traffic quietly disappeared.
This presentation tells the story of how we turned one of anycast's most frustrating behaviors-ICMP replies returning to the "wrong" node-into a measurement. That insight grew into an automated pipeline running 117,000 probes per second across 2.6 million targets, measuring latency, loss, jitter, routing behavior, path MTU failures, ECMP paths, and visibility at 845 Internet Exchanges.
It is also the story of how two network engineers who are not full-time developers built the system through intensive collaboration with AI coding models. AI supplied much of the implementation capacity; the humans supplied decades of network intuition, architectural direction, validation, and the authority to say when the code was confidently wrong.
Tobias Heister; Talk
We are all well aware of BGP as our protocol to run the Internet. As we sometimes notice (e.g. in the Talk by Wolfgang Tremmel at DENOG17) BGP still has ties to its predecessor EGP and can still claim it learned things from that protocol (Sometimes for nefarious reasons).
Follow me on a journey to find out what we need to do in order to still run the EGP Protocol in 2026. How far back in time do we need to go in order to legitimately put the E into the Origin of BGP updates?
Why? Because We do what we must because we can!