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

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 (depth-first) tree order to reflect the 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. 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.¶

Codes are assigned in preorder (depth-first) tree order to reflect the model’s hierarchy.¶

no-buffer/class conveys per-QoS class congestion loss; the specific class (e.g., DSCP/class index, or L2 PCP) SHOULD be exported via the appropriate companion IE in the same record.¶

3.4. Implementation Requirements

### Semantics and Scope {#impl-semantics}¶

1. Scope of this IE. flowDiscardClass MUST be used only to report flow-level discard classification under flow/discards from [I-D.ietf-opsawg-discardmodel]. It MUST NOT be used for interface, device, or control-plane discard counters.¶

2. Enumeration. Exporters MUST encode values only from the IANA “flowDiscardClass Values” subregistry for this IE. Collectors MUST accept both aggregate and leaf values and interpret aggregates as semantic supersets of their descendants.¶

3. Unknown/Unassigned values. Collectors receiving an unknown or unassigned value MUST treat it as unknown and MUST NOT remap it to another code. Exporters MUST NOT transmit unassigned values.¶

4. Reversibility. The value of flowDiscardClass MUST NOT change under biflow reversal as defined by [RFC5103].¶

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-09, 18 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-discardmodel-09>.

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

[RFC6313]

Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, <https://www.rfc-editor.org/rfc/rfc6313>.

[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. Scope Alignment (What Must Match)

Accurate correlation depends on joining records that describe the same exporter/vantage, component, interface (if applicable), direction, class, and time window:¶

• Exporter & vantage. Join on the same Exporter/Observation Domain (e.g., observationDomainId). Where multiple taps or pipeline stages exist, include observationPointId (and, if available, line-card/port identifiers) so flow data and counters represent comparable points.¶

• Component & interface.¶

  • Interface component: include ingressInterface/egressInterface in Flow Records and match the same ifIndex and direction as the discardmodel counters.¶

  • Device component: drop the interface key and aggregate across interfaces for the same exporter/time/class.¶

  • Control-plane component: no interface key; match by exporter/time/class (and any control-plane class identifiers available).¶

• Time. Align Flow intervals (flowStart/flowEnd, or an observation-time IE) with the sampling/roll-up interval of the discardmodel counters. In practice, bucket both datasets (e.g., 1-minute buckets) and allow small skew to cover clock/polling jitter.¶

A.2. Class and Reason Alignment

• Discard class. flowDiscardClass mirrors the discardmodel hierarchy (parents + leaves). Select the value(s) that match the anomaly (e.g., errors/l3/ttl-expired, policy/l3/acl, no-buffer/class, etc.).¶

• Traffic class identity (when relevant). For no-buffer/class, Exporters SHOULD also export the traffic-class identifier used by the queue (e.g., ipDiffServCodePoint / ipClassOfService, or dot1qPriority for L2). If the device uses internal queue IDs, provide a mapping (via Options data or out-of-band config) so collectors can align Flow Records with per-class counters.¶

A.3. Recommended Exporter Context

When exporting Flow Records that carry flowDiscardClass, Exporters SHOULD include:¶

• Context: ingressInterface/egressInterface, observationPointId (if applicable), time bounds (flowStart/flowEnd or an observation-time IE), and the relevant class IE (ipDiffServCodePoint/ipClassOfService/dot1qPriority, etc.).¶

• Quantification: droppedPacketDeltaCount and/or droppedOctetDeltaCount, so per-class dropped volume from flows can be compared to discardmodel aggregates.¶

• Multiplicity handling: if multiple discard reasons apply to the same flow interval, either export one record per reason or use IPFIX Structured Data to encode multiple flowDiscardClass values.¶

A.4. Collector Workflow (General Pattern)

Given an anomaly in the discardmodel (per interface/device/control-plane, direction, class, and time):¶

1. Select the time bucket(s) and affected key(s): exporter, component (and interface if applicable), direction, discard class.¶

2. Find impacted flows: filter Flow Records that overlap the bucket(s) and match the exporter/component keys and either¶

   • explicitly report the same flowDiscardClass, or¶

   • (for aggregate classes) belong to the same traffic class and vantage where the loss is counted.¶

3. Aggregate per flow within the bucket(s): bytes/packets and, if available, dropped-bytes/packets.¶

4. Rank or group flows as needed:¶

   • Impacted analysis: which flows suffered loss (by dropped-octets/packets, or by presence of the discard class)?¶

   • Causal analysis (when meaningful): which flows likely contributed to the interface/device condition (e.g., top senders in the same class and egress interface during a no-buffer/class spike)?¶

5. Validate: compare summed flow-level dropped deltas (if exported) to the discardmodel deltas for that bucket. Small gaps are expected (sampling, timing, vantage); large gaps suggest vantage mismatch or incomplete class mapping.¶

A.5. Handling Expected Discrepancies

• Vantage mismatch. Flow telemetry captured before queueing/policing but counters tallied after will skew attribution. Use observationPointId (and device documentation) to align vantage.¶

• Class remapping. If DSCP is remarked, use post-class IEs or queue-ID mappings so class identity matches where the drop is counted.¶

• Sampling/filtering. Flow sampling reduces visibility of small flows and biases shares; where possible, rely on flow-level dropped-octet counters, or increase the bucket size to stabilize estimates.¶

• Clock skew. Apply a small skew window (e.g., ±30 s) when joining buckets across datasets.¶

A.6. Operational Example: Congestive Loss (no-buffer/class) and Elephant Flows

This example illustrates the workflow above for congestive loss (no-buffer/class) on an egress interface. It identifies high-volume ("elephant") flows most likely responsible for a spike by joining per-class interface discards with per-class, per-interface flow aggregates and ranking flows by bytes/rate.¶

Assumed tables:¶

• flows(observation_domain_id, egress_ifindex, flow_start, flow_end, octet_delta, packet_delta, ip_dscp, src_addr, dst_addr, src_port, dst_port, protocol, flowdiscardclass)¶

• interface_discards(observation_domain_id, ifindex, direction, discard_class, class_id, ts, packet_delta, octet_delta)¶

Note: In Table 1, no-buffer/class has value 38.¶

-- Identify elephant flows contributing to egress no-buffer/class drops
WITH params AS (
  SELECT
    38::smallint AS no_buffer_class,          -- flowDiscardClass for no-buffer/class (Table 1)
    interval '1 minute' AS bucket,            -- analysis granularity
    interval '30 seconds' AS skew,            -- clock/bucket tolerance
    100000000::bigint AS elephant_bytes_min   -- 100 MB per bucket (example threshold)
),

-- 1) Per-minute egress no-buffer/class discard spikes per interface + class
events AS (
  SELECT
      i.observation_domain_id,
      i.ifindex,
      i.class_id,                               -- DSCP / QoS class as exported by the device
      date_trunc('minute', i.ts) AS ts_bucket,
      SUM(i.packet_delta) AS drop_pkts,
      SUM(i.octet_delta)  AS drop_octets
  FROM interface_discards i
  JOIN params p ON i.discard_class = p.no_buffer_class
  WHERE i.direction = 'egress'
  GROUP BY 1,2,3,4
  HAVING SUM(i.packet_delta) > 0
),

