Information Element for Flow Discard Classification

3.1. Design Rationale

The mapping between [I-D.ietf-opsawg-discardmodel] and the IPFIX flowDiscardClass Information Element follows these principles, maintaining consistency with the YANG model while allowing self-contained decoding from a single IE:¶

1. Scope. The flowDiscardClass Information Element is specifically for reporting flow-level discard reasons, and therefore only represents the flow subtree from [I-D.ietf-opsawg-discardmodel]. The component is implicitly "flow" and the type is implicitly "discards"; interface, device, and control-plane components are out of scope for this IE.¶

2. Hierarchy preserved. The enumeration mirrors the model: both leaves (specific reasons) and structural aggregates are assigned values so collectors can perform coarse or fine roll-ups. For L3, structural aggregates include address-family and cast (v4/v6, unicast/multicast/broadcast).¶

3. Self-contained decoding. The value alone carries the discard class. Exporters and collectors can still use other IEs (e.g., flowDirection, ipVersion, addresses, ipDiffServCodePoint) for correlation, but they are not required to decode the class.¶

4. Specificity preference. The scheme encourages reporting the most-specific known class when available; aggregate values provide a fallback when only a broader category is known.¶

5. Implementation-friendly ordering. Codes are assigned in preorder traversal (where each parent is numbered before its children) to reflect the model’s hierarchy and simplify range/roll-up handling in implementations.¶

3.2. flowDiscardClass Definition

Name: flowDiscardClass¶

Description: Classifies the reason a packet was discarded in a flow, using the hierarchical classification scheme defined in [I-D.ietf-opsawg-discardmodel].¶

Abstract Data Type: unsigned8¶

Data Type Semantics: identifier¶

Units: none¶

Range: 0..38 (values from Table 1; other values are unassigned and MUST be treated as unknown)¶

Reversibility: reversible (value does not change under flow reversal as per [RFC5103])¶

Status: current¶

ElementId: TBD¶

References: [I-D.ietf-opsawg-discardmodel]¶

3.3. flowDiscardClass Values

Table 1 defines the values for the flowDiscardClass Information Element mapped from the corresponding [I-D.ietf-opsawg-discardmodel] Discard Class. Codes are assigned in preorder traversal to reflect the hierarchy.¶

The code points for flowDiscardClass are maintained by IANA in the "flowDiscardClass Values" subregistry of the IPFIX registry. Future additions or changes are managed via Expert Review as described in Section 5.¶

For discard classes where per-traffic-class granularity is operationally significant (e.g., no-buffer, policy/l3/policer), the traffic class SHOULD be conveyed via companion IEs in the same Flow Record (e.g., ipDiffServCodePoint for L3, dot1qPriority for L2). This enables correlation with per-class interface counters from [I-D.ietf-opsawg-discardmodel].¶

3.4. Implementation Requirements

5.1. New IPFIX Information Element: flowDiscardClass

IANA is requested to register a new Information Element as follows:¶

• Name: flowDiscardClass¶

• ElementId: TBD (to be assigned by IANA)¶

• Description: Classifies the reason a packet was discarded in a flow, using the hierarchical classification scheme defined in [I-D.ietf-opsawg-discardmodel].¶

• Abstract Data Type: unsigned8¶

• Data Type Semantics: identifier¶

• Units: none¶

• Range: 0..38 (values are listed in the “flowDiscardClass Values” subregistry created below; other values are unassigned and MUST be treated as unknown)¶

• Reversibility: reversible (value does not change under flow reversal as per [RFC5103])¶

• Status: current¶

• Reference: This document; [RFC7013]¶

5.2. New Subregistry: “flowDiscardClass Values”

IANA is requested to create a new subregistry titled "flowDiscardClass Values" under the IPFIX Information Elements registry. This subregistry contains the enumerated values for the flowDiscardClass IE.¶

• Registration Procedure: Expert Review ([RFC8126])¶

• Reference: This document; [RFC7013]¶

• Fields:¶

  • Value (integer)¶

  • Name (path under flow/discards/...)¶

  • Description (optional)¶

  • Reference¶

Designated Expert guidance: New code points should reflect additions to or clarifications of discard reasons in [I-D.ietf-opsawg-discardmodel] (or its successor). Existing code points MUST NOT be repurposed. Backwards-compatible additions are preferred. Experts SHOULD maintain the hierarchical structure (e.g., assigning aggregates and leaves consistently) and, where practical, preserve preorder (depth-first) numbering to align with the existing tree.¶

6.1. Normative References

[I-D.ietf-opsawg-discardmodel]

Evans, J., Pylypenko, O., Haas, J., Kadosh, A., and M. Boucadair, "Information and Data Models for Packet Discard Reporting", Work in Progress, Internet-Draft, draft-ietf-opsawg-discardmodel-10, 26 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-discardmodel-10>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5103]

Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, DOI 10.17487/RFC5103, January 2008, <https://www.rfc-editor.org/rfc/rfc5103>.

[RFC7011]

Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/rfc/rfc7011>.

[RFC7012]

Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/rfc/rfc7012>.

[RFC7013]

Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 2013, <https://www.rfc-editor.org/rfc/rfc7013>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[RFC7270]

Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10.17487/RFC7270, June 2014, <https://www.rfc-editor.org/rfc/rfc7270>.

A.1. Correlation Keys

To correlate a discard counter anomaly with flow records, the collector must join data on three key dimensions:¶

1. Time: Align the counter collection interval with the Flow Record start/end times (allowing for small clock skew).¶

2. Location: Match the Observation Domain and Interface.¶

   • For Ingress discards: match ingressInterface.¶

   • For Egress discards: match egressInterface.¶

