Internet-Draft IM and DM for Packet Discard Reporting July 2026
Evans, et al. Expires 23 January 2027 [Page]
Workgroup:
Operations and Management Area Working Group
Internet-Draft:
draft-ietf-opsawg-discardmodel-15
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Evans, Ed.
Individual
O. Pylypenko, Ed.
Nvidia
J. Haas
HPE
A. Kadosh
Cisco Systems, Inc.
M. Boucadair, Ed.
Orange

Information and Data Models for Packet Discard Reporting

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 - both intended (e.g., due to policy) and unintended (e.g., due to congestion or errors) - to enable automated network 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.

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 23 January 2027.

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. 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 packet discards, Layer 2 frame discards, and discards during MPLS label processing [RFC3031]. 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.

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.

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.

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.

  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]
    |     ...
    +-- 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
    |     |  ...
    |     +-- 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]
                      ...
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.

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. 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 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].

<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).

     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.";
  }

  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.";
  }

  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.";
    }
  }

  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;
      }
    }
  }

  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.";
    uses qos {
      augment "qos/class" {
        description
          "Adds per-type discard counters to each QoS class.";
        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.";
      }
      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-rx {
    description
      "Layer 3 ingress packet error discard counters.";
    container rx {
      description
        "Layer 3 ingress packet receive error discard
         counters.";
      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;
        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.";
      }
      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 due to not
         matching a valid route.";
    }
    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)";
    }
    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).
         For SR-MPLS, invalid SIDs have to be accounted
         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 due to an
         invalid MPLS label.";
      reference
        "RFC 3031: Multiprotocol Label Switching Architecture";
    }
  }

  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
        "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;
    }
    container l3 {
      description
        "Layer 3 packet error discard counters.";
      uses errors-l3-rx;
      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.";
      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 due to
         Denial-of-Service (DoS) protection policies.";
    }
  }

  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;
    }
    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;
    }
  }

  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 {
      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)";
  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";
  }

  /*
   * 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;
    }
  }
}

<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]
       |        ...
       +--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
          |     ...
          +--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. While the DM defines a comprehensive set of counters and statistics, implementations MAY support a subset of the defined features based on device capabilities and operational requirements. Implementations must clearly document which features are supported and how they map to the DM.

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:

  1. All instances of Layer 2 frame or Layer 3 packet receipt, transmission, and discards MUST be accounted for.

  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.

  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 and exposed by an implementation. Typically, this can be exposed by an implementation by means of discard-order-capability.

  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.

  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.

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:

  • 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

  • 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)";
  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
   */

  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.";

    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.";

    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.

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.

  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:

  • 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:

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 [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], 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.

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, , <https://doi.org/10.1109/IEEESTD.2022.10004498>.
[RFC791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[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, , <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, , <https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc6020>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8343]
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8791>.
[RFC9911]
Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, , <https://www.rfc-editor.org/rfc/rfc9911>.

11.2. Informative References

[RED93]
Floyd, S. and V. Jacobson, "Random early detection gateways for congestion avoidance", , <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, , <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC2863]
McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc3704>.
[RFC3882]
Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, DOI 10.17487/RFC3882, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc4884>.
[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, , <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, , <https://www.rfc-editor.org/rfc/rfc5635>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8029>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8340>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8622]
Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, , <https://www.rfc-editor.org/rfc/rfc8622>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9117>.
[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, , <https://www.rfc-editor.org/rfc/rfc9907>.

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 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.

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.

Table 1: Example Signal-Cause-Mitigation Mapping (1)
Case DISCARD-CLASS Discard Cause DISCARD-RATE DISCARD-DURATION
E1 ingress/discards/errors/l2/rx Upstream device or link error >Baseline O(1min)
T1 ingress/discards/errors/l3/ttl-expired Traceroute <=Baseline  
T2 ingress/discards/errors/l3/ttl-expired Convergence >Baseline O(1s)
T3 ingress/discards/errors/l3/ttl-expired Routing loop >Baseline O(1min)
P1 .*/policy/.* Policy    
R1 ingress/discards/errors/l3/no-route Convergence >Baseline O(1s)
R2 ingress/discards/errors/l3/no-route Config error >Baseline O(1min)
R3 ingress/discards/errors/l3/no-route Invalid destination >Baseline O(10min)
I1 ingress/discards/errors/internal Device errors >Baseline O(1min)
B1 egress/discards/no-buffer Congestion <=Baseline  
B2 egress/discards/no-buffer Congestion >Baseline O(1min)
A1 egress/discards/no-buffer/../discard-type[type="aqm"]/ AQM drop <=SLA  
A2 egress/discards/no-buffer/../discard-type[type="aqm"]/ AQM drop >SLA O(1min)
Table 2: Example Signal-Cause-Mitigation Mapping (2)
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 or move traffic
A1 egress/discards/no-buffer/../discard-type[type="aqm"]/ N No action
A2 egress/discards/no-buffer/../discard-type[type="aqm"]/ Y Move traffic or add capacity

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
    |  |  |     +-- 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
    |     |  |  |  +-- 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
    |  +-- 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
    |     |  |  |  +-- 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
    |              +-- 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
          |  +-- 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
          |     +-- 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
       |  |     +--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
          |  |  |  +--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
       |  |  +--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
          |  +--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
                      +--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.

Contributors

Nadav Chachmon
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America

Authors' Addresses

John Evans (editor)
Individual
Oleksandr Pylypenko (editor)
Nvidia
2788 San Tomas Expy
Santa Clara, CA 95051
United States of America
Jeffrey Haas
HPE
United States of America
Aviran Kadosh
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Mohamed Boucadair (editor)
Orange
France