]> Individual

john@nopacketleftbehind.net

Nvidia

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

HPE

US jeffrey.haas@hpe.com

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 by its cause (e.g., errors, congestion, or policy). This classification enables operators to determine which losses are expected or intended and which are unintended, and to select appropriate mitigation actions, including automated mitigation of unintended packet loss. The YANG data model specifies an implementation of this Information Model for network elements with a focus on interface, device, and control-plane discards. About This Document 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). A common operational workflow is to reconcile device- and interface-level packet loss with the traffic flows that were impacted. To support this, the IM defined in this document includes a flow component which applies the same discard classification at the flow level as at the device and interface levels, so that flow-level discard reporting (e.g., via IPFIX) can be directly correlated with device- and interface-level discard reporting. This document defines an Information Model (IM) and specifies a corresponding YANG Data Model (DM) for packet loss reporting to address the above issues. The IM provides precise classification of packet loss to enable accurate automated mitigation. The DM specifies a YANG implementation of this IM for network elements, while maintaining consistency through clear semantics. The scope of this document is limited to reporting Layer 3 (including MPLS ) packet discards and Layer 2 frame discards. The reported signals may trigger automated mitigation actions; the definition and execution of those actions are deployment-specific. Protocol actions associated with a discard (e.g., ICMP error message generation) are governed by the applicable protocol specifications and local policy. describes the problem space and requirements. explains the design rationale. 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:

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.

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

Design Rationale

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

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 , the 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 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 . The full YANG tree diagram of the IM is provided in .

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. 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 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 ). In practice, ingress DoS protection policies are often realised 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 due to control-plane protection policies , including the Generalized TTL Security Mechanism (GTSM) , are reported under the control-plane component's policy discards. A GTSM discard indicates that the received TTL or Hop Limit is outside the configured expected range. Consistent with the requirements listed in , 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 ). 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 and of , Sections and of ).

• 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 traceroute operations, including MPLS LSP ping/traceroute and pseudowire VCCV 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 (, ).

