# SDN Published articles for SDN. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Worth Reading: AI Enthusiasts Against AI Skeptics DevFeed: [Worth Reading: AI Enthusiasts Against AI Skeptics]() Original publisher: [Read original article]() Published: 2026-06-22T06:25:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Artificial Intelligence](), [Vibe coding](), [Software-defined networking](), [Ansible]() Tags: [ai](), [ansible](), [article](), [sdn](), [vibe-coding](), [worth-reading]() ### AI overview A recommendation of Charity Majors's article contrasting AI enthusiasts, who are racing against time, with AI skeptics, who are racing against entropy. It also cautions against exaggerated claims about vibe coding and other technologies such as OpenFlow, SDN, OpenDaylight, and Ansible. ### Source excerpt Charity Majors wrote an excellent article describing AI enthusiasts in a race against time and AI skeptics in a race against entropy. Fair warning: its very first sentence triggered an acute case of PTSD: I recently attended a talk where one of the presenters made some pretty...astonishing claims about what they had achieved by the pure, uncut power of vibe coding. I've seen way too many presentations making "astonishing claims" about the unlimited unicorn-driven powers of OpenFlow, SDN, OpenDaylight, or Ansible. Read more ... ## SwiNOG 40: Application-Based Source Routing with SRv6 DevFeed: [SwiNOG 40: Application-Based Source Routing with SRv6]() Original publisher: [Read original article]() Published: 2025-08-27T06:28:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [SRv6](), [networking](), [eBPF](), [Routing (disambiguation)]() Tags: [ebpf](), [network](), [networking](), [routing](), [sdn](), [srv6]() ### AI overview This commentary examines an application-based traffic-steering design that uses SRv6, an intent-based system, and eBPF on client hosts to add per-application SRv6 headers. It highlights potentially better scalability than RSVP-based traffic engineering because the design avoids host-to-network signaling, periodic path refreshes, and extra network state, while noting unresolved path-liveness and failure-recovery concerns. ### Source excerpt The we should give different applications different paths across the network idea never dies (even though in many places the residential Internet gives you enough bandwidth to watch 4K videos), and the Leveraging Intent-Based Networking and SRv6 for Dynamic End-to-End Traffic Steering (video) by Severin Dellsperger was an interesting new riff on that ancient grail hunt. Their solution uses SRv6 for traffic steering1, an Intent-Based System2 that figures out paths across the network, and eBPF on client hosts3 to add per-application SRv6 headers to outgoing traffic. Read more ... ## Finding Source Routing Paths DevFeed: [Finding Source Routing Paths]() Original publisher: [Read original article]() Published: 2025-06-13T06:10:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Software-defined networking](), [Network architectures](), [IS-IS]() Tags: [is-is](), [management](), [network](), [networking](), [networking-fundamentals](), [ospf](), [protocol](), [routing](), [sdn](), [software]() ### AI overview This tutorial explains how source-routing paths are determined and installed across networks. It examines centralized controller-based routing, SDN and OpenFlow, and segment routing with Path Computation Elements, then compares these approaches with older virtual-circuit provisioning systems. ### Source excerpt In the previous blog post, we discussed the generic steps that network devices (or a centralized controller) must take to discover paths across a network. Today, we'll see how these principles are applied in source routing, one of the three main ways to move packets across a network. Brief recap: In source routing, the sender has to specify the (loose or strict) path a packet should take across the network. The sender thus needs a mechanism to determine that path, and as always, there are numerous solutions to this challenge. We'll explore a few of them, using the sample topology shown in the following diagram. Read more ... ## Traffic steering into label-switched paths (LSPs) DevFeed: [Traffic steering into label-switched paths (LSPs)]() Original publisher: [Read original article]() Published: 2025-03-10T07:12:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [SR-MPLS](), [MPLS-TE](), [Software-defined networking](), [Network](), [NETCONF]() Tags: [mpls](), [mpls-te](), [netconf](), [network](), [sdn](), [traffic-engineering](), [worth-reading]() ### AI overview The article discusses steering network traffic into label-switched paths (LSPs) built with SR-MPLS, MPLS-TE, or an SDN controller. It explains that installing LSPs is only part of the task; network devices must also be configured to use them. ### Source excerpt You can use SR-MPLS, MPLS-TE, or an SDN controller to build virtual circuits (label-switched paths) across the network core. The controller can push the LSPs into network devices with PCEP, BGP-LU, or some sort of NETCONF/RESTCONF trickery. Unfortunately, you're only half done once you have installed the LSPs. You still have to persuade the network devices to use them. Welcome to the confusing world of traffic steering explored in the Loopback as a Service blog post by Dmytro Shypovalov. Read more ... ## Using an SDN Controller for RSVP-TE DevFeed: [Using an SDN Controller for RSVP-TE]() Original publisher: [Read original article]() Published: 2025-02-20T07:14:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Software-defined networking](), [SR-MPLS]() Tags: [article](), [mpls](), [mpls-te](), [sdn](), [sr-mpls](), [worth-reading]() ### AI overview A recommendation for an article about using an SDN controller with RSVP-TE. It discusses why RSVP-TE may still be preferred over SR-MPLS, the role of an SDN controller, and RSVP/SR coexistence and interworking. ### Source excerpt Dmytro Shypovalov published another article well worth reading: why should you use an SDN controller for RSVP-TE. It covers: The reasons people might still prefer RSVP-TE over SR-MPLS and the current state of RSVP-TE What an SDN controller might bring to the RSVP-TE world SR/RSVP coexistence and interworking Have fun! ## Happy Holidays and All the Best in 2025! DevFeed: [Happy Holidays and All the Best in 2025!]() Original publisher: [Read original article]() Published: 2024-12-16T07:21:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Software-defined networking](), [Artificial Intelligence]() Tags: [2025](), [ai](), [networking](), [sdn](), [worth-reading]() ### AI overview A year-end note announces the author's retreat until mid-January, wishes readers well in 2025, and mentions upcoming netlab features. It also comments that AI is unlikely to make networking engineers obsolete, citing SDN as a comparison. ### Source excerpt Another year is almost gone, and it's time for my traditional "I will disappear until mid-January" retreat (also, don't expect me to read my email until I'm back). I hope you'll also be able to disconnect from the crazy pace of the networking world, forget the "AI will make networking engineers obsolete" shenanigans (hint: SDN did not), and focus on your loved ones. I would also like to wish you all the best in 2025! Read more ... ## NOG.HR: A NOG Meeting Worth Attending DevFeed: [NOG.HR: A NOG Meeting Worth Attending]() Original publisher: [Read original article]() Published: 2024-10-21T05:34:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Network](), [Software-defined networking](), [GitHub]() Tags: [github](), [network](), [networking](), [sdn]() ### AI overview A personal account of the Croatian NOG.HR meeting, describing its size, organization, presentations, and discussions following a netlab presentation. Ideas raised included an SDN lab with Open vSwitch, link impairment, remote GitHub repository support, and OPNsense support. ### Source excerpt I never know what to expect when I'm invited to speak at a regional (or in-country) Network Operator Group (NOG) meeting. Sometimes, it turns out to be a large conference (PLNOG and ITNOG come to mind); other times, it's just a few people gathered around free donuts and coffee1. Last week's Croatian NOG (NOG.HR) meeting was in the Goldilocks zone between the extremes: plenty of interested networking engineers, but not large enough to be overpowering. Also, it was such a nice experience ;) Read more ... ## Kubernetes vs. Virtualization for Cloud-Native Operations on Bare-Metal Servers DevFeed: [Kubernetes vs. Virtualization for Cloud-Native Operations on Bare-Metal Servers]() Original publisher: [Read original article]() Author: ev@goteleport.com (Ev Kontsevoy) Published: 2019-05-22T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [Kubernetes](), [virtualization](), [Cloud Native Ecosystem](), [Software-defined networking](), [networking](), [Server]() Tags: [backup](), [cloud-native](), [disaster-recovery](), [k8s](), [kubernetes](), [network](), [networking](), [sdn](), [storage](), [virtualization]() ### AI overview This final article in a three-part series compares Kubernetes with virtualization for operating a self-managed, bare-metal cluster. It explains that containers can improve workload consolidation, while virtualization can provide broader cloud-like capabilities through virtual networks, storage, and load balancers. ### Source excerpt In the final chapter of this series, we look at why Kubernetes is a better choice than virtualization to enable a more "cloudy" mode of operations on your new cluster. ## Networking for a Bare-Metal Kubernetes Cluster After AWS DevFeed: [Networking for a Bare-Metal Kubernetes Cluster After AWS]() Original publisher: [Read original article]() Author: ev@goteleport.com (Ev Kontsevoy) Published: 2019-05-14T15:39:34Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Kubernetes](), [networking](), [Amazon Web Services](), [cloud-infrastructure](), [Containers](), [Software-defined networking]() Tags: [aws](), [bare-metal](), [hardware](), [ip](), [k8s](), [kubernetes](), [lan](), [networking](), [router](), [sdn]() ### AI overview This article explains how to design a simple, non-redundant network for a small bare-metal Kubernetes environment in a colocation facility after leaving AWS. It discusses network complexity, legacy limitations, SDN concepts, public subnet routing, and separate private LANs for management, security, and performance. ### Source excerpt This is part three of a three-part series on considerations that companies will want to address if they decide to build their own cloud environment.