Summary
- Revision 16 of the OPSAWG packet-discard model gives devices a common structure for reporting where and why packets were dropped. It distinguishes error, policy and congestion-related conditions across interfaces, devices, flows and the control plane, but explicitly says counters alone do not establish operator intent.
- An automated response can be wrong even when the counter and its classification are correct. Policy changes, counter discontinuities, partial feature support, reason ordering, unanchored flows and shifting service baselines can break the meaning of a delta without breaking its syntax.
- Before automation changes forwarding, the observation should belong to an active intent epoch: a bounded operational record that joins one counter lifetime to a policy version, service promise, scope, permitted action, blast-radius ceiling and rollback owner. The epoch is Daniel Kade’s proposal, not an IETF requirement or YANG field.
Better names for where packets disappear
Many network counters answer an urgent question badly. ifInDiscards can rise while saying little about cause. ifInErrors may include only errored packets that were dropped on one platform and every errored packet on another. Vendor-specific commands often reveal more detail, but their branches, labels and accounting order do not necessarily line up.
draft-ietf-opsawg-discardmodel-16 tries to make that observation plane more coherent. The active OPSAWG Internet-Draft, now in the RFC Editor Queue, defines an information model and a YANG data model for Layer 2 frame and Layer 3 packet discards. Its hierarchy can identify the component that counted a discard—control plane, interface, flow or device—the direction, the layer and the subtype. Policy branches include ACL, policer, reverse-path check, denial-of-service protection and null-route discards. Error branches separate malformed or corrupt input, MTU conditions, expired TTL, missing routes and internal failures. No-buffer branches make congestion-related loss visible by QoS class and, when available, discard type.
This is a real improvement. A rising aggregate is an alarm with a broad address. A classified discard is closer to a witness statement: this device, in this direction and processing context, made the final decision not to forward or locally deliver these packets. The draft requires a packet to be counted only once in its relevant context and requires the ordering to be characterized when several discard reasons could apply. Those rules reduce double counting and explain which classifier wins.
But a witness statement is not an order to act. The model describes what the forwarding implementation recorded. It does not carry the change ticket that installed the ACL, the customer contract behind a policer, the traffic-engineering capacity of the alternative path or the incident commander's limit on automated intervention.
“Policy” is a cause class, not a certificate of intent
Suppose the policy counter rises after traffic matches an ACL. The device has supplied valuable evidence: the drop went through a configured policy path rather than a corrupt-frame or empty-buffer path. It has not proved that the ACL is the policy its owner meant to deploy.
The draft makes this distinction unusually clear. Device discard counters do not by themselves establish operator intent. An ACL drop can be intended because a security rule rejects forbidden traffic. It can be unintended because a valid flow matched a malformed prefix or because yesterday's exception was omitted from today's configuration. A policer can correctly reject traffic above a purchased profile and still expose sustained overload that demands commercial or capacity review. A policy branch therefore records mechanism, not legitimacy.
The same caution applies outside policy. Receive errors above baseline often signal an upstream link or device problem, yet the operator still has to know the baseline and scope. TTL-expired packets near a low baseline can be ordinary traceroute. A short spike can accompany convergence. Sustained elevation can be evidence of a routing loop. A no-buffer counter can sit within a documented loss objective for best-effort traffic or cross an SLA threshold for a protected class. The class does not change; the interpretation does.
Rate, duration and affected scope help, but each is local. A counter path cannot contain the customer promise, maintenance window, incident exception or risk appetite that turns a measurement into “expected”, “unintended”, “urgent” or “do not touch”. Appendix B therefore labels its signal-to-action mappings as examples. Its intended/unintended column is illustrative, not a normative property of any class.
The dangerous delta can be perfectly valid arithmetic
Automation rarely acts on a counter's absolute value. It acts on a delta, rate or change from baseline. That creates a second authority problem: before interpreting the difference between two readings, the system must prove that both readings belong to the same meaningful period.
Hardware counters can restart. A device can reboot, a line card can be replaced, a process can reset or a collector can miss an interval. The draft tells aggregate implementations to handle possible discontinuities in underlying counters. Even without a reset, feature exposure can change. YANG Library data can show whether a feature is supported, but an implementation may support a feature without populating every counter. Two devices can expose the same path with different practical completeness. Where several discard conditions are possible, the documented reason order can also differ.
Then there is the configuration. A counter that existed before and after an ACL deployment may be numerically continuous while its operational meaning is not. At 02:11, policy/l3/acl may measure denials under version A. At 02:13, the same leaf may measure version B, with a wider match and a new exception set. Subtracting the two readings yields correct arithmetic across incompatible intentions.
The reverse can happen too. A line-card reset may return a counter to zero while the policy and service promise remain unchanged. Treating the post-reset value as evidence that the incident ended would confuse storage continuity with operational continuity. A trustworthy system needs both clocks: when the measurement state began, and when the governing intent began.
This is why configuration validation belongs before and after a change. Revision 16 says device metrics alone cannot tell whether a configuration error turned an intended discard into an unintended one. It points to pre-deployment validation or a significant change in ACL discards after configuration as necessary context. That comparison is useful only if the observer records which configuration, which baseline and which counter lifetime each sample belongs to.
Build an intent epoch, not a bigger alarm
An intent epoch is the interval in which one declared service intention, one relevant policy or configuration version, and one interpretable counter lifetime coexist. It is not a timestamp attached after the incident. It is the unit against which automation earns permission to act.
At the start of an epoch, the operator records the device or logical network element, interface or control-plane scope, direction, layer and exact discard-class path. The record names the model revision, supported features, populated leaves and discard-reason ordering. It establishes the counter baseline, collection interval and discontinuity evidence. For a flow-level trigger, it also identifies how the flow is anchored; the information model aligns flow classes but deliberately does not define the underlying flow identity.
The other half is institutional. The epoch binds the active configuration and policy version, its change reference and activation time, the service owner, the applicable SLA or baseline, and the thresholds for rate, duration and affected scope. Most importantly, it records the action envelope. A no-buffer trigger may be permitted to shift at most a defined traffic share to a capacity-verified path. A receive-error trigger may isolate one member only after a second signal confirms the failure. A policy-discard trigger may alert but never remove the policy automatically.
Each action needs a cooldown, a blast-radius ceiling, a rollback condition and a person who owns escalation.
An epoch closes when any premise breaks: a counter discontinuity; a policy or configuration activation; a baseline or SLA change; feature or population drift; a gap in observation; a reassigned interface; a changed reason-order capability; an ownership transfer. The next sample can still be legitimate telemetry. It simply cannot inherit the old authority silently.
This boundary prevents two common failures. The first is stale permission: yesterday's approved action keeps running against today's policy. The second is false continuity: a collector treats a reset or implementation change as if it were one uninterrupted measurement history. The intent epoch gives both failures a deterministic stop condition without asking the packet-forwarding path to wait for a central approver.
Correlation is evidence assembly, not authority expansion
The model deliberately supports reconciliation between interface or device counters and flow records. That helps answer which traffic suffered. It does not make the relationship automatic. Revision 16 requires future flow-oriented data models to anchor the flow structure so that a discard is unambiguously associated with a flow. Until that anchor is present, an automation should not convert a broad interface event into a customer-specific remedy.
Nor should more data sources expand the automation's mandate by accumulation. A counter, flow record, configuration diff and topology snapshot can jointly support a stronger diagnosis. None independently decides whether traffic may be moved, a link removed, a configuration rolled back or an incident handed to a human. Evidence raises confidence; authority remains bounded by the approved action envelope.
The distinction matters because the draft's example mitigations are powerful. Removing a device may push traffic onto links already near capacity. Moving traffic can change latency, congestion and failure domains. Rolling back a change can restore an earlier vulnerability along with earlier reachability. Returning a component to service can reintroduce the condition that triggered the response. An accurate discard class can select a plausible branch. It cannot price all consequences.
Read access is part of the control surface
The YANG model's operational counters are read-only, and the draft uses NACM default-deny-all on its discard-statistics containers. That may look separate from response authority, but it is part of the same governance problem. Fine-grained discard data can reveal attacks and misconfigurations. An adversary able both to inject traffic and observe the resulting policy counter can measure which probes worked and adapt.
An intent epoch should therefore record not only who may act, but which collector and identity supplied the observation. Secure transport and mutual authentication protect management access; access control limits who can read the state. Neither proves that the sample was complete, fresh or interpreted under the right policy version. Authentication says who delivered the evidence. The epoch says which decision that evidence is allowed to support.
What success looks like
The useful outcome is not “zero discards”. Some discards enforce security, quality-of-service and resource limits. Nor is success “every anomaly remediated automatically”. Escalation is a valid action when the evidence or mandate is incomplete.
Success is narrower and more defensible: every automated change can be reconstructed from an observation that belonged to one active epoch; the measured class, scope, rate and duration were supported and populated; the policy and service baseline were current; the proposed action stayed inside a pre-authorized envelope; independent conditions were checked where required; and closure evidence shows whether the change helped, was reversed or required human judgment.
Revision 16 supplies the vocabulary for the first half of that record. Operators must supply the second half. A packet-discard counter can say where packets stopped. Only a bounded intent epoch can say whether the network was still authorized to move.
Sources
- IETF Datatracker: Information and Data Models for Packet Discard Reporting, revision 16
- IETF Datatracker: current document status
- IETF Datatracker: document history
- RFC 2863: The Interfaces Group MIB
- RFC 7011: IP Flow Information Export
- RFC 7270: Cisco-Specific Information Elements Reused in IPFIX
- RFC 7950: YANG 1.1
- RFC 8341: Network Configuration Access Control Model
- RFC 8343: A YANG Data Model for Interface Management
- RFC 8525: YANG Library
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
