Skip to content
nodeza.learn
SRv6 course/1. Foundations/Lesson 1.4

Compression: RFC 9800, NEXT-C-SID, and what "uSID" really means

S1·E4Your slide says 96 bytes and theirs says 40 · Hotel lobby, 07:10, an hour before the meeting that decides the purchase order

S1·E4Analyze~30 minsources checked todayverified against RFC 9800 sections 2, 3, 4.1, 4.2, 5, 9.1 and 12.1 re-fetched 2026-09-07; RFC 9602 section 6 re-fetched 2026-09-07; Cumulus Linux 5.18 Segment Routing page re-fetched 2026-09-07

Builds on: The SRH on the wire, SIDs as instructions: LOC:FUNCT:ARG and the behavior zoo

Before you read: what do you already know?

3 quick questions. Wrong answers are fine and expected; trying first makes the lesson stick.

After this lesson you can

  • Compute how many CSIDs fit in one container for a given Locator-Block and CSID length and check it against the RFC formula.
  • Distinguish NEXT-C-SID from REPLACE-C-SID by container format packing order and mandatory-to-implement lengths.
  • State what RFC 9800 standardises and what uSID vocabulary belongs to vendors rather than the RFC.
  • Compare the per-packet overhead of a full SRH a reduced SRH and a uSID carrier for the same path.

Episode 4 — Your slide says 96 bytes and theirs says 40

The situation · Hotel lobby, 07:10, an hour before the meeting that decides the purchase order

The incumbent’s architect challenged your overhead number in front of the customer’s director yesterday afternoon. Your deck priced a three-segment path at 96 bytes; his showed 40 for the same picture, and procurement wants to know which of you is selling something. The SE has a lobby coffee going cold and a spreadsheet row open since the briefing room. The night-shift operator has already texted a photo of two boxes in the DR rack, labeled. Both numbers are real. You have an hour and a lobby table to work out which question each answers.

Compression exists because uncompressed SRv6 is mostly repetition. RFC 9800, Standards Track, June 2025, says why in one sentence: all SIDs instantiated from the same Locator-Block “share the same most significant bits”, so the encoding “seeks to decrease the packet header length by avoiding the repetition of the same Locator-Block and reducing the use of padding bits.”[1] A CSID container is a single 128-bit address holding several short identifiers, and its capacity is one line of arithmetic: floor((128-LBL)/LNFL), which at a 32-bit block and 16-bit CSIDs is six.[1] Six hops riding in the destination address - and when the policy is a single segment the headend may push no SRH at all.[2]

Then the vocabulary problem: his deck says uSID on every page and the RFC never uses the word once.[1]

uSID is not in the RFC. NEXT-C-SID at a 32-bit Locator-Block and a 16-bit CSID is, and they are the same thing.

So you rebuild the slide from the container up.

1The waste that compression removes

RFC 9800, “Compressed SRv6 Segment List Encoding”, Standards Track, June 2025, is the document that ends a five-year argument.[1] Its abstract states what it does: “This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list … This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as [previously specified], or a CSID container.”[1][3]

The reason it works is stated plainly in section 3: “In an SR domain, all SRv6 SIDs instantiated from the same Locator-Block share the same most significant bits … The compressed segment list encoding seeks to decrease the packet header length by avoiding the repetition of the same Locator-Block and reducing the use of padding bits.”[1] Look at a three-segment list from lesson 2 with that sentence in mind. Each 16-byte entry repeats the same 4-byte block and then pads out most of the remaining bits with zeros, because RFC 8986 requires the leftover bits of a SID to be zero.[2] You are spending 48 bytes to convey perhaps six bytes of new information.

The new vocabulary in section 2 is worth learning exactly, because vendor documentation mixes it with its own: Locator-Block is the B of RFC 8986 section 3.1, Locator-Node is the N, a Compressed-SID (CSID) is the short identifier, and a CSID container is “a 128-bit IPv6 address that functions as a container holding a list of one or more CSIDs and the Argument (if any) of the last CSID.”[1][2] The GIB is the Global Identifiers Block and the LIB the Local Identifiers Block.[1] The length notation matters too: LBL is the Locator-Block length, LNL the Locator-Node length, FL the Function length, AL the Argument length, and LNFL = LNL + FL, also called the CSID length.[1]

2NEXT-C-SID: the container and its arithmetic

