Summary

  • RFC 9831 lets Segment Types I, J and K include an SRv6 SID field whose value is zero when a controller wants to express desired endpoint behavior or SID structure without specifying the SID itself.
  • The S flag proves that a field is present; it does not prove that the field contains an executable SID. The headend still resolves the node or adjacency through its own SR knowledge and may reject a missing or mismatched result.
  • An audit-worthy chain therefore preserves flags, raw values, topology context, resolved SID, verification reason, selected path, installed state and packet observation instead of collapsing them into one green “SID received” status.

Sixteen zero octets can carry a decision

The useful surprise in RFC 9831 is not that a field may be optional. Protocols are full of optional fields. The surprise is that presence and supply are intentionally different states.

For SRv6 Segment Types I, J and K, the S flag says that a 16-octet SID field is present. A controller may fill that field with the IPv6 zero value when it wants to indicate a desired endpoint behavior or SID structure without specifying the SID. The receiver has bytes, length and a positive presence signal. It still does not have the executable identifier.

That zero is not interchangeable with an absent field. If the SID field is absent, the associated behavior-and-structure block must also be absent. If the field is present as zero, the controller can carry that additional context. A third state exists when the field contains a nonzero SID. Three wire states can therefore represent three different allocations of work: describe only the node or adjacency; describe it plus desired behavior or structure while delegating the value; or supply a concrete value for the receiver to check and use.

A monitoring system that reduces all three states to sid: null destroys the controller's decision. A system that reduces the second and third to sid_field_present: true invents an executable value that never arrived. The minimum accurate receipt retains the S and B flags, the raw 128 bits, the segment type and the rest of the identifying context.

“Explicit path” does not mean every value was explicit

RFC 9831 says the Segment List sub-TLV encodes a single explicit path toward an endpoint. Each Segment sub-TLV is one element of that path. It is tempting to read “explicit” as “ready to push into a packet.” Types C through K show why that shortcut fails.

Types C and D can name a node by IPv4 or IPv6 address for SR-MPLS. Types E through H can name links through node addresses, link addresses and interface identifiers. Types I through K do the equivalent work for SRv6 nodes and adjacencies. These are typed references. RFC 9256 requires the headend to resolve them into an SR-MPLS label or SRv6 SID.

The path is explicit at the level of intended elements and order. Its executable representation may still depend on the receiver's current view of which node originated a prefix, which interface identifies a link, which adjacency a local and remote pair denotes, and which SID corresponds to that context. A controller can fix the route's grammar without freezing the receiver's entire topology into the advertisement.

That is a useful form of indirection. It also creates a dependency that should never disappear from the evidence. Two headends can receive identical bytes and resolve them differently if their SR information differs. One can resolve a current SID while another has no matching entry. A later investigation that preserves only the advertised segment list cannot explain the difference.

Four flags divide four kinds of authority

The A, S, B and V flags are compact, but they do not all answer the same question.

The A flag says that the SR Algorithm field is meaningful for the segment types to which it applies. When A is not set, the sender must put zero in that field and the receiver must ignore it. This zero is padding with no asserted algorithm, not a delegated algorithm request. The same numeric surface—zero—therefore has a different meaning from the all-zero SID allowed by Types I, J and K.

The S flag says a SID field is present. It says nothing by itself about whether that value is zero, whether a nonzero value matches the described node or link, or whether the receiver can use it.

The B flag says the SRv6 endpoint behavior and SID structure are present for Types B, I, J and K. That block cannot float free of a SID field. Yet its presence still need not accompany a specified nonzero SID, because the included SID field may be zero. B can therefore describe constraints or expectations for a value that the receiving headend must finish resolving.

The V flag requests SID verification by SR Policy Manager. It is a request to perform a check, not a receipt that the check passed. Recording V=1 as “verified” would turn an instruction into a result.

These distinctions are small enough to fit in one octet and consequential enough to split accountability among controller intent, protocol encoding, receiver resolution and receiver verification. A dashboard that paints all four as one validity indicator loses the very boundary the flags make inspectable.

The receiver is not a passive decoder

RFC 9256 describes an SR database, or SR-DB, as a conceptual collection of information that supports path computation and validation. It may draw on link-state, topology and other sources; an implementation is not required to create a literal new database with that name. What matters is that the headend possesses a local evidentiary context against which a reference can be resolved.

