]> Amazon

1 Principal Place, Worship Street London EC2A 2FA UK jevanamz@amazon.co.uk

Nvidia

2788 San Tomas Expy Santa Clara CA 95051 US opylypenko@nvidia.com

Juniper Networks

1133 Innovation Way Sunnyvale CA 94089 US jhaas@juniper.net

Cisco Systems, Inc.

170 West Tasman Dr. San Jose CA 95134 US akadosh@cisco.com

Orange

France mohamed.boucadair@orange.com

Operations and Management Area Operations and Management Area Working Group Troubleshooting Diagnostic Network Automation Network Service Resilience Robustness Root cause Anomaly Incident Customer experience 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 the interface, device, and control-plane discards. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Operations and Management Area Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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" and "A YANG Data Model for Interface Management" , 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, provides support for reporting discards per flow in IP Flow Information Export (IPFIX) 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). 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 packet loss at Layer 3 and frames discarded at Layer 2. This document considers only the signals that may trigger automated mitigation actions and not how the actions are defined or executed. Such considerations are deployment-specific. describes the problem space and requirements. defines the IM and its classification scheme. specifies the corresponding YANG data model and implementation requirements together with a set of usage examples, and the complete YANG module definition. Appendices and provide additional context and implementation guidance.

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

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 when, and only when, they appear in all capitals, as shown here. Tree diagrams used in this document follow the notation defined in . This document makes use of the following terms:

Packet discard:

It accounts for any instance where a packet is dropped by a device, regardless of whether the discard was intentional or unintentional.

Intended packet discards (Intended discards, for short):

Are 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):

Are packets that were dropped, which the network operator otherwise intended to deliver, i.e., which indicates 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.

Device discard counters do not by themselves establish operator intent. Discards reported under policy (e.g., ACL/policer) indicate only that traffic matched a configured rule; such discards may still be unintended if the configuration is in error. Determining intent for policy discards requires external context (e.g., configuration validation and change history) which is out of scope for this specification.

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 for more examples.

While most of FEATURE-DISCARD-SCOPE, FEATURE-DISCARD-RATE, and FEATURE-DISCARD-DURATION are implicitly supported by the Interfaces Group MIB and the YANG Data Model for Interface Management , FEATURE-DISCARD-CLASS requires a more detailed classification scheme than they define. The IM provided in defines such a classification scheme to enable automated mapping from discard signals to appropriate mitigation actions (refer to for examples).

Information Model (IM) The IM is defined using YANG , with Data Structure Extensions , allowing the model to remain abstract and decoupled from specific implementations in accordance with . This abstraction supports different DM implementations, such as YANG or IPFIX , 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 .

• Design note: In order to ease reuse of the IM structure by DMs but without requiring that these DMs to parse the "sx" structure defined in , main reusable nodes are defined in a common module () while the main IM structure is defined in .

