Summary

  • The IESG approved draft-ietf-opsawg-discardmodel-16 on 13 August 2026 as a Proposed Standard. Its information model and YANG data model give operators a more consistent way to report interface, device and control-plane packet discards.
  • The document explicitly says that classification alone does not decide whether a discard is intended or unintended. A counter identifies a device-local condition; operator intent, configuration, baseline, duration, service context, implementation ordering and adjacent evidence determine what the observation means and who may act on it.

The same class can support opposite decisions

The opening is hypothetical. It is not a reported vendor defect or network incident. Both observations can be truthful because a policy discard means that traffic matched an enforced rule. It does not say whether the rule still represents the service owner’s intention.

At the first interface, an access-control list rejects traffic that was never entitled to cross the boundary. A rising counter is expected enforcement. Removing the rule would create exposure. At the second, a topology change has moved legitimate traffic into the same match condition. The device records the same class, but leaving the rule untouched prolongs a service failure.

This is the distinction the newly approved model makes useful. A common vocabulary can narrow the search surface without appointing the counter as judge. It can tell an automation system where the device finalized a discard and under which reporting branch it accounted for the event. The system still needs local evidence before it labels the loss acceptable, identifies a root cause or changes production state.

Approval creates a common observation grammar

On 13 August 2026, the IESG approved version 16 of “Information and Data Models for Packet Discard Reporting” for publication as a Proposed Standard. The document remains an Internet-Draft until the RFC Editor publishes it. It is a product of the Operations and Management Area Working Group.

The announcement describes an implementation-independent information model and a corresponding YANG data model focused on interface, device and control-plane discards. The shepherd evidence reported mappings or implementations on nine hardware platforms from four vendors, plus an open-source implementation of part of the YANG model. That is meaningful running-code evidence. It is not proof of universal deployment, identical silicon accounting or support by any named production network.

Existing management counters can show total discards or errors, but their coarse semantics make intended and unintended loss hard to separate. The approved work introduces a hierarchical path: component, direction, traffic or discard type, protocol layer, subtype and, where needed, a more specific reason and metric.

The component may be the control plane, an interface, a flow or the whole device. Direction distinguishes ingress from egress. Layer distinguishes Layer 2 frames from Layer 3 packets. The major discard branches separate errors, policy and no-buffer conditions. This shared grammar makes cross-platform investigation and automation more tractable.

It does not create an omniscient observer. The model records operational state exposed by a device. It does not reconstruct every upstream event, packet path, customer expectation or administrative decision that gave that state meaning.

The dropping device owns one narrow fact

The implementation rules define where the count belongs. A packet is counted as discarded only by the device that makes the final decision not to forward or locally deliver it. Passing a packet to another internal processing path, including punting it to the control plane, is not yet a discard. If it is later dropped, the count belongs where that final event occurs.

That rule reduces ambiguity. It prevents an internal handoff from being mistaken for loss and gives one device responsibility for the observed discard. Interface attribution is preferred when possible; otherwise the event must be attributed at device level.

The observation point is not necessarily the causal origin. A receive-side Layer 2 error may mean that the dropping device correctly rejected a damaged frame whose corruption arose on a link or upstream transmitter. A Layer 3 receive error can describe an invalid outer header received from elsewhere. A no-route discard may follow a local table problem, a configuration error or a transient convergence state. TTL expiry may result from ordinary diagnostic traffic, a sender’s low limit, convergence or a routing loop.

The counter therefore supports the sentence “this device finalized a discard under this class.” It cannot alone support “this device caused the service failure,” “this was the first fault,” or “this remedy is safe.”

Single accounting does not mean single causation

The model works hard to avoid double counting. Within one direction or context, a frame or packet must belong to traffic or discard, not both. A Layer 2 discard must not also be counted at Layer 3. An individual discard belongs to at most one error, policy or no-buffer subclass; a detailed no-buffer type is included in its enclosing aggregate.