Section 4.1 defines the flavor that everything in NVIDIA’s portfolio implements. In NEXT-C-SID each CSID container is “a fully formed 128-bit SID”: the Locator-Node and Function of the container are those of the first CSID in the sequence, and its Argument is “the contiguous series of subsequent CSIDs.”[1] So the container is simultaneously a legal IPv6 address you can route toward and a list of instructions for the nodes further along.

The capacity rule is one line and you should be able to produce it on a whiteboard: “When all CSIDs have the same length, a CSID container can carry up to K CSIDs, where K is computed as floor((128-LBL)/LNFL).”[1] At LBL = 32 and LNFL = 16 that is floor(96/16) = 6, which is the number SONiC’s uSID design quotes for a carrier - “uSID carrier is 128-bit IPv6 address that can carry upto 6 uSIDs”.[1][7] NVIDIA’s Cumulus Linux page states no per-carrier capacity; what it publishes instead is the four supported block, node and function length combinations.[5]

The mandatory-to-implement profile is the other line to memorise, verbatim: “An implementation MUST support a 32-bit LBL and a 16-bit CSID length (LNFL) … and it MAY support any additional Locator-Block and CSID length.”[1] The argument length follows: “The AL for NEXT-CSID flavor SIDs is equal to 128-LBL-LNFL.”[1] That 32/16 pair is the profile everyone tests against; anything else is off the well-trodden path in every implementation you will meet.

Linux agrees by construction. The kernel defines a 32-bit default Locator-Block and a 16-bit default Locator-Node Function, and the man page states the same defaults.[10][11] Its validation is strict: each length must be non-zero, at most 120 bits and byte aligned, and their sum must not exceed 128, which the man page phrases as “must be greater than 0 and evenly divisible by 8.”[10][11] So a request for a 33-bit block fails on alignment, not on policy.

The new IANA codepoints are what you will actually read in a decode: 43 End with NEXT-CSID, 44 with PSP, 45 with USP, 46 with PSP and USP, 47 with USD, and 52 End.X with NEXT-CSID with its flavored variants following, plus 85 to 92 for End.T and 96 and 97 for the new inter-domain behaviors End.LBS and End.XLBS.[1]

overhead 40 B1440 B fits MTU 1500
Outer IPv6 header — 40 BVer/TC/Flow4 BPayload Len1400 BNext Header41Hop Limit64Source Address16 B · fcbb:bbbb:100::1Destination Address16 B · fcbb:bbbb:1:2:3::Destination address as a CSID container — LBL 32 + 6 × 16 bits (K = floor((128 − 32) / 16) = 6)Locator-Block32 b · fcbbbbbbactive CSID0001CSID 20002CSID 30003End-of-Carrier0000End-of-Carrier0000End-of-Carrier0000Inner packet — 1400 BOriginal packet (IPv6)1400 B · hop limit already decremented

40 B overhead + 1400 B inner = 1440 B · red line = link MTU 1500 · grey line = the 1280-octet IPv6 floor · largest inner packet that fits: 1460 B

0000  60 00 00 00 05 78 29 40 fc bb bb bb 01 00 00 00 
0010  00 00 00 00 00 00 00 01 fc bb bb bb 00 01 00 02 
0020  00 03 00 00 00 00 00 00 
…… 1400 B of inner packet not shown
SR policy — in policy order, first segment first (this is the order you type after segs)
  • 1.
  • 2.
  • 3.
K = 6 CSIDs / container
uSID carrier

NEXT-C-SID (RFC 9800 §4.1). The whole path is packed into one 128-bit CSID container that is simply the destination address — no SRH on the wire. RFC 9800 never uses the word "uSID".

ip -6 route add <uN prefix> encap seg6local action End flavors next-csid dev eth1

Overhead: 40 B outer IPv6 + 0 B (no SRH) = 40 B. The same 3-segment path as a full SRH costs 96 B; as one uSID carrier it costs 40 B.

All 3 CSIDs fit in one container (K = floor((128 - 32) / 16) = 6), so there is no SRH at all — the carrier is the destination address.

source

Destination Address — 16 B — the active SID

fcbb:bbbb:1:2:3:: (the only SID on the wire)

Always holds the segment the packet is being forwarded to right now.

This is why a transit node needs no SRv6 support at all: it does a plain IPv6 route lookup on this address (RFC 8754 §3.2). At an endpoint, line S15 decrements Segments Left and line S16 copies Segment List[Segments Left] into this field.

