Summary

  • The one-octet TLV Length field limits one IS-IS TLV value to 255 octets.
  • Multiple occurrences with the same type and, where applicable, the same key form one Multi-Part TLV in an IIH or in the level-specific LSP set.
  • A supporting receiver processes all occurrences; an unsupported receiver chooses one and ignores the rest, so protocol acceptance alone is not evidence of a complete object.

The failure is subtle because the packet can be valid. A large set of information is divided into occurrences, but a receiver that has no MP-TLV support does not reconstruct the set. It selects one occurrence for processing and ignores the others. The resulting object may be partial even though the LSP passed syntax checks and entered the database.

RFC 9885 addresses this with a grouping rule: occurrences with the same TLV type and, where the TLV specification supplies one, the same key are processed as a Multi-Part TLV. The rule applies to an IIH or to the level-specific LSP set. The key is not redefined by RFC 9885; it remains the key specified by the individual TLV. MP-TLV support also leaves the existing TLV encoding unchanged. This is reassembly and processing guidance, not a new wire format.

The receiver distinction is decisive. An implementation supporting MP-TLV processes information from all occurrences belonging to the same type and key. One without support processes one occurrence and ignores the others. Implementations therefore need the RFC's applicability declarations and capability advertisement to make support and scope visible. The RFC also covers deployment controls, alarms and restrictions on generation. Those mechanisms matter because sending multipart information into a population that cannot safely consume it can produce silent incompleteness.

A precise lab fixture should use one object whose encoded information is 256 octets or more, split across two occurrences of the relevant TLV. Keep the type identical and, when applicable, keep the key byte-for-byte identical. Place both occurrences in the same IIH or the same level-specific LSP set. Test a supporting receiver and an unsupported receiver separately. Verify that the first reconstructs the complete information, while the second retains only one occurrence. Then change only the key and verify that the fragments do not merge.

This fixture tests the boundary, grouping, and unsupported behavior without assuming a vendor implementation.

Theo March analysis — not an RFC requirement: partial deployment should be treated as a completeness problem, not merely a compatibility checkbox. Operators should seek evidence that every intended occurrence was received, grouped and incorporated, rather than infer completeness from adjacency or LSP acceptance. Useful evidence may include per-key part counts, reconstructed length, discard or alarm events, and before-and-after object comparisons. These are assurance practices, not claims that RFC 9885 mandates a particular telemetry model.

The frozen source supports protocol semantics and deployment considerations only. It does not establish current vendor implementation coverage, deployment prevalence, observed production failure rates, or performance or convergence impact in any named network. No such conclusion can be drawn from this briefing.

Operator decision path: first identify whether the object can exceed 255 octets; second identify the TLV type and its own key; third confirm the receiver's advertised MP-TLV capability and applicability; fourth test same-type/same-key grouping; fifth require completeness evidence and alarms; sixth restrict generation until the receiving population is confirmed; finally record the change and rollback condition. If any step is unknown, keep generation disabled or limited to a compatible scope.

Sources