These constraints make counters reconcilable. They do not claim that a packet had only one contributing condition. One packet might face a policy match, a shallow buffer and an invalid header. A device still needs a deterministic reporting choice.

When multiple discard reasons apply, the ordering must be characterized unambiguously. Implementations should expose discard-order-capability, ordered from highest to lowest precedence, or document another mechanism when constraints require it. Two platforms can observe the same packet and select different reported classes if their pipelines apply reasons in a different order, while both comply with a documented precedence.

An automation system must therefore ingest capability and ordering evidence alongside counters. Comparing only the leaf names can create a false equivalence across devices. A change in firmware or forwarding pipeline can change which reason wins without changing the traffic or service contract.

The restraint is institutional as well as technical. Standardization makes the reporting vocabulary comparable. It does not erase the implementation path that selected one counter over another.

Counter epochs are part of the evidence

Aggregate Layer 2 and Layer 3 totals should cover the underlying classes, but the document allows exceptions when granular counters have distinct discontinuity times. A counter reset, line-card restart, process restart or feature activation can put totals and subtypes in different evidence epochs.

Subtracting two values without their observation interval and discontinuity evidence can produce a rate that never existed. Summing a long-lived aggregate with newly initialized leaf counters can make valid data look incomplete. Treating a reset as recovery can close an incident while the underlying loss continues.

The same caution applies to coverage. Implementations may support a subset of control-plane, interface, flow and device features. Supported features are discoverable through YANG Library. Even within a supported feature, an implementation may not populate every counter; it should expose what is actually populated through documentation or programmatic means.

Three states must therefore remain separate: the model defines a counter; the device advertises the relevant feature; the implementation populates that counter correctly in the current epoch. Absence at the third state is not a zero. A zero is not proof that no affected packet existed outside the observation scope.

Intent remains operator-local

The approved document states the boundary directly: its classification does not by itself determine whether a specific discard condition is intended or unintended. The operator makes that determination from the class together with local policy, configured intent, baseline behavior, duration, affected scope, service context and other operational evidence.

A policy discard illustrates the point. It proves that traffic matched an ACL, policer, reverse-path check, protection rule or explicit null route. The match may enforce a valid security boundary. It may also reflect a stale ACL, the wrong prefix, an obsolete customer profile or an unintended interaction after a change.

No-buffer loss is also contextual. Best-effort traffic below an agreed performance threshold may be an accepted consequence of load. Sustained loss above that threshold may require capacity or traffic movement. Lower Effort traffic may tolerate a different baseline. A single congestion leaf cannot import the service contract into the device.

TTL-expired traffic may be normal at a low rate because traceroute intentionally elicits it. A sustained step change may indicate convergence trouble or a loop. The class is the signal. Rate, duration and topology decide whether it becomes an incident.

This is precisely why a standards-based counter should not directly own remediation. It can open an investigation or qualify a policy rule. The people and systems that hold the current service intent must authorize the state change.

Automation needs an evidence join, not a counter trigger

The document identifies plausible mitigations: remove a problematic link or device, restore one to service, move traffic, roll back a recent change or escalate to an operator. These are materially different actions. The wrong one can expand an outage or remove an intentional control.

A safe decision joins several records. Start with device identity, software and forwarding pipeline. Record the exact component, interface, direction, layer, class and subtype; the feature advertisement; populated-counter evidence; reporting precedence; counter value, time, discontinuity and baseline. Add the configuration or policy object that could produce the result, its owner and approved intent. Then add routing, adjacency, queue, hardware, flow and packet evidence from before and after the observation point.

For a policy discard, verify the rule and the traffic that matched it. For receive errors, inspect the upstream link and transmitter before taking the correctly dropping interface out of service. For no-buffer loss, locate the constrained resource and distinguish ingress device capacity from egress queue pressure. For no-route, compare routing state and convergence timing rather than assuming the interface is defective.

The counter becomes powerful when it is a typed key in this evidence join. Used alone as a trigger, it is merely a more precise way to automate an unsupported inference.

Sources