FAE angle: DOCA Flow's "copy the active SID to the IPv6 destination address" action — src field_string "outer.srv6.segments", dst "outer.ipv6.dst_ip", width 128 — is exactly line S16 done in hardware. That single copy is the uN/End primitive on a ConnectX or BlueField.

DOCA Flow 3.5.0 guide

Click any field in the packet (or tab to it and press Enter) to see what it does. DOCA Flow accounting: each distinct SRH configuration costs 128 B of actions memory (DOCA_FLOW_SRV6_ACTION_MEM_SIZE), and doca_flow_external_action_srv6_register() must be called before doca_flow_init().

Compare the same three hops as srh reduced and usid. Watch the overhead readout drop from 96 to 80 to 40 bytes, then change the Locator-Block to 48 and see the capacity of one container fall.

3REPLACE-C-SID, and why you mostly meet the other one

Section 4.2 defines the second flavor, and the difference is in the container format. REPLACE-C-SID starts with a fully formed 128-bit container whose Argument “carries the index of the current CSID in the current CSID container. The Argument value is initially 0.”[1] Subsequent containers are in packed format: “a 128-bit Segment List entry split into K ‘positions’ of LNFL bits, where K is computed as floor(128/LNFL).”[1] Note the different formula - the packed containers do not carry a Locator-Block at all, so all 128 bits are positions.

The packing order is the trap. Verbatim: “The second CSID in the CSID sequence is encoded in the least significant bit position of the first CSID container in packed format (position K-1), the third CSID is encoded in position K-2, and so on.”[1] Read a REPLACE-C-SID packed container left to right expecting path order and you will decode the path backwards.

Its mandatory-to-implement rule is different from NEXT-C-SID’s and this is a common briefing error: “This document defines the REPLACE-CSID flavor for 16-bit and 32-bit CSID lengths (LNFL). An implementation MUST support a 32-bit CSID length.”[1] The index occupies ceiling(log_2(128/LNFL)) bits of the Argument, and the RFC recommends “An LBL of 48, 56, 64, 72, or 80 bits … for easier reading in operation.”[1]

The RFC also says how to run a domain with both, and it is a warning rather than an invitation: “Both CSID flavors can coexist in the same SR domain, on the same SR segment endpoint node, and even in the same segment list. However, operators should generally avoid instantiating SIDs of different CSID flavors within the same routing domain or Locator-Block.”[1] Section 9.1 adds that “A deployment should use consistent LBLs and CSID lengths for all SIDs within a routing domain. Heterogeneous lengths, while possible, may impact the compression efficiency.”[1]

For a Dell OEM conversation the practical fact is short. REPLACE-C-SID codepoints exist - they start at 101 for End, 105 for End.X, 109 for End.T and include 116 to 124 for the decap family, where End.DT46 with REPLACE-CSID is 120.[1] But the Linux kernel implements only NEXT_CSID as a flavor operation, and Cumulus Linux documents only uN and uA, which are NEXT-C-SID behaviors.[10][5] If a customer’s existing deployment is REPLACE-C-SID flavored, say so on the first call rather than in the bake-off.

4What uSID really means, and where the word comes from

Now the terminology point this lesson exists for. RFC 9800 never uses the word uSID or micro-segment. A search of the published RFC for uSID, micro-segment and micro segment returns nothing; the RFC’s vocabulary is CSID, CSID container, NEXT-CSID and REPLACE-CSID.[1] “uSID” is vendor and industry vocabulary for the NEXT-C-SID flavor at a 32-bit Locator-Block and a 16-bit CSID length - which happens to be exactly the mandatory-to-implement profile.[1]

The industry’s own carrier layout, in its own words, is <uSID-Block><Active-uSID><Next-uSID>...<Last-uSID><End-of-Carrier>[...<End-of-Carrier>], where “End-of-Carrier: A globally reserved uSID that marks the end of a uSID list. The End-of-Carrier ID is 0000.”[7] The worked example in the SONiC design uses block 2001:41f0, active 0100, next 0200, last 0A00, then two End-of-Carriers of 0000 to fill out the 128 bits.[7] None of that is in the RFC, so cite it as industry practice and not as the standard.

