Summary
- The proposed packet-discard model classifies a condition. The draft expressly says that device counters do not establish operator intent and that a class must be joined to policy, baseline, duration, scope, service context and other evidence.
- A
policydiscard proves that traffic matched a configured rule. It does not prove the rule was intended, current or safe. Automation needs a separate decision record before it changes a network.
At 03:12, a newly deployed access list began dropping traffic. The device reported the loss exactly as designed: ingress, policy, Layer 3, ACL. A controller saw a rise above its threshold, concluded that the change was defective and rolled it back. The drops stopped.
The rollback also restored traffic that the security team had deliberately blocked.
The counter was right. The controller was wrong. That distinction matters more than whether the incident ended quickly. The device had observed packets matching a rule and had assigned the event to a precise branch of a reporting tree. It had not observed the change ticket, the security exception, the service owner’s intention, the customer contract or the authority that decided which risk should prevail. A correct measurement had been promoted into a decision it was never built to make.
That is the important limit inside Information and Data Models for Packet Discard Reporting. Revision 16 is dated 30 July 2026 and expires on 31 January 2027. At the 2 October research cut-off, the OPSAWG document was an active Internet-Draft intended as a Proposed Standard, submitted to the IESG and sitting in the RFC Editor queue awaiting editor assignment. It had no RFC number. Its maturity is relevant, but queue position does not prove that any deployed platform implements the model completely or consistently.
The draft gives operators something the old counters could not. ifInDiscards, ifOutDiscards, ifInErrors and ifOutErrors tell useful but broad stories. They can aggregate different causes, and implementations have not always agreed on which errored packets belong in which count. The proposed hierarchy separates direction, component and discard class. It aligns device and interface reporting with a flow component so that operations systems can correlate them. This is a serious improvement.
It is not a transfer of operational sovereignty from people and policy to a YANG path.
Five states, not one alarm
A safe system keeps at least five states apart.
The first is the event: a forwarding component did not carry a packet onward. The second is the measurement: a counter changed during an interval. The third is classification: the implementation placed the change under a named branch such as errors/l2/rx, no-buffer or policy/l3/policer. The fourth is judgment: an operator decides whether that condition was intended. The fifth is action: someone or some controller changes topology, configuration or capacity.
Customer impact is a sixth state, because even unintended loss is not identical to a measured service failure. A discarded scan packet, a duplicated probe and a paid transaction can increment the same family of counters while creating different consequences.
Flatten those states into one red light and the reporter silently becomes judge and actuator. Preserve them and the class becomes what it should be: a more exact question.
The draft is unusually direct about this. Device discard counters do not by themselves establish operator intent. Whether a condition is intended depends on the class together with local policy, configured intent, baseline behaviour, duration, affected scope, service context and other evidence. Its appendix offers mappings from signals to possible mitigation, but says the Unintended? column is illustrative rather than a normative property of the class.
That sentence prevents an enormous category error. It means a standards-defined label can be interoperable without becoming a universal verdict.
The same class can tell three different stories
Consider TTL expiry. A low background rate may be ordinary traceroute. A short increase can accompany route convergence. A sustained rise above baseline can indicate a persistent loop. The class remains TTL-expired while time and topology change its meaning. An automation system that treats the first packet as proof of a loop will manufacture incidents from diagnostics. One that waits only for volume may miss a small but persistent failure on a critical path.
No-buffer loss has the same problem. A best-effort queue can discard below a service threshold without breaching the operator’s intended offer. The identical class, sustained above an SLA, can require intervention. Lower Effort traffic is designed to yield under congestion. Expedited Forwarding traffic above a provisioned profile may be intentionally policed. The name of the class does not carry the commercial service promise.
Policy discards are sharper but not more sovereign. They indicate that traffic matched a configured rule. A policer may be enforcing the purchased profile. An ACL may be stopping an attack. Or a stale prefix, reversed mask or mistaken object group may be discarding valid traffic. The draft says device metrics alone cannot identify a configuration error. Configuration validation and before-and-after evidence are needed.
That makes the tempting rule—“policy drops after a change mean rollback”—unsafe. The rise can prove that a rule became active. It cannot tell whether the rule’s effect was desired. The decision belongs to an authority chain that includes the service intent and the owner of the risk.
Precision still has provenance
The value of a counter depends on how it was produced. The draft notes that TTL-expired packets sent toward a device CPU may be limited by a policer. Counting all ingress packets with TTL=1 can provide a proxy. That proxy can be useful, but it is not the same observation as a hardware record of every expiry action. If the dashboard erases the distinction, it presents estimated coverage as complete coverage.
Counter discontinuities are another trap. A component restart can reset an aggregate. Without a reset marker, the next calculation can show an impossible negative rate or a miraculous recovery. The reporting tree is seven levels deep, while a minimal implementation can stop at six. Missing depth may mean unsupported granularity, not zero events.
Flow correlation also needs an anchor. The information model includes a flow component so flow-level and interface-level discards can share a classification. It does not define every flow identity. Future models must anchor the structure so that a reported discard is unambiguously associated with a flow. Similar timestamps and matching byte counts are clues, not identity.
These are not minor implementation details. They determine what proposition the evidence can support. A number without model revision, interval, reset state, hierarchy depth and observation method is detached from the process that gave it meaning.
Mitigation is a new experiment
Even a correct diagnosis does not make a proposed remedy safe. The draft warns that removing a congested device can redirect traffic to links or devices that are already congested. A controller can correctly identify no-buffer loss and still amplify the outage.
Mitigation therefore needs its own evidence envelope: the action, the actor allowed to take it, the affected topology, expected benefit, maximum blast radius, reversibility, cooldown, stop condition and post-action measurement. “The counter went down” is insufficient if it fell because traffic disappeared or customers were moved onto a path the dashboard does not observe.
Heng Lu’s reality-layer discipline supplies a clean constitutional rule. A record of execution must not be inflated into authority over the next execution. The Minimum Initial Specification should keep the common layer narrow: stable identifiers, class path, counter provenance, time window, reset state, baseline, scope, linked configuration and an explicit action authorisation. It need not encode every business judgment in the telemetry schema. It must prevent those judgments from being smuggled in as if the device made them.
Running-Code Primacy then makes the rule testable. Generate the same ACL discard from a correct rule and a mistaken rule. Produce TTL expiry with traceroute, convergence and a loop. Hold the class constant while crossing an SLA threshold. Reset a counter. Remove one hierarchy level. Break a flow anchor. Withdraw a congested node and watch where its traffic goes. A system that exposes uncertainty, stops at its authority boundary and verifies customer outcome is ready for a closed loop. One that simply maps a class to a command is not.
The draft improves the vocabulary of loss. Its deeper lesson is that better vocabulary should reduce institutional fantasy, not automate it. The counter saw the drop. Only an accountable decision layer can decide what the drop means and who may act.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-opsawg-discardmodel/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/references/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-opsawg-discardmodel-16.txt
- https://www.ietf.org/archive/id/draft-ietf-opsawg-discardmodel-16.html
- https://www.ietf.org/archive/id/draft-ietf-opsawg-discardmodel-16.xml
- https://datatracker.ietf.org/doc/rfc2863/
- https://www.rfc-editor.org/rfc/rfc2863.txt
- https://datatracker.ietf.org/doc/rfc8343/
- https://www.rfc-editor.org/rfc/rfc8343.txt
- https://datatracker.ietf.org/doc/rfc7270/
- https://www.rfc-editor.org/rfc/rfc7270.txt
- https://datatracker.ietf.org/doc/rfc7011/
- https://www.rfc-editor.org/rfc/rfc7011.txt
- https://datatracker.ietf.org/doc/rfc8622/
- https://www.rfc-editor.org/rfc/rfc8622.txt
- https://datatracker.ietf.org/doc/rfc3246/
- https://www.rfc-editor.org/rfc/rfc3246.txt
- https://datatracker.ietf.org/doc/rfc8341/
- https://www.rfc-editor.org/rfc/rfc8341.txt
- https://datatracker.ietf.org/doc/rfc6241/
- https://www.rfc-editor.org/rfc/rfc6241.txt
- https://datatracker.ietf.org/doc/rfc8040/
- https://www.rfc-editor.org/rfc/rfc8040.txt
- https://datatracker.ietf.org/doc/rfc9907/
- https://www.rfc-editor.org/rfc/rfc9907.txt
- https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel
- https://github.com/o-pylypenko-aws/draft-ietf-opsawg-discardmodel-sample
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
