Summary

  • Revision 19 defines two independent optional mechanisms: link-flap-suppression delays short carrier transitions, while dampening remembers repeated failures through an exponentially decaying penalty.
  • During a down-delay timer, the model can report the interface as up while the underlying link is actually down; a stable oper-status can therefore be stale by design.
  • Feature declarations, accepted configuration, falling penalty, restored adjacency, an active route, installed forwarding and successful service are different evidence objects and should be retained as one timed chain.

The honest mismatch

The most revealing leaf in draft-ietf-netmod-intf-ext-yang-19 is not a threshold. It is timer-running. Its down value means the interface is still reported up although the underlying link is down. Its up value means carrier has returned although the interface has not yet been reported up. The model exposes this mismatch because short-lived physical transitions and higher-layer reactions do not have to share a clock.

The feature is called link-flap-suppression, not carrier-delay. Operators may recognise the latter phrase, but the schema contains a container with down and up leaves measured in milliseconds. down waits for continuous loss of carrier before reporting failure. That pause can give an optical protection mechanism time to act, but the draft states the cost plainly: traffic may be black-holed for the configured interval and reconvergence delayed. up requires the signal to remain present and error-free before the interface is announced as usable, reducing the chance that a brief return immediately destabilises higher layers.

Suppression hides a transition only from higher layers. The read-only carrier-transitions counter should still advance when the underlying state changes, even if oper-status and last-change do not. A screen showing “up for six hours” can therefore coexist with several physical transitions. Without the counter and timer state, the screen is an incomplete account.

Two controls, two kinds of time

Short-delay suppression asks whether one transition persisted long enough to deserve propagation. The separate dampening feature asks whether repeated up-to-down events have accumulated enough history to keep the interface out of service. Each fall adds 1,000 penalty units. The penalty decays exponentially; half-life states the seconds required to halve it. Crossing suppress holds the interface down. Falling below reuse, while the underlying link is up, can release it. max-suppress-time limits the sentence when no new penalties arrive.

These numbers are policy, not diagnosis. A long half-life protects the wider control plane from repeated noise but makes old failures govern the present for longer. A low suppress threshold isolates instability sooner but risks extending an outage that an upper layer might otherwise route around. A low reuse threshold demands more quiet time before return. The model's example—60 seconds, 750, 2,000 and 240 seconds—is an illustration, not a universal profile. The presence container may also enable device-specific defaults, so an audit needs the values actually in use.

The two features can operate together. One can hide a short transition, while the other retains memory across many transitions. Their counters and states must not be merged into one “flap alarm”. A timer finishing says a debounce interval ended. suppressed=false says the local penalty gate is open. Neither says the fibre, optics, power, remote peer or intermediate path stopped causing the event.

A feature declaration is only the first receipt

YANG 1.1 uses features to make schema branches conditional. YANG Library lets a server list the features it supports. Seeing link-flap-suppression or dampening in that list is valuable: the client may expect those nodes in the advertised schema. It is not proof that the desired values were accepted on this interface, reached the configuration actually in use, or influenced the hardware event path.

NMDA gives the next distinction. Intended configuration and operational state may differ because values take time to propagate, interact with hardware or are rejected locally. A complete record therefore preserves the candidate or intended write, the returned configuration receipt, and the operational values later reported as in use. A successful validation, IESG state, or <ok>-style configuration response stops at its own layer.

The IETF Datatracker record and revision history establish that revision 19 is an active NETMOD draft submitted for Proposed Standard publication. They do not establish a deployed implementation. The model's security section requires protected management transport and mutual authentication and points to NACM, while also using boilerplate that names no individually exceptional writable node. Operators should not confuse that drafting choice with an assurance that a delay or dampening change is operationally harmless.

“Up” begins the investigation

RFC 8343 describes oper-status=up as ready to pass packets. Revision 19 adds essential context: while a timer runs, reported state can intentionally lag the underlying carrier. After the timer, “up” still remains an interface-local assertion. It does not prove that a routing adjacency returned, that every neighbor accepted new state, or that traffic followed the expected path.

The chain should therefore be tested in order. First record raw carrier transitions and the suppression algorithm's state. Then verify each relevant protocol adjacency and its reset/rebuild timestamps. Next inspect the RIB: RFC 8349 can identify a preferred route within one RIB, but that says nothing by itself about hardware programming. FIB or platform forwarding state, next-hop resolution and policy application require their own evidence.

Finally observe packets and the service. RFC 7799 distinguishes active, passive and hybrid measurement. A probe should name direction, addresses, traffic class, packet characteristics, observation points and time window. A successful ping on one member is not evidence for every LAG or ECMP member, every packet size, both directions or the customer transaction. BFD can supply fast path-liveness evidence where deployed; its session state still does not certify the application.

The same discipline applies to apparently good news. A penalty below reuse, an expired timer or fewer alarms may describe a calmer local instrument. Physical stability needs a quiet observation window tied to the component. Restored forwarding needs packets across the relevant treatment. Recovered business needs an application or customer result. Root-cause closure needs an explanation supported by maintenance, optical, power or other causal evidence—not the mere disappearance of symptoms.