Summary

  • RFC 5330 counts TE LSPs signalled with bandwidth equal to zero across a link. It explicitly allows management-configured and provisioned LSPs to be omitted, so the integer is not a complete census unless the originator's inclusion policy is known.
  • Absence of the optional sub-TLV means absence of information, not zero. A count does not establish byte load, reserved capacity, backup readiness, affected services or outcome; each of those claims needs its own dated receipt.

A precise change with no physical event

Suppose a router upgrade changes only the source of configuration. Before the cutover, all zero-bandwidth TE LSPs are created through one signalling workflow and enter the advertised count. Afterwards, a management controller provisions part of the same population through a path that the originator elects to omit. The LSP inventory remains stable. Traffic remains stable. The RFC 5330 value falls.

That is not necessarily a faulty advertisement. Section 1 of RFC 5330 says that unconstrained TE LSPs configured and provisioned through a management system may be omitted from the reported count. The standard defines a field while leaving a legitimate local boundary around its population.

An observability system that stores only link, time and integer cannot explain the change. It has retained the answer and discarded the question that produced it. “51” is reproducible only when the evidence also identifies the originator, the signalling and provisioning paths included, the omission rule, the policy version and the time at which that rule became active.

The lesson is not that the count is untrustworthy. It is that a trustworthy count can still be incomparable with the value beside it.

Zero belongs to the signalling request

RFC 5330 defines an unconstrained TE LSP as a TE LSP signalled with bandwidth equal to zero. The zero is part of the RSVP-TE request semantics used to establish the path. It does not say the path carries zero packets. It does not say the link has zero load. It does not reserve zero business value, create infinite capacity or remove failure exposure.

The motivating model makes the distinction concrete. Operators may build a full mesh of these LSPs for local protection with MPLS TE Fast Reroute. Traffic routed onto them can follow the IGP shortest path when the TE metric matches the IGP metric. A path can therefore request no bandwidth reservation and still carry traffic whose interruption matters.

The advertised count answers a deliberately narrow question: how many TE LSPs in the originator's reported population were signalled with a bandwidth value of zero across this link? It does not answer how much traffic those LSPs carry or how unevenly the traffic is distributed among them.

Calling the value “zero-bandwidth tunnels” in a user interface invites a categorical mistake. “Zero reserved bandwidth” is accurate. “No bandwidth,” “idle,” and “free capacity” are different claims.

The standard supplies an input, not a balancing verdict

RFC 5330 arose from a practical problem in symmetric networks. Multiple equal-cost paths can have the same IGP and TE cost. For zero-bandwidth LSPs, reservable bandwidth is not an effective tie-breaker. The number of unconstrained TE LSPs across each link can provide another input.

But the RFC is careful about the inference. It says algorithms can be designed by making statistical assumptions about aggregate traffic carried by a set of unconstrained LSPs. It then places the specification of those load-balancing algorithms outside its scope.

That boundary matters. A controller may decide that fewer LSPs probably means less aggregate load. Another may use byte counters, latency, risk groups or historical demand. A third may decline to reoptimise at all. RFC 5330 coordinates the field; it does not certify any of those choices.

The evidence chain must therefore retain the count used, the population contract, every other input, the algorithm and version, candidate paths, the selected action and the observed result. A balanced integer is not a balanced network. Two paths with 40 LSPs each may carry radically different traffic because the flows behind those paths are not exchangeable units.

An absent field is not a zero field

The Unconstrained TE LSP Count sub-TLV is optional in both its IS-IS and OSPF forms. RFC 5330 says its absence should be interpreted as an absence of information about the link.

This is a strong semantic instruction. A missing sub-TLV must not be normalised to numeric zero merely because a database column is non-nullable or a charting library prefers a baseline. Zero says the reported population was empty. Absence says the originator supplied no value through this mechanism.

Those states lead to different decisions. An optimiser that reads absence as zero can steer new paths towards the least-observed link. A failure model can declare that no unconstrained LSP is exposed. An audit can celebrate a reduction that was only a loss of telemetry.

The minimum data model therefore needs a presence state independent of the integer. It should distinguish at least present-and-zero, present-and-positive, absent, malformed, unsupported and not observed. Collapsing those states is not tidying data. It is manufacturing evidence.

The first duplicate governs the receiver

