Since the start of the Segment Routing over IPv6 dataplane (SRv6) project in 2017, the ecosystem has grown unabated.
SRv6 has been deployed in eight public, large-scale commercial networks, including Softbank, Iliad, China Telecom, LINE Corporation, China Unicom, CERNET2, China Bank and Uganda MTN.
In addition, 25 hardware implementations support SRv6 at line rate. These implementations span across custom silicon (Cisco systems and Huawei) and merchant silicon (Broadcom, Barefoot, Arccus, Intel, Marvel and Mellanox).
The open-source community is also largely backing up SRv6 with 11 open-source platforms/applications. SRv6 is not only supported in the native Linux kernel and FD.io VPP (since 2017) but also in P4, Wireshark, tcpdump, iptables, nftables, snort, ExaBGP and Contiv-VPP.
Most importantly it is an IETF Proposed Standard (RFC 8402, RFC 8754).
In this series of posts, I will discuss the details of the technology and how it simplifies the network by eliminating protocols such as Multiprotocol Label Switching (MPLS), Virtual Extensible LAN (VxLAN) and Network Service Header (NSH). Relying solely on the native IPv6 header and header extension, SRv6 provides the same services and flexibility as SR-MPLS, directly over the IPv6 dataplane.
What is SRv6?
SRv6 technology defines packet processing in the network as a program.
This network program is expressed as a list of instructions, which are represented as 128-bit segments, often called Segment ID (SID). They have the form of an IPv6 address.
The first instruction of the network program is placed in the Destination Address (DA) of the packet. If the network program requires more than one instruction, the remaining list of instructions is placed in the Segment Routing Extension Header (SRH).
For example, an SRv6 network program with three instructions will have the first instruction placed in the DA of the packet. The remaining two instructions are placed in the SRH.
The network program can likely be expressed with one single instruction. In this case, the first and only instruction will be in the DA and there won’t be any need for SRH.
SRv6 instructions
An SRv6 instruction can represent any topological or service-based instruction. For example, the instructions related to Traffic Engineering (TE) and Fast Re-Route (FRR) — ‘End’ and ‘End.X’ — as well as the Virtual Private Network (VPN) instructions — ‘End.DX’ and ‘End.DT’ — are examples of SRv6 instructions that are defined at the IETF.
The End instruction represents the shortest path to a given node.
The End.X instruction represents the shortest path to a given node followed by a forwarding adjacency over a specific link. These two instructions can be combined by an SDN controller to express any path through a network, without any per-flow state in the network.
The SRv6 VPN instruction End.DT indicates a shortest-path to a selected Egress Peering Engineering (PE) within a selected slice (for example, low-cost or low-delay) followed by its decapsulation of the inner transported packet and the lookup in a VPN table bound to the segment.
The SRv6 End.DX instruction is the same except that a lookup in a VPN table is not required: the segment is bound to a specific PE-CE L3 VPN interface or an attachment circuit for L2 VPN.
SRv6 Header
SRv6 network programs with more than one instruction require an SRv6 Header (SRH) (RFC 8754). Packets get encapsulated into an outer IPv6 header, which carries the first instruction as DA, and SRH, which carries the remaining instructions list.
The SRH includes a TAG field that carries per-flow metadata and is very useful for Group-Based Policy (GBP) use-cases.
The Segments Left field in the SRH is a pointer into the network program indicating the next instruction to bring into the outer IPv6 DA field. The instruction in the DA is the so-called active instruction as it is the one being executed. The pointer traverses the list of instructions (segments) in the SRH as the network program is executed.
Each instruction (segment) has a locator and a function part.
The Locator part (the most significant bits of the instruction) acts as a routing prefix, which is advertised in IGP or BGP by an SRv6-capable ‘parent’ node owning the instruction. Packets that have such SRv6 instruction as DA are routed to the parent node using the shortest path to the Locator prefix. Leveraging the Flexible-Algorithm capability of the IGP, the shortest-path can be customized on a per-slice basis, for example, low-cost vs low-delay vs disjointedness.
When the packet arrives at the parent node, it finds that the Locator matches its own locator, hence it will execute the instruction encoded in the Function bits. These Function bits can be mapped to any behaviour such as TE, FRR, VPN or NFV.
This is the first part of the SRH that has been optimized for hardware processing to be executed at line rate.
The second part of the SRH (at the bottom of the drawing) is the Metadata Type-Length-Value (TLV), which can contain user information, credentials or performance data. It has been specifically optimized for NFV integration and allows the different services that are integrated in the SRv6 solution to be able to pass information to each other. As an example, a deep packet inspection can record some information in this TLV, and other applications can leverage them.
SRv6 Domain
The SRv6 Domain is the service provider domain where SRv6 services are built to transport any kind of customer traffic including IPv4, IPv6, or even L2 frames.
Packets are encapsulated at the ingress of the SRv6 domain with an outer IPv6 Header. If the network program has more than one instruction, the Ingress PE also pushes an SRH. Each packet follows its path in the SRv6 domain as the encoded network program is executed and it eventually reaches the Egress PE.
The Egress PE removes the added IPv6 header and SRH (if there are any) and the inner customer packet is forwarded to the other customer site. The customer packet leaving the Egress PE is exactly the same as the customer packet that entered the Ingress PE.
SRv6 provides end-to-end integrity as all SRv6 network programming operations are applied to the outer header (pushed at Ingress PE and removed at Egress PE), hence forbidding customer packets to be tampered with.
SRv6 Deployments
The SRv6 co-development between Softbank and Cisco started in 2017, culminating in the industry-first SRv6 commercial deployment in 2019.
Shortly after, Iliad publicly announced the development of a new large-scale network in Italy to support its SRv6 services. This network relies on 1,800+ nodeboxes acting as access devices (developed by Iliad) as well as 1,000+ Cisco NCS 5500 routers. The integration of SRv6-capable devices developed by service providers with networking vendors’ platforms clearly demonstrates how mature the SRv6 ecosystem is.
Read more about the Softbank and Iliad deployments.
As mentioned, the SRv6 solution is being standardized at the IETF.
RFC 8402 defines the Segment Routing (SR) architecture and its instantiation over an IPv6 data plane (SRv6), while RFC 8754 (SRH: Segment Routing Extension Header) defines the SRv6 dataplane.
The network programming model in now with the Internet Engineering Steering Group for publication and the IS-IS extensions for SRv6 and OAM are in the last-call status — check latest updates.
In my next post I will discuss examples of deployed SRv6 use-cases.
Clarence Filsfils is a Cisco Systems Fellow, with 25-years’ experience leading innovation, productization, marketing and deployment for Cisco Systems.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Can you point me to the IOS versions that actually implement the SRv6 data-plane? I have seen the SRv6 control plane and CLI, but I haven’t found any IOS version where that actually translates to SRH headers on the wire… The CLI commands on the IOS versions that I have found completely ignore the path steering and just X-in-IPv6 tunnel the packets straight to the destination.
I think that its also only fair to mention certain other facts.
The network programming draft in the IETF is currently the subject of an appeal the outcome of which we are awaiting.
There are many aspects to that appeal, from process violations to the fact that in the opinion of the appellants (and many others), the draft currently violates the base IPv6 specification which could have significant consequences. In fact, by violating the current specification, I would argue that the Network programming draft is in fact in violation of the working group charter through which it is being railroaded.
But – probably the most important point to make on this – is that there is a *huge* amount of concern about burning of the v6 address space when using this technology. Concerns that the authors of this draft have point blank refused to clarify or discuss either within the IETF or with the RIR’s.
SRv6 network programming is not the utopia it is being spelt out to be – and I would advice anyone looking at this technology – to stop and really understand the potential breakage and consequences of utilizing this in its current form.
Also – please – take note of the comment left by Sander as well – despite all the deployment claims – package capture after packet capture do now show true SRv6 network programming implementation – instead of they show tunneling (which technically is allowed by the draft) – but full implementations? Many requests have been made for packet captures or hardware lists that can actually do this – and so far all we have is deafening silence.
As a follow up to the last comment – more details about the appeal, and the link to the appeal itself, can be found here:
https://www.linkedin.com/pulse/when-comes-time-appeal-andrew-alston/
Support on IOS-XR starts with version 6.6 for NCS and ASR9000 (3rd and 4th gen LC).
Despite publicly available announcements from operators who have deployed, I am amused to read someone quoting “the deployment “claims””. Please note that IOS-XR supports SRv6 since 6.6.1 on Cisco custom silicon (ASR9000 series) as well as on merchant silicon (Broadcom’s Jericho/Jericho+) NCS55xx series. Since then, more and more features have been added. The deployments are using 6.6.1 and later images. Furthermore, there is public documentation and config guides present on Cisco product pages.