The two behavior names you will meet everywhere are equally vendor-flavoured but map cleanly. NVIDIA’s documentation is explicit: “Cumulus Linux supports uN (End with NEXT-CSID) and uA (End.X with NEXT-CSID) endpoint behaviors, defined in RFC9800.”[5] The scope sentence beside it is the one to quote to a customer: segment routing runs “On the Spectrum-4 switch only. In the default VRF only”, with a maximum of 256 locators and static SIDs only.[5][6] The supported length combinations are published as a table - uN at 32/16/0, uA plus uN at 16/16/16, uN only at 16/16/0, and uA only at 16/0/16 - so a SID plan that does not match one of those four rows is not configurable.[5][6]

FRR uses the same names from the other side of the stack: a locator with behavior usid makes BGP “instantiate and advertise SRv6 uSID behaviors (e.g., uDT4 / uDT6 / uDT46) instead of classic SRv6 behaviors (e.g., End.DT4 / End.DT6 / End.DT46)”, and its SID formats are exactly two, usid-f3216 and uncompressed.[9] Its static-sids node accepts only uN, uA, uDT4, uDT6 and uDT46, with uA requiring an outgoing interface.[13] On Linux the same thing is a flavor: ip -6 route add ... encap seg6local action End flavors next-csid dev eth1 is a uN, and lblen/nflen change the profile.[11]

Endpoint (RFC 8986 §4.1-§4.3)
Decap services (§4.4-§4.9)
Binding (§4.13, §4.15)
Headend (§5)
uSID names (RFC 9800)
flavor
implementation

uN + next-csid

IANA codepoint 43Cumulus on Spectrum-4: supported
RFC 9800 §4.1 (End with NEXT-CSID) · uN — End with the NEXT-CSID flavor

A global CSID (from the GIB) bound to End. The active CSID sits at the front of the container in the DA; processing it shifts the next CSID into place instead of reading a fresh 128-bit segment out of the SRH. "uN" is industry vocabulary — RFC 9800 never uses "uSID" or "micro-segment".

LOC:FUNCT:ARG — 128 bitsCumulus Linux locator defaultsLOC = B:N (32b)ARG 96bbit 0bit 127B 16b · N 16b · ARG 96bCSID container — K = floor((128 − 16) / 16) = 7 CSIDsB 16bCSID 1CSID 2CSID 3CSID 4CSID 5CSID 6CSID 7active CSID first; End-of-Carrier value 0000 marks the end of the list
RFC 8986 / 9800supported

RFC 9800 §4.1 defines the NEXT-CSID flavor of End. ⚠ The RFC never uses the word "uSID" — that is vendor vocabulary.

next-csid: RFC 9800 §4.1, Standards Track, June 2025 — and it Updates RFC 8754.

Linux seg6localsupported

`action End flavors next-csid [lblen 32] [nflen 16]`. Defaults SEG6_LOCAL_LCBLOCK_DBITS 32 / SEG6_LOCAL_LCNODE_FN_DBITS 16 — exactly the F3216 profile.

next-csid: `flavors next-csid [lblen N] [nflen N]`, defaults 32 / 16. Supported on End (= uN) and End.X (= uA) only. Lengths must be > 0, ≤ 120 and byte-aligned; `lblen 33` is rejected.

FRR staticd/bgpdsupported

staticd: `sid <prefix> locator NAME behavior uN` (no vrf). zebra: `behavior usid` on the locator, `format usid-f3216`.

next-csid: Locator `behavior usid` + `format usid-f3216`; staticd exposes it as the uN / uA / uDT* behavior names.

Cumulus on Spectrum-4supported

Supported — uN "defined in RFC9800", but on the Spectrum-4 switch only, in the default VRF only, max 256 locators, static SIDs only. Introduced in Cumulus Linux 5.14.0, unchanged through 5.18.

next-csid: The only thing Cumulus Linux implements: uN and uA, "defined in RFC9800".

source

community SONiCsupported

Static-config HLD: SRV6_MY_SIDS action defaults to uN. "uN behavior is implemented with PSP and USD flavor."

next-csid: Exposed as the uN / uA / uDT* actions in SRV6_MY_SIDS.

DOCA Flow 3.5.0partial

The uN data-plane primitive is expressible (COPY outer.srv6.segments → outer.ipv6.dst_ip, width 128) but there is no CSID container shift and no SID table.

next-csid: DOCA Flow has no CSID container logic; it copies the whole 128-bit active SID into the DA.

