Information and Data Models for Packet Discard Reporting
draft-ietf-opsawg-discardmodel-16
| Document | Type | Active Internet-Draft (opsawg WG) | |
|---|---|---|---|
| Authors | John Evans , Oleksandr Pylypenko , Jeff Haas , Aviran Kadosh , Mohamed Boucadair | ||
| Last updated | 2026-07-30 | ||
| Replaces | draft-opsawg-evans-discardmodel | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Reviews |
INTDIR Telechat review
(of
-14)
by Carlos Pignataro
Ready w/issues
YANGDOCTORS Early review
(of
-10)
by Ladislav Lhotka
Ready w/issues
INTDIR Early review
(of
-09)
by Satoru Matsushima
Ready w/nits
YANGDOCTORS Early review
(of
-03)
by Ladislav Lhotka
Ready w/issues
|
||
| Additional resources |
GitHub Repository
Related Implementations Mailing list discussion |
||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Diego Lopez | ||
| Shepherd write-up | Show Last changed 2026-05-12 | ||
| IESG | IESG state | IESG Evaluation::AD Followup | |
| Action Holders | |||
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved. |
||
| Responsible AD | Mahesh Jethanandani | ||
| Send notices to | diego.r.lopez@telefonica.com | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Expert Reviews OK |
draft-ietf-opsawg-discardmodel-16
Operations and Management Area Working Group J. Evans, Ed.
Internet-Draft Individual
Intended status: Standards Track O. Pylypenko, Ed.
Expires: 31 January 2027 Nvidia
J. Haas
HPE
A. Kadosh
Cisco Systems, Inc.
M. Boucadair, Ed.
Orange
30 July 2026
Information and Data Models for Packet Discard Reporting
draft-ietf-opsawg-discardmodel-16
Abstract
This document defines an Information Model and specifies a
corresponding YANG data model for packet discard reporting. The
Information Model provides an implementation-independent framework
for classifying packet loss by its cause (e.g., errors, congestion,
or policy). This classification enables operators to determine which
losses are expected or intended and which are unintended, and to
select appropriate mitigation actions, including automated mitigation
of unintended packet loss. The YANG data model specifies an
implementation of this Information Model for network elements with a
focus on interface, device, and control-plane discards.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://o-
pylypenko.github.io/draft-ietf-opsawg-discardmodel/draft-ietf-opsawg-
discardmodel.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/.
Discussion of this document takes place on the Operations and
Management Area Working Group mailing list (mailto:opsawg@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/
opsawg/. Subscribe at https://www.ietf.org/mailman/listinfo/opsawg/.
Source for this draft and an issue tracker can be found at
https://github.com/o-pylypenko/draft-ietf-opsawg-discardmodel.
Evans, et al. Expires 31 January 2027 [Page 1]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Editorial Note (To be removed by the RFC Editor) . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7
5. Information Model (IM) . . . . . . . . . . . . . . . . . . . 8
5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Subtype Definitions . . . . . . . . . . . . . . . . . . . 12
5.3. "ietf-packet-discard-reporting-common" YANG Module . . . 13
5.4. "ietf-packet-discard-reporting-sx" YANG Module . . . . . 30
6. Data Model (DM) . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Implementation Requirements . . . . . . . . . . . . . . . 35
6.3. Usage Examples . . . . . . . . . . . . . . . . . . . . . 37
6.4. "ietf-packet-discard-reporting" YANG Module . . . . . . . 39
Evans, et al. Expires 31 January 2027 [Page 2]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
7. Operational Considerations . . . . . . . . . . . . . . . . . 43
7.1. Determining Operator Intent . . . . . . . . . . . . . . . 43
7.2. Deployment Experience . . . . . . . . . . . . . . . . . . 44
7.3. Anchoring Flow Structure . . . . . . . . . . . . . . . . 45
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 45
8.1. Information Model Implementations . . . . . . . . . . . . 45
8.2. Data Model Implementations . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9.1. Information Model . . . . . . . . . . . . . . . . . . . . 46
9.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1. Normative References . . . . . . . . . . . . . . . . . . 48
11.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Where Do Packets Get Dropped? . . . . . . . . . . . 54
Appendix B. Example Signal-to-mitigation Action Mapping . . . . 55
Appendix C. Full Information Model Tree . . . . . . . . . . . . 58
Appendix D. Full Data Model Tree . . . . . . . . . . . . . . . . 65
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 70
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction
The primary function of a network is to transport and deliver packets
according to service level objectives. For network operators,
understanding both where and why packet loss occurs within a network
is essential for effective operation. Device-reported packet loss
provides the most direct signal for identifying service impact.
While certain types of packet loss, such as policy-based discards,
are intentional and part of normal network operation, unintended
packet loss can impact customer services. To automate network
operations, operators must be able to detect customer-impacting
packet loss, determine its root cause, and apply appropriate
mitigation actions. Precise classification of packet loss is thus
crucial to ensure that anomalous packet loss is easily detected and
that the right action is taken to mitigate the impact. Taking the
wrong action can make problems worse; for example, removing a
congested device from service can exacerbate congestion by
redirecting traffic to other already congested links or devices.
Existing metrics for reporting packet loss, such as ifInDiscards,
ifOutDiscards, ifInErrors, and ifOutErrors defined in "The Interfaces
Group MIB" [RFC2863] and "A YANG Data Model for Interface Management"
[RFC8343], are insufficient for automating network operations.
First, they lack precision; for instance, ifInDiscards aggregates all
discarded inbound packets without specifying the cause, making it
challenging to distinguish between intended and unintended discards.
Evans, et al. Expires 31 January 2027 [Page 3]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Second, these definitions are ambiguous, leading to inconsistent
vendor implementations. For example, in some implementations
ifInErrors accounts only for errored packets that are dropped, while
in others, it includes all errored packets, whether they are dropped
or not. Many implementations support more discard metrics than
these, however, they have been inconsistently implemented due to the
lack of a standardised classification scheme and clear semantics for
packet loss reporting. For example, [RFC7270] provides support for
reporting discards per flow in IP Flow Information Export (IPFIX)
[RFC7011] using the forwardingStatus IPFIX Information Element,
however, the defined drop reason codes also lack sufficient clarity
to facilitate automated root cause analysis and impact mitigation
(e.g., the "For us" reason code). A common operational workflow is
to reconcile device- and interface-level packet loss with the traffic
flows that were impacted. To support this, the IM defined in this
document includes a flow component which applies the same discard
classification at the flow level as at the device and interface
levels, so that flow-level discard reporting (e.g., via IPFIX) can be
directly correlated with device- and interface-level discard
reporting.
This document defines an Information Model (IM) and specifies a
corresponding YANG Data Model (DM) for packet loss reporting to
address the above issues. The IM provides precise classification of
packet loss to enable accurate automated mitigation. The DM
specifies a YANG implementation of this IM for network elements,
while maintaining consistency through clear semantics.
The scope of this document is limited to reporting Layer 3 (including
MPLS [RFC3031]) packet discards and Layer 2 frame discards. The
reported signals may trigger automated mitigation actions; the
definition and execution of those actions are deployment-specific.
Protocol actions associated with a discard (e.g., ICMP error message
generation) are governed by the applicable protocol specifications
and local policy.
Section 3 describes the problem space and requirements. Section 4
explains the design rationale. Section 5 defines the IM and its
classification scheme. Section 6 specifies the corresponding YANG
data model and implementation requirements together with a set of
usage examples, and the complete YANG module definition. Appendices
A and B provide additional context and implementation guidance.
1.1. Editorial Note (To be removed by the RFC Editor)
Note to the RFC Editor: This section is to be removed prior to
publication.
Evans, et al. Expires 31 January 2027 [Page 4]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
This document contains placeholder values that need to be replaced
with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed.
Please apply the following replacements:
* XXXX --> the assigned RFC number for this I-D
* 2026-03-03 --> the actual date of the publication of this document
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Tree diagrams used in this document follow the notation defined in
[RFC8340].
This document makes use of the following terms:
Packet discard: Any instance where a packet is dropped by a device,
regardless of whether the discard was intended or unintended.
Intended packet discards (Intended discards, for short): Packets
dropped due to deliberate network policies or configurations
designed to enforce security or Quality of Service (QoS). For
example, packets dropped because they match an Access Control List
(ACL) denying certain traffic types.
Unintended packet discards (Unintended discards, for short): Packets
that were dropped, which the network operator otherwise intended
to deliver, indicating an error state. There are many possible
reasons for unintended packet loss, including: erroring links may
corrupt packets in transit; incorrect routing tables may result in
packets being dropped because they do not match a valid route;
configuration errors may result in a valid packet incorrectly
matching an ACL and being dropped.
Evans, et al. Expires 31 January 2027 [Page 5]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
3. Problem Statement
The fundamental problem for network operators is how to automatically
detect when and where unintended packet loss is occurring and
determine the appropriate action to mitigate it. For any network,
there are a small set of potential actions that can be taken to
mitigate customer impact when unintended packet loss is detected, for
example:
1. Take a problematic device, link, or set of devices and/or links
out of service.
2. Return a device, link, or set of devices and/or links back into
service.
3. Move traffic to other links or devices to alleviate congestion or
avoid problematic paths.
4. Roll back a recent change to a device that might have caused the
problem.
5. Escalate to a network operator as a last resort when automated
mitigation is not possible.
The ability to select the appropriate mitigation action depends on
four key features of packet loss:
FEATURE-DISCARD-SCOPE: Determines which devices, interfaces, and/or
flows are impacted. This also needs to cover control-plane
discards.
FEATURE-DISCARD-RATE: The rate and/or magnitude of the discards,
indicating the severity and urgency of the problem. Rate may be
expressed using absolute (e.g., packets per second (pps)) or
relative (e.g., percent) values.
FEATURE-DISCARD-DURATION: The duration of the discards which helps
to distinguish transient from persistent issues.
FEATURE-DISCARD-CLASS: The type or class of discards, which is
crucial for selecting the appropriate type of mitigation.
Examples may be: error discards may require taking faulty
components out of service, no-buffer discards may require traffic
redistribution, or intended policy discards typically require no
action. Refer to Table 1 for more examples.
Evans, et al. Expires 31 January 2027 [Page 6]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
While most of FEATURE-DISCARD-SCOPE, FEATURE-DISCARD-RATE, and
FEATURE-DISCARD-DURATION are implicitly supported by the Interfaces
Group MIB [RFC2863] and the YANG Data Model for Interface Management
[RFC8343], FEATURE-DISCARD-CLASS requires a more detailed
classification scheme than they define. The IM provided in Section 5
defines such a classification scheme to enable automated mapping from
discard signals to appropriate mitigation actions.
The classification defined in this document does not by itself
determine whether a specific discard condition is intended or
unintended. That determination is made by the operator, based on the
discard class together with local policy, configured intent, baseline
behaviour, duration, affected scope, and other operational context.
For example, policy discards may be intended when they enforce a
deliberate access-control rule, but unintended when a configuration
error causes valid traffic to match that rule. Similarly, TTL-
expired packets may be expected at a low baseline rate due to
traceroute or other diagnostic activity, while a sustained increase
above baseline may indicate convergence, a routing loop, or another
operational fault.
The purpose of the discard classification is to expose the signal
with enough precision that an operator or automation system can make
that determination consistently. Appendix B provides illustrative
examples of how discard class, rate, duration, and inferred cause can
be combined to determine whether a discard is unintended and what
action, if any, is appropriate.
4. Design Rationale
1. The IM is defined using YANG [RFC7950], with Data Structure
Extensions [RFC8791], allowing the model to remain abstract and
decoupled from specific implementations in accordance with
[RFC3444]. This abstraction supports different DM
implementations, such as YANG or IPFIX [RFC7011], while ensuring
consistency across implementations. Using YANG for the IM
enables this abstraction, leverages the community's familiarity
with its syntax, and ensures lossless translation to the
corresponding YANG data model, which is defined in Section 6.
Evans, et al. Expires 31 January 2027 [Page 7]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
2. The number and granularity of discard classes defined in the IM
represent a compromise. It aims to provide sufficient detail to
enable appropriate automated actions while avoiding excessive
detail, which may hinder quick problem identification.
Additionally, it helps to limit the quantity of data produced per
interface, constraining the data volume and device CPU impacts.
While further granularity is possible, the defined schema has
generally proven to be sufficient for the task of mitigating
unintended packet loss.
3. There are many possible ways to define the discard classification
tree. For example, an approach is to use a multi-rooted tree,
rooted in each protocol. Instead, a better approach is to define
a tree where protocol discards and causal discard classes are
accounted for orthogonally. This decision reduces the number of
combinations of classes and has proven sufficient for determining
mitigation actions.
5. Information Model (IM)
Design note: In order to ease reuse of the IM structure by DMs but
without requiring these DMs to parse the "sx" structure defined in
[RFC8791], the main reusable nodes are defined in a common module
(Section 5.3) while the main IM structure is defined in
Section 5.4.
5.1. Structure
The IM defines a hierarchical classification scheme for packet
discards, which captures where in a device the discards are accounted
for (component), in which direction of traffic they were flowing
(direction), whether they were successfully processed or discarded
(type), what protocol layer they belong to (layer), and the specific
reason for any discards (subtypes). This structure enables both
high-level monitoring of total discards (i.e., aggregates) and more
detailed triage to map to mitigation actions.
The abstract structure of the IM is depicted in Figure 1. The full
YANG tree diagram of the IM is provided in Appendix C.
module: ietf-packet-discard-reporting-sx
structure packet-discard-reporting:
+-- control-plane {pdr-common:control-plane-stats}?
| +-- traffic* [direction]
| | ...
| +-- discards* [direction]
| ...
Evans, et al. Expires 31 January 2027 [Page 8]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
+-- interface* [name] {pdr-common:interface-stats}?
| +-- name string
| +-- traffic* [direction]
| | +-- direction identityref
| | +-- l2
| | | ...
| | +-- l3
| | | ...
| | +-- qos!
| | ...
| +-- discards* [direction]
| +-- direction identityref
| +-- l2
| | ...
| +-- l3
| | ...
| +-- errors
| | +-- l2
| | | ...
| | +-- l3
| | | ...
| | +-- internal
| | ...
| +-- policy
| | +-- l2
| | | ...
| | +-- l3
| | ...
| +-- no-buffer
| +-- qos!
| +-- class* [id]
| | ...
| +-- discard-type* [type]
| ...
+-- flow* [direction] {pdr-common:flow-reporting}?
| +-- direction identityref
| +-- traffic
| | +-- l2
| | | ...
| | +-- l3
| | | ...
| | +-- qos!
| | ...
| +-- discards
| +-- l2
| | ...
| +-- l3
| | ...
Evans, et al. Expires 31 January 2027 [Page 9]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +-- errors
| | +-- l2
| | | ...
| | +-- l3
| | | ...
| | +-- internal
| | ...
| +-- policy
| | +-- l2
| | | ...
| | +-- l3
| | ...
| +-- no-buffer
| +-- qos!
| +-- class* [id]
| | ...
| +-- discard-type* [type]
| ...
+-- device {pdr-common:device-stats}?
+-- traffic
| +-- l2
| | ...
| +-- l3
| | ...
| +-- qos!
| ...
+-- discards
+-- l2
| ...
+-- l3
| ...
+-- errors
| +-- l2
| | ...
| +-- l3
| | ...
| +-- internal
| ...
+-- policy
| +-- l2
| | ...
| +-- l3
| ...
+-- no-buffer
+-- qos!
+-- class* [id]
| ...
+-- discard-type* [type]
Evans, et al. Expires 31 January 2027 [Page 10]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
...
Figure 1: Abstract IM Tree Structure
The discard reporting can be organised into several types: control
plane, interface, flow, and device. In order to allow for better
mapping to underlying DMs, the IM supports a set of "features" to
control the supported type.
A complete classification path follows the pattern:
component/direction/type/layer/subtype/sub-subtype/.../metric.
Appendix A illustrates where these discards typically occur in a
network device. The elements of the tree are defined as follows:
* Component:
- control-plane: discards of traffic to or from a device's
control plane.
- interface: discards of traffic to or from a specific network
interface.
- flow: discards of traffic associated with a specific traffic
flow.
- device: discards of traffic transiting the device.
* Direction:
- ingress: counters for incoming packets or frames.
- egress: counters for outgoing packets or frames.
* Type:
- traffic: counters for successfully received or transmitted
packets or frames.
- discards: counters for packets or frames that were dropped.
* Layer:
- l2: Layer 2 traffic and discards. This covers both frame and
byte counts.
- l3: Layer 3 traffic and discards. This covers both packet and
byte counts.
Evans, et al. Expires 31 January 2027 [Page 11]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
The hierarchical structure allows for future extensions while
maintaining backward compatibility. New discard types can be added
as new branches without affecting existing implementations.
The corresponding YANG module is defined in Section 5.4.
5.2. Subtype Definitions
discards/policy/: These are discards of packets that matched a
configured policy, including: ACLs, traffic policers, unicast
Reverse Path Forwarding (uRPF) checks, Denial-of-Service (DoS)
protection rules, and explicit null routes. Such discards are
typically intended, although whether a specific policy discard is
intended is determined by the operator (see Section 7.1). In
practice, ingress DoS protection policies are often realised using
mechanisms such as ingress filtering and uRPF ([RFC2827],
[RFC3704], and [RFC8704]), remotely triggered blackholing
([RFC3882], [RFC5635]), or BGP Flow Specification-based filters
([RFC8955], [RFC8956], and [RFC9117]); all such policy-driven
discards are reported under this class. Discards due to control-
plane protection policies [RFC6192], including the Generalized TTL
Security Mechanism (GTSM) [RFC5082], are reported under the
control-plane component's policy discards. A GTSM discard
indicates that the received TTL or Hop Limit is outside the
configured expected range. Consistent with the requirements
listed in Section 6.2, a policy discard increments one and only
one of the policy subtypes.
discards/errors/: These are discards due to errors in processing
packets or frames, which typically indicate unintended packet loss
(see Section 7.1). There are multiple subclasses:
* discards/errors/l2/rx/: These are frames discarded due to
errors in the received Layer 2 frame, including: Cyclic
Redundancy Check (CRC) errors, invalid Media Access Control
(MAC) addresses, invalid VLAN tags, frame size violations
and other malformed frame conditions.
* discards/errors/l3/rx/: These discards occur due to errors in
the received packet, indicating an upstream problem rather
than an issue with the device dropping the errored packets,
including: header checksum errors and invalid packet errors
(i.e., incorrect version, incorrect header length, invalid
options, and other malformed packet conditions).
These discards are based upon the outer header of packets.
* discards/errors/l3/mtu-exceeded/: These discards occur when
Evans, et al. Expires 31 January 2027 [Page 12]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
the packet size exceeds the applicable MTU. The subclasses
distinguish whether the forwarding node was permitted to
fragment the packet (Sections 3.1 and 3.2 of [RFC791],
Sections 4.5 and 5 of [RFC8200]).
* discards/errors/l3/ttl-expired: These discards occur due to
TTL [RFC791] (or Hop Limit [RFC8200]) expiry. These can
occur, e.g., for the following reasons: normal traceroute
operations, including MPLS LSP ping/traceroute [RFC8029] and
pseudowire VCCV [RFC5085] which intentionally use TTL
expiry, end-system TTL/Hop limit set too low, or routing
loops in the network.
* discards/errors/l3/no-route: These discards occur due to a
packet not matching any route in the routing table. This
may be due to routing configuration errors or to transient
conditions during convergence.
* discards/errors/l3/neighbor-resolution-failure: These discards
occur when the forwarding engine cannot resolve or use the
link-layer adjacency required to forward the packet to the
selected next hop ([RFC826], [RFC4861]).
* discards/errors/internal/: These discards occur due to
internal device issues, including: parity errors in device
memory or other internal hardware errors. Any errored
discards not explicitly assigned to other classes are also
accounted for here.
discards/no-buffer/: These are congestion-related discards,
including tail-drop discards due to buffer exhaustion and discards
due to an Active Queue Management (AQM) algorithm, such as Random
Early Detection (RED) [RED93] or Controlled Delay (CoDel)
[RFC8289]. Implementations MAY additionally report per-type
counters in the discard-type list.
An example of possible signal-to-mitigation action mapping is
provided in Appendix B.
5.3. "ietf-packet-discard-reporting-common" YANG Module
The "ietf-packet-discard-reporting-common" module imports "ietf-yang-
types" defined in [RFC9911]. The module references [RFC8402],
[RFC8660], [RFC8754], and [RFC8986].
Evans, et al. Expires 31 January 2027 [Page 13]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
<CODE BEGINS>
file "ietf-packet-discard-reporting-common@2026-03-03.yang"
module ietf-packet-discard-reporting-common {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:"
+ "ietf-packet-discard-reporting-common";
prefix pdr-common;
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: https://datatracker.ietf.org/wg/opsawg/
WG List: OPSAWG <mailto:opsawg@ietf.org>
Editor: John Evans
<mailto:john@nopacketleftbehind.net>
Editor: Oleksandr Pylypenko
<mailto:opylypenko@nvidia.com>
Author: Jeffrey Haas
<mailto:jeffrey.haas@hpe.com>
Author: Aviran Kadosh
<mailto:akadosh@cisco.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This module defines a common YANG module for packet discard
reporting.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Evans, et al. Expires 31 January 2027 [Page 14]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2026-03-03 {
description
"Initial revision.";
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
/*
* Features
*/
feature control-plane-stats {
description
"Indicates support of control plane discard statistics.";
}
feature interface-stats {
description
"Indicates support of interface discard statistics.";
}
feature flow-reporting {
description
"Indicates support of flow discard reporting.";
}
feature device-stats {
description
"Indicates support of global device discard statistics.";
}
/*
* Identities
*/
identity direction {
description
"Defines a direction for the reported statistics.";
}
Evans, et al. Expires 31 January 2027 [Page 15]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
identity ingress {
base direction;
description
"Reports statistics for the received packets from
the network.";
}
identity egress {
base direction;
description
"Reports statistics for the sent packets to
the network.";
}
identity address-family {
description
"Defines a type for the address family.
This identity is defined here rather than importing
it from other YANG modules to simplify implementations
and avoid inheriting dependencies of those modules.
Additional address families can be added by defining
identities derived from this base identity, without
affecting existing implementations.";
}
identity ip {
base address-family;
description
"Identity for IP address family.";
}
identity ipv4 {
base ip;
description
"Identity for IPv4 address family.";
}
identity ipv6 {
base ip;
description
"Identity for IPv6 address family.";
}
identity no-buffer-type {
description
"Defines a type for congestion-related discards.";
Evans, et al. Expires 31 January 2027 [Page 16]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
identity aqm {
base no-buffer-type;
description
"Indicates a discard due to an Active Queue Management (AQM)
algorithm.";
}
identity tail-drop {
base no-buffer-type;
description
"Indicates a discard due to tail drop.";
}
/*
* Groupings
*/
grouping basic-packets {
description
"Grouping for packet counters.";
leaf packets {
type yang:counter64;
description
"Number of packets.";
}
}
grouping basic-packets-bytes {
description
"Grouping for packet and byte counters.";
uses basic-packets;
leaf bytes {
type yang:counter64;
description
"Number of bytes.";
}
}
grouping basic-frames {
description
"Grouping for Layer 2 frame counters.";
leaf frames {
type yang:counter64;
description
"Number of Layer 2 frames.";
}
Evans, et al. Expires 31 January 2027 [Page 17]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
grouping l2-traffic {
description
"Grouping for Layer 2 frame and byte counters.";
uses basic-frames;
leaf bytes {
type yang:counter64;
description
"Number of Layer 2 bytes.";
}
}
grouping l3-traffic {
description
"Layer 3 traffic counters per address family.";
list address-family-stat {
key "address-family";
description
"Reports per address family traffic counters.";
leaf address-family {
type identityref {
base address-family;
}
description
"Specifies an address family.";
}
uses basic-packets-bytes;
container unicast {
description
"Unicast traffic counters.";
uses basic-packets-bytes;
}
container multicast {
description
"Multicast traffic counters.";
uses basic-packets-bytes;
}
container broadcast {
when "derived-from-or-self(../address-family, "
+ "'pdr-common:ipv4')" {
description
"Only applicable for IPv4.";
}
description
"Broadcast traffic counters.";
uses basic-packets-bytes;
}
Evans, et al. Expires 31 January 2027 [Page 18]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
}
grouping class-list {
description
"Class-based traffic counters.";
list class {
key "id";
min-elements 1;
description
"Class traffic counters.";
leaf id {
type string;
description
"Indicates a Quality of Service (QoS) class
identifier.";
}
uses basic-packets-bytes;
}
}
grouping qos {
description
"QoS traffic counters.";
container qos {
presence "QoS statistics are available.";
description
"Per-class QoS traffic counters.";
uses class-list;
}
}
grouping no-buffer-qos {
description
"QoS discard counters.";
container qos {
presence "QoS statistics are available.";
description
"Per-class QoS traffic counters.";
list class {
key "id";
min-elements 1;
description
"Class traffic counters.";
leaf id {
type string;
description
"Indicates a QoS class identifier.";
Evans, et al. Expires 31 January 2027 [Page 19]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
uses basic-packets-bytes;
list discard-type {
key "type";
description
"Per-type discard counters.";
leaf type {
type identityref {
base no-buffer-type;
}
description
"Specifies the discard type.";
}
uses basic-packets-bytes;
}
}
}
}
grouping traffic {
description
"All traffic counters.";
container l2 {
description
"Layer 2 traffic counters.";
uses l2-traffic;
}
container l3 {
description
"Layer 3 traffic counters.";
uses l3-traffic;
}
uses qos;
}
grouping errors-l2-rx {
description
"Layer 2 ingress frame error discard counters.";
container rx {
description
"Layer 2 ingress frame receive error discard
counters.";
leaf frames {
type yang:counter64;
description
"The number of frames discarded due to errors
with the received frame.";
}
Evans, et al. Expires 31 January 2027 [Page 20]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
leaf crc-error {
type yang:counter64;
description
"The number of received frames discarded due to
Cyclic Redundancy Check (CRC) error.";
}
leaf invalid-mac {
type yang:counter64;
description
"The number of received frames discarded due to
an invalid Media Access Control (MAC) address.
Applies to Ethernet or Ethernet-derived
encapsulations where MAC addresses are present.";
}
leaf invalid-vlan {
type yang:counter64;
description
"The number of received frames discarded due to
an invalid VLAN tag. Applies to Ethernet or
Ethernet-derived encapsulations where VLAN tags
are present.";
}
leaf invalid-frame {
type yang:counter64;
description
"The number of invalid received frames discarded due to
other reasons, not limited to: malformed frames,
frame-size violations.";
}
}
}
grouping errors-l3 {
description
"Layer 3 packet error discard counters.";
container rx {
description
"Counters for Layer 3 packets discarded due to errors
in the received packet, indicating an upstream problem
rather than an issue with the reporting device.";
leaf packets {
type yang:counter64;
description
"The number of Layer 3 packets discarded due to
errors in the received packet.";
}
leaf checksum-error {
type yang:counter64;
Evans, et al. Expires 31 January 2027 [Page 21]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
description
"Reports IPv4 packets discarded because validation of the
IPv4 header checksum failed.
This counter is applicable only to IPv4 packets. IPv6 does
not include an internet-layer header checksum, so IPv6
packets are not reported under this counter.";
}
leaf invalid-packet {
type yang:counter64;
description
"The number of received invalid packets discarded due
to other reasons, not limited to: invalid packet length,
invalid header fields, invalid options, invalid protocol
version, invalid flags or control bits, malformed
packets.";
}
}
container mtu-exceeded {
description
"Counters for packets discarded because their size exceeded
the applicable Maximum Transmission Unit (MTU).";
leaf packets {
type yang:counter64;
description
"The total number of packets discarded because their size
exceeded the applicable MTU. This includes packets
reported by the more specific counters in this
container.";
}
leaf fragmentation-not-permitted {
type yang:counter64;
description
"The number of packets discarded because the packet size
exceeded the applicable MTU and the forwarding node was
not permitted to fragment the packet. This includes IPv4
packets with the Don't Fragment (DF) bit set and IPv6
packets, which forwarding nodes do not fragment.";
}
leaf fragmentation-permitted-not-performed {
type yang:counter64;
description
"The number of packets discarded because the packet size
exceeded the applicable MTU, fragmentation was permitted
in principle, but the packet was not fragmented and
forwarded. This includes IPv4 packets with the DF bit
clear.";
}
Evans, et al. Expires 31 January 2027 [Page 22]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
reference
"RFC 791: Internet Protocol, Sections 3.1 and 3.2
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification, Sections 4.5 and 5";
}
leaf ttl-expired {
type yang:counter64;
description
"The number of packets discarded because the TTL
(IPv4 or MPLS) expired or the Hop Limit (IPv6)
was exceeded.";
}
leaf no-route {
type yang:counter64;
description
"The number of received packets discarded because the
destination address does not match a valid entry in the
routing table. This includes packets discarded after
outer header removal (e.g., MPLS label disposition or
tunnel decapsulation) when the exposed IP header does
not match a valid entry in the routing table. MPLS label
lookup failures are reported under 'invalid-label'.";
}
leaf neighbor-resolution-failure {
type yang:counter64;
description
"Reports packets discarded because the forwarding engine
could not resolve or use the link-layer adjacency required
to forward the packet to the selected next hop.
This includes packets dropped because ARP resolution for an
IPv4 next hop failed, Neighbor Discovery resolution for an
IPv6 next hop failed, or the resolved neighbor entry was
unusable according to local neighbor state.
This counter applies when route selection identified a next
hop, but forwarding could not complete because the required
neighbor or adjacency information was unavailable or
unusable. Packets discarded because no route matched
the destination are reported under 'no-route'. Packets
discarded due to internal device faults are reported
under 'internal'.";
reference
"RFC 826: An Ethernet Address Resolution Protocol -- or --
Converting Network Protocol Addresses to 48.bit
Ethernet Address for Transmission on Ethernet
Hardware
RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";
Evans, et al. Expires 31 January 2027 [Page 23]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
leaf invalid-sid {
type yang:counter64;
description
"The number of received packets discarded due to an
invalid Segment Routing over IPv6 (SRv6) segment
identifier (SID).
This counter is incremented only by the node processing
the SID (i.e., where the packet's destination address
matches a locally instantiated SID); transit nodes that
forward the packet without processing the SRH do not
increment it. Discards of SRv6 packets whose
destination address does not match a valid route are
reported under 'no-route'.
For SR-MPLS, SID lookup failures are reported under
'invalid-label'.";
reference
"RFC 8402: Segment Routing Architecture
RFC 8660: Segment Routing with the MPLS Data Plane
RFC 8754: IPv6 Segment Routing Header (SRH)
RFC 8986: Segment Routing over IPv6 (SRv6) Network
Programming";
}
leaf invalid-label {
type yang:counter64;
description
"The number of received packets discarded because the
top MPLS label does not match a valid Incoming Label
Map (ILM) entry. This is the MPLS equivalent of
'no-route'.";
reference
"RFC 3031: Multiprotocol Label Switching Architecture,
Section 3.18";
}
}
grouping errors-l3-int {
description
"Internal error discard counters.";
leaf packets {
type yang:counter64;
description
"The number of packets discarded due to internal
errors.";
}
leaf parity-error {
type yang:counter64;
description
Evans, et al. Expires 31 January 2027 [Page 24]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
"The number of packets discarded due to parity
errors, which typically mean that the ASIC
detected corruption in an internal memory, table,
buffer, or metadata structure used while processing
the packet, and dropped the packet rather than
forwarding it using potentially bad state.";
}
}
grouping errors-l2-tx {
description
"Layer 2 transmit error discard counters.";
container tx {
description
"Layer 2 transmit frame error discard counters.";
leaf frames {
type yang:counter64;
description
"The number of Layer 2 frames discarded due to
errors when transmitting.";
}
}
}
grouping errors-l3-tx {
description
"Layer 3 transmit error discard counters.";
container tx {
description
"Layer 3 transmit packet error discard counters.";
leaf packets {
type yang:counter64;
description
"The number of Layer 3 packets discarded due to
errors when transmitting.";
}
}
}
grouping errors {
description
"Error discard counters.";
container l2 {
description
"Layer 2 frame error discard counters.";
uses errors-l2-rx;
uses errors-l2-tx;
}
Evans, et al. Expires 31 January 2027 [Page 25]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
container l3 {
description
"Layer 3 packet error discard counters.";
uses errors-l3;
uses errors-l3-tx;
}
container internal {
description
"Internal error discard counters.";
uses errors-l3-int;
}
}
grouping policy-l2 {
description
"Layer 2 policy frame discard counters.";
leaf frames {
type yang:counter64;
description
"The number of Layer 2 frames discarded due
to policy.";
}
leaf acl {
type yang:counter64;
description
"The number of frames discarded due to Layer 2
Access Control Lists (ACLs).";
}
}
grouping policy-l3 {
description
"Layer 3 policy packet discard counters.";
leaf packets {
type yang:counter64;
description
"The number of Layer 3 packets discarded due to policy.";
}
leaf acl {
type yang:counter64;
description
"The number of packets discarded due to Layer 3
(and higher layers) ACLs.";
}
container policer {
description
"Counters for packets discarded due to policer
violations.";
Evans, et al. Expires 31 January 2027 [Page 26]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
uses basic-packets-bytes;
container classes {
presence "Per-class policer statistics are available.";
description
"Per-class policer discard counters.";
uses class-list;
}
}
leaf null-route {
type yang:counter64;
description
"The number of packets discarded due to matching
a null route.";
}
leaf rpf {
type yang:counter64;
description
"The number of packets discarded due to failing
Reverse Path Forwarding (RPF) check.";
}
leaf dos {
type yang:counter64;
description
"The number of packets discarded by dedicated
Denial-of-Service (DoS) protection mechanisms, such as
implementation-specific heuristics that identify and discard
DoS traffic.
Where a DoS attack is mitigated using an ACL or a null
route, those discards are reported under 'acl' or
'null-route' respectively, not under this counter, since
the association with DoS mitigation is known only to the
operator.";
}
}
grouping discards {
description
"Discard counters.";
container l2 {
description
"Layer 2 frame discard counters.";
uses l2-traffic;
}
container l3 {
description
"Layer 3 packet discard counters.";
uses l3-traffic;
Evans, et al. Expires 31 January 2027 [Page 27]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
}
container errors {
description
"Error discard counters.";
uses errors;
}
container policy {
description
"Policy-related discard counters.";
uses policy;
}
container no-buffer {
description
"Congestion-related discard counters.";
uses no-buffer-qos;
}
}
grouping policy {
description
"Policy-related discard counters.";
container l2 {
description
"Layer 2 policy frame discard counters.";
uses policy-l2;
}
container l3 {
description
"Layer 3 policy packet discard counters.";
uses policy-l3;
}
}
grouping traffic-and-discards {
description
"Specifies overall traffic and discard counters.";
container traffic {
description
"Traffic counters.";
uses traffic;
}
container discards {
description
"Discard counters.";
uses discards;
}
}
Evans, et al. Expires 31 January 2027 [Page 28]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
grouping interface {
description
"Interface-level traffic and discard counters.";
list traffic {
key "direction";
description
"Traffic counters.";
leaf direction {
type identityref {
base direction;
}
description
"Specifies a direction.";
}
uses traffic;
}
list discards {
key "direction";
description
"Discard counters.";
leaf direction {
type identityref {
base direction;
}
description
"Specifies a direction.";
}
uses discards;
}
}
grouping control-plane {
description
"Control plane packet counters.";
list traffic {
key "direction";
description
"Total control plane packets.";
leaf direction {
type identityref {
base direction;
}
description
"Specifies a direction.";
}
uses basic-packets-bytes;
}
list discards {
Evans, et al. Expires 31 January 2027 [Page 29]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
key "direction";
description
"Control plane packet discard counters.";
leaf direction {
type identityref {
base direction;
}
description
"Specifies a direction.";
}
uses basic-packets-bytes;
container policy {
description
"Number of control plane packets discarded due to policy.";
uses basic-packets;
}
}
}
}
<CODE ENDS>
5.4. "ietf-packet-discard-reporting-sx" YANG Module
The "ietf-packet-discard-reporting-sx" module uses the "sx" structure
defined in [RFC8791] and also imports the "ietf-packet-discard-
reporting-common" module (Section 5.3).
<CODE BEGINS> file "ietf-packet-discard-reporting-sx@2026-03-03.yang"
module ietf-packet-discard-reporting-sx {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting-sx";
prefix pdr-sx;
import ietf-packet-discard-reporting-common {
prefix pdr-common;
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
Evans, et al. Expires 31 January 2027 [Page 30]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
contact
"WG Web: https://datatracker.ietf.org/wg/opsawg/
WG List: OPSAWG <mailto:opsawg@ietf.org>
Editor: John Evans
<mailto:john@nopacketleftbehind.net>
Editor: Oleksandr Pylypenko
<mailto:opylypenko@nvidia.com>
Author: Jeffrey Haas
<mailto:jeffrey.haas@hpe.com>
Author: Aviran Kadosh
<mailto:akadosh@cisco.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This module defines an information model for packet discard
reporting.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2026-03-03 {
description
"Initial revision.";
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
/*
Evans, et al. Expires 31 January 2027 [Page 31]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
* Main structure definition
*/
sx:structure packet-discard-reporting {
description
"Specifies the abstract structure of packet discard
reporting data.";
container control-plane {
if-feature "pdr-common:control-plane-stats";
description
"Control plane packet counters.";
uses pdr-common:control-plane;
}
list interface {
if-feature "pdr-common:interface-stats";
key "name";
description
"Indicates a list of interfaces for which packet
discard reporting data is provided.";
leaf name {
type string;
description
"Indicates the name of the interface.";
}
uses pdr-common:interface;
}
list flow {
if-feature "pdr-common:flow-reporting";
key "direction";
description
"Flow packet counters.";
leaf direction {
type identityref {
base pdr-common:direction;
}
description
"Specifies a direction.";
}
uses pdr-common:traffic-and-discards;
}
container device {
if-feature "pdr-common:device-stats";
description
"Device level packet counters.";
uses pdr-common:traffic-and-discards;
}
}
}
Evans, et al. Expires 31 January 2027 [Page 32]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
<CODE ENDS>
6. Data Model (DM)
This DM implements the IM defined in Section 5 for the interface,
device, and control-plane components. It is a device model per
Section 2.1 of [RFC8969]. Specifically, it is a device-local
(network element) operational state model: counters are scoped to a
single device (interfaces and control plane).
The IM defines the abstract classification tree using YANG data
structure extensions [RFC8791]. The reusable groupings are defined
in the "ietf-packet-discard-reporting-common" module (Section 5.3).
This DM imports that common module and reuses the same hierarchy of
components, directions, layers, and discard classes, attaching the
groupings via augment statements to existing YANG modules for
routing, interfaces, and logical network elements. The flow
component is defined only in the IM for use by flow-oriented data
models and is not instantiated in this DM.
6.1. Structure
There is a direct mapping between the IM components and their DM
implementations, with each component in the hierarchy represented by
corresponding YANG containers and leaf data nodes. The abstract tree
is shown in Figure 2.
module: ietf-packet-discard-reporting
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--ro traffic-discard-stats {pdr-common:control-plane-stats}?
+--ro discard-order-capability* identityref
+--ro traffic* [direction]
| ...
+--ro discards* [direction]
...
augment /if:interfaces/if:interface/if:statistics:
+--ro traffic-discard-stats {pdr-common:interface-stats}?
+--ro discard-order-capability* identityref
+--ro traffic* [direction]
| +--ro direction identityref
| +--ro l2
| | ...
| +--ro l3
| | ...
| +--ro qos!
| +--ro class* [id]
Evans, et al. Expires 31 January 2027 [Page 33]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| ...
+--ro discards* [direction]
+--ro direction identityref
+--ro l2
| ...
+--ro l3
| ...
+--ro errors
| +--ro l2
| | ...
| +--ro l3
| | ...
| +--ro internal
| ...
+--ro policy
| +--ro l2
| | ...
| +--ro l3
| ...
+--ro no-buffer
+--ro qos!
+--ro class* [id]
| ...
+--ro discard-type* [type]
...
augment /lne:logical-network-elements/lne:logical-network-element:
+--ro traffic-discard-stats {pdr-common:device-stats}?
+--ro discard-order-capability* identityref
+--ro traffic
| +--ro l2
| | ...
| +--ro l3
| | ...
| +--ro qos!
| +--ro class* [id]
| ...
+--ro discards
+--ro l2
| ...
+--ro l3
| ...
+--ro errors
| +--ro l2
| | ...
| +--ro l3
| | ...
| +--ro internal
| ...
Evans, et al. Expires 31 January 2027 [Page 34]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
+--ro policy
| +--ro l2
| | ...
| +--ro l3
| ...
+--ro no-buffer
+--ro qos!
+--ro class* [id]
| ...
+--ro discard-type* [type]
...
Figure 2: Abstract DM Tree Structure
The full tree structure is provided in Appendix D.
6.2. Implementation Requirements
The following requirements apply to the implementation of the DM and
are intended to ensure consistent implementation across different
vendors and platforms while allowing for platform-specific
optimisations where needed.
Requirements 1-13 relate to packets forwarded or discarded by the
device, while requirement 14 relates to packets destined for or
originating from the device, and requirements 15 and 16 relate to
feature support:
1. All instances of Layer 2 frame or Layer 3 packet receipt,
transmission, and discards MUST be accounted for. A frame or
packet MUST be counted as discarded only by the device that
discards it, i.e., when the device makes the final determination
not to forward or locally deliver it. Handing a packet to
another processing path within the device (e.g., punting it to
the control plane) is not a discard; if the packet is
subsequently dropped, it MUST be accounted for in the class
corresponding to where that drop occurs (see requirement 14).
2. All instances of Layer 2 frame or Layer 3 packet receipt,
transmission, and discards SHOULD be attributed to the physical
or logical interface of the device where they occur. Where they
cannot be attributed to the interface, they MUST be attributed
to the device.
3. An individual frame MUST only be accounted for by either the
Layer 2 traffic class or the Layer 2 discard classes within a
single direction or context, i.e., ingress or egress or device.
This is to avoid double counting.
Evans, et al. Expires 31 January 2027 [Page 35]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
4. An individual packet MUST only be accounted for by either the
Layer 3 traffic class or the Layer 3 discard classes within a
single direction or context, i.e., ingress or egress or device.
This is to avoid double counting.
5. A frame discard accounted for at Layer 2 MUST NOT be accounted
for at Layer 3 and vice versa. This is to avoid double
counting.
6. The aggregate Layer 2 and Layer 3 traffic and discard classes
SHOULD account for all underlying frames or packets received,
transmitted, and discarded across all other classes. There
might be exceptions when distinct discontinuity times are
observed for more granular discards.
7. The aggregate QoS traffic and no-buffer discard classes MUST
account for all underlying packets received, transmitted, and
discarded across all other classes. All packets and bytes
reported under discard-type MUST also be included in the
enclosing class aggregate.
8. In addition to the Layer 2 and Layer 3 aggregate classes, an
individual discarded packet MUST only account against a single
error, policy, or no-buffer discard subclass. When per-type
counters are reported, the discard MUST be counted in at most
one discard-type entry.
9. When there are multiple reasons for discarding a packet, the
ordering of discard class reporting MUST be unambiguously
characterised. Implementations SHOULD expose this ordering by
means of discard-order-capability and MAY use another mechanism
(e.g., due to implementation constraints), provided the ordering
is documented.
10. class[id] represents the QoS class assigned to a packet by the
forwarding implementation using Diffserv [RFC2475], IEEE 802.1Q
PCP [IEEE802.1Q], MPLS TC [RFC5462], or another mechanism. If
no QoS classification is used, no-buffer discards MUST be
reported as class[id="0"], which represents the default class.
11. When traffic is mirrored, the discard metrics MUST account for
the original traffic rather than the reflected traffic.
Evans, et al. Expires 31 January 2027 [Page 36]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
12. Congestion-related discards can be realised differently with
different queueing and memory architectures. Whether a no-
buffer discard is attributed to ingress or egress can differ
accordingly. For successful auto-mitigation, discards due to
egress interface congestion MUST be reportable on egress, while
discards due to device-level congestion (e.g., due to exceeding
the device forwarding rate) MUST be reportable on ingress.
13. When the ingress and egress headers differ (for example, at a
tunnel endpoint), the discard class attribution MUST relate to
the outer header at the point of discard.
14. Traffic to the device control plane (to-CPU) has its own class.
However, traffic from the device control plane (from-CPU) MUST
be accounted for in the same way as other egress traffic.
15. Implementations MAY support a subset of the defined features
based on device capabilities and operational requirements.
Which features an implementation supports is discoverable from
the device itself: support for each feature is advertised via
the YANG library [RFC8525].
16. Where an implementation supports a feature but does not populate
every counter within it, the implementation SHOULD expose which
counters are populated. It may do so in documentation or via
programatic means (e.g., local help command).
6.3. Usage Examples
This section assumes that no class of service is implemented.
If all of the requirements listed in Section 6.2 are met, a "good"
unicast IPv4 packet received would increment:
* interface/traffic[direction="ingress"]/l3/address-family-
stat[address-family="ipv4"]/unicast/packets
* interface/traffic[direction="ingress"]/l3/address-family-
stat[address-family="ipv4"]/unicast/bytes
* interface/traffic[direction="ingress"]/qos/class[id="0"]/packets
* interface/traffic[direction="ingress"]/qos/class[id="0"]/bytes
A received unicast IPv6 packet discarded due to Hop Limit expiry
would increment:
Evans, et al. Expires 31 January 2027 [Page 37]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
* interface/discards[direction="ingress"]/l3/address-family-
stat[address-family="ipv6"]/unicast/packets
* interface/discards[direction="ingress"]/l3/address-family-
stat[address-family="ipv6"]/unicast/bytes
* interface/discards[direction="ingress"]/errors/l3/ttl-expired
An IPv4 packet discarded on egress by tail drop due to buffer
exhaustion would increment:
* interface/discards[direction="egress"]/l3/address-family-
stat[address-family="ipv4"]/unicast/packets
* interface/discards[direction="egress"]/l3/address-family-
stat[address-family="ipv4"]/unicast/bytes
* interface/discards[direction="egress"]/no-buffer/qos/
class[id="0"]/packets
* interface/discards[direction="egress"]/no-buffer/qos/
class[id="0"]/bytes
If per-type counters are reported, the packet would also increment:
* interface/discards[direction="egress"]/no-buffer/qos/
class[id="0"]/discard-type[type="tail-drop"]/packets
* interface/discards[direction="egress"]/no-buffer/qos/
class[id="0"]/discard-type[type="tail-drop"]/bytes
A multicast IPv6 packet dropped due to RPF check failure would
increment:
* interface/discards[direction="ingress"]/l3/address-family-
stat[address-family="ipv6"]/multicast/packets
* interface/discards[direction="ingress"]/l3/address-family-
stat[address-family="ipv6"]/multicast/bytes
* interface/discards[direction="ingress"]/policy/l3/rpf
A "good" Layer 2 frame received would increment:
* interface/traffic[direction="ingress"]/l2/frames
* interface/traffic[direction="ingress"]/l2/bytes
Evans, et al. Expires 31 January 2027 [Page 38]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
* interface/traffic[direction="ingress"]/qos/class[id="0"]/packets
* interface/traffic[direction="ingress"]/qos/class[id="0"]/bytes
6.4. "ietf-packet-discard-reporting" YANG Module
The "ietf-packet-discard-reporting" module imports "ietf-packet-
discard-reporting-common" (Section 5.3), "ietf-netconf-acm"
[RFC8341], "ietf-interfaces" [RFC8343], "ietf-routing" [RFC8349], and
"ietf-logical-network-element" [RFC8530].
<CODE BEGINS> file "ietf-packet-discard-reporting@2026-03-03.yang"
module ietf-packet-discard-reporting {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting";
prefix pdr;
import ietf-packet-discard-reporting-common {
prefix pdr-common;
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-logical-network-element {
prefix lne;
reference
"RFC 8530: YANG Model for Logical Network Elements";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
Evans, et al. Expires 31 January 2027 [Page 39]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
contact
"WG Web: https://datatracker.ietf.org/wg/opsawg/
WG List: OPSAWG <mailto:opsawg@ietf.org>
Editor: John Evans
<mailto:john@nopacketleftbehind.net>
Editor: Oleksandr Pylypenko
<mailto:opylypenko@nvidia.com>
Author: Jeffrey Haas
<mailto:jeffrey.haas@hpe.com>
Author: Aviran Kadosh
<mailto:akadosh@cisco.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This module defines a data model for packet discard reporting.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2026-03-03 {
description
"Initial revision.";
reference
"RFC XXXX: Information and Data Models for Packet Discard
Reporting";
}
/*
* Identities
Evans, et al. Expires 31 January 2027 [Page 40]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
*/
identity discard-class {
description
"Base identity to identify the discard class.";
}
identity layer2 {
base discard-class;
description
"Indicates a Layer 2 discard.";
}
identity layer3 {
base discard-class;
description
"Indicates a Layer 3 discard.";
}
identity internal {
base discard-class;
description
"Indicates an internal discard.";
}
identity policy {
base discard-class;
description
"Indicates a discard due to a policy.";
}
identity no-buffer {
base discard-class;
description
"Indicates a congestion-related discard.";
}
/*
* Groupings
*/
grouping discard-order-policy {
description
"Defines the implementation-specific precedence of discard
classes when multiple discard reasons apply to a single
packet.
The list is ordered from highest to lowest precedence.";
Evans, et al. Expires 31 January 2027 [Page 41]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
leaf-list discard-order-capability {
type identityref {
base discard-class;
}
description
"The discard class identity that has this precedence.";
}
}
/*
* Main structure definition
*/
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol" {
if-feature "pdr-common:control-plane-stats";
description
"Adds control plane discard counters.";
container traffic-discard-stats {
nacm:default-deny-all;
config false;
description
"Traffic and discard counters for the control plane.";
uses discard-order-policy;
uses pdr-common:control-plane;
}
}
augment "/if:interfaces/if:interface/if:statistics" {
if-feature "pdr-common:interface-stats";
description
"Adds traffic and discard reporting to the interface
statistics.";
container traffic-discard-stats {
nacm:default-deny-all;
config false;
description
"Traffic and discard counters for the interface.";
uses discard-order-policy;
uses pdr-common:interface;
}
}
augment "/lne:logical-network-elements"
+ "/lne:logical-network-element" {
if-feature "pdr-common:device-stats";
description
"Adds device level traffic and discard counters.";
Evans, et al. Expires 31 January 2027 [Page 42]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
container traffic-discard-stats {
nacm:default-deny-all;
config false;
description
"Traffic and discard counters for the logical network
element.";
uses discard-order-policy;
uses pdr-common:traffic-and-discards;
}
}
}
<CODE ENDS>
7. Operational Considerations
7.1. Determining Operator Intent
Device discard counters do not by themselves establish operator
intent. The classification defined in this document identifies the
discard condition. Whether that condition is intended or unintended
is determined by the operator using the discard class together with
local policy, configured intent, baseline behaviour, duration,
affected scope, service context, and other operational evidence.
Some discard classes provide a strong signal on their own. For
example, errors/l2/rx above baseline will generally indicate
unintended loss, since it reports errored received frames.
Similarly, TTL-expired packets may be expected at a low baseline rate
due to traceroute or other diagnostic activity, while a sustained
increase above baseline may indicate a convergence issue, a
persistent routing loop, or another operational fault.
Congestion-related loss depends on operator context. A level of no-
buffer discards below a defined traffic performance indicator
(captured in an SLA, typically) may be expected or intended. The
same discard class above a performance indicator, sustained for
longer than expected, may be unintended and thus require action. For
example, congestion-related discards of best-effort traffic are
reported under interface/discards[direction="egress"]/no-buffer/qos/
class[id], where class[id] identifies the best-effort class. Such
discards may be determined to be intended if the loss rate over the
measurement interval is below the operator's SLA, and unintended if
it is above the SLA (see cases B1 and B2 in Appendix B). Similarly,
for Lower Effort (LE) [RFC8622] traffic, a higher loss rate during
periods of high utilisation may be acceptable or intended, subject to
the operator's service policy. When available, discard-type counters
allow operators to apply different baselines to AQM and tail-drop
discards.
Evans, et al. Expires 31 January 2027 [Page 43]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Policy discards may also require additional context. Discards
reported under policy (for example, ACL or policer discards) indicate
only that traffic matched a configured rule. If a configured policer
discards traffic because the offered load exceeds a provisioned
service profile, that may be considered an intended discard, reported
under policy/l3/policer. For example, Expedited Forwarding (EF)
[RFC3246] traffic in excess of its provisioned profile may be
intentionally discarded by a policer, although sustained policer
discards may still indicate overload of the provisioned service.
Policy discards may nonetheless be unintended if the configuration is
in error. Determining intent for policy discards requires operator-
local context. Operators should verify the configuration enforced in
underlying nodes and continuously ensure that the configuration is
consistent with the intended service.
7.2. Deployment Experience
This section captures practical insights gained from implementing the
model across multiple vendors' platforms, as guidance for future
implementers and operators:
1. Platforms often account for the number of packets discarded where
the TTL has expired (or IPv6 Hop Limit exceeded), and the device
CPU has returned an ICMP Time Exceeded message [RFC4884].
However, there is typically a policer applied to limit the number
of packets sent to the device CPU, which implicitly limits the
rate of TTL discards that are processed. One method to account
for all packet discards due to TTL expiry, even those that are
dropped by a policer when being forwarded to the CPU, is to use
accounting of all ingress packets received with TTL=1 as a proxy
measure.
2. Where no route discards are implemented with a default null
route, separate discard accounting is required for any explicit
null routes configured in order to differentiate between
interface/discards[direction="ingress"]/policy/l3/null-route and
interface/discards[direction="ingress"]/errors/l3/no-route.
3. It is useful to account separately for transit packets discarded
by ACLs or policers, and packets discarded by ACLs or policers
which limit the number of packets to the device control plane.
Evans, et al. Expires 31 January 2027 [Page 44]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
4. It is not possible to identify a configuration error (e.g., when
intended discards are unintended) with device discard metrics
alone. For example, additional context is needed to determine if
ACL discards are intended or due to a misconfigured ACL (i.e.,
with configuration validation before deployment or by detecting a
significant change in ACL discards after a configuration change
compared to before).
5. Aggregate counters need to be able to deal with the possibility
of discontinuities in the underlying counters.
6. While the classification tree is seven levels deep, a minimal
implementation may only implement the top six.
7.3. Anchoring Flow Structure
The flow component is included in the IM so that flow-level discard
classification is aligned with the device- and interface-level
classification, enabling correlation between flow records and device
or interface discard counters. The characterisation of a flow
depends on the underlying data model that adheres to the IM. From
that standpoint, the IM does not make an assumption about flow
characterisation and identification. Future flow-oriented data
models MUST ensure that the flow structure is anchored so that the
discards are unambiguously associated with a flow.
8. Implementation Status
Note to RFC Editor: This section is to be removed before publication
as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
8.1. Information Model Implementations
The IM defined in Section 5 has been implemented or mapped on at
least nine hardware platforms across four vendors, including:
Evans, et al. Expires 31 January 2027 [Page 45]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
* Broadcom: Trident, Tomahawk 1, Tomahawk 3, Tomahawk 5
* Cisco: Q200L
* Juniper: MX, PTX, QFX
* Marvell: TL7
8.2. Data Model Implementations
A YANG-compliant open-source SLAX script implements a subset of the
DM defined in Section 6 for Juniper MX routers. This implementation
is available at:
* https://github.com/o-pylypenko-aws/draft-ietf-opsawg-discardmodel-
sample/ (https://github.com/o-pylypenko-aws/draft-ietf-opsawg-
discardmodel-sample/)
Practical observations from these implementations are reflected in
Section 7.2.
9. Security Considerations
9.1. Information Model
The IM defined in Section 5.4 specifies a YANG module using [RFC8791]
data extensions. As such, there are no additional security issues
related to the YANG module that need to be considered.
The "ietf-packet-discard-reporting-common" YANG module defines a set
of identities, types, and groupings. These nodes are intended to be
reused by other YANG modules. The module by itself does not expose
any data nodes that are writable, data nodes that contain read-only
state, or RPCs. As such, there are no additional security issues
related to the YANG module that need to be considered.
Modules that use the groupings that are defined in the "ietf-packet-
discard-reporting-common" module should identify the corresponding
security considerations.
9.2. Data Model
This section is modelled after the template described in
Section 3.7.1 of [RFC9907].
The YANG module specified in Section 6.4 defines a data model that is
designed to be accessed via YANG-based management protocols, such as
Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF
Evans, et al. Expires 31 January 2027 [Page 46]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC8040]. These YANG-based management protocols (1) have to use a
secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS
[RFC9846], and QUIC [RFC9000]) and (2) have to use mutual
authentication.
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are no particularly sensitive writable data nodes.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following
subtrees and data nodes have particular sensitivities/
vulnerabilities:
rt:control-plane-protocol/pdr:traffic-discard-stats,
if:statistics/pdr:traffic-discard-stats, and lne:logical-network-
element/pdr:traffic-discard-stats: Access to these data nodes would
reveal information about the attacks to which an element is
subject, misconfigurations, etc.
Also, an attacker who can inject packets can infer the efficiency
of their attack by monitoring (the increase of) some discard
counters (e.g., policy) and adjust their attack strategy
accordingly.
10. IANA Considerations
IANA is requested to register the following URIs in the "ns" registry
within the "IETF XML Registry" group [RFC3688]:
URI:
urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting-common
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting-sx
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
Evans, et al. Expires 31 January 2027 [Page 47]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
IANA is requested to register the following YANG modules in the "YANG
Module Names" registry [RFC6020] within the "YANG Parameters"
registry group:
Name: ietf-packet-discard-reporting-common
Maintained by IANA? N
Namespace:
urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting-common
Prefix: pdr-common
Reference: RFC XXXX
Name: ietf-packet-discard-reporting-sx
Maintained by IANA? N
Namespace:
urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting-sx
Prefix: pdr-sx
Reference: RFC XXXX
Name: ietf-packet-discard-reporting
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-packet-discard-reporting
Prefix: pdr
Reference: RFC XXXX
11. References
11.1. Normative References
[IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, 22 December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>.
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC826, November 1982,
<https://www.rfc-editor.org/rfc/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Evans, et al. Expires 31 January 2027 [Page 48]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/rfc/rfc5462>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/rfc/rfc8341>.
Evans, et al. Expires 31 January 2027 [Page 49]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/rfc/rfc8343>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/rfc/rfc8349>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Logical Network Elements", RFC 8530,
DOI 10.17487/RFC8530, March 2019,
<https://www.rfc-editor.org/rfc/rfc8530>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/rfc/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/rfc/rfc8791>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/rfc/rfc9911>.
11.2. Informative References
[RED93] Floyd, S. and V. Jacobson, "Random early detection
gateways for congestion avoidance", August 1993,
<https://ieeexplore.ieee.org/document/251892>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.
Evans, et al. Expires 31 January 2027 [Page 50]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/rfc/rfc2863>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/rfc/rfc3246>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/rfc/rfc3444>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/rfc/rfc3704>.
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, DOI 10.17487/RFC3882, October 2004,
<https://www.rfc-editor.org/rfc/rfc3882>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/rfc/rfc4252>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/rfc/rfc4884>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/rfc/rfc5082>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <https://www.rfc-editor.org/rfc/rfc5085>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/rfc/rfc5635>.
Evans, et al. Expires 31 January 2027 [Page 51]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/rfc/rfc6192>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7270] Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-
Specific Information Elements Reused in IP Flow
Information Export (IPFIX)", RFC 7270,
DOI 10.17487/RFC7270, June 2014,
<https://www.rfc-editor.org/rfc/rfc7270>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/rfc/rfc8029>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
Iyengar, Ed., "Controlled Delay Active Queue Management",
RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/rfc/rfc8289>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/rfc/rfc8525>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/rfc/rfc8622>.
Evans, et al. Expires 31 January 2027 [Page 52]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/rfc/rfc8704>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/rfc/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/rfc/rfc8956>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/rfc/rfc8969>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P.
Mohapatra, "Revised Validation Procedure for BGP Flow
Specifications", RFC 9117, DOI 10.17487/RFC9117, August
2021, <https://www.rfc-editor.org/rfc/rfc9117>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/rfc/rfc9907>.
Evans, et al. Expires 31 January 2027 [Page 53]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Appendix A. Where Do Packets Get Dropped?
Understanding where packets are discarded in a network device is
essential for interpreting discard signals and determining
appropriate mitigation actions. Figure 3 depicts an example of where
and why packets may be discarded in a typical single-ASIC, shared-
buffered type device. While actual device architectures vary between
vendors and platforms, with some using multiple ASICs, distributed
forwarding, or different buffering architectures, this example
illustrates the common processing stages where packets may be
dropped. The logical model for classifying and reporting discards
remains consistent regardless of the underlying hardware
architecture.
Packets ingress on the left and egress on the right:
.-----------.
| Control |
| Plane |
| |
'---+---^---'
from_cpu | | to_cpu
| |
.-----------------------v---+-----------------------.
| |
.---+---. .----------. .---------. .----------. .---+---.
| | | | | | | | | |
Rx-->PHY/MAC+--> Ingress +--> Buffers +--> Egress +-->PHY/MAC+-> Tx
| | | Pipeline | | | | Pipeline | | |
'-------' '----------' '---------' '----------' '-------'
Typically Unintended:
errors/l2/rx errors/l3/rx no-buffer errors/l3/tx
errors/l3/no-route
errors/l3/ttl-expired
errors/internal
Typically Intended:
policy/acl policy/acl
policy/policer policy/policer
policy/rpf
policy/null-route
Figure 3: Example of Where Packets Get Dropped
See Appendix B for examples of how these discard signals map to root
causes and mitigation actions.
Evans, et al. Expires 31 January 2027 [Page 54]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Appendix B. Example Signal-to-mitigation Action Mapping
The effectiveness of automated mitigation depends on correctly
mapping discard signals to root causes and appropriate actions.
Tables 1 and 2 give example discard signal-to-mitigation action
mappings based on the features described in Section 3.
Tables 1 and 2 are a single logical example split into two physical
tables for readability. Rows with the same Case value correspond.
Table 1 shows the observed discard signal, inferred cause, rate, and
duration. Table 2 shows the example operator determination of
whether the discard is unintended and the corresponding example
mitigation action.
The "Unintended?" column is illustrative. It is not a normative
property of the discard class. In practice, the same discard class
can be intended or unintended depending on the operator's policy,
expected baseline for that class, persistence of the signal, affected
scope, and other operational context.
Evans, et al. Expires 31 January 2027 [Page 55]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
+====+=============================+===========+==========+========+
|Case| DISCARD-CLASS |Discard |DISCARD- |DISCARD-|
| | |Cause |RATE |DURATION|
+====+=============================+===========+==========+========+
|E1 | ingress/discards/errors/l2/ |Upstream |>Baseline |O(1min) |
| | rx |device or | | |
| | |link error | | |
+----+-----------------------------+-----------+----------+--------+
|T1 | ingress/discards/errors/l3/ |Traceroute |<=Baseline| |
| | ttl-expired | | | |
+----+-----------------------------+-----------+----------+--------+
|T2 | ingress/discards/errors/l3/ |Convergence|>Baseline | O(1s) |
| | ttl-expired | | | |
+----+-----------------------------+-----------+----------+--------+
|T3 | ingress/discards/errors/l3/ |Routing |>Baseline |O(1min) |
| | ttl-expired |loop | | |
+----+-----------------------------+-----------+----------+--------+
|P1 | .*/policy/.* |Policy | | |
+----+-----------------------------+-----------+----------+--------+
|R1 | ingress/discards/errors/l3/ |Convergence|>Baseline | O(1s) |
| | no-route | | | |
+----+-----------------------------+-----------+----------+--------+
|R2 | ingress/discards/errors/l3/ |Config |>Baseline |O(1min) |
| | no-route |error | | |
+----+-----------------------------+-----------+----------+--------+
|R3 | ingress/discards/errors/l3/ |Invalid |>Baseline |O(10min)|
| | no-route |destination| | |
+----+-----------------------------+-----------+----------+--------+
|I1 | ingress/discards/errors/ |Device |>Baseline |O(1min) |
| | internal |errors | | |
+----+-----------------------------+-----------+----------+--------+
|B1 | egress/discards/no-buffer |Congestion |<=Baseline| |
+----+-----------------------------+-----------+----------+--------+
|B2 | egress/discards/no-buffer |Congestion |>Baseline |O(1min) |
+----+-----------------------------+-----------+----------+--------+
|A1 | egress/discards/no- |AQM drop |<=SLA | |
| | buffer/../discard- | | | |
| | type[type="aqm"]/ | | | |
+----+-----------------------------+-----------+----------+--------+
|A2 | egress/discards/no- |AQM drop |>SLA |O(1min) |
| | buffer/../discard- | | | |
| | type[type="aqm"]/ | | | |
+----+-----------------------------+-----------+----------+--------+
Table 1: Example Signal-Cause-Mitigation Mapping (1)
Evans, et al. Expires 31 January 2027 [Page 56]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
+====+========================================+===========+=========+
|Case| DISCARD-CLASS |Unintended?|Possible |
| | | |actions |
+====+========================================+===========+=========+
|E1 | ingress/discards/errors/l2/rx | Y |Take |
| | | |upstream |
| | | |link or |
| | | |device |
| | | |out of |
| | | |service |
+----+----------------------------------------+-----------+---------+
|T1 | ingress/discards/errors/l3/ttl-expired | N |No |
| | | |action |
+----+----------------------------------------+-----------+---------+
|T2 | ingress/discards/errors/l3/ttl-expired | Y |No |
| | | |action |
+----+----------------------------------------+-----------+---------+
|T3 | ingress/discards/errors/l3/ttl-expired | Y |Roll |
| | | |back |
| | | |change |
+----+----------------------------------------+-----------+---------+
|P1 | .*/policy/.* | N |No |
| | | |action |
+----+----------------------------------------+-----------+---------+
|R1 | ingress/discards/errors/l3/no-route | Y |No |
| | | |action |
+----+----------------------------------------+-----------+---------+
|R2 | ingress/discards/errors/l3/no-route | Y |Roll |
| | | |back |
| | | |change |
+----+----------------------------------------+-----------+---------+
|R3 | ingress/discards/errors/l3/no-route | N |Escalate |
| | | |to |
| | | |operator |
+----+----------------------------------------+-----------+---------+
|I1 | ingress/discards/errors/internal | Y |Take |
| | | |device |
| | | |out of |
| | | |service |
+----+----------------------------------------+-----------+---------+
|B1 | egress/discards/no-buffer | N |No |
| | | |action |
+----+----------------------------------------+-----------+---------+
|B2 | egress/discards/no-buffer | Y |Bring |
| | | |capacity |
| | | |back |
| | | |into |
| | | |service |
Evans, et al. Expires 31 January 2027 [Page 57]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | | |or move |
| | | |traffic |
+----+----------------------------------------+-----------+---------+
|A1 | egress/discards/no-buffer/../discard- | N |No |
| | type[type="aqm"]/ | |action |
+----+----------------------------------------+-----------+---------+
|A2 | egress/discards/no-buffer/../discard- | Y |Move |
| | type[type="aqm"]/ | |traffic |
| | | |or add |
| | | |capacity |
+----+----------------------------------------+-----------+---------+
Table 2: Example Signal-Cause-Mitigation Mapping (2)
The 'Baseline' in the 'DISCARD-RATE' column is both DISCARD-CLASS and
network dependent. A rate less than or equal to baseline generally
represents expected behaviour for that operator and network context.
A rate greater than baseline indicates an anomaly candidate.
Appendix C. Full Information Model Tree
The following YANG tree diagram shows the complete IM structure:
module: ietf-packet-discard-reporting-sx
structure packet-discard-reporting:
+-- control-plane {pdr-common:control-plane-stats}?
| +-- traffic* [direction]
| | +-- direction identityref
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- discards* [direction]
| +-- direction identityref
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
| +-- policy
| +-- packets? yang:counter64
+-- interface* [name] {pdr-common:interface-stats}?
| +-- name string
| +-- traffic* [direction]
| | +-- direction identityref
| | +-- l2
| | | +-- frames? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- l3
| | | +-- address-family-stat* [address-family]
| | | +-- address-family identityref
| | | +-- packets? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 58]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | | +-- bytes? yang:counter64
| | | +-- unicast
| | | | +-- packets? yang:counter64
| | | | +-- bytes? yang:counter64
| | | +-- multicast
| | | | +-- packets? yang:counter64
| | | | +-- bytes? yang:counter64
| | | +-- broadcast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- qos!
| | +-- class* [id]
| | +-- id string
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- discards* [direction]
| +-- direction identityref
| +-- l2
| | +-- frames? yang:counter64
| | +-- bytes? yang:counter64
| +-- l3
| | +-- address-family-stat* [address-family]
| | +-- address-family identityref
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| | +-- unicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- multicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- broadcast
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- errors
| | +-- l2
| | | +-- rx
| | | | +-- frames? yang:counter64
| | | | +-- crc-error? yang:counter64
| | | | +-- invalid-mac? yang:counter64
| | | | +-- invalid-vlan? yang:counter64
| | | | +-- invalid-frame? yang:counter64
| | | +-- tx
| | | +-- frames? yang:counter64
| | +-- l3
| | | +-- rx
| | | | +-- packets? yang:counter64
| | | | +-- checksum-error? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 59]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | | | +-- invalid-packet? yang:counter64
| | | +-- mtu-exceeded
| | | | +-- packets?
| | | | | yang:counter64
| | | | +-- fragmentation-not-permitted?
| | | | | yang:counter64
| | | | +-- fragmentation-permitted-not-performed?
| | | | yang:counter64
| | | +-- ttl-expired? yang:counter64
| | | +-- no-route? yang:counter64
| | | +-- neighbor-resolution-failure? yang:counter64
| | | +-- invalid-sid? yang:counter64
| | | +-- invalid-label? yang:counter64
| | | +-- tx
| | | +-- packets? yang:counter64
| | +-- internal
| | +-- packets? yang:counter64
| | +-- parity-error? yang:counter64
| +-- policy
| | +-- l2
| | | +-- frames? yang:counter64
| | | +-- acl? yang:counter64
| | +-- l3
| | +-- packets? yang:counter64
| | +-- acl? yang:counter64
| | +-- policer
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | | +-- classes!
| | | +-- class* [id]
| | | +-- id string
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- null-route? yang:counter64
| | +-- rpf? yang:counter64
| | +-- dos? yang:counter64
| +-- no-buffer
| +-- qos!
| +-- class* [id]
| +-- id string
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
| +-- discard-type* [type]
| +-- type identityref
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
+-- flow* [direction] {pdr-common:flow-reporting}?
| +-- direction identityref
Evans, et al. Expires 31 January 2027 [Page 60]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +-- traffic
| | +-- l2
| | | +-- frames? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- l3
| | | +-- address-family-stat* [address-family]
| | | +-- address-family identityref
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | | +-- unicast
| | | | +-- packets? yang:counter64
| | | | +-- bytes? yang:counter64
| | | +-- multicast
| | | | +-- packets? yang:counter64
| | | | +-- bytes? yang:counter64
| | | +-- broadcast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- qos!
| | +-- class* [id]
| | +-- id string
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- discards
| +-- l2
| | +-- frames? yang:counter64
| | +-- bytes? yang:counter64
| +-- l3
| | +-- address-family-stat* [address-family]
| | +-- address-family identityref
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| | +-- unicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- multicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- broadcast
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- errors
| | +-- l2
| | | +-- rx
| | | | +-- frames? yang:counter64
| | | | +-- crc-error? yang:counter64
| | | | +-- invalid-mac? yang:counter64
| | | | +-- invalid-vlan? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 61]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | | | +-- invalid-frame? yang:counter64
| | | +-- tx
| | | +-- frames? yang:counter64
| | +-- l3
| | | +-- rx
| | | | +-- packets? yang:counter64
| | | | +-- checksum-error? yang:counter64
| | | | +-- invalid-packet? yang:counter64
| | | +-- mtu-exceeded
| | | | +-- packets?
| | | | | yang:counter64
| | | | +-- fragmentation-not-permitted?
| | | | | yang:counter64
| | | | +-- fragmentation-permitted-not-performed?
| | | | yang:counter64
| | | +-- ttl-expired? yang:counter64
| | | +-- no-route? yang:counter64
| | | +-- neighbor-resolution-failure? yang:counter64
| | | +-- invalid-sid? yang:counter64
| | | +-- invalid-label? yang:counter64
| | | +-- tx
| | | +-- packets? yang:counter64
| | +-- internal
| | +-- packets? yang:counter64
| | +-- parity-error? yang:counter64
| +-- policy
| | +-- l2
| | | +-- frames? yang:counter64
| | | +-- acl? yang:counter64
| | +-- l3
| | +-- packets? yang:counter64
| | +-- acl? yang:counter64
| | +-- policer
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | | +-- classes!
| | | +-- class* [id]
| | | +-- id string
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- null-route? yang:counter64
| | +-- rpf? yang:counter64
| | +-- dos? yang:counter64
| +-- no-buffer
| +-- qos!
| +-- class* [id]
| +-- id string
| +-- packets? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 62]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +-- bytes? yang:counter64
| +-- discard-type* [type]
| +-- type identityref
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
+-- device {pdr-common:device-stats}?
+-- traffic
| +-- l2
| | +-- frames? yang:counter64
| | +-- bytes? yang:counter64
| +-- l3
| | +-- address-family-stat* [address-family]
| | +-- address-family identityref
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| | +-- unicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- multicast
| | | +-- packets? yang:counter64
| | | +-- bytes? yang:counter64
| | +-- broadcast
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- qos!
| +-- class* [id]
| +-- id string
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
+-- discards
+-- l2
| +-- frames? yang:counter64
| +-- bytes? yang:counter64
+-- l3
| +-- address-family-stat* [address-family]
| +-- address-family identityref
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
| +-- unicast
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- multicast
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- broadcast
| +-- packets? yang:counter64
| +-- bytes? yang:counter64
+-- errors
Evans, et al. Expires 31 January 2027 [Page 63]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +-- l2
| | +-- rx
| | | +-- frames? yang:counter64
| | | +-- crc-error? yang:counter64
| | | +-- invalid-mac? yang:counter64
| | | +-- invalid-vlan? yang:counter64
| | | +-- invalid-frame? yang:counter64
| | +-- tx
| | +-- frames? yang:counter64
| +-- l3
| | +-- rx
| | | +-- packets? yang:counter64
| | | +-- checksum-error? yang:counter64
| | | +-- invalid-packet? yang:counter64
| | +-- mtu-exceeded
| | | +-- packets?
| | | | yang:counter64
| | | +-- fragmentation-not-permitted?
| | | | yang:counter64
| | | +-- fragmentation-permitted-not-performed?
| | | yang:counter64
| | +-- ttl-expired? yang:counter64
| | +-- no-route? yang:counter64
| | +-- neighbor-resolution-failure? yang:counter64
| | +-- invalid-sid? yang:counter64
| | +-- invalid-label? yang:counter64
| | +-- tx
| | +-- packets? yang:counter64
| +-- internal
| +-- packets? yang:counter64
| +-- parity-error? yang:counter64
+-- policy
| +-- l2
| | +-- frames? yang:counter64
| | +-- acl? yang:counter64
| +-- l3
| +-- packets? yang:counter64
| +-- acl? yang:counter64
| +-- policer
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| | +-- classes!
| | +-- class* [id]
| | +-- id string
| | +-- packets? yang:counter64
| | +-- bytes? yang:counter64
| +-- null-route? yang:counter64
| +-- rpf? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 64]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +-- dos? yang:counter64
+-- no-buffer
+-- qos!
+-- class* [id]
+-- id string
+-- packets? yang:counter64
+-- bytes? yang:counter64
+-- discard-type* [type]
+-- type identityref
+-- packets? yang:counter64
+-- bytes? yang:counter64
Appendix D. Full Data Model Tree
The following YANG tree diagram shows the complete DM structure:
module: ietf-packet-discard-reporting
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--ro traffic-discard-stats {pdr-common:control-plane-stats}?
+--ro discard-order-capability* identityref
+--ro traffic* [direction]
| +--ro direction identityref
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--ro discards* [direction]
+--ro direction identityref
+--ro packets? yang:counter64
+--ro bytes? yang:counter64
+--ro policy
+--ro packets? yang:counter64
augment /if:interfaces/if:interface/if:statistics:
+--ro traffic-discard-stats {pdr-common:interface-stats}?
+--ro discard-order-capability* identityref
+--ro traffic* [direction]
| +--ro direction identityref
| +--ro l2
| | +--ro frames? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro l3
| | +--ro address-family-stat* [address-family]
| | +--ro address-family identityref
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| | +--ro unicast
| | | +--ro packets? yang:counter64
| | | +--ro bytes? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 65]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | +--ro multicast
| | | +--ro packets? yang:counter64
| | | +--ro bytes? yang:counter64
| | +--ro broadcast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro qos!
| +--ro class* [id]
| +--ro id string
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--ro discards* [direction]
+--ro direction identityref
+--ro l2
| +--ro frames? yang:counter64
| +--ro bytes? yang:counter64
+--ro l3
| +--ro address-family-stat* [address-family]
| +--ro address-family identityref
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
| +--ro unicast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro multicast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro broadcast
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--ro errors
| +--ro l2
| | +--ro rx
| | | +--ro frames? yang:counter64
| | | +--ro crc-error? yang:counter64
| | | +--ro invalid-mac? yang:counter64
| | | +--ro invalid-vlan? yang:counter64
| | | +--ro invalid-frame? yang:counter64
| | +--ro tx
| | +--ro frames? yang:counter64
| +--ro l3
| | +--ro rx
| | | +--ro packets? yang:counter64
| | | +--ro checksum-error? yang:counter64
| | | +--ro invalid-packet? yang:counter64
| | +--ro mtu-exceeded
| | | +--ro packets?
| | | | yang:counter64
Evans, et al. Expires 31 January 2027 [Page 66]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | | +--ro fragmentation-not-permitted?
| | | | yang:counter64
| | | +--ro fragmentation-permitted-not-performed?
| | | yang:counter64
| | +--ro ttl-expired? yang:counter64
| | +--ro no-route? yang:counter64
| | +--ro neighbor-resolution-failure? yang:counter64
| | +--ro invalid-sid? yang:counter64
| | +--ro invalid-label? yang:counter64
| | +--ro tx
| | +--ro packets? yang:counter64
| +--ro internal
| +--ro packets? yang:counter64
| +--ro parity-error? yang:counter64
+--ro policy
| +--ro l2
| | +--ro frames? yang:counter64
| | +--ro acl? yang:counter64
| +--ro l3
| +--ro packets? yang:counter64
| +--ro acl? yang:counter64
| +--ro policer
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| | +--ro classes!
| | +--ro class* [id]
| | +--ro id string
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro null-route? yang:counter64
| +--ro rpf? yang:counter64
| +--ro dos? yang:counter64
+--ro no-buffer
+--ro qos!
+--ro class* [id]
+--ro id string
+--ro packets? yang:counter64
+--ro bytes? yang:counter64
+--ro discard-type* [type]
+--ro type identityref
+--ro packets? yang:counter64
+--ro bytes? yang:counter64
augment /lne:logical-network-elements/lne:logical-network-element:
+--ro traffic-discard-stats {pdr-common:device-stats}?
+--ro discard-order-capability* identityref
+--ro traffic
| +--ro l2
| | +--ro frames? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 67]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| | +--ro bytes? yang:counter64
| +--ro l3
| | +--ro address-family-stat* [address-family]
| | +--ro address-family identityref
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| | +--ro unicast
| | | +--ro packets? yang:counter64
| | | +--ro bytes? yang:counter64
| | +--ro multicast
| | | +--ro packets? yang:counter64
| | | +--ro bytes? yang:counter64
| | +--ro broadcast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro qos!
| +--ro class* [id]
| +--ro id string
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--ro discards
+--ro l2
| +--ro frames? yang:counter64
| +--ro bytes? yang:counter64
+--ro l3
| +--ro address-family-stat* [address-family]
| +--ro address-family identityref
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
| +--ro unicast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro multicast
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro broadcast
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--ro errors
| +--ro l2
| | +--ro rx
| | | +--ro frames? yang:counter64
| | | +--ro crc-error? yang:counter64
| | | +--ro invalid-mac? yang:counter64
| | | +--ro invalid-vlan? yang:counter64
| | | +--ro invalid-frame? yang:counter64
| | +--ro tx
| | +--ro frames? yang:counter64
Evans, et al. Expires 31 January 2027 [Page 68]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
| +--ro l3
| | +--ro rx
| | | +--ro packets? yang:counter64
| | | +--ro checksum-error? yang:counter64
| | | +--ro invalid-packet? yang:counter64
| | +--ro mtu-exceeded
| | | +--ro packets?
| | | | yang:counter64
| | | +--ro fragmentation-not-permitted?
| | | | yang:counter64
| | | +--ro fragmentation-permitted-not-performed?
| | | yang:counter64
| | +--ro ttl-expired? yang:counter64
| | +--ro no-route? yang:counter64
| | +--ro neighbor-resolution-failure? yang:counter64
| | +--ro invalid-sid? yang:counter64
| | +--ro invalid-label? yang:counter64
| | +--ro tx
| | +--ro packets? yang:counter64
| +--ro internal
| +--ro packets? yang:counter64
| +--ro parity-error? yang:counter64
+--ro policy
| +--ro l2
| | +--ro frames? yang:counter64
| | +--ro acl? yang:counter64
| +--ro l3
| +--ro packets? yang:counter64
| +--ro acl? yang:counter64
| +--ro policer
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| | +--ro classes!
| | +--ro class* [id]
| | +--ro id string
| | +--ro packets? yang:counter64
| | +--ro bytes? yang:counter64
| +--ro null-route? yang:counter64
| +--ro rpf? yang:counter64
| +--ro dos? yang:counter64
+--ro no-buffer
+--ro qos!
+--ro class* [id]
+--ro id string
+--ro packets? yang:counter64
+--ro bytes? yang:counter64
+--ro discard-type* [type]
+--ro type identityref
Evans, et al. Expires 31 January 2027 [Page 69]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
+--ro packets? yang:counter64
+--ro bytes? yang:counter64
Acknowledgements
The content of this document has benefitted from feedback from JR
Rivers, Ronan Waide, Chris DeBruin, and Marcos Sanz.
Thanks to Benoît Claise, Joe Clarke, Tom Petch, Mahesh Jethanandani,
Paul Aitken, and Randy Bush for the review and comments.
Thanks to Ladislav Lhotka for the YANGDOCTORS reviews, Sergio Belotti
for the OPSDIR review, Satoru Matsushima for the INTDIR review,
Derrell Piper for the SECDIR review, Roni Even for the GENART review,
and Michael Tüxen for the TSVART review. Special thanks to Carlos
Pignataro for the detailed INTDIR review and suggestions that
enhanced this specification.
Thanks to Diego Lopez for shepherding the document and Mahesh
Jethanandani for the AD review.
Thanks to Christopher Inacio, Éric Vyncke, Gorry Fairhurst, Ketan
Talaulikar, Deb Cooley, and Mike Bishop for the IESG review.
Contributors
Nadav Chachmon
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: nchachmo@cisco.com
Authors' Addresses
John Evans (editor)
Individual
Email: john@nopacketleftbehind.net
Oleksandr Pylypenko (editor)
Nvidia
2788 San Tomas Expy
Santa Clara, CA 95051
United States of America
Email: opylypenko@nvidia.com
Evans, et al. Expires 31 January 2027 [Page 70]
Internet-Draft IM and DM for Packet Discard Reporting July 2026
Jeffrey Haas
HPE
United States of America
Email: jeffrey.haas@hpe.com
Aviran Kadosh
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: akadosh@cisco.com
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Evans, et al. Expires 31 January 2027 [Page 71]