Summary

  • RFC 9514 lets BGP-LS carry SRv6 node, link, Locator, SID, behaviour and structure information to consumers such as path-computation systems.
  • A Prefix NLRI with SRv6 Locator TLV 1162 is only a Locator advertisement unless Prefix Metric TLV 1155 is also present; verified Errata 7737 corrects the published RFC’s mistaken reference to TLV 1095.
  • The consumer must preserve declaration, reachability classification, SID association, computation, installation and observed forwarding as separate receipts.

The first screen in the operations room looks convincing. A BGP-LS consumer has accepted a Prefix NLRI. The object carries SRv6 Locator TLV 1162, an algorithm and a metric. The Locator appears in inventory. A path engine can join it to the node that advertised it. Nothing is malformed.

Yet one question is still unanswered: is this prefix ordinary reachability, or only the covering address space under which a node provisions SIDs?

RFC 9514 answers with a deliberately narrow test. A Locator is advertised as a Prefix NLRI with an SRv6 Locator TLV. The same object counts as ordinary prefix reachability only when it also carries the applicable Prefix Metric TLV. Without that second field, it remains only a Locator advertisement.

One corrected number changes the claim

The published text names IGP Metric TLV 1095. That is wrong. The RFC Editor’s verified errata record corrects the field to Prefix Metric TLV 1155 because 1095 belongs with a Link NLRI, while the Locator is associated with a Prefix NLRI.

This is not cosmetic bookkeeping. A consumer following the uncorrected number could search the wrong object class, mistake the Locator TLV’s own metric for the missing reachability evidence, or produce inconsistent behaviour across software versions. The correction protects a semantic boundary: “this prefix organizes SRv6 SIDs” and “this prefix is advertised as reachable” are two propositions.

The Locator TLV includes a metric copied from the underlying IS-IS or OSPFv3 Locator advertisement. That value describes the Locator declaration. It does not silently become Prefix Metric TLV 1155. Two fields can both contain something called a metric without owning the same decision right.

RFC 9514 exports an SRv6 object graph

RFC 9514 is broader than the Locator rule. It maps SRv6 information into four BGP-LS surfaces. Node attributes carry capabilities, algorithms and Maximum SID Depth types. Link attributes carry End.X, LAN End.X and link-specific limits. Prefix attributes carry Locators. A new SRv6 SID NLRI, type 6, carries each node-associated SID with its own descriptors and attributes.

The separate SID NLRI is a scaling decision. Putting every SID into one Node attribute would make the update grow with the node’s SID population and force a large update when one SID changed. Individual NLRIs let one SID change independently. They also create a lifecycle obligation: the consumer has to join the SID to the correct node, source protocol, topology identifier, endpoint behaviour and Locator epoch without treating a surviving neighbouring object as proof that the withdrawn SID still exists.

Every SID NLRI requires an Endpoint Behavior TLV. EPE PeerNode or PeerSet SIDs add peer context; the optional SID Structure TLV can state locator-block, locator-node, function and argument lengths. RFC 8986 defines the endpoint-behaviour vocabulary, while RFC 8402 supplies the Segment Routing architecture. A behaviour code is an attributed instruction, not a packet trace showing that a device executed it.

The source chain matters. RFC 9514 copies relevant fields from the OSPFv3 SRv6 extensions or the IS-IS SRv6 extensions. For BGP EPE or the Direct Protocol-ID, the local node supplies the information on its own behalf. RFC 8814 provides the BGP-LS MSD carriage used for finite node and link limits. These inputs do not become one omniscient statement merely because one consumer stores them together.

BGP checks the envelope; the consumer owns the meaning

RFC 9514 explicitly leaves semantic and content checking, including whether a TLV is associated with the right NLRI or BGP-LS Attribute, to the consumer. BGP can enforce the wire contract. It cannot certify that a Locator was meant as reachable, that a SID is still instantiated, that an algorithm is permitted by current policy or that a computed path fits the running network.

The manageability section explains the consequence: encoding or decoding errors can hide information from an SR PCE or give it incorrect information, causing optimization to fail or behave unexpectedly or inconsistently. Application handling is implementation-specific and outside the RFC. That limit is not a flaw. It identifies who must produce the next receipt.

The current BGP-LS base model in RFC 9552 helps name the roles: a producer derives and originates a topology projection, a propagator selects and forwards BGP information, and a consumer assembles and uses it. A valid update proves what crossed one interface. It does not prove what the consumer concluded.

Record the transition, not a green icon

A defensible record starts with the source protocol, producer, Protocol-ID, Identifier and Local Node Descriptors. It retains the exact Prefix NLRI, Locator TLV 1162, algorithm, Locator metric and topology epoch. It records whether Prefix Metric TLV 1155 was present, absent, duplicated or rejected, and which errata-aware rule the consumer applied.

If a SID is used, the record adds the SID NLRI, Information TLV 518, Endpoint Behavior TLV 1250, applicable peer context, optional structure lengths and withdrawal history. Computation then gets its own receipt: consumer snapshot, constraints, policy version, candidate set, selected path and time. Device acceptance, SR-policy or FIB installation and controlled packet observation follow separately.

The official trail is unusually useful because it shows both specification and repair. The RFC Editor provides the information record, plain text and XML. The Datatracker preserves the RFC history, the final draft revision and reference graph. The live IANA BGP-LS registry records the code points. Together they establish the common language and its corrected reading, not a named deployment result.

The editorial discipline comes from three disclosed Heng Lu essays: running-code primacy, minimum initial specification and voluntary adoption and reality layers. They are not IETF requirements. Their common use here is precise: do not let a standards symbol, a controller model or an installed entry impersonate an observed packet outcome.