Summary

  • RFC 9800 lets an SR source encode several compressed SIDs inside fewer 128-bit containers, but only after it validates the structure of each eligible SID and preserves the original ordered segment list.
  • Clarence Filsfils is one of five named authors of this collective IETF work. Its operational lesson is not that compression makes routing simpler; it makes length, flavor, allocation and boundary records more consequential.

The bytes that did not make a decision

Imagine a strict SRv6 path whose packet must visit a sequence of topological or service functions. In the ordinary representation, each Segment Identifier is an IPv6 address. Many of those 128-bit values may begin with the same locator block, and some may end with padding zeros. Repeating those bits is unambiguous, but it increases the encapsulation carried by every packet.

RFC 9800, published in June 2025, asks a narrow question: when several consecutive SIDs share structure, can the source carry their distinguishing parts without repeating the common material? The answer is a compressed SID, or CSID. It contains the Locator-Node and Function portions of the original SID. One 128-bit CSID container can then hold one or more such compressed instructions, together with the argument of the last CSID where applicable.

This is not generic compression applied to an opaque byte string. The packet remains executable while it is changing. At each endpoint, a valid IPv6 Destination Address must identify the active local behavior. The next instruction must be recovered in a defined order. An error is not merely a poor compression ratio: it can send the packet to the wrong behavior or cause a drop.

That is why the most important line in the design is not “use fewer bytes.” It is “express the same list of segments as the original SID list.” RFC 9800 makes that an obligation of the SR source. A shorter list that changes the program is not an optimization. It is a different—and possibly dangerous—routing instruction.

Two ways to unpack the next instruction

RFC 9800 defines two endpoint-behavior flavors, NEXT-CSID and REPLACE-CSID. They solve the same repetition problem with different encodings.

With NEXT-CSID, the container is already a fully formed SRv6 SID. Its locator block and first CSID occupy the active part of the address; later CSIDs are placed in the Argument bits. When the endpoint finishes the active behavior, it copies the next compressed instruction forward within the Destination Address, clears the low unused bits, reduces the hop limit and submits the packet to another IPv6 lookup. Several steps can therefore be consumed from one address-sized container.

REPLACE-CSID uses the Segment Routing Header differently. The first item in a sequence is a full SID, while later CSIDs sit in packed 128-bit Segment List entries without the repeated locator block. An index in the active SID's Argument identifies the current packed position. Processing either moves the index within the current container or advances Segments Left to the next container, then constructs the next valid Destination Address.

Neither flavor creates a new service meaning. An adjacency remains an adjacency; a table lookup remains a table lookup. The RFC's security section is explicit that compression changes how the next SID is encoded and decoded, not the semantic of the active or following segment. That distinction is the compatibility promise: the path can become smaller without quietly becoming a different path.

It is also a warning against treating the two formats as casual alternatives. They have different recommendations for locator-block and CSID lengths, different endpoint codepoints and different packing behavior. RFC 9800 permits them to coexist—even in one list—but generally advises operators not to mix flavors inside the same routing domain or locator block. Flexibility at the wire level does not remove the operational cost of heterogeneity.

Compression starts with a refusal test

The source node may learn SIDs from local configuration, calculate them locally, or receive an ordered list from a controller. RFC 9800 does not privilege one origin. In every case, the source must validate the structure of each SID before compressing it.

The checks are deliberately mechanical. The Locator-Block length cannot be zero. The combined Locator-Node and Function length cannot be zero. The Argument length must equal the space left after the locator block, locator node and function are subtracted from 128 bits. If the arithmetic does not close, the structure is treated as unknown and the SID is not compressible.

This refusal is a feature. A source does not have to reject the entire policy merely because one instruction cannot be packed. A compressed segment list may combine CSID sequences with ordinary uncompressed SIDs. The safe fallback is visible and local: retain the full representation for the instruction whose structure cannot be proved.

The rule captures a useful separation of powers. A controller may choose a path, but it cannot make malformed length information true by declaring the path important. A configuration system may supply a SID, but it cannot force the source to compress an unknown structure. The source owns the final encoding decision because it is the node that will place the executable list in the packet.

RFC 9800 likewise leaves the derivation of the original uncompressed path outside scope. Metrics, exclusions, service objectives and fast-reroute intent are decided elsewhere. Compression is applied after those choices and must preserve them. This keeps an encoding standard from becoming an undeclared policy engine.

