SwiNOG 40: Application-Based Source Routing with SRv6
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 grailhunt.
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.
Does this make sense? It might in some niche scenarios. It’s also one of the first use cases I encountered where I said, “Well, maybe it does make sense to use SRv6 here, assuming the problem is worth solving.”
This solution has a clear advantage over RSVP-based TE – it scales infinitely better because there is no host-to-network signalling (all the magic happens in the Intent-Based System), no periodic path refreshments, and no extra state in the network.
Drawbacks? The obvious one is the path liveliness problem, going all the way back to Token Ring Source Route Bridging sometime in the previous millennium. The path an application is using might become unavailable4, but as nobody knows the application is using the path (because there is no host-to-network signalling), nobody is telling the application to start using another path. In principle, the Intent-Based System could use something like HTTP/2 Server Push to tell the hosts to change their application paths. In practice, I’d like to see how well that scales and how quickly it reacts to network failures in a large-scale environment.
-
Remember: SRv6 is mostly remarketed source routing ↩︎
-
Sounds so much better than an SDN controller, right? ↩︎
-
Everything is better with
BluetootheBPF ↩︎ -
And the usual rerouting doesn’t help because the application is using a fixed path across the network. In some cases, that fixed path might result in interestingly circuitous traffic flows; the proof is left as an exercise for the reader. ↩︎
Hello Ivan. IBN is different from SDN. While SDN encompasses a lot of acronyms and ideas about network management that revolve around a centralized and software-based controller, IBN is simply about building a system that allows network operators/engineers and other systems to express requirements in a declarative and desired-state way rather than in an imperative way. I think they are very different ideas, although SDN systems can use IBN e.g. as a paradigm for their north-bound interface.
Regarding source-based traffic steering and associated signaling, I agree that an application listing desired nodes/segments to traverse seems impractical. However, combining Segment Routing (either using MPLS or IPv6) and "flexible algorithm" (rfc9350) seems more realitsic: 1/ IGPs implement multiple topologies based on different metrics (link delay, number of hops, etc.), using new TLVs in a distributed way, 2/ network engineers associate numbering rules associated with these different metrics, 3/ applications use these numbering rules to indicate their requirements. These are quite new technologies so I cannot reference any real-world large scale end-to-end and time-tested implementation, but that's the idea :-)
Peace
PS: I did not watch the video, only went through the slides.