Summary

  • RFC 8362 sets the OSPFv3 U-bit on its Extended LSAs so a router that does not recognise their function can still store and flood them according to the encoded scope. A matching LSDB entry is therefore evidence of carriage, not of interpretation, feature enablement, SPF use, RIB selection or packet forwarding.
  • Acee Lindem co-authored RFC 8362 with Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem and Fred Baker. The standard also separates unknown optional information from malformed input: unknown TLVs are ignored, while an incorrectly encoded Extended LSA must not be installed, acknowledged or flooded.

One database, unequal understanding

Picture three routers in one OSPFv3 area. The first originates an Extended Router-LSA containing information defined by an extension that the third router supports. The middle router predates that extension. It does not know the LSA function code, cannot interpret the new fields and cannot use them to calculate the extension's result. Yet the LSA can reach the third router through it.

This is not an accidental tolerance. OSPFv3 places a U-bit and flooding-scope bits in the LS Type. RFC 5340 says that an unrecognised LSA with U=0 is treated as though it had link-local scope. With U=1, an unrecognised LSA is stored and flooded according to the scope encoded in its type. RFC 8362 assigns its Extended LSAs new function codes—adding 32 decimal, or 0x20, to the corresponding base function—and requires the U-bit to be set.

The middle router is doing real work. It checks enough structure to accept the LSA, maintains it in the link-state database and participates in reliable flooding. But it is a custodian, not a semantic witness. If an operator finds the LSA in that router's database, the defensible statement is narrow: this router received and retained this identified advertisement within OSPFv3's rules. The observation does not prove that the router implements the advertised extension or acted on it.

That distinction matters because routing dashboards often collapse four different claims into one green indicator:

  1. The bytes arrived and a well-formed LSA entered the LSDB.
  2. The implementation recognised the LSA or TLV grammar.
  3. A feature was enabled and used the recognised information in a decision.
  4. The decision reached the RIB, FIB and packets.

RFC 8362 intentionally allows the first claim without the other three. A database-presence query cannot close the gap by itself.

The envelope changed so the contents could grow

The older OSPFv3 Router-LSA, Network-LSA, Inter-Area-Prefix-LSA, Inter-Area-Router-LSA, AS-External-LSA and Link-LSA have fixed formats. Adding information to a fixed body is hard to do without coupling future capabilities to a historic layout. RFC 8362 defines Extended versions whose variable information is carried in type-length-value structures. A TLV gives a feature a named container; sub-TLVs allow finer additions inside it.

The design solves two separate problems. The new LSA function codes let a router distinguish the extensible envelope from the legacy one. The U-bit lets that envelope cross a router that has not yet learned its meaning. Those mechanisms create room for incremental deployment, but they do not define what every future extension should do when only part of the topology supports it. RFC 8362 explicitly leaves that question to the specification that defines the new TLV or sub-TLV.

Unknown information inside a known Extended LSA has its own rule. Unrecognised TLVs and sub-TLVs are ignored during parsing and processing. “Ignored” is not the same as “deleted from the protocol” and not the same as “supported”. A router may preserve the surrounding LSA for flooding while declining to attach meaning to a component. The extension author still has to say whether partial deployment is harmless, limits the feature or invalidates the intended outcome.

Later work demonstrates why the distinction remains live. RFC 9492 uses OSPFv3 Extended LSAs for application-specific link attributes. It separates the advertisement of attributes for an application from enabling that application on a link. A receiver can therefore observe structured information without acquiring authority to infer that the associated application is active everywhere the LSA travels.

Unknown is not malformed

Forward compatibility depends on tolerating new, well-formed meanings. It does not require circulating broken encodings. RFC 8362 draws the line sharply: if an Extended LSA has inconsistent length information or another encoding error, the receiving implementation must not install it in the LSDB, must not acknowledge it and must not flood it. The error should be counted and logged.

This creates three operational response classes rather than one generic “unsupported” bucket:

  • Known and valid: parse the defined structures and apply only the behaviour authorised by the relevant extension and configuration.
  • Unknown but well formed: retain and flood within the encoded scope where the U-bit rule applies, while making no claim of semantic participation.
  • Malformed: quarantine from the LSDB and flooding process, then expose the rejection as operational evidence.

Confusing the second and third classes produces opposite failures. Dropping every unknown type breaks forward-compatible flooding and can prevent newer routers from exchanging valid state across an older one. Flooding malformed input as though novelty excused structural failure enlarges the fault domain. The useful control is not “accept unfamiliar” or “reject unfamiliar”; it is a parser and telemetry path that can distinguish novelty from invalidity.

The language of evidence should preserve that distinction. A counter for malformed Extended LSAs supports a rejection claim. An unknown-LSA view supports a custody claim. A decoded TLV view supports a recognition claim. None alone proves that a route was selected or traffic changed.

