Summary

  • RFC 5329 sets the U-bit so an unrecognized Intra-Area-TE-LSA is still flooded within its area. Propagation therefore proves continuity of the distribution mechanism, not support for the TE meaning inside the LSA.
  • The LSA's Link State ID is arbitrary. OSPFv3 link identity comes from the Advertising Router and the mandatory pair of Neighbor Interface ID plus Neighbor Router ID, with address evidence helping to distinguish parallel links.

The cleanest flood can end in an empty database

Imagine an area in which every router acknowledges the same sequence and checksum. The LSA graph is green from edge to edge. A change window closes because the control-plane advertisement plainly reached every hop.

One router in the middle did not recognize the LS type. RFC 5329 still required it to flood the LSA at the defined area scope. Another router recognized the type but ignored a nested TLV it did not understand. A third parsed the known fields but had TE advertisement disabled for the area. A fourth constructed state, but its path computation never consumed that version.

None of those outcomes contradicts the green flooding graph. They expose the category error inside it. Flooding is a receipt for distribution. Recognition is a receipt for software capability. Parsing is a receipt for a particular field. Enablement is a receipt for policy. Consumption is a receipt for a decision process. They are related, but no one of them stands in for the next.

This separation is not a defect in OSPFv3. The U-bit is a continuity mechanism: older or narrower nodes need not become semantic bottlenecks for an extension they cannot interpret. The operational mistake is asking that mechanism to attest what it was designed to preserve without understanding.

An arbitrary number is not a link identity

RFC 5329 says the Link State ID of the Intra-Area-TE-LSA is an arbitrary value used to maintain multiple TE LSAs. It has no topological significance. That sentence is easy to retain in a parser and easy to violate in an inventory.

If an observability system keys a circuit by Advertising Router plus Link State ID, it can make an implementation's packaging choice look like physical topology. An originator can redistribute Link TLVs across several LSAs or choose different arbitrary IDs after restart. The underlying link may be unchanged while the dashboard reports deletion and creation.

The proper evidence chain is more specific. For OSPFv3, the mandatory Neighbor ID sub-TLV combines the Neighbor Interface ID and Neighbor Router ID. It appears exactly once in a Link TLV. Local and remote global-address sets can add evidence, especially when parallel links join the same pair of routers. Network type and originator identity provide further context.

That still does not make the tuple an organizational asset record. A Router ID is not a legal entity, an Interface ID is not a circuit contract, and an advertised address is not proof of current reachability. The tuple identifies a protocol link claim inside a particular LSDB observation.

OSPFv2 intuition becomes hazardous at the version boundary

The OSPFv2 TE extension used a Link ID whose meaning depended on link type. RFC 5329 cannot carry that model across unchanged because OSPFv3 does not use IPv4 interface addresses in the same way to identify neighbors. It says the old Link ID sub-TLV should not be sent and must be ignored when received.

This is a strong interoperability boundary. A decoder that displays the familiar OSPFv2 field without marking it ignored can give an operator a plausible but non-authoritative neighbor. A migration tool that copies it into a canonical link key can preserve the wrong evidence with great precision.

The replacement is not one new scalar. It is the pair of Neighbor Interface ID and Neighbor Router ID. The need for a pair is the point: one value locates the neighbor's protocol identity, the other locates the relevant interface context. Collapsing them recreates the ambiguity RFC 5329 removed.

Parallel links turn optional evidence into an uncertainty budget

Local and Remote Interface IPv6 Address sub-TLVs help distinguish parallel links. They may contain several global addresses and must not include link-local addresses. Yet the remote-address field can be omitted; on a multi-access network it may be set to ::.

Absence therefore has a narrow meaning: this LSA did not supply that address evidence. It does not prove that the neighbor has no address, that the adjacency is down or that only one physical path exists. A zero value in a permitted context is not a measured zero.

An evidence model should preserve the full sets, their origin, and the fact that a field was absent, prohibited, ignored or explicitly zero. It should never silently coerce all four states to null. When two parallel links share router identities, a missing supporting address widens uncertainty and should lower confidence rather than trigger a guessed merge.

First wins is a protocol rule, not a deduplication detail

The Neighbor ID sub-TLV is mandatory and exactly once. Other RFC 5329 sub-TLVs should not appear more than once; if they do, instances after the first are ignored. Unrecognized TLV types are also ignored.

A generic decoder that converts TLVs into a dictionary commonly implements last-write-wins. That can invert the RFC decision. A security appliance that sorts fields before storing them can also destroy which instance was first. The normalized record then looks cleaner than the packet while no longer representing the receiver's interpretation.

Retain ordered instances, advertised lengths, excluded padding, parser disposition and the selected instance. A downstream view may show the selected value, but it must be possible to reconstruct why that value controlled. The rejected duplicate is incident evidence, not clutter.

A stable address is still only an advertisement

The Router IPv6 Address TLV carries a stable routable address and should be reachable when the router is reachable. It must not be link-local and appears in exactly one TE LSA from a supporting router.

The phrase “should be reachable” does not create a probe result. It defines the intended property of the advertised address. A route to that address, a completed control connection, a live management plane and a successful application transaction remain separate observations.

This distinction matters during incidents. If the address remains in the LSDB after a failure, the protocol record shows what the router last advertised under the LSA lifecycle. It does not override packet loss, expiry, withdrawal or independent path evidence. Conversely, a failed ping does not by itself invalidate the syntax or identity of the advertisement.

Code points and installed software do not prove enablement

IANA records function code 10 and the relevant TLV and sub-TLV assignments. Those numbers make interoperable encoding possible. They do not say that a given router supports the feature, that the feature is enabled, or that policy permits its output.

RFC 5329's management discussion makes the control surface visible. Area TE advertisement defaults false. The interface-level disable variable matters only within an enabled area and defaults false. Effective behavior is the result of scope, interface and implementation state, not one capability flag.

An audit that finds the code point in a binary or MIB schema has found potential. An audit that reads one configuration line has found intent. Evidence of emitted LSAs, parsed state and consumer use is needed to establish operation.

Sources and evidence boundary

These sources establish protocol semantics, publication history and registry assignments. They do not establish a present deployment, named implementation, configured policy, live adjacency, TE database, computed path, reservation, forwarding result or user outcome.