Summary

  • RFC 9885 lets one IS-IS object span several same-type, same-key TLVs when 255 octets are no longer enough; each part must remain independently parsable and receivers must combine all parts regardless of order or LSP fragment.
  • Its new type-30 capability is deliberately informational, has no per-codepoint syntax and must not change protocol sending or receiving behavior.
  • Enablement therefore requires an external fleet record proving that every receiving implementation handles the relevant codepoint, not merely a row of advertised capability bits.

The maintenance window has not begun, but the change board is already green. Every router in the inventory appears to advertise “MP-TLV support.” The proposed change is one line: allow a traffic-engineering object to exceed the space in one IS-IS TLV. Nothing in the dashboard looks controversial.

Then one engineer asks the question the capability cannot answer: support for which codepoint, on which software image, in which receiver role?

RFC 9885 exists because an old and useful format has met a larger operating reality. An IS-IS Type-Length-Value tuple gives the Length field one octet, limiting the Value to 255 octets. New traffic-engineering attributes and larger networks can exceed that space. The RFC codifies multiple occurrences of a TLV as the default expansion mechanism where an earlier specification did not already provide another rule.

That sounds like fragmentation, but the analogy is dangerous. An MP-TLV is not a byte stream cut at arbitrary positions. Multiple tuples form one logical object only when they have the same type and the same existing object key, where a key applies. Every part must be parsable on its own. A sub-TLV or any other data unit cannot be cut between parts. If it is, the encoding is invalid.

The receiver assembles meaning, not bytes

A supporting receiver must accept the information in every part. Arrival order does not matter. The parts may sit in one LSP, in different LSP fragments, or at different positions in an IIH. Their content is processed as if concatenated, with repeated key material identifying the same object rather than creating several objects.

The distinction matters when information conflicts. A metric can belong to the fixed portion of a reachability TLV without being part of the object's key. If different parts repeat that non-key value inconsistently, the result is an error. The same is true when a sub-TLV intended to appear once occurs with competing values. Unless the defining specification gives a more precise rule, the first occurrence in the lowest-numbered LSP is used; in an IIH, the first occurrence wins.

RFC 9885 also separates receiver tolerance from sender discipline. A receiver cannot reject two 100-byte parts merely because they could have fit into one TLV. But a sender should not generate multiple parts unless the codepoint permits MP-TLV and the information actually exceeds a single TLV. If a TLV still has capacity but its current LSP does not, moving the whole TLV to another LSP is preferable to splitting it.

This asymmetry prevents local tidiness from becoming an interoperability failure. Receivers accept valid but unnecessarily divided input. Senders avoid producing it. A monitoring system that reports only “accepted” misses whether the sender followed its narrower obligation.

Type 30 is a warning label, not a handshake

Partial deployment changes the stakes. A router without MP-TLV support may select one occurrence and ignore another. If the ignored part contains link attributes used for constrained path calculation, routers can compute different views of the topology. RFC 9885 names the consequences plainly: unexpected forwarding, loops, dropped traffic and failures that are difficult to diagnose.

The RFC introduces a zero-length sub-TLV, type 30, inside the IS-IS Router CAPABILITY TLV to help operators see support for codepoints whose earlier specifications implied, rather than explicitly stated, multi-part handling. Its scope is per IS-IS level. Its role, however, is unusually narrow.

The advertisement is informational only. An implementation must not change what it sends or how it processes received information because the advertisement appeared. It is not negotiation. It is not consent. It is not a dynamic safety interlock.

More importantly, type 30 has no syntax for naming individual codepoints. The specification assumes broad support for relevant codepoints while acknowledging that real products may implement only those needed by particular deployment scenarios. A router can therefore advertise the generic signal and still leave the decisive question unresolved.

IANA's new MP columns solve a different problem. They state whether MP-TLV procedures apply to a registered codepoint. MP=Y is a property of the protocol definition, not a telemetry report from a device. It cannot establish that a specific image parses that codepoint, that generation is enabled, or that every receiver in an area behaves consistently.

The authorization record lives outside the protocol

RFC 9885 puts the residual duty on the operator. Implementations that can generate MP-TLVs should offer enable/disable controls at per-codepoint granularity because support can vary by TLV. If generation is disabled, the implementation must log both receipt of an MP-TLV and a local condition that would require generating one. Operators should not enable the feature until all implementations that will receive the advertisements can interpret them correctly.

That is a stronger gate than “all devices advertise type 30.” It requires an inventory of receiver roles, levels, versions and codepoints; laboratory or vendor conformance evidence; observation of disabled-mode alarms; and a deployment sequence that retains a rollback path. Authentication under the existing IS-IS security framework remains valuable, but authenticated input can still be misunderstood. Origin integrity and semantic capability are different records.

The standards lesson aligns with running-code primacy. A protocol registry can say that a mechanism is applicable. A router can say that it supports an implicit class of behavior. Neither symbolic statement outranks the observed behavior of the exact binary that will calculate and install routes.

Sources