Summary

  • On 25 August 2026, the IESG approved draft-ietf-idr-sr-policy-seglist-id-14 as a Proposed Standard. At the evidence freeze it remained an active Internet-Draft in the RFC Editor queue, while IANA still showed value 19 as a temporary registration.
  • The new 32-bit Segment List ID is unique only within one Candidate Path. It is not a global identity, and the same ID may remain while the ordered SID sequence changes. Operational proof must therefore bind the scoped ID to current content, accepted control-plane state, SRPM validation, forwarding installation and traffic.

A green object survived the change window

A controller opens a change window with an object called Segment List 42. It belongs to one Candidate Path and contains three ordered instructions. Telemetry, a NETCONF attachment and the assurance dashboard all use the number 42.

The controller then changes the SID sequence but keeps the ID. The dashboard remains green. The time series has no discontinuity. An operator looking only at the label can reasonably believe that the same path survived the window.

It did not. The scoped reference remained; the instructions it denoted changed.

This is an illustrative control-room test, not a reported vendor incident. It exposes the central operating question created by the IETF news: what exactly is authorized by a stable Segment List ID when the specification explicitly permits mutable content beneath it?

The answer is narrower than most inventory systems prefer. The ID can make a segment list easier to reference. It cannot, by itself, establish which path was advertised, accepted, selected, programmed or used.

What the IESG approved

The IESG announcement says revision 14 of “BGP SR Policy Extensions for Segment List Identifier” was approved as a Proposed Standard on 25 August. The Inter-Domain Routing Working Group produced the document.

At the 28 August evidence freeze, the Datatracker still described it as an active Internet-Draft. The IESG state was RFC Ed Queue; the RFC Editor was awaiting reference checking and formatting; IANA action was in progress after a version change. The draft was dated 24 August, last updated in the tracker on 26 August and scheduled to expire on 25 February 2027.

Those stages matter. Approval is a standards decision. It is not a numbered RFC, a completed IANA action or a deployment report.

The public IANA registry makes the procedural separation visible. In the SR Policy Segment List Sub-TLVs registry, value 19 still appears as a temporary Segment List ID assignment registered on 19 December 2025, expiring on 19 December 2026 and referring to an earlier draft revision. Revision 14 asks IANA to assign 19 for the finished document. At the freeze, the registry and publication process had not yet converged on that final state.

A useful answer to a real matching problem

An SR Policy can have multiple Candidate Paths, and each Candidate Path can contain multiple segment lists. RFC 9830 defines how BGP carries Candidate Path information to a headend—the node that writes the segment instructions into packets.

Without a compact identifier, a headend reporting per-list statistics may have to repeat the entire SID sequence. A controller then compares the SIDs one by one to determine which list produced the counters. The draft also describes configuration sent through YANG and NETCONF that needs to refer to a segment list learned through BGP. A small cross-reference reduces bytes and matching work.

That is a practical improvement. It also creates a tempting shortcut: once several systems share the same number, the number begins to look like the thing itself.

The encoding is deliberately modest. The optional Segment List ID sub-TLV sits inside a Segment List sub-TLV, under the SR Policy Tunnel Type in the BGP Tunnel Encapsulation Attribute. Its type is 19 and its length is six octets. Four octets hold the unsigned ID; the flag and reserved octets are sent as zero.

Values from 1 through 0xffffffff are identifiers. Zero means no identifier has been assigned and is equivalent to omitting the sub-TLV. None of those wire details grants global identity.

The Candidate Path is part of the key

The draft's most important sentence is a scope rule. A non-zero Segment List ID must be unique among the segment lists inside one Candidate Path. The same value may appear under another Candidate Path, another SR Policy or another headend without referring to the same ordered instructions.

An external reference must therefore carry the Candidate Path as well as the ID. A database keyed only by 42 has already lost required context. A telemetry platform that merges all observations for 42 can combine unrelated paths while remaining internally consistent.

Even the Candidate Path plus ID tuple is not a historical identity. The specification says the ID does not make the SID sequence immutable. A controller may update the sequence and retain the number.

That makes the identifier closer to a mutable slot than a content address. For live control, that can be convenient. For audit, incident reconstruction and configuration joins, it is dangerous unless the tuple is paired with a timestamp, revision or content fingerprint.

The control record should include the SR Policy NLRI—Distinguisher, Color and Endpoint—the Candidate Path identity, the Segment List ID, the ordered SID sequence and the moment that mapping became valid. Otherwise, two systems can agree on the tuple while referring to different revisions.

Error handling can remove the reference before the path

The extension has several distinct failure modes.

If the Segment List ID sub-TLV has a length other than six octets, the associated BGP SR Policy NLRI is malformed and RFC 7606 treat-as-withdraw handling applies. That is a control-plane outcome, not evidence that traffic safely moved to an alternative.

If one segment list contains multiple instances of the sub-TLV, the receiver uses the first and ignores the others. The duplicate instances are not treated as a malformed advertisement.

If multiple segment lists inside one Candidate Path carry the same non-zero ID, the problem is semantic and belongs to the SR Policy Module. A receiver may treat all those lists as having no ID association. The paths and their instructions may still exist while the cross-reference disappears.

Unsupported capability creates another boundary. Under RFC 9830's default behavior, a Candidate Path carrying an unknown or unsupported sub-TLV is not considered usable. In a mixed fleet, adding a seemingly optional identifier can therefore change Candidate Path usability on older headends. The draft advises advertising it selectively to nodes that support it.

A rollout inventory must separate software support, per-peer advertisement, accepted update, SRPM interpretation and usable Candidate Path. “Optional” does not mean operationally inert.

BGP carries the description; forwarding supplies the verdict

RFC 9830 is explicit that ordinary BGP processing does not validate the tunnel itself. BGP transports the Candidate Path information; SRPM performs the relevant policy validation. The architecture then has further transitions: a usable Candidate Path may or may not become active, an active path may or may not be programmed correctly, and programmed instructions may or may not carry the intended traffic.

The minimum evidence chain is therefore:

  1. exact draft or RFC and registry state;
  2. controller and headend capability;
  3. peer-specific advertisement scope;
  4. received BGP NLRI and attributes;
  5. Candidate Path plus Segment List ID plus ordered SID content;
  6. parser and SRPM validation result;
  7. Candidate Path usability and active selection;
  8. forwarding programming at the headend;
  9. counters or telemetry tied to the same content revision;
  10. observed traffic outcome.

An ID at stage five cannot authorize claims about stage ten.

The same discipline applies to cross-protocol use. RFC 9857 already carries a segment-list identifier in BGP-LS reporting, while the new draft discusses YANG/NETCONF references. Similar semantics do not create a universal namespace. Every consumer must preserve Candidate Path scope, type and freshness, then prove that its reference still denotes the content installed by the headend.

A compact identifier also concentrates sensitive meaning

The draft warns that Segment List IDs may reveal mission-critical or commercially sensitive information. A compact token can expose stable control relationships even when the complete SID sequence is withheld. Access therefore belongs inside the trusted SR domain and should be limited to trusted routers and controller applications.

Management of the ID itself is outside the document's scope. Allocation across controllers, collision prevention, reuse intervals, content revisioning, retention and rollback remain operator choices. The standard solves a wire-reference problem; it does not solve the surrounding authority model.

The implementation section cannot fill that gap. It records self-reported H3C and ZTE work based on draft version 3 and last updated in February 2025. The draft says such listings are not IETF endorsement and were not independently verified. They show implementation interest, not present interoperability or fleet adoption.

Sources