FAE angle: uN is the behavior NVIDIA switching actually ships, and it also collapses the classic MSD interop bug — with 6 CSIDs in one container, Segments Left is 0 or 1 and IS-IS MSD type 41 (SRH Max Segments Left) stops being the constraint.

Read the support row for uN across implementations, then select replace-csid and watch the cumulus and linux cells strike through with their reasons.

5Where the SIDs live: 5f00::/16 against the ULA reality

Compression makes the address plan more important, not less, because the Locator-Block is now shared by everything. RFC 9602, October 2024, gives the domain a purpose-built block: IANA assigned 5f00::/16 with the name “Segment Routing (SRv6) SIDs”, allocation date 2024-04, in the IPv6 Special-Purpose Address Registry.[4] The rationale is worth quoting to a security team: it is “desirable to allocate some address space that explicitly signals that the addresses within that space cannot be expected to comply with [RFC4291] … useful in identifying and potentially filtering packets at the edges of the SR Domains to make it simpler for the SR Domain to fail closed.”[4] The RFC also notes that “At the time of writing, global DNS SHOULD NOT reference addresses assigned from this block.”[4]

It is available, not mandatory, and the field has not moved. RFC 8986 itself documents operators using ULA space per country and per router; FRR’s documentation uses fcbb:bbbb:1::/48 style locators; Cumulus Linux’s configuration example uses fcbb::/16; SONiC’s static-configuration design uses FCBB:BBBB:21::.[2][9][5][8] Expect a customer to be on ULA, which is fine, and expect their edge filter to be hand-maintained as a result.

Two more planning inputs before you write a SID plan. Multiple global CSIDs may exist under one Locator-Block, “e.g., one per IGP flexible algorithm”, and Flex-Algo identifiers occupy the range 128 to 255.[1][12] And the community SONiC defaults do not agree with each other: the 2021 SRV6_MY_SID_TABLE schema used block 40 node 24 function 16 and the sonic-srv6 YANG model in the same document defaults to 32/16/16/0,[14] while the 2025 static-configuration design uses 32/16/16 with a zero argument length.[8] State both when you teach it, and always ask which one the customer’s build ships.

Size a uSID carrier for a real path

Customer path: five SRv6-aware nodes, Locator-Block fcbb:bbbb::/32, node identifiers 16 bits, no function bits used on the transit hops. Question: does the path fit in one carrier, and what does it cost?

  1. Compute capacity. K = floor((128 - LBL) / LNFL) = floor((128 - 32) / 16) = 6.[1] Five hops fit in one container with one position spare for an End-of-Carrier.[7]
  2. Lay out the carrier. Block fcbb:bbbb, then the five node CSIDs in path order, then 0000 as End-of-Carrier, padded with further 0000 values to 128 bits.[7]
  3. Choose the encapsulation. The policy is now a single segment, so the headend may omit the SRH entirely - RFC 8986 allows the push of the SRH to be omitted “when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV.”[2]
  4. Price it. Overhead is the outer IPv6 header alone: 40 bytes. The same five hops uncompressed would be 40 + 8 + (5 x 16) = 128 bytes, or 112 bytes as a reduced SRH.[3][2]
  5. Name the behavior at each hop. Each transit node runs uN, which is End with the NEXT-CSID flavor - IANA codepoint 43 in an unflavored advertisement.[1]
  6. Check it against the target platform. On Cumulus Linux the 32/16/0 row of the supported combination table is exactly the uN-only case, so this plan is configurable there; on Linux it is action End flavors next-csid with the default 32 and 16 lengths.[5][11]
  7. State the residual risk. Every node must draw its CSID from the same Locator-Block and use the same CSID length, and the whole path must be within one domain - inter-domain compression needs End.LBS or End.XLBS.[1]

Episode 4 — case closed: one line item, two endpoints

How it ended

You walk in with the same path priced three ways: 96 bytes as a full SRH, 80 reduced, 40 when the hops ride in one container and no SRH is pushed.[3][2][1] Then you say the mapping out loud once - his uSID is NEXT-C-SID at the mandatory-to-implement 32-bit Locator-Block and 16-bit CSID length - and check that profile against what NVIDIA switching documents: uN and uA, no REPLACE-C-SID.[1][5]

What you say to the architect: “Your 40 and my 96 are the same network. One is the worst case and the other is the design point.”[1]

The network lead reads page one back to the room. Procurement gets its one line item, the SE closes the spreadsheet row six weeks after opening it, and the operator’s labels were right.

