Summary

  • RFC 5284 assigns USER_ERROR_SPEC Class 194 so an RSVP node that does not understand the object can forward it unchanged; survival across a path is not evidence of shared interpretation.
  • The operational meaning belongs to the Enterprise Number, Sub Org and User Error Value tuple, while logging, local action and independently verified repair remain separate receipts.

An RSVP error leaves a controller with two objects. The familiar ERROR_SPEC says that an error occurred. Beside it sits a Class 194 capsule containing an enterprise number, a team namespace and a 16-bit value. Three old nodes cannot open the capsule, yet each passes it onward without changing a byte. The destination knows the enterprise's private map and resolves the value to a precise condition.

It would be tempting to report that the network understood the error. The evidence supports something narrower. The extension survived the path. One receiver may have interpreted it. Nothing in that receipt says the transit nodes adopted the same taxonomy, that the destination selected the right response, or that the original condition disappeared.

RFC 5284 is a compact lesson in how interoperability can preserve disagreement. It adds user-defined errors to RSVP without exhausting a small global error-code space and without requiring every intermediate implementation to learn every organization's vocabulary. Its architecture creates a portable envelope around locally governed meaning. The boundary is not an inconvenience to be hidden by a dashboard. It is the control surface operators need to see.

The extension does not replace the standard shell

RSVP already required ERROR_SPEC in PathErr and ResvErr messages; RSVP-TE later required it in Notify. RFC 5284 keeps that rule intact. USER_ERROR_SPEC is additional information, not an alternative container that silently changes the mandatory message shape.

When an existing standard error code describes the condition, the user object may accompany it. When no other code applies, RFC 5284 assigns Error Code 33, User Error Spec, with sub-code 0, Further details in User Error Spec. Code 33 is a pointer to the companion object, not the private diagnosis itself. A message that uses Code 33 without carrying USER_ERROR_SPEC is malformed.

That two-part design produces a useful audit question: did the receiver accept the standard error shell, and did it also receive a valid extension object? Reporting only the outer code loses the enterprise value. Reporting only the private value loses the standard context. Treating either fragment as the complete failure state invents certainty the wire format did not supply.

The allowed message types are also bounded. The object may appear in PathErr, ResvErr or Notify. Its presence on another message must be treated as malformed. ResvConf may carry ERROR_SPEC, but RFC 5284 explicitly excludes it because that use does not carry meaningful error codes and values. A generic decoder that accepts the extension everywhere would erase a normative placement check.

Class 194 preserves bytes, not comprehension

The most consequential compatibility choice is the class number. RSVP reserves the 192–247 range for objects that an implementation which does not understand them forwards unchanged. RFC 5284 assigns USER_ERROR_SPEC Class 194, C-Type 1. An older hop can therefore keep the diagnostic capsule in motion without knowing what it means.

This is running-code compatibility in a disciplined form. The old node does not need a software update merely to avoid destroying the new object. But its forwarding behavior supplies exactly one receipt: the object was retained on the message it forwarded. It does not establish that the node recognized the enterprise, decoded the string, validated a private registry, changed local state or accepted an operational instruction.

The distinction matters in mixed estates. A packet trace at the destination may show that every byte arrived. An inventory may show five intermediate implementations. Those facts do not justify assigning five semantic acknowledgements. The topology carried an opaque object; the authority to interpret it remained at endpoints that possessed the relevant mapping.

RFC 5284 reinforces this restraint for duplicates. Implementations should ignore repeated occurrences of USER_ERROR_SPEC and forward them unchanged. Three copies are not three votes and are not automatically a more severe condition. Multiplicity is a message-shape fact, not a consensus protocol.

The namespace is part of the error value

Inside the object, a 32-bit Private Enterprise Number identifies an organization. The 8-bit Sub Org field can divide that organization's value space among teams or parallel development efforts; it should be zero when separate spaces are unnecessary. Only then comes the 16-bit User Error Value.

The complete key is therefore not 42. It is something like (enterprise E, sub-organization 3, value 42). Another enterprise can use 42 for an unrelated condition. Even two teams inside one enterprise can assign it differently. Stripping the first two fields before aggregation turns scoped evidence into a collision.

IANA's Enterprise Numbers registry makes the organizational namespace globally distinguishable. It does not globalize the private definitions beneath that number. Nor does assignment authenticate a particular sender. A receiver still needs RSVP message protection and a local authorization decision before it treats an error as a trusted basis for action.

Version is another implicit dimension. An enterprise can revise its internal mapping across software releases. A durable incident record should preserve the full tuple, the object bytes, the mapping or implementation version used by the receiver and the time of interpretation. Otherwise a later analyst may decode an old value with a new dictionary and produce a confident but false explanation.

A shared TLV shape can contain private semantics

RFC 5284 permits user-defined subobjects. Their envelope is a conventional type-length-value structure. Type and Length occupy one byte each; total length includes those fields, is at least four bytes and is a multiple of four. Those rules make the structure safely traversable.

They do not make its contents universal. The enterprise and sub-organization assign the Type and define the Value. A generic implementation may be able to skip, retain and forward an unknown subobject correctly while remaining unable to interpret a single bit inside it.

This is a valuable form of partial interoperability. Syntax supplies containment and forward progress. Namespace supplies ownership. A private specification supplies semantics. Local policy decides whether the result is actionable. Systems become brittle when those layers are collapsed into the claim that a standards-shaped object is standards-defined in every detail.

The description is for assistance, not command

The object may carry an Error Description encoded as UTF-8/Net-Unicode and padded with nulls to a four-byte boundary. Its declared length excludes padding, and zero length is valid. RFC 5284 recommends single-line printable US-ASCII when feasible so more recipients can use it easily, while retaining the UTF-8 requirement.

The standard is unusually clear about the field's authority. An implementation may not be able to display the description because of its character-set capabilities. The string should therefore be supplementary and should not contain information critical to operating the network. Critical information belongs in the numeric user error value.

That separation prevents a human-readable sentence from becoming an undocumented control API. A console can show a helpful explanation, but automation should resolve the scoped numeric value through an explicit mapping. A receiver that cannot process UTF-8 should escape it according to RFC 5137 rather than reinterpret arbitrary bytes.

Logging introduces its own risk. Error strings may contain overruns or embedded control characters. Preserving the original object for evidence and rendering a sanitized view for operators are compatible duties. Replacing the evidence bytes with the sanitized display would damage fidelity; placing untrusted bytes directly into a terminal would damage the observation surface.

One green status erases five different receipts

RFC 5284 recommends that a receiver log at least the Enterprise Number, Sub-organization, User Error Value and Error Description. An implementation capable of interpreting the content should take further action. These are adjacent requirements, not equivalent outcomes.

A useful record keeps at least five states separate:

  1. the object was received with a valid message shape;
  2. the complete namespace tuple and bytes were logged;
  3. a named mapping version produced an interpretation;
  4. an authorized local component attempted an action; and
  5. an independent signal showed whether the underlying condition changed.

The fourth state can fail after perfect interpretation. A repair command may be rejected, race with another controller or address only a symptom. The fifth state can later reverse if the condition recurs. Calling every state handled makes the system easier to demo and harder to operate.

The honest design is a receipt graph. Each transition names the actor, input, policy version, timestamp and result. The error object becomes one evidence node in that graph rather than a master switch. This also limits blast radius: a new private value can be logged safely before any automatic response is authorized.