Structure The IM defines a hierarchical classification scheme for packet discards, which captures where in a device the discards are accounted (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 . The full YANG tree diagram of the IM is provided in .

Abstract IM Tree Structure

The discard reporting can be organized 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. 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 .

Subtype Definitions

discards/policy/:

These are intended discards, meaning packets dropped due to a configured policy, including: ACLs, traffic policers, unicast Reverse Path Forwarding (uRPF) checks, Distributed Denial-of-Service (DDoS) protection rules, and explicit null routes. In practice, ingress DDoS protection policies are often realized using mechanisms such as ingress filtering and uRPF (, , and ), remotely triggered blackholing (, ), or BGP Flow Specification–based filters (, , and ); all such policy-driven discards are reported under this class.

discards/errors/:

These are unintended discards due to errors in processing packets or frames. There are multiple sub-classes:

• 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, MTU exceeded, invalid packet errors (i.e., incorrect version, incorrect header length, invalid options, and other malformed packet conditions).

• discards/errors/l3/ttl-expired:

  These discards occur due to TTL (or Hop limit) expiry. These can occur, e.g., for the following reasons: normal trace-route operations, 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, e.g., which may be due to routing configuration errors or may be transient discards during convergence.

• 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 discards due to buffer exhaustion (that is congestion related discards). These can be tail-drop discards or due to an active queue management algorithm, such as Random Early Detection (RED) or Controlled Delay (CoDel) .

An example of possible signal-to-mitigation action mapping is provided in .

"ietf-packet-discard-reporting-common" YANG Module The "ietf-packet-discard-reporting-common" module imports "ietf-yang-types" defined in . Editor: John Evans Editor: Oleksandr Pylypenko Author: Jeffrey Haas Author: Aviran Kadosh Editor: Mohamed Boucadair "; 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 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."; } /* * 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 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."; } leaf invalid-vlan { type yang:counter64; description "The number of received frames discarded due to an invalid VLAN tag."; } 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 "The number of received packets discarded due to a checksum error."; } leaf mtu-exceeded { type yang:counter64; description "The number of received packets discarded due to MTU exceeded."; } 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."; } } leaf ttl-expired { type yang:counter64; description "The number of received packets discarded due to expired TTL or Hop Limit exceeded."; } leaf no-route { type yang:counter64; description "The number of received packets discarded due to not matching a valid route."; } 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."; } leaf invalid-label { type yang:counter64; description "The number of received packets discarded due to an invalid MPLS label."; } } 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."; } } 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 ACLs."; } container policer { description "The number of 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 ddos { type yang:counter64; description "The number of packets discarded due to Distributed Denial-of-Service (DDoS) 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 "Discard counters due to buffer unavailability."; uses 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; } } } } ]]>

"ietf-packet-discard-reporting-sx" YANG Module The "ietf-packet-discard-reporting-sx" module uses the "sx" structure defined in and also imports the "ietf-packet-discard-reporting-common" module (). Editor: John Evans Editor: Oleksandr Pylypenko Author: Jeffrey Haas Author: Aviran Kadosh Editor: Mohamed Boucadair "; 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"; leaf direction { type identityref { base pdr-common:direction; } description "Specifies a direction."; } description "Flow packet counters."; 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; } } } ]]>

Data Model (DM) This DM implements the IM defined in for the interface, device, and control-plane components. It is a device model per . 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 . This DM imports that module and reuses the same groupings and hierarchy of components, directions, layers, and discard classes, attaching them 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 are not instantiated in this DM.

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 .

Abstract DM Tree Structure

The full tree structure is provided in .

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. However, 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 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.
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.
9. When there are multiple reasons for discarding a packet, the ordering of discard class reporting MUST be defined. Typically, this can be exposed by an implementation by means of discard-order-capability.
10. If Diffserv is not 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. No-buffer discards can be realized differently with different memory architectures. Whether a no-buffer discard is attributed to ingress or egress can differ accordingly. For successful auto-mitigation, discards due to an 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. Traffic from the device control plane (from-CPU) is accounted for by origin, independent of the forwarding mechanism (e.g., any egress policer it traverses), and MUST also be accounted for in the same way as other egress traffic.

Usage Examples This section assumes that no class of service is implemented. If all of the requirements listed in 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/traffic[direction="ingress"]/l3/address-family-stat[address-family="ipv6"]/unicast/packets
• interface/traffic[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 due to no buffers 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/class[id="0"]/packets
• interface/discards[direction="egress"]/no-buffer/class[id="0"]/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

"ietf-packet-discard-reporting" YANG Module The "ietf-packet-discard-reporting" module imports "ietf-packet-discard-reporting-common" (), "ietf-netconf-acm" , "ietf-interfaces" , "ietf-routing" , and "ietf-logical-network-element" . Editor: John Evans Editor: Oleksandr Pylypenko Author: Jeffrey Haas Author: Aviran Kadosh Editor: Mohamed Boucadair "; 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 (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 discard due to buffer unavailability."; } /* * 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; } config false; 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 discard-stats { nacm:default-deny-all; config false; description "List of control plane discard counters."; uses discard-order-policy; uses pdr-common:control-plane; } } augment "/if:interfaces/if:interface/if:statistics" { if-feature "pdr-common:interface-stats"; description "Adds packet discard reporting to the interface statistics."; 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 packet counters."; container discard-stats { nacm:default-deny-all; config false; description "List of device level discard counters."; uses discard-order-policy; uses pdr-common:traffic-and-discards; } } } ]]>

Operational Considerations

Deployment Experience This section captures practical insights gained from implementing the model across multiple vendors' platforms, as guidance for future implementers and operators:

1. 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.
2. 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.
3. 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 . There is typically a policer applied to limit the number of packets sent to the device CPU, however, which implicitly limits the rate of TTL discards that are processed. One method to account for all packet discards due to TTL expired, 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.
4. 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/ingress/discards/policy/null-route/packets and interface/ingress/discards/errors/no-route/packets.
5. 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.
6. 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).
7. Aggregate counters need to be able to deal with the possibility of discontinuities in the underlying counters.
8. While the classification tree is seven levels deep, a minimal implementation may only implement the top six.

Anchoring Flow Structure The characterization 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 characterization 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.

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.

Information Model Implementations The IM defined in 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

Data Model Implementations A YANG-compliant open-source SLAX script implements a subset of the DM defined in for Juniper MX routers. This implementation is available at:

• https://github.com/o-pylypenko-aws/draft-ietf-opsawg-discardmodel-sample/

Practical observations from these implementations are reflected in .

Security Considerations

Information Model The IM defined in specifies a YANG module using 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.

Data Model This section is modeled after the template described in . The YANG module specified in defines a data model that is designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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:discard-stats, if:statistics/pdr:traffic, if:statistics/pdr:discards, and lne:logical-network-element/pdr: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 its attack by monitoring (the increase of) some discard counters (e.g., policy) and adjust its attack strategy accordingly.

IANA Considerations IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" : IANA is requested to register the following YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry:

References Normative References This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes YANG mechanisms for defining abstract data structures with YANG. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK] This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012. This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community. Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server. This document updates the validation procedure in RFC 8955. This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK] This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

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

Example of Where Packets Get Dropped PHY/MAC+--> Ingress +--> Buffers +--> Egress +-->PHY/MAC+-> Tx | | | Pipeline | | | | Pipeline | | | '-------' '----------' '---------' '----------' '-------' Unintended: errors/l2/rx errors/l3/rx no-buffer errors/l3/tx errors/l3/no-route errors/l3/ttl-expired errors/internal Intended: policy/acl policy/acl policy/policer policy/policer policy/rpf policy/null-route ]]>

See for examples of how these discard signals map to root causes and mitigation actions.

Example Signal-to-mitigation Action Mapping The effectiveness of automated mitigation depends on correctly mapping discard signals to root causes and appropriate actions. Tables and give example discard signal-to-mitigation action mappings based on the features described in . Example Signal-Cause-Mitigation Mapping (1)

DISCARD-CLASS	Discard cause	DISCARD-RATE	DISCARD-DURATION
ingress/discards/errors/l2/rx	Upstream device or link error	>Baseline	O(1min)
ingress/discards/errors/l3/ttl-expired	Tracert	<=Baseline
ingress/discards/errors/l3/ttl-expired	Convergence	>Baseline	O(1s)
ingress/discards/errors/l3/ttl-expired	Routing loop	>Baseline	O(1min)
.*/policy/.*	Policy
ingress/discards/errors/l3/no-route	Convergence	>Baseline	O(1s)
ingress/discards/errors/l3/no-route	Config error	>Baseline	O(1min)
ingress/discards/errors/l3/no-route	Invalid destination	>Baseline	O(10min)
ingress/discards/errors/internal	Device errors	>Baseline	O(1min)
egress/discards/no-buffer	Congestion	<=Baseline
egress/discards/no-buffer	Congestion	>Baseline	O(1min)