Verification can fail in several distinct ways. The headend may be unable to find a supplied SID in its SR information. It may resolve the context for a Type C–K segment and find that the resulting SID differs from the value the controller supplied. It may be unable to resolve a non-first segment at all. Those failures should not be collapsed into “bad route.” One indicates missing local knowledge, another a conflict between the advertised value and local context, and another an unresolved step in an ordered path.

The multi-domain boundary makes the allocation of authority more explicit. RFC 9256 recognizes that a headend may not be able to verify reachability for SIDs in remote domains. For such unverifiable segments, Types A or B must be used; the first SID must always be reachable. The protocol does not pretend that a local resolver has omniscience. It changes representation when contextual verification cannot travel far enough.

The headend is therefore an adjudicator, not a serialization endpoint. It interprets which fields matter, looks up context, resolves missing values, compares supplied and resolved values, validates the segment list, and later decides whether the candidate can become active. Authentication of the BGP peer can protect who sent the message. It cannot make the sender's node address, interface identifier, behavior or topology view correct.

Mixed technologies expose the validation boundary

RFC 9831 carries types for both SR-MPLS and SRv6, but RFC 9256 makes a segment list that mixes those two technologies invalid. BGP can transport the individual sub-TLVs and their lengths. The SR Policy layer still has to judge the list as a whole.

This is another reason not to treat successful parsing as successful execution. Length rules can establish that the expected octets arrived. Flag rules can establish which fields are to be interpreted. Type rules can establish whether a field describes a node, an adjacency, a label or an SRv6 SID. None of those isolated checks proves that the ordered list is coherent, locally resolvable or installable.

RFC 9830 already places explicit-path semantic validation outside BGP and inside SRPM. RFC 9831 says its extensions do not change SR Policy operations or fault management. Round 205 examined the broad authority boundary between BGP carriage and SRPM/data-plane action. The narrower issue here lies inside the carried description: even before candidate selection, a present field can be a request for local completion rather than a finished forwarding instruction.

Code points coordinate grammar, not reality

IANA records the Segment List sub-TLV values for Types C through H and I through K, as well as the A and S flag bits. Those allocations keep senders and receivers from assigning incompatible meanings to the same bit positions. They are essential infrastructure for interoperation.

Registration does not show that a particular router implements every type, that its SR information is current, that a controller chose the correct node, that an interface identifier still denotes the intended link, or that the resulting SID reached the forwarding plane. Experimental publication likewise establishes a reviewed design for implementation and evaluation, not a deployment census.

The distinction matters most when an operations product wants one simple answer. “Supported” may mean that a parser recognizes Type J. “Resolved” may mean that local context produced a SID. “Verified” may mean that the supplied and resolved values agree. “Active” may mean that SRPM selected the candidate. “Installed” may mean that the forwarding plane accepted it. “Observed” may mean that a controlled packet followed the intended effect. No code point authorizes those words to become synonyms.

A receipt chain for partial specification

The minimally useful controller receipt stores the intended policy, segment order, type, node and adjacency context, A/S/B/V flags, field lengths, raw values, controller identity and configuration version. It should say explicitly whether the controller supplied a nonzero SID, supplied zero to delegate resolution, or omitted the field.

The headend resolution receipt adds the sources and version of its current SR information, the resolved label or SID, the lookup time and any ambiguity. The verification receipt records whether a supplied value was found and matched, whether a reference could be resolved, whether technology mixing invalidated the list, and the reason for rejection.

The operational chain then continues. Candidate validity is not active selection. Active selection is not forwarding installation. Installation is not packet observation. Packet observation is not a customer or application result. Those later receipts may all be green, but none can be inferred from the fact that sixteen octets existed in a BGP attribute.

The practical reward is not bureaucratic volume. It is the ability to assign a failure to the correct handoff. If a controller deliberately delegated resolution, an absent headend mapping is not a malformed controller SID. If a controller supplied a nonzero SID that disagrees with current context, the problem is not merely “route unavailable.” If the resolved and verified segment never reaches forwarding, the resolver should not be blamed for the next boundary.

Sources