Making IP networks self-sufficient
01/07/2024
Written by Pablo Camarillo, Making IPv6 networks self-sufficient
IP is at the heart of our lives. Every time we use the mobile phone, it’s on an IP network. Every time we send an email is through an IP network. When we stream a movie is over an IP network. When we control our smart home appliances it’s over an IP network.
Interestingly enough, we have accepted the fact that IP cannot deliver any form of service by itself, and it needs additional hacks to solve its limitations. For example, whenever there is a need to deliver Traffic Engineering, we need to rely on MPLS. Similarly, IP doesn’t provide any native VPN mechanism. This has been solved with VXLAN, GRE, or any of the plethora of VPN tunneling protocols. This is also the case with NSH for Service Chaining or GTP for mobile networks.
Today on each single domain you have a limitation and a shim-protocol to solve that specific limitation. But the picture gets even more complex: when we need to have a policy that goes through several domains, these shim layers are not compatible in between them, and we need to deploy gateways at domain boundaries to translate between protocols. This is often the case for policies starting at the DC (i.e., VxLAN) that need to traverse the metro (i.e., MPLS). We always need to deploy a gateway in between both domains to perform protocol translation.
Almost 10 years ago a group of passionate network engineers embarked on a journey to simplify networks by bringing back IP, in a self-sufficient manner, and removing all the unnecessary shim-layers that the industry has heavily relied on. This is what led to the inception of SRv6 uSID, with the intention to make IPv6 self-sufficient. It is based on three pillars:
- End-to-end: The ability to have a single policy across domains, all the way from the host up to the cloud through the access, core, and metro. This is tremendously beneficial, as it allows to remove the gateways that are placed at domain boundaries. Such gateways perform DPI and protocol conversion functionality, and hence are a bottleneck in terms of scale and reliability, aside from the huge cost they represent. In addition to the removal of this gateways, this end-to-end principle also aids bringing control of the policy closer to the application, the socket, that is the one who knows what is the intent that is required for the traffic.
- Any service, with no shim layers: you can build any form of traffic engineering, fast-reroute, VPNs, slicing, service chaining, or any other service natively without any shim layer. Any additional protocol only adds operational complexity and additional cost, and hence we seek simplification.
- Scalable, reliable, and seamless deployment: uSID has been built on top of the most fundamental building block, IP Longest Prefix Match. We hide the network program behind this 30-year-old principle of IP. This provides the seamless deployment behavior allowing to encode a uSID network program amongst legacy IPv6 nodes. In addition, it provides better routing scale. As reported by Bell Canada, SRv6 uSID provides at least 500 times better routing scale than MPLS thanks to IP Summarization, allowing to have more nodes on each domain.
But the solution is not limited to building anything. In addition, the solution must also deliver embedded assurance. It is not a secret that network assurance is of paramount importance, and we are shifting into a customer experience-oriented era, were networks need to be SLA-obsessed. That is why the solution also has a second pillar, that is IP Measurements. It delivers embedded assurance, right into the IP nodes, by generating the probe natively from the hardware. It ensures that all ECMP paths are measured, and the measurements are aggregated and reported using rich metrics unlike the industry defacto standard of min, max, avg which fall very short from a statistical point of view. IP Measurements will be covered in a subsequent blog.
Outperforming on a per-domain basis
In engineering, a common paradox is that solutions designed for multiple segments are often outperformed by custom solutions tailored to specific segments. For instance, if we look at vehicles, a SUV is designed to handle a wide range of driving conditions. However, a high-performance sports car will outperform it on paved roads in terms of speed and handling, while a dedicated off-road vehicle will handle rough terrains much better than a SUV. However, this paradox is challenged by SRv6 uSID. Network operators have demonstrated that SRv6 uSID not only matches but surpasses customs solutions in their respective segments.
(Free access, no subscription required)
Bell Canada, for instance, migrated from SR-MPLS to SRv6 uSID in their Metro network. They realized significant economic benefits by eliminating MPLS, simplifying their network by avoiding the complexity of RFC 3107, and increasing routing scale through IP summarization. During MPLS World Congress Dan Voyer(Fellow at Bell) introduced their deployment (recording here), highlighting how uSID outperforms MPLS for Metro networks. He analyzed various angles, such as hardware performance with larger linerate dataplane push capabilities and reduced FIB/counter consumption, improved routing scale with more nodes per domain, and efficient load-balancing due to uSID’s hardware-friendly entropy solving the problematic of MPLS.
Additionally, Gyan Mishra from Verizon explained how uSID outperforms VXLAN in the DC environments by offering lower MTU overhead. uSID provides 5% less overhead than IPv6/UDP/VxLAN for the average IMIX packet, hence 5% cheaper fabric. In addition uSID fulfills the needs for traffic engineering, and enabling host control over network policies.
SRv6 uSID Industry Status
As of today, SRv6 uSID is widely supported across routing vendors, merchant silicon, opensource, and a various set of partners.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.