-- 2) Aggregate flows per minute keyed by egress interface + class
flow_buckets AS (
  SELECT
      f.observation_domain_id,
      f.egress_ifindex AS ifindex,
      f.ip_dscp        AS class_id,
      date_trunc('minute', f.flow_end) AS ts_bucket,
      f.src_addr, f.dst_addr, f.src_port, f.dst_port, f.protocol,
      SUM(f.octet_delta)  AS bytes,
      SUM(f.packet_delta) AS pkts
  FROM flows f
  -- Optional: uncomment to include only flows explicitly marked as no-buffer/class
  -- WHERE f.flowdiscardclass = 38
  GROUP BY 1,2,3,4,5,6,7,8,9
),

-- 3) Join flows to discard spikes within a fuzzy time window and same class/interface
joined AS (
  SELECT
      e.observation_domain_id,
      e.ifindex,
      e.class_id,
      e.ts_bucket,
      e.drop_pkts,
      e.drop_octets,
      fb.src_addr, fb.dst_addr, fb.src_port, fb.dst_port, fb.protocol,
      fb.bytes, fb.pkts,
      (fb.bytes::numeric / NULLIF(e.drop_octets,0)) AS byte_share,
      (fb.pkts::numeric  / NULLIF(e.drop_pkts,0))   AS pkt_share
  FROM events e
  JOIN flow_buckets fb
    ON fb.observation_domain_id = e.observation_domain_id
   AND fb.ifindex               = e.ifindex
   AND fb.class_id              = e.class_id
   AND fb.ts_bucket BETWEEN e.ts_bucket - (SELECT skew FROM params)
                        AND     e.ts_bucket + (SELECT bucket FROM params) + (SELECT skew FROM params)
)

-- 4) Rank top flows per interface+class+minute and keep "elephants"
SELECT
    observation_domain_id, ifindex, class_id, ts_bucket,
    drop_pkts, drop_octets,
    src_addr, dst_addr, src_port, dst_port, protocol,
    bytes, pkts, byte_share, pkt_share,
    (8.0 * bytes) / EXTRACT(EPOCH FROM (SELECT bucket FROM params)) AS bits_per_sec,
    ROW_NUMBER() OVER (
      PARTITION BY observation_domain_id, ifindex, class_id, ts_bucket
      ORDER BY bytes DESC
    ) AS rank_in_bucket
FROM joined
WHERE bytes >= (SELECT elephant_bytes_min FROM params)
ORDER BY ts_bucket, observation_domain_id, ifindex, class_id, rank_in_bucket;

Implementation notes:¶

• If your device maps DSCP→queue differently, join via a mapping table instead of class_id = ip_dscp.¶

• Adjust bucket, skew, and elephant_bytes_min for your polling cadence and "elephant" threshold.¶

• Helpful indexes:¶

  • interface_discards(discard_class, direction, ts, observation_domain_id, ifindex, class_id)¶

  • flows(egress_ifindex, ip_dscp, flow_end, observation_domain_id)¶