Lab

Goal: measure the compressed path on real NVIDIA silicon-attached links and turn it into a customer-facing number. No firmware writes and no mode changes. Steps 1-4 touch only sysctls and routes on the hosts; the optional step 5 applies a locator configuration to a Spectrum-4 switch. Every step names its rollback.

  1. Pre-flight on both ends. Record kernel, interface, MTU and current seg6 state before you change anything: 
    uname -r
ip -6 link show
sysctl net.ipv6.conf.all.seg6_enabled
    Expected: seg6_enabled = 0, the shipping default. Rollback for the enable you are about to do: sysctl -w net.ipv6.conf.all.seg6_enabled=0 plus the same for default and the named interface.
  2. Repeat the carrier test between the BlueField-3 Arm and a ConnectX host over the real link: install uN on the Arm side, send a single-carrier path from the host, and capture on the receiver. Expected: no SRH on the wire and the carrier visible in the destination address.[2][1] Rollback: delete the routes on both ends.
  3. Measure, do not estimate. Sweep ping6 -s to find the largest inner payload that survives the compressed path, then repeat for the same hops encoded as an uncompressed three-segment SRH from lesson 2. Expected: the compressed path carries 56 more bytes of payload, because 96 bytes of overhead became 40.[3][2]
  4. Do the customer arithmetic on paper: for their chosen Locator-Block length, compute K = floor((128 - LBL) / LNFL) and compare it to their worst-case path diameter, not their average one.[1] Deliverable: one line - “at your block length you get K hops per carrier and your longest path is N, so you need M carriers.”
  5. Optional, customer lab only: on a Spectrum-4 running Cumulus Linux 5.14 or newer, configure a locator and confirm the combination against the documented table: 
    nv set router segment-routing srv6 state enabled
nv set router segment-routing srv6 locator LEAF prefix fcbb::/16
nv set router segment-routing srv6 locator LEAF block-length 16
nv set router segment-routing srv6 locator LEAF node-length 0
nv set router segment-routing srv6 locator LEAF func-length 16
nv config apply
    Expected: this is the uA-only row of the supported table.[5] Rollback: nv unset router segment-routing srv6 locator then nv config apply. Then verify that a 32/16/0 locator is accepted as the uN-only row, and that a combination outside the four documented rows is not.[5][6]

Retrieval check

10 questions from memory. Answer before looking anything up; misses become flashcards.

Explain it to a Dell SE

Explain to a Dell SE, in five sentences, how six hops can fit in one IPv6 address and what you would have to check about the customer's addressing before promising it.

14 flashcards for this lesson — 0 in deck. Spaced review lives at /review.

Sources

Facts in this lesson were checked against RFC 9800 sections 2, 3, 4.1, 4.2, 5, 9.1 and 12.1 re-fetched 2026-09-07; RFC 9602 section 6 re-fetched 2026-09-07; Cumulus Linux 5.18 Segment Routing page re-fetched 2026-09-07. Dates are when each page was fetched.

  1. RFC 9800 - Compressed SRv6 Segment List Encoding · fetched 2026-09-07
  2. RFC 8986 - SRv6 Network Programming · fetched 2026-09-07
  3. RFC 8754 - IPv6 Segment Routing Header (SRH) · fetched 2026-09-07
  4. RFC 9602 - SRv6 SIDs in the IPv6 Addressing Architecture · fetched 2026-09-07
  5. Segment Routing | Cumulus Linux 5.18 · fetched 2026-09-07
  6. Segment Routing | NVUE Command Reference · fetched 2026-09-07
  7. SONiC HLD - SRv6 uSID · fetched 2026-09-07
  8. SONiC HLD - Static Configuration of SRv6 in SONiC · fetched 2026-09-07
  9. FRR documentation - Zebra (SRv6 locators and SID formats) · fetched 2026-09-07
  10. Linux kernel source - net/ipv6/seg6_local.c · fetched 2026-09-07
  11. iproute2 man source - ip-route.8.in · fetched 2026-09-07
  12. RFC 9350 - IGP Flexible Algorithm · fetched 2026-09-07
  13. FRR documentation - Static (staticd SRv6 static-sids) · fetched 2026-09-07
  14. SONiC HLD - SRv6 · fetched 2026-09-07

The same idea elsewhere

Other lessons that cover this ground, sometimes from another course's angle.