Summary

  • RFC 3970 declared a traffic-engineered tunnel up when at least one of its paths was up. Separate objects measured tunnel uptime and primary-path uptime, so the aggregate state did not prove which path carried traffic.
  • The MIB kept configured, computed and signaling-recorded routes distinct, while optional, disabled-by-default and rate-limited notifications plus wrapping or discontinuous counters could not constitute a complete event ledger.

An operator looking at a single field wants a single answer. Is the tunnel up? In January 2005, RFC 3970 supplied that answer—but also supplied enough neighboring fields to show why it was incomplete. A traffic-engineered tunnel was a logical object instantiated by one or more paths. It was up when at least one path was up. The primary path could be down while an alternate preserved the tunnel-level result.

That was not a defect in the state model. It was the purpose of aggregation. The mistake would be to promote the aggregate into evidence it never contained. RFC 3970 exposed teTunnelTimeUp and teTunnelPrimaryTimeUp separately. An observer could calculate how much time the tunnel operated and how much of that time it operated on its primary path. The two counters existed because “available” and “on the intended path” were different claims.

The specification defined a Management Information Base for traffic-engineered tunnels such as MPLS label-switched paths. Its requirements setting followed RFC 2119; its object machinery came from SMIv2 in RFC 2578, RFC 2579 and RFC 2580. The wider management architecture was described by RFC 3411 and the applicability guide in RFC 3410. Those foundations matter because a MIB is a managed projection, not the network itself.

Four route truths occupied different rows

RFC 3970 divided its model into tunnel, path and hop tables. A tunnel was logical. Paths instantiated it. Ordered hops described a path. Within that hierarchy, the standard resisted a tempting collapse.

The configured route recorded what management asked for. The computed route recorded what an implementation-dependent constraint algorithm selected. The recorded route represented what the signaling protocol reported as actually used. A zero value meant there was no computed or recorded route. Beyond all three sat the forwarding counters and direct service observation.

These were not redundant copies. An operator could configure a loose hop; an algorithm could fill in a sequence satisfying bandwidth and administrative-group constraints; signaling could establish something different or nothing at all. The traffic-engineering requirements of RFC 2702, the RSVP-TE mechanisms in RFC 3209 and the CR-LDP history in RFC 3212 were related layers, not a licence to infer one layer from another.

Path state sharpened the separation. down meant signaling failed. dormant described a backup not signaled. ready meant signaled but not yet carrying traffic. Only operational meant signaled and carrying traffic. A successful control-plane act therefore had its own state before data-plane carriage began.

The MIB applied only at the ingress. The ingress was expected to use a protocol such as RSVP-TE to tell other routers what they needed to set up the tunnel; extension to other points was left for future study. A complete row at the ingress did not certify every transit implementation or egress outcome.

A snapshot was not a timeline

RFC 3970 provided packet and octet counters, transition counts, path-change counts and timestamps. It also documented why none should be read without continuity metadata. Packet and octet counters could reset when the management subsystem was reinitialized and at other times. teTunnelDiscontinuityTimer marked the latest such discontinuity. A positive delta across an unexamined reset boundary could be nonsense; a smaller number did not prove traffic had reversed.

Tunnel age, total time up and primary time up used TimeTicks. They wrapped after roughly sixteen months. The RFC explicitly presented them as interval measurements and instructed the management station to account for wrap. The arithmetic for an uptime percentage therefore required two observations, their timestamps, the agent's continuity and wrap handling. One large absolute number was not an eternal record.

Notifications were intentionally lossy as history. Up, down, active-path-change and reroute notifications each had to be limited to no more than one per minute when change was rapid. Notifications formed an optional conformance group and were disabled when teNotificationEnable was false, whose default was false. A collector that received no trap could be looking at stability, disabled generation, optional-function absence, delivery loss or a throttled interval.

The distinction between two notification types was equally revealing. “Changed” meant that the active path changed or another path became active. “Rerouted” meant that the active path stayed the same while its route changed. Path identity and route identity were separate even within the event vocabulary.

A free index was an invitation, not a reservation

To create a tunnel, a management application first read teNextTunnelIndex. Yet two applications could read the same candidate. Only when an SNMP SET arrived did the agent decide whether the value was still unused. One contender could succeed and the other fail, forcing a reread. The read supplied a plausible next value; it did not grant ownership.

Paths and hop lists followed similar row-lifecycle mechanics. Some modifications required placing the relevant tunnel or path notInService, changing properties and returning it to active, which could re-signal paths. RowStatus=active was an instruction about the conceptual row's management lifecycle, not a receipt that packets had crossed the network.

Conformance also came in layers. A minimal implementation could expose all mandatory objects read-only. Full compliance supported their stated write capabilities. Notifications remained optional. Saying “implements RFC 3970” therefore did not establish that a manager could create tunnels, receive every event or alter a route.

The MIB could associate a TE tunnel with the Interfaces MIB and, conditionally, the IP Tunnel MIB. It imported MPLS textual conventions from RFC 3811. Those joins gave management objects common identifiers and types; they did not make an interface row, an IP encapsulation, a signaled path and a delivered application one fact.

Read access could reveal; write access could reroute

The security section treated management visibility as power. Changing administrative groups altered the meaning of include and exclude constraints. Changing path tables could alter bandwidth, status and route. Unauthorized writes could cause flapping or disruption. Unauthorized reads could expose tunnel endpoints, traffic volume, path properties and routes—commercially sensitive material for some providers.

RFC 3970 therefore recommended the authentication and privacy mechanisms of SNMPv3 and discouraged earlier versions. But cryptographic authentication still answered only who reached the management service. The operator had to authorize which principals could GET or SET which objects. Identity, permitted action and network result remained distinct.

The maintained record—the RFC Editor information page, errata search and IETF Datatracker—establishes status and reported corrections. RFC 9141 later repaired an obsolete working-group archive reference in the contact information. None of those sources measures deployment, vendor behavior, availability or an incident.

The durable lesson is not that the MIB lacked truth. It carried several narrow truths at once. Tunnel state summarized paths; path state separated signaling from carriage; route objects preserved successive decisions; counters required continuity; notifications traded completeness for operational restraint. The management system became trustworthy only when each value was allowed to say exactly what it had observed—and no more.

Sources