SRv6 uSID
Load top1.vpnv4v6.srv6.configured.cfg
L3VPN for IPv4 and IPv6 is currently functional using SRv6 in the core.
Change the core to use uSID (microSID) instead. Use the block fd00:0000::/32 as the uSID block.
Answer
Explanation
uSID (microSID) is an optimization for SRv6. uSID uses SID compression so that space in the IPv6 header is not wasted on duplication of bits (the common SID block and zero padding).
Let’s take an SR-TE policy that traverses five nodes, and ends with a function on the last node that has an instruction to decapsulate the packet and forward out an IPv4 VRF table. The SRH would look as follows. Remember that the zeroth index is the last segment, so this policy steers along the path R1-R2-R3-R4-R5, with a function on R5.
Notice that the the prefix is always the same (fd00:0000), and the zero padding is always the same. (Indexes 1 through 4 have all zeros after the third hextet). We can compress this SRH into a single 128-bit address by doing the following:
Each SID endpoint (R1, R2, R3, R4 and R5) must do a “shift and forward” operation to allow this to work. First, IPv6 routing carries the packet to R1 via the fd00:000:0001::/48 entry in IGP. R1 then sees that its own uSID is present, but the packet is not destined for itself. (There is no end-of-carrier (0000) following its own uSID, nor is there a local SID instruction (e000-ffff)). R1 deletes its own uSID, shifts the rest of the IPv6 address to the left 16 bits, and pads 16 bits of zeros at the end.
This process continues until the packet arrives at R5 with address fd00:0000:0005:e0001::. R5 has this entry in its FIB with a DT4 behavior.
The beauty of this compression is that MTU overhead is reduced, no SRH is needed (when using 6 or fewer uSIDs), and no change to basic SRv6 behavior needs to be made. There is no downside to using uSID compared to using “full” SIDs. Therefore most implementations of SRv6 these days use uSID from the beginning.
Cisco’s implementation requires a 32 bit uSID block and 16 bit uSID ID. A uSID carrier is a 128-bit SID that carries multiple uSIDs within it. Each uSID carrier starts with the 32 bit uSID block, and is followed by 16 bit uSIDs.
The 16 bit uSIDs can either represent a global node, or represent a local forwarding instruction (such as an Adj SID or a L3VPN forwarding instruction). In order to differentiate between global node uSIDs and local uSIDs, local uSIDs are always in the range e000-ffff. A local uSID must be proceeded by the node’s global uSID, just like we have seen with SR-MPLS. This allows the packet to be steered to the node which understands the local SID meaning.
To configure uSID, you simply use a ::/48 locator (32 bit block plus 16 bit ID). Additionally, you specify that the node will preform PSP and USD behavior. If the node is the penultimate endpoint (there is only one entry left in the SRH), it can perform PSP. If the node is the final endpoint, it can decapsulate the packet.
First, to accomplish this lab, we must remove the existing locator to be able to re-configure it for uSID. Then we re-define the SRv6 locator as a uSID locator.
There is also an option for micro-segment behavior unode shift-only, however this is not allowed to be committed on XRv9K. Presumably, this could be used for P-only routers, because they would only need to be SR-TE waypoints, and not decapsulate the header as an egress PE?
Just like with regular SRv6 using “full” SIDs, the locator is advertised into the IGP. This is already configured in this lab, so we don’t need to worry about this.
The nodes will advertise their locator into the IGP just as before, but now the END SID is a uN (microSID Node SID). The END.X SID is now a uA (microSID Adj-SID). The block length is now 32 bits, with the node ID length as 16 bits. Remember that this is not configurable. You must allocate the locator prefixes with this format in mind. This format is notated as F3216.
In the SRv6 manager, we can see that the SID base block is actually a ::/24. This means we can configure multiple ::/32 locators but they must come from this ::/24. Typically the ULA space is used for uSID (fc00::/7).
Notice that we can configure an additional locator with a block such as fd00:33::/32, but not fd00:1111::/32.
Each router will automatically begin allocating local uSIDs from the locator configured under the BGP services. For example, we can examine the local uSIDs allocated on XR5:
These are installed into the FIB, just as we have seen before with regular SRv6:
Notice above that each uN SID has a ::/48 and ::/64 entry, and each uA SID has a ::/64 and ::/80 entry. When there are more uSIDs following the uN or uA, the ::/48 or ::/64 will be matched, respectively, and the node will only do shift and forward. When the end-of-carrier follows the ::/48, it will match the ::/64 or ::/80 entry (because the end-of-carrier is 16 bits of zeros). In this case, the PSP/USD behavior will happen instead of shift and forward.
All L3VPN services should still be working. Instead of a full SID, a uSID is advertised with the L3VPN route. The label now contains the local uSID (eXXX). Note that you need to ignore the trailing 0 in the label. For example, 0xe0020 is actually 0xe002.
The detailed RIB entry references that the f3216 microSID format is used for encapsulating the customer packet and forwarding to XR7:
Now that we have uSID configured, we can use SR-TE policies. We will see this in upcoming labs.
Last updated