• 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) or Controlled Delay (CoDel) . Implementations MAY additionally report per-type counters in the discard-type list.

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 . The module references , , , and . 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 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."; container qos { presence "QoS statistics are available."; description "Per-class QoS traffic counters."; list class { key "id"; min-elements 1; description "Class traffic counters."; leaf id { type string; description "Indicates a QoS class identifier."; } uses basic-packets-bytes; list discard-type { key "type"; description "Per-type discard counters."; leaf type { type identityref { base no-buffer-type; } description "Specifies the discard type."; } uses basic-packets-bytes; } } } } grouping traffic { description "All traffic counters."; container l2 { description "Layer 2 traffic counters."; uses l2-traffic; } container l3 { description "Layer 3 traffic counters."; uses l3-traffic; } uses qos; } grouping errors-l2-rx { description "Layer 2 ingress frame error discard counters."; container rx { description "Layer 2 ingress frame receive error discard counters."; leaf frames { type yang:counter64; description "The number of frames discarded due to errors with the received frame."; } leaf crc-error { type yang:counter64; description "The number of received frames discarded due to Cyclic Redundancy Check (CRC) error."; } leaf invalid-mac { type yang:counter64; description "The number of received frames discarded due to an invalid Media Access Control (MAC) address. Applies to Ethernet or Ethernet-derived encapsulations where MAC addresses are present."; } leaf invalid-vlan { type yang:counter64; description "The number of received frames discarded due to an invalid VLAN tag. Applies to Ethernet or Ethernet-derived encapsulations where VLAN tags are present."; } leaf invalid-frame { type yang:counter64; description "The number of invalid received frames discarded due to other reasons, not limited to: malformed frames, frame-size violations."; } } } grouping errors-l3 { description "Layer 3 packet error discard counters."; container rx { description "Counters for Layer 3 packets discarded due to errors in the received packet, indicating an upstream problem rather than an issue with the reporting device."; leaf packets { type yang:counter64; description "The number of Layer 3 packets discarded due to errors in the received packet."; } leaf checksum-error { type yang:counter64; 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 because the destination address does not match a valid entry in the routing table. This includes packets discarded after outer header removal (e.g., MPLS label disposition or tunnel decapsulation) when the exposed IP header does not match a valid entry in the routing table. MPLS label lookup failures are reported under 'invalid-label'."; } leaf neighbor-resolution-failure { type yang:counter64; description "Reports packets discarded because the forwarding engine could not resolve or use the link-layer adjacency required to forward the packet to the selected next hop. This includes packets dropped because ARP resolution for an IPv4 next hop failed, Neighbor Discovery resolution for an IPv6 next hop failed, or the resolved neighbor entry was unusable according to local neighbor state. This counter applies when route selection identified a next hop, but forwarding could not complete because the required neighbor or adjacency information was unavailable or unusable. Packets discarded because no route matched the destination are reported under 'no-route'. Packets discarded due to internal device faults are reported under 'internal'."; reference "RFC 826: An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; } leaf invalid-sid { type yang:counter64; description "The number of received packets discarded due to an invalid Segment Routing over IPv6 (SRv6) segment identifier (SID). This counter is incremented only by the node processing the SID (i.e., where the packet's destination address matches a locally instantiated SID); transit nodes that forward the packet without processing the SRH do not increment it. Discards of SRv6 packets whose destination address does not match a valid route are reported under 'no-route'. For SR-MPLS, SID lookup failures are reported under 'invalid-label'."; reference "RFC 8402: Segment Routing Architecture RFC 8660: Segment Routing with the MPLS Data Plane RFC 8754: IPv6 Segment Routing Header (SRH) RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming"; } leaf invalid-label { type yang:counter64; description "The number of received packets discarded because the top MPLS label does not match a valid Incoming Label Map (ILM) entry. This is the MPLS equivalent of 'no-route'."; reference "RFC 3031: Multiprotocol Label Switching Architecture, Section 3.18"; } } grouping errors-l3-int { description "Internal error discard counters."; leaf packets { type yang:counter64; description "The number of packets discarded due to internal errors."; } leaf parity-error { type yang:counter64; description "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; 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 by dedicated Denial-of-Service (DoS) protection mechanisms, such as implementation-specific heuristics that identify and discard DoS traffic. Where a DoS attack is mitigated using an ACL or a null route, those discards are reported under 'acl' or 'null-route' respectively, not under this counter, since the association with DoS mitigation is known only to the operator."; } } grouping discards { description "Discard counters."; container l2 { description "Layer 2 frame discard counters."; uses l2-traffic; } container l3 { description "Layer 3 packet discard counters."; uses l3-traffic; } 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; } } } } ]]>

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

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 . The reusable groupings are defined in the "ietf-packet-discard-reporting-common" module (). 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.

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. Requirements 1-13 relate to packets forwarded or discarded by the device, while requirement 14 relates to packets destined for or originating from the device, and requirements 15 and 16 relate to feature support:

1. All instances of Layer 2 frame or Layer 3 packet receipt, transmission, and discards MUST be accounted for. A frame or packet MUST be counted as discarded only by the device that discards it, i.e., when the device makes the final determination not to forward or locally deliver it. Handing a packet to another processing path within the device (e.g., punting it to the control plane) is not a discard; if the packet is subsequently dropped, it MUST be accounted for in the class corresponding to where that drop occurs (see requirement 14).
2. All instances of Layer 2 frame or Layer 3 packet receipt, transmission, and discards SHOULD be attributed to the physical or logical interface of the device where they occur. Where they cannot be attributed to the interface, they MUST be attributed to the device.
3. An individual frame MUST only be accounted for by either the Layer 2 traffic class or the Layer 2 discard classes within a single direction or context, i.e., ingress or egress or device. This is to avoid double counting.
4. An individual packet MUST only be accounted for by either the Layer 3 traffic class or the Layer 3 discard classes within a single direction or context, i.e., ingress or egress or device. This is to avoid double counting.
5. A frame discard accounted for at Layer 2 MUST NOT be accounted for at Layer 3 and vice versa. This is to avoid double counting.
6. The aggregate Layer 2 and Layer 3 traffic and discard classes SHOULD account for all underlying frames or packets received, transmitted, and discarded across all other classes. There might be exceptions when distinct discontinuity times are observed for more granular discards.
7. The aggregate QoS traffic and no-buffer discard classes MUST account for all underlying packets received, transmitted, and discarded across all other classes. All packets and bytes reported under discard-type MUST also be included in the enclosing class aggregate.
8. In addition to the Layer 2 and Layer 3 aggregate classes, an individual discarded packet MUST only account against a single error, policy, or no-buffer discard subclass. When per-type counters are reported, the discard MUST be counted in at most one discard-type entry.
9. When there are multiple reasons for discarding a packet, the ordering of discard class reporting MUST be unambiguously characterised. Implementations SHOULD expose this ordering by means of discard-order-capability and MAY use another mechanism (e.g., due to implementation constraints), provided the ordering is documented.
10. class[id] represents the QoS class assigned to a packet by the forwarding implementation using Diffserv , IEEE 802.1Q PCP , MPLS TC , 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.
15. Implementations MAY support a subset of the defined features based on device capabilities and operational requirements. Which features an implementation supports is discoverable from the device itself: support for each feature is advertised via the YANG library .
16. Where an implementation supports a feature but does not populate every counter within it, the implementation SHOULD expose which counters are populated. It may do so in documentation or via programatic means (e.g., local help command).

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

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

Operational Considerations

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 ). Similarly, for Lower Effort (LE) 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) 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.

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

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.

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

IANA Considerations IANA is requested to register the following URIs in the "ns" registry within the "IETF XML Registry" group : IANA is requested to register the following YANG modules in the "YANG Module Names" registry within the "YANG Parameters" registry group:

References Normative References IEEE 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. This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] 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 specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] 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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK] 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 memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level. Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes. The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK] This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK] 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. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. 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 describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores. This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK] 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. 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 | | | '-------' '----------' '---------' '----------' '-------' 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 ]]>

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 . Tables and are a single logical example split into two physical tables for readability. Rows with the same Case value correspond. Table shows the observed discard signal, inferred cause, rate, and duration. Table 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. 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)

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.

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, Satoru Matsushima for the INTDIR review, Derrell Piper for the SECDIR review, Roni Even for the GENART review, and Michael Tüxen for the TSVART review. Special thanks to Carlos Pignataro for the detailed INTDIR review and suggestions that enhanced this specification. Thanks to Diego Lopez for shepherding the document and Mahesh Jethanandani for the AD review. Thanks to Christopher Inacio, Éric Vyncke, Gorry Fairhurst, Ketan Talaulikar, Deb Cooley, and Mike Bishop for the IESG review.

Contributors Cisco Systems, Inc.

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