3. Discard Class: Match the YANG discard-class leaf with the IPFIX flowDiscardClass value.¶

   • Note: If the drop is specific to a traffic class (e.g., no-buffer), the collector must also match the traffic class identifier (e.g., ipDiffServCodePoint) to the specific queue experiencing loss.¶

A.2. Analysis Strategies

Once flow records are correlated with discard counters, operators can rank or group flows to determine:¶

• Impacted analysis: Which flows suffered loss? This is determined by grouping flows by the presence of the flowDiscardClass (or summing dropped-octets/packets) to identify the symptomatic flows of the event.¶

• Causal analysis (when meaningful): Which flows likely contributed to the interface/device condition? For congestive discards (e.g. no-buffer), this is determined by identifying the top senders (by total volume or rate) in the same traffic class and egress interface during the anomaly.¶

A.3. Operational Example: Impacted Flows (Congestion Drops)

Scenario: an anomaly is detected in no-buffer discards on Ethernet1/0 (ifIndex 10) in the egress direction. The drops are occurring in the Best Effort queue (DSCP 0).¶

1. Signal: Interface discard counter¶

   • Time: 2025-09-18 10:00:00 – 10:01:00¶

   • Observation Domain: 1234¶

   • Interface: 10 (egress)¶

   • Class: no-buffer (value 38; see Table 1)¶

   • Queue/DSCP: 0¶

2. Correlation: SQL Query¶

   The operator queries the IPFIX store to perform impact analysis — identifying symptomatic flows of the congestion event:¶

   sql SELECT src_addr, dst_addr, l4_dst_port, protocol, SUM(droppedPacketDeltaCount) AS total_pkt_discards FROM flow_records WHERE -- 0. Match Observation Domain observationDomainId = 1234 -- 1. Match Location (egress interface) AND egressInterface = 10 -- 2. Match Time Window (any overlap with counter interval) AND flowEnd >= '2025-09-18 10:00:00' AND flowStart <= '2025-09-18 10:01:00' -- 3. Match Discard Class (no-buffer) AND flowDiscardClass = 38 -- 4. Match Traffic Class context (Best Effort) AND ipDiffServCodePoint = 0 GROUP BY src_addr, dst_addr, l4_dst_port, protocol ORDER BY total_pkt_discards DESC LIMIT 10; ¶

3. Result¶

   The query returns the top flows most affected by the discard event, allowing the operator to pinpoint specific applications or users impacted by the congestion:¶

A.4. Operational Example: Causal Flows (Congestion Drops)

Using the same scenario as in Appendix A.3, the operator now wants to identify flows that likely caused the congestion — that is, heavy senders in the affected queue and interface during the anomaly. These flows may or may not themselves have experienced drops.¶

1. Signal: Interface discard counter¶

   Same as in Section A.3:¶

   • Time: 2025-09-18 10:00:00 – 10:01:00¶

   • Observation Domain: 1234¶

   • Interface: 10 (egress)¶

   • Class: no-buffer (value 38)¶

   • Queue/DSCP: 0¶

2. Correlation: SQL Query¶

   The operator queries the IPFIX store to perform a causal analysis by ranking flows by total traffic volume in the same time window, interface, and traffic class. The query does not require flowDiscardClass = 38, since flows can contribute to congestion even if only some packets (or none of the sampled packets) were dropped.¶

   sql SELECT src_addr, dst_addr, l4_dst_port, protocol, SUM(octetDeltaCount) AS total_bytes, SUM(packetDeltaCount) AS total_pkts, SUM(droppedPacketDeltaCount) AS total_pkt_discards FROM flow_records WHERE -- 0. Match Observation Domain observationDomainId = 1234 -- 1. Match Location (egress interface) AND egressInterface = 10 -- 2. Match Time Window (any overlap with counter interval) AND flowEnd >= '2025-09-18 10:00:00' AND flowStart <= '2025-09-18 10:01:00' -- 3. Match Traffic Class context (Best Effort queue) AND ipDiffServCodePoint = 0 GROUP BY src_addr, dst_addr, l4_dst_port, protocol ORDER BY total_bytes DESC LIMIT 10; ¶

3. Result¶

   This query returns flows that carried the most traffic through the congested interface and queue during the interval. These high-volume flows are candidates for having contributed to the congestion. The total_drops column (if present) can still be used to see which of these heavy flows also suffered loss.¶

In this example, the flow from 10.0.0.5 transferred 850 MB with limited discards, while the smaller flow from 192.0.2.10 suffered significant packet loss.¶

A.5. Implementation Note on Sampling

When flow sampling is active, flowDiscardClass indicates that a sampled packet was dropped. To estimate the total (unsampled) flow-level impact and compare it with interface counters (which are typically unsampled), operators can apply a sampling-rate multiplier to the flow counters (droppedPacketDeltaCount and/or droppedOctetDeltaCount).¶

Let: * p = the sampling probability (e.g., 0.01 for 1-in-100 sampling) * N = 1 / p be the corresponding "1-in-N" sampling interval.¶

The sampling-rate multiplier is N. Estimated totals are then: * estimated_total_dropped_packets = droppedPacketDeltaCount * N * estimated_total_dropped_octets = droppedOctetDeltaCount * N¶

For example, if the exporter samples 1 in every 100 packets, the multiplier is 100. If the exporter samples 1 in every 1000 packets, the multiplier is 1000.¶

Exporters typically report their sampling configuration via IPFIX (samplingInterval and/or samplingProbability). Because sampling is probabilistic, these estimates are approximate; using larger time windows and higher-volume aggregates tends to make them more robust.¶