What identifies the thing that travelled

Even “the same LSA” needs discipline. RFC 5340 identifies an LSA by LS Type, Link State ID and Advertising Router. Sequence number, checksum and age help determine which instance is current. The checksum omits the LS age field, while age advances as the advertisement is held and flooded.

It is therefore safer to correlate protocol identity and instance data than to promise byte-for-byte persistence at every hop. An operator seeking a carriage receipt should record the type, scope bits, advertising router, link-state ID, sequence number and checksum, together with the observation time and receiving interface or area. The LS age can support the path narrative, but it should not be mistaken for an immutable payload byte.

That receipt can answer whether an older transit router preserved reachability between capable endpoints. It cannot prove that every observer decoded the same sub-TLV, applied the same policy or installed the same forwarding state. Those are separate joins to capability, configuration, calculation and packet evidence.

Two migrations, neither certified by presence

RFC 8362 describes a full migration in which legacy and Extended LSAs operate in separate OSPFv3 instances. The extended instance initially receives a less preferred administrative distance. Operators compare the resulting RIBs, change the preference when satisfied, verify again and only then remove the legacy instance. The sequence treats the RIB comparison as a gate rather than assuming that successful flooding makes both instances equivalent.

The document also allows a sparse-mode deployment. Legacy LSAs continue to drive ordinary SPF calculation, while Extended LSAs carry only information needed by new functionality. This can avoid the cost of two complete instances, but it makes the extension's partial-deployment semantics decisive. A few visible Extended LSAs do not reveal whether capable routers form the required topology, whether all necessary advertisements exist or whether the new function affects a decision.

Both approaches need more than an LSDB screenshot. Full migration needs a route-by-route exception ledger before preference changes and again before legacy withdrawal. Sparse mode needs a capability and adjacency map, an inventory of required TLVs, and evidence of the feature outcome at the endpoints that use it. Carriage is one checkpoint in each method, never the completion certificate.

The management model preserves the boundary

RFC 9587, published in 2024 and also co-authored by Lindem, defines a YANG model for OSPF. Its OSPFv3 state includes an extended-LSA-support control whose default is false, and operational representations for unknown TLVs and sub-TLVs that expose their type, length and hexadecimal value.

Those fields are valuable precisely because they do not pretend that raw visibility equals meaning. A collector can show that opaque information existed, where it was observed and whether extended support was configured. It still needs implementation capability, feature state, SPF or application output, RIB/FIB evidence and—where the claim concerns service—packet observation to establish consequences.

Management data can also lose authority as it moves. A polling interval may miss a short-lived rejection. A controller may normalise away scope bits. A database may retain an old LSA after a feature was disabled. Evidence should retain collection time, source router, model path and protocol identity so that a later report does not turn an observation into a timeless fact.

Acee Lindem as a bounded authorial thread

RFC 8362 was published in April 2018 by Acee Lindem, Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem and Fred Baker. It updates the OSPFv3 base specification in RFC 5340 and the address-family extension in RFC 5838. The current IETF Link State Routing working-group page lists Lindem as one of its chairs; that is a dated organisational role, not ownership of an open standard.

The record supports a precise claim about Lindem: he participated in collective standards work that makes extensible OSPFv3 state observable and deployable across unequal implementations, and later helped describe how such state can be represented operationally. It does not support calling him the sole inventor of Extended LSAs, the author of every later TLV, or the controller of vendor behaviour and network deployment.

That bounded attribution strengthens the technical lesson. Consensus produced a mechanism with deliberately divided authority. An originator controls what it advertises. The protocol controls how a valid unknown envelope travels. An implementation controls what it recognises. Configuration controls which features may act. Routing and forwarding systems control the installed consequence. Operators control what evidence they retain. No single LSDB row can stand in for all six.

A receipt for semantics, not just transport

A defensible operational record links the claims instead of compressing them:

  1. Carriage: protocol identity, instance data, scope, arrival time and the routers on which the LSA was retained.
  2. Recognition: implementation and version evidence showing which LSA, TLV and sub-TLV grammars each router understands.
  3. Eligibility: configuration proving that the relevant extension or application is enabled where the specification requires it.
  4. Use: SPF, application or policy output showing that the recognised information entered a decision.
  5. Installation: RIB and FIB evidence identifying the resulting routes, next hops or attributes.
  6. Effect: bounded packet or service observations tied to the same change.
  7. Rejection: malformed-input counters and logs showing what never entered the flooding system.

The first line is not a weak form of the sixth. It is a different fact. RFC 8362 makes that difference visible by design: sometimes the most correct thing a router can do with information it does not understand is carry it faithfully to one that does. Reliability begins by giving that custody its proper credit—and no more.

Sources