Example Signal-Cause-Mitigation Mapping (2)

DISCARD-CLASS	Unintended?	Possible actions
ingress/discards/errors/l2/rx	Y	Take upstream link or device out-of-service
ingress/discards/errors/l3/ttl-expired	N	no action
ingress/discards/errors/l3/ttl-expired	Y	No action
ingress/discards/errors/l3/ttl-expired	Y	Roll-back change
.*/policy/.*	N	No action
ingress/discards/errors/l3/no-route	Y	No action
ingress/discards/errors/l3/no-route	Y	Roll-back change
ingress/discards/errors/l3/no-route	N	Escalate to operator
ingress/discards/errors/internal	Y	Take device out-of-service
egress/discards/no-buffer	N	No action
egress/discards/no-buffer	Y	Bring capacity back into service or move traffic

The 'Baseline' in the 'DISCARD-RATE' column is both DISCARD-CLASS and network dependent.

Full Information Model Tree The following YANG tree diagram shows the complete IM structure:

Full Data Model Tree The following YANG tree diagram shows the complete DM structure:

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, and Satoru Matsushima for the INTDIR review. Thanks to Diego Lopez for shepherding the document and Mahesh Jethanandani for the AD review.

Contributors Cisco Systems, Inc.

170 West Tasman Dr. San Jose CA 95134 US nchachmo@cisco.com