In the first blog of this 2-part series on segment routing fundamentals, we looked at segment routing’s more abstract definition and its implementation using MPLS. At the end, we noted that both Layer 3 and Layer 2 services can benefit from segment routing and explained how. If you’re only just joining us now, feel free to pause and catch up on Part 1 here.

Ready to dive into Part 2? Let’s get back to segment routing itself!

To understand how SRv6 operates, we must first look at its unique naming conventions and the logic that allows the network to function as a programmable entity.

The logic of SRv6: network programming

SRv6 has its own unique convention for naming segments.

The IGP prefix segment was originally called “End,” and the adjacency segment was called “End.X.” Other segments more relevant (in practice) to special situations involving interworking and migration have been named “End.B6.Encaps.Red” or “End.B6.BM” in SRv6.

The term the router uses at the network ingress is “H.Encaps” or “H.Encaps.Red.” Somewhere in between, something like “H.Insert” or “H.Insert.Red” might occur.

Does this dot-notation-based syntax seem familiar? If you’re reminded of object-oriented programming languages like Python or Java, you’re not wrong. So, how did this come to be part of Segment Routing?

From a Segment Routing perspective, a segment’s SID encodes an instruction the network must execute. The network thus behaves much like a program whose instructions are processed by a computer.

In the context of Segment Routing, people often refer to the “programmable network” or “network programming.” The latter term even made it into the title of an RFC that is central to SRv6: “Segment Routing over IPv6 (SRv6) Network Programming” (RFC 8986). This explains the naming convention for SRv6, which may seem strange at first.

In SRv6, some segments use a SID with an argument that’s processed when the instruction runs. This is the case, for example, when using SRv6 as the data plane for EVPN services.

Anatomy of an SRv6 SID

To wrap up this discussion of Segment Routing, let’s look behind the scenes of SRv6.

In SR MPLS, it’s easy to replicate the fundamental concept of segment routing using labels as SIDs and a label stack as a SID list. But how does this work with IPv6 as the platform for Segment Routing? Here, specially formatted IPv6 addresses serve as SIDs.

Typically, an IPv6 address space (known as an SR block) is reserved for this purpose, usually in the range of /33, /40, or /48. This is followed by a Node ID, typically 16 bits long, then a 16-bit Function field, an Argument, and some padding.

From Locator to execution

Together, the SR block and Node ID form the Locator. It doesn’t just appear out of thin air, and it can’t be automatically generated by smart SRv6 routers (RFCs call this the “SRv6-enabled node”).

Instead, it must be configured by the administrator. The rest of the SID is then automatically generated depending on the router’s task. The SRv6 router publishes the locator in the IGP (OSPF or IS-IS), so that all SIDs formed from it are reachable throughout the network via IPv6 routing.

The “Function” portion, in combination with the “Argument,” encodes the instruction to be executed on the SRv6 router.

The instructions must be executed on an SRv6 router based on IPv6 routing. To do this, the SRv6 router creates an entry in the IPv6 routing table for each SID generated from the locator, including a note specifying the instruction to be executed.

This kills two birds with one stone: transport to the SRv6 router and processing on that router.

In other words: what exactly should be done with the traffic at the segment endpoint? Some ideas: nothing at all, just forwarding to the next segment; forwarding to a specific link; handing it off to an L3 or L2 context for further processing; forwarding via a traffic engineering path; and so on. The imagination has nearly no limits here.

How the SID list works

So how does the SID list work? Since only a single SID fits into the IPv6 header, the Segment Routing header is included with the packets in the encapsulation. It contains an indexed list of SIDs.

Unfortunately, this isn’t exactly intuitive. Since 0 is the index of the last segment, the first segment is actually at the end of the entire list.

The “Segments Left” field points to the SID of the current segment, which is also found as the IPv6 destination address in the IPv6 header. Upon arrival at the segment endpoint, “Segments Left” is shifted to the next index, and this SID is then adopted as the IPv6 destination address; a quick look at the IPv6 routing table, and off it goes.

Overhead and the role of SDN

Of course, this adds a lot of overhead. People have, naturally, complained vehemently. Later improvements introduced Micro SIDs, which take up significantly less space. (I can discuss that along with Software-Defined Networking (SDN) in another blog.)

The good news is that you only need SDN in the context of traffic engineering. So in a segment routing network without traffic engineering, there’s no need for SDN! Even in a network with traffic engineering, it isn’t strictly necessary. The network can handle many traffic engineering tasks all on its own!

Later, I can discuss where it falls short in some tasks, such as:

• Interdomain traffic engineering
• Disjoint path
• Bandwidth on demand
• Bidirectional co-routed path

Segment routing in the Cisco ecosystem

Cisco has supported the development of Segment Routing from the very beginning with creative energy, having played a leading role in standardization efforts. Segment Routing is now fully mature at Cisco and a standard feature of the service provider product line based on IOS XR (Cisco 8000 Series Routers, NCS, etc.).

As a Cisco Platinum Learning Partner, we at ExperTeach are delighted to accompany Cisco on its Segment Routing journey and guide knowledge-hungry individuals through the inner workings of this exciting, ever-evolving technology through our training offerings.