For IS-IS, RFC 5330 assigns an optional two-octet value in sub-TLV type 23. For OSPF, it assigns an optional four-octet value in sub-TLV type 23 inside the TE Link TLV. In both cases, the field must not appear more than once in the relevant container. If another instance is present, the receiver processes only the first.

This creates a forensic trap for generic telemetry software. Many decoders turn TLVs into a dictionary keyed by type. A last-write-wins map presented with values 12 and 19 will retain 19. A conforming receiver will act on 12. Both dashboards may then look internally consistent while describing different facts from the same packet.

The remedy is to preserve ordered raw instances before normalisation. The parse receipt should record the container, byte offsets, declared lengths, every encountered value, the selected first instance and the reason later instances were ignored. Once a pipeline discards order, the receiver's decision cannot be reconstructed from the normalised row.

An IANA registry entry helps the decoder know what type 23 means. It does not prove which bytes arrived, which instance controlled, or whether a device used the result.

Freshness can conceal a sampling policy

The count can change whenever an unconstrained LSP is established, moved or removed. Flooding every small change immediately, however, may create undesirable protocol churn. RFC 5330 leaves LSA and LSP origination triggers outside scope and warns against systematic flooding at excessively fine granularity.

Consequently, a recent advertisement may still represent a sampled or thresholded view. Sequence number and age prove facts about the protocol object. They do not reveal the local trigger policy, how many unadvertised changes accumulated, or whether the count was recomputed from a complete source.

A useful count receipt needs both protocol freshness and production semantics: origin time, observation time, refresh context, trigger threshold or batching rule, last recomputation time and population-policy epoch. Monitoring should alert when a count remains unchanged across known LSP churn, not automatically conclude that the network is stable.

This is another reason not to compare raw integers across implementations or domains. One may originate on every event, another after a threshold, and a third on a timer. The values can differ temporarily without either side violating the shared field definition.

A failure count is not a customer count

RFC 5330 notes that the field can help evaluate how many unconstrained TE LSPs would be affected by a link failure. That use is valuable, but the noun remains LSP.

One LSP may carry many services; another may be idle. Several LSPs may share one facility-backup tunnel. A one-to-one protection design and a facility-backup design create different relationships between primary paths and backup resources. A backup can be signalled yet lack sufficient capacity under a particular concurrent failure. A protected path can switch locally while packets are still lost or an application misses its deadline.

The blast-radius chain therefore cannot jump from the advertised count to customers. It must join the link to the actual LSP population, each LSP to its current traffic and services, each primary to its protection association and readiness, the failure to the repair action, and the repair to observed delivery.

The count can prioritise where to investigate. It cannot close the investigation.

Count contracts make comparisons possible

The word “contract” here does not require a new protocol extension. It means the local semantics necessary to interpret the existing field without invention.

At minimum, record whether management-provisioned LSPs are included; which signalling states qualify; how make-before-break overlap is treated; when a newly signalled path enters the population; when a torn-down path leaves it; how duplicate instances are handled; which trigger policy controls origination; and which software and configuration version produced the value.

Version that contract. Bind each observation to its version. When policy changes, emit a boundary event rather than presenting the next integer as an ordinary network movement.

This follows a wider discipline in Internet coordination. The registry supplies a stable codepoint. The standard supplies minimum interoperable meaning. The originator makes permitted local choices. Running systems produce observations. None of those layers should impersonate another.

Without the contract, a central platform is tempted to impose uniformity after the fact. It guesses that all vendors include the same paths, that missing means zero and that current means instantaneous. That does not remove local variation. It hides it.

The seven receipts behind one integer

A defensible operational claim can be assembled in stages.

First, retain a wire receipt: protocol, scope, advertising router or system, link identity, LSA or LSP key, sequence, checksum, capture point and time.

Second, retain a parse receipt: container, ordered sub-TLV instances, widths, selected first instance and ignored material.

Third, retain the count receipt: presence state, value, origin time, observation time and age.

Fourth, attach the population contract: inclusion and omission rules, policy version, configuration source and activation time.

Fifth, join the actual LSP receipt: tunnel and LSP identity, ingress and egress, signalled bandwidth, path and state.

Sixth, measure traffic and protection separately: counters and intervals, backup association, readiness, shared capacity and last test.

Seventh, preserve the decision and impact receipts: consumer version, algorithm inputs, selected action, failure observation, services affected, restoration and delivered outcome.

The integer remains useful precisely because it no longer carries claims it cannot support.

Sources