Segment Routing has crossed the chasm – “Early Adopters” have already embraced it, and now the “Early Majority” is adopting it. Interestingly, at the very same time the industry is surfing the Segment Routing MPLS wave, the next wave is already coming in and will even be more disruptive to the way you design and engineer your network infrastructure – this is the Segment Routing IPv6 (SRv6) wave.
Segment Routing has been designed from the ground up to work in a native IPv6 environment. The core capabilities available with SR MPLS – such as 50ms protection (TI-LFA), Traffic Engineering with SLAs (e.g. low latency, disjointedness, etc.) – are de facto available with SRv6.
But it does not stop here – SRv6 opens the door to an entirely new paradigm: “Network Programming.”
The purpose of this blog is not to dive into the nitty gritty details of how that works, but rather to give you a sense of what’s possible when you construct a network infrastructure that has embedded programming capabilities.
IPv6 packet headers were designed with IPv6 Extension Headers. It did not seem like a big deal initially, but one can quickly realize these extensions can make a huge difference.
SRv6 is actually taking advantage of these Extension Headers by inserting Segment Routing Headers into IPv6 packets. So, every IPv6 packet is now augmented with a list of Segment Identifiers (Segment IDs), that are nothing else than 128-bits IPv6 addresses.
Well, so far, you may think it looks pretty similar to SR MPLS, as in both cases you have a list of Segment IDs used to direct traffic over a specific path through the network. True to the exception of the Segment ID size – 128-bits for SRv6 compared to 32-bits for SR MPLS.
That increase in size is actually changing the whole paradigm! With 128 bits, 4 times 32 bits, you can pack more than mere IP addresses into a Segment ID and hence go beyond routing purposes.
These 128-bits Segment IDs can be used and allocated for different purposes. Let me give you an example here:
- The first 64 bits can be used to direct traffic to a specific node in the network – the “main body” of the program
- The next 32 bits can be used to enforce some actions on the traffic – the “function” part
- The remaining 32 bits can be used to pass some additional information – the “argument” part
For those having any kind of past programming experience, you can easily understand where we are heading here.
SRv6 necessitates a mindset shift as SRv6 makes your applications and your network interact in a completely different, new way. It’s no longer about merely routing traffic from point A to point B – SR MPLS had already operated a shift there, as it was bringing the capability to route traffic from point A to point B according to some specific constraints expressed by applications (e.g. SR Traffic Engineering). SRv6 goes one step further by enabling the infrastructure to perform some actions on the applications.
With SRv6, we provide you with a toolkit to program your network infrastructure in a way that was not possible before. Use cases, enabled by this network programming paradigm, are numerous and are still to be fleshed out.
“With the concept of network programming and SRv6, we are now able to take our network to the next level of simplification while adding richer embedded capabilities. Through its extensibility and host stack integration, it provides service and content providers the ability to create true application oriented network behaviors within and across network domain boundaries.” said Daniel Bernier, Senior Technical Architect, Bell Canada.
In March 2017, an “SRv6 Network Programming” draft was published at the IETF, rallying around some major service providers. At the very same time, early hardware implementations can be demonstrated. To see more about that, watch this demo on SRv6 VPN and Traffic-Engineering (TE).
We are leading the pack by working closely with some lead operators and by focusing our efforts on use cases that bring significant and timely benefits to our customers.