The control plane becomes a structure ledger

The refusal test is only as useful as its inputs. RFC 9800 therefore requires the SRv6 SID Structure to be signaled for its new SIDs. The endpoint that advertises a locally instantiated SID must report length values that match the actual local format, and it must advertise the Argument bits as zero.

Those fields can travel through SRv6 extensions for IS-IS, OSPFv3, BGP, BGP-LS or PCEP-related workflows. A controller can provide an uncompressed ordered list with behavior and structure, leaving the source to perform the final compression. What the protocols distribute is not proof of successful forwarding; it is the evidence needed to decide whether compression is legal.

That distinction changes troubleshooting. When an uncompressed policy works and a compressed one fails, the operator should not begin with an abstract argument about SRv6. The sharper questions are: Which structure did the endpoint instantiate? Which structure did it advertise? Which version did the controller retain? Which flavor did the source support? Did the source validate the same lengths that the forwarding node uses? Did a software change alter one of those records without withdrawing the old capability?

A field can be syntactically present and operationally stale. The source can calculate 128-LBL-LNL-FL correctly from the wrong inventory and still build the wrong packet. The standard supplies deterministic rules, but the organization must keep the facts feeding those rules current.

A boundary can change the shared prefix without becoming global authority

A CSID sequence normally shares one Locator-Block. That is the source of much of the saving: common high-order bits do not need to be repeated for every instruction. A path crossing routing domains, however, may enter a different block.

RFC 9800 introduces End.LBS and End.XLBS for that transition. End.LBS swaps the locator block when the boundary lies on the endpoint itself. End.XLBS combines the swap with a specific Layer 3 cross-connect when the boundary is on an adjacent link. In both cases, the target locator block is a local property of the instantiated SID.

The means by which the source learns that target block is outside the RFC. It might be configured or signaled by a controller. This omission is not an invitation to guess. It marks an organizational interface: someone must own the block mapping, publish it to the source, version it with the boundary configuration and withdraw it when the relationship changes.

The mechanism is therefore a good example of local authority inside a portable contract. The RFC defines how a valid swap is executed. The endpoint controls its local target property. The source needs a trustworthy record of that property. No global registry decides the commercial or operational meaning of the boundary, yet two implementations can still agree on the packet transition.

Numbering space is part of the compression budget

Compression has a capacity trade. A shorter CSID leaves more room in a container for additional instructions, but provides a smaller identifier space. A longer CSID provides more allocation flexibility and less packing efficiency. RFC 9800 does not declare one universal answer. It recommends consistent locator-block and CSID lengths within a routing domain so that the chosen trade remains understandable.

The document also distinguishes a Global Identifiers Block from a Local Identifiers Block. GIB values are shared among endpoints under a locator-block space and can therefore be consumed across the domain. LIB values are unique per node. The recommended discipline reserves shared space primarily for genuinely global segments, such as node identity, while using local space for services, adjacencies and cross-connects.

This is allocation policy expressed close to the forwarding mechanism. An operator that spends global identifiers on every local function may exhaust the shared space sooner. An operator that maximizes compression with very short fields may later discover that the numbering plan cannot accommodate growth. Packet efficiency and namespace durability draw from the same finite design.

Filsfils's place in a collective record

The RFC Editor record names Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Bruno Decraene and Francois Clad as the authors of RFC 9800. The document emerged from the IETF SPRING working group and updates the earlier IPv6 Segment Routing Header specification. Its registered behaviors are now recorded in IANA's Segment Routing registry.

Cisco's public author page identifies Filsfils as a Cisco Fellow and describes a long Segment Routing record. That is useful source-dated context, but the RFC remains collaborative. A company biography cannot turn working-group text, peer review, implementation choices and operator responsibility into one person's private authority.

The bounded attribution is still meaningful. Filsfils is named on the architecture that introduced SR, on the SRH and SRv6 behavior work that the compression design updates, and on RFC 9800 itself. His public record connects the broad idea of an ordered instruction list to the less glamorous problem of carrying that list efficiently without changing its meaning.

That last problem is where standards prove their value. Repetition can be removed only when the common part is named. Instructions can share a container only when their lengths and scope are known. A boundary can rewrite the shared prefix only when the local target is explicit. The packet becomes smaller because the surrounding contract becomes more exact.

Sources