While many people are still figuring out segment routing, up crops SRv6, and then SRv6+. Read why we want SRv6+, and why we believe it's crucial we get it.
Now - that leads to questions - whats going on - and there seems to be some lack of understanding as to what this is - and why we want it - so - here is a kind of 101 on what SRv6+ is - why we want it - and why we believe its crucial we get it.
Firstly though - lets step back - and look at what SRv6 is, in brief. Effectively, segment routing has various types of segment identifiers - these can be seen in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02. While I won't detail all of them - sufficient to say that most SR today uses Type 1 SID's (which are basically MPLS labels), with some Type 3 SID's used for TE path formation for first hop for colorless SR. Some of the other SID types are starting to appear as more SR based stuff is developed, but that's the predominant case.
SRv6 however uses IPv6 addresses in extended headers in place of labels. These are placed in Routing Extension Headers, and stacked. an SRH comprises of a 64bit "header", and then stacked v6 SID's. Meaning - at a bare minimum, an SRv6 packet has a 192 bits of additional data - by comparison, an MPLS header is 32 bits long (20 bit label + 3 Traffic Class + 1 Bottom of Stack + 8 TTL). Thats pretty huge overhead - and if you stack labels 4 deep - well - it gets crazy. Secondly, SRv6 also effectively uses IPv6 addresses as well, not IPv6 addresses - it results in overloading of the V6 address. While there isn't enough in the wild to truly evaluate the consequences of this - I suspect there is much that believes that an IPv6 address is, well, an IPv6 address - and this could get messy - fast.
So, now, with that said, lets talk about SRv6+ - which is in effect a combination of 4 drafts, that can be found here:
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-03
https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-05
https://tools.ietf.org/html/draft-bonica-6man-oam-03
The first of these drafts replaces the standard v6 segment routing header with a compressed routing header (CRH). The CRH uses a list of SID's that are either 8, 16 or 32 bits long, and these SID's are then mapped to IPv6 addresses elsewhere - and in a future post I will go into more detail about exactly how this works - but suffice to say - it gets rid of the huge overhead imposed by the traditional SRH - and actually makes SRv6 viable - rather than something that imposes overhead that no sane operator will accept.
The second of these seperates out instructions sent by a source node to intermediate nodes from the IPv6 address. Basically - in SRv6 normal, found at https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05 - you will see in section 4 they define a massive list of functions that can be associated with a SID. Keep in mind - in the context of this - a V6 SID is a V6 address - so what this does - is overload the address. In the segment end option draft however, there is an optional header that carries instructions and other information - without overloading the address space.
The third draft effectively creates a non-MPLS label method of carrying VPN context information - for devices that cannot handle MPLS labels but still need VPNv6. (I may write more on this in a future article)
The forth RFC allows for embedded OAM instructions - basically allowing a source node to instruct nodes deeper in the path to perform certain actions (Log the packet, count the packets, send an ICMPv6 OAM packet back to the source, send certain telemetric data back to a collector etc). Considering the stateless nature of SR - being able to embed such instructions certainly have some interesting applications that would be... rather useful. For example - if I were to tell each node on a path to send me telemetric data that included the time of arrival of the packet and the packet itself, it would be possible to correlate the received data from each node to effectively provide me with real time latency metrics between the nodes on the path.
So - thats a crash course of what SRv6+ is. Why do we want it? Because the overhead imposed by SRv6 is not acceptable - the overloading of IPv6 addresses makes no sense and imposes certain dangers - and the OAM options provided by the OAM RFC provide some extremely interesting possibilities in a world where controllers, machine learning and other such things start to take deeper hold in our networks.
Now, it will be interesting to see how this moves going forward. I suspect we will see modifications of the drafts and some refinement - but what I will say is - judging by what I have seen at places like the MPLS Global Forum - SRv6 is coming, the only question is in what form. For my money - I'm backing something that doesn't impose insane overhead and overload the address space, and doesn't force an upgrade of router interfaces just to deal with the overhead.