Operations and Management Area Working Group A. Dogra Internet-Draft M. Kumar Intended status: Standards Track S. Gopalakrishnan Expires: 29 April 2027 Cisco Systems 26 October 2026 IPFIX Information Elements for Priority-based Flow Control Telemetry draft-dogra-opsawg-ipfix-pfc-00 Abstract Priority-based Flow Control (PFC) pauses Ethernet traffic by priority. This document defines two IP Flow Information Export (IPFIX) Information Elements and an Options Template record pattern for per-priority totals of received and transmitted PFC control frames. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Dogra, et al. Expires 29 April 2027 [Page 1] Internet-Draft IPFIX PFC Telemetry October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 4. PFC Counter Observation Model . . . . . . . . . . . . . . . . 3 4.1. Scope and Direction . . . . . . . . . . . . . . . . . . . 3 4.2. Priority Semantics . . . . . . . . . . . . . . . . . . . 3 4.3. Control-Frame Count Semantics . . . . . . . . . . . . . . 4 5. New Information Elements . . . . . . . . . . . . . . . . . . 4 6. Export Model . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Export Requirements . . . . . . . . . . . . . . . . . . . . . 6 8. Operational Considerations . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10.1. pfcPriority . . . . . . . . . . . . . . . . . . . . . . 7 10.2. pfcControlFrameTotalCount . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [IEEE8021Q] specifies Priority-based Flow Control (PFC). [IEEE8023] specifies the PFC MAC Control frame format. A PFC frame contains a 16-bit class-enable vector and eight 16-bit pause-time fields, one for each priority. The lower eight vector bits select the corresponding pause-time fields. PFC applies to a physical link and a priority. It does not identify an IP Flow. Existing IPFIX Information Elements identify Observation Points, physical interfaces, and observation times. They do not identify a PFC vector position or count PFC control frames for that position. This document defines only those missing elements. The PFC counter Data Records defined in Section 6 carry pfcPriority and pfcControlFrameTotalCount. A collector can correlate these records with separately exported IPFIX Flow Records that describe traffic. The traffic Flow Records do not need to contain the new PFC Information Elements. This correlation requires a common device, physical interface, time, and known traffic-to-priority mapping. It cannot prove that a Flow caused PFC activity. Dogra, et al. Expires 29 April 2027 [Page 2] Internet-Draft IPFIX PFC Telemetry October 2026 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Applicability Existing management interfaces can report PFC configuration, state, and counters. Their coverage depends on the supported data model and implementation. YANG-Push can report applicable operational data [RFC8641]. The IEEE PFC MIB [IEEE-PFC-MIB] defines interface counters for MAC Control request and indication primitives. [RFC8038] provides a mechanism to export those MIB objects through IPFIX. This specification provides a common format for deployments that use existing IPFIX infrastructure. It uses IPFIX observation, interface, template, transport, and collector functions. 4. PFC Counter Observation Model 4.1. Scope and Direction Each record identifies one Observation Point, one physical interface, one PFC priority, one direction, and one observation time. A received-frame record uses ingressPhysicalInterface (252). A transmitted-frame record uses egressPhysicalInterface (253). A record MUST NOT contain both physical-interface Information Elements. For a physical interface that belongs to a Link Aggregation Group, the record MUST identify that member interface. An exporter MUST NOT use an aggregate Link Aggregation Group counter for this record. 4.2. Priority Semantics pfcPriority contains an unsigned8 priority index n, with valid values from 0 through 7. The value n identifies bit n of the PFC class- enable vector and pause-time field n in a PFC frame. It is not a bitmap and does not contain the vector or a pause-time value. For example, a value of 3 identifies bit 3 and pause-time field 3. Dogra, et al. Expires 29 April 2027 [Page 3] Internet-Draft IPFIX PFC Telemetry October 2026 An exporter MUST NOT substitute dot1qPriority (244) or an internal queue index for pfcPriority. A collector needs the applicable device, interface, and time-dependent mapping to correlate the priority with traffic. That mapping does not change the fixed association between bit n and pause-time field n. 4.3. Control-Frame Count Semantics For received frames, the source counts valid PFC frames observed from the link before local enablement, policy, or watchdog processing. For transmitted counts, the exporter MUST count only valid PFC frames that it can confirm were emitted on the link. An internal generation request does not prove transmission. Transmission does not prove peer reception or execution of the pause request. The source MUST count every qualifying frame at the specified physical interface and Observation Point. An exporter MUST NOT substitute a count from a packet-sampled subset or an extrapolated estimate for pfcControlFrameTotalCount. For each set class-enable bit, the source increments the counter for that priority once. It counts zero-quanta resume requests and non- zero pause or refresh requests. It does not increment a counter for a clear class-enable bit, regardless of the pause-time value. One frame can increment counters for multiple priorities. A collector MUST NOT report the sum of different priority counters as a count of unique wire frames. A qualifying frame meets the MAC Control and PFC requirements in [IEEE8023] and [IEEE8021Q]: receive-validation requirements for received frames, or transmit-format requirements for transmitted frames. The exporter MUST NOT count frames that fail these requirements, including frames with a detected frame-check-sequence error or an incorrect MAC Control EtherType or PFC opcode. Reserved- field and pause-time-field treatment follows those IEEE specifications. This document defines no additional rejection rules. If the source cannot distinguish qualifying from non-qualifying frames, the exporter MUST NOT use that source for pfcControlFrameTotalCount. 5. New Information Elements +===========================+============+==============+========+ | Name | Type | Semantics | Units | +===========================+============+==============+========+ | pfcPriority | unsigned8 | identifier | none | +---------------------------+------------+--------------+--------+ | pfcControlFrameTotalCount | unsigned64 | totalCounter | frames | Dogra, et al. Expires 29 April 2027 [Page 4] Internet-Draft IPFIX PFC Telemetry October 2026 +---------------------------+------------+--------------+--------+ Table 1: PFC Information Elements Section 10 gives the complete definitions and registration requests. 6. Export Model An Options Template Record defines each PFC counter Data Record. All Scope Fields precede the non-Scope Fields, as [RFC7011] requires. Received and transmitted counters use separate Options Template Records. The two Options Template Records use different physical- interface fields. +=======+======================================+=============+ | Role | Information Element | Requirement | +=======+======================================+=============+ | Scope | observationPointId (138) | REQUIRED | +-------+--------------------------------------+-------------+ | Scope | ingressPhysicalInterface (252) for | REQUIRED, | | | received, or egressPhysicalInterface | exactly one | | | (253) for transmitted | | +-------+--------------------------------------+-------------+ | Scope | pfcPriority | REQUIRED | +-------+--------------------------------------+-------------+ | Data | observationTimeMilliseconds (323) | REQUIRED | +-------+--------------------------------------+-------------+ | Data | pfcControlFrameTotalCount | REQUIRED | +-------+--------------------------------------+-------------+ Table 2: PFC Counter Record [RFC5477] defines observationTimeMilliseconds. Its value is the closest available time when the source counter was read. It is not the record export time. The PFC Counter Record reports a total, not a copy of a PFC frame. It contains no class-enable vector or pause-time values. The total can include frames with different pause-time values and does not measure elapsed paused time. pfcControlFrameTotalCount is the counter value at observationTimeMilliseconds. The counter starts at zero when its measurement source initializes. It counts independently of export. It wraps after 2^64 - 1, as the totalCounter semantic in Section 3.2.2 of [RFC7012] requires. A counter reset starts a new epoch at zero. Dogra, et al. Expires 29 April 2027 [Page 5] Internet-Draft IPFIX PFC Telemetry October 2026 The required fields do not identify a counter reset or a counter epoch. An increase does not prove that no reset occurred. A decrease can result from a reset or a wrap. The observation time and IPFIX Transport Session do not establish epoch continuity. The required PFC Counter Record does not provide the information needed for an exact interval count. A Collecting Process MUST NOT report an exact interval count from two readings without reliable information beyond the required fields. To report such a count, the Collecting Process MUST confirm that both readings refer to the same scoped counter instance. It MUST also confirm that no reset occurred and fewer than 2^64 increments occurred between the observation times. If these conditions hold, the interval count is the later value minus the earlier value, modulo 2^64. Otherwise, the interval count is unknown. A rate based on an unknown interval count is also unknown. This document does not define an epoch Information Element or a method to provide the additional information. The fields listed in the PFC Counter Record table MUST occur exactly once in their specified roles, with exactly one of the two physical- interface Information Elements. The order of the listed Scope Fields and the order of the listed non-Scope Fields are not significant. Collecting Processes MUST accept Templates with additional Information Elements. They MUST also accept message streams with records from other Templates, as Section 9.2 of [RFC7013] requires. 7. Export Requirements Exporters follow [RFC7011] for Template lifecycle and field handling. Before IANA assigns Element IDs, experiments use enterprise-specific Information Elements under an appropriate Private Enterprise Number. The TBD values in this document are not wire values. Experiments that cross an administrative or implementation boundary SHOULD export Information Element Type Records, as Section 3.9 of [RFC5610] specifies. They can also communicate equivalent type information out of band. If the source counter is narrower than 64 bits, the exporter MUST account for its wraps. It MUST distinguish a source reset from a wrap. The exported unsigned64 value must have the totalCounter behavior defined above. If the exporter cannot meet these requirements, it MUST NOT export that source as pfcControlFrameTotalCount. A zero value is a valid counter reading. It does not prove that no qualifying frames occurred because the counter can wrap. A missing record gives no count. A collector MUST NOT treat a missing record as a zero value. Dogra, et al. Expires 29 April 2027 [Page 6] Internet-Draft IPFIX PFC Telemetry October 2026 8. Operational Considerations Reporting frequency controls export volume and time resolution for correlation. The number of physical interfaces, priorities, and directions also affects export volume. Operators SHOULD select an export path that remains available when PFC pauses the monitored priority. 9. Security Considerations The IPFIX security considerations in [RFC7011] and [RFC7012] apply. PFC telemetry can reveal physical topology, service-priority use, congestion hot spots, and workload timing. Exporters and Collecting Processes SHOULD authenticate one another. They SHOULD protect the confidentiality and integrity of the telemetry. They SHOULD apply appropriate authorization and retention controls. TLS or DTLS deployments MUST follow the current BCP 195 recommendations in [RFC9325]. Authentication of the IPFIX Transport Session authenticates the Exporting Process. It does not authenticate a counted PFC frame. An unauthorized peer can send a syntactically valid frame. A counter increase does not prove genuine congestion. High-impact remediation SHOULD require other operational evidence. 10. IANA Considerations This document requests two new Information Elements from IANA. IANA is requested to register them in the "IPFIX Information Elements" registry [IANA-IPFIX]. The registrations follow [RFC7012] and [RFC7013]. Registry terminology follows [RFC9710]. IANA is requested to assign values from the unassigned Element ID range 128 through 32767. The RFC Editor is requested to replace TBD1 and TBD2 with these values. "This document" below refers to the resulting RFC. 10.1. pfcPriority Name: pfcPriority Element ID: TBD1 Description: A priority index n in the range 0 through 7. The value n identifies bit n of the Priority-based Flow Control class-enable vector and pause-time field n in a PFC frame. This value is not a bitmap. It contains neither the vector nor a pause-time value. It does not identify an IEEE 802.1Q tag Priority Code Point or an internal queue. Abstract Data Type: unsigned8 Data Type Semantics: identifier Dogra, et al. Expires 29 April 2027 [Page 7] Internet-Draft IPFIX PFC Telemetry October 2026 Units: none Range: 0-7 Status: current Additional Information: See [IEEE8023], Annex 31D, and [IEEE8021Q], Clause 36. Reference: This document 10.2. pfcControlFrameTotalCount Name: pfcControlFrameTotalCount Element ID: TBD2 Description: The total number of qualifying PFC MAC Control frames for one PFC priority, as defined in Section 4.3. The containing Data Record identifies the priority. The counter increments when that priority's class-enable vector bit is one. It counts frames with zero and non-zero pause-time values. One frame can increment counters for multiple priorities. It represents complete qualifying-frame counting, not a count from a packet-sampled subset or an extrapolated estimate. It does not contain pause- time values. In the PFC Counter Record defined in Section 6, the physical-interface Information Element identifies received or transmitted direction. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter Units: frames Status: current Additional Information: See [IEEE8023], Annex 31D. Reference: This document 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, . [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, DOI 10.17487/RFC5610, July 2009, . Dogra, et al. Expires 29 April 2027 [Page 8] Internet-Draft IPFIX PFC Telemetry October 2026 [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, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . [RFC9710] Boucadair, M. and B. Claise, "Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry", RFC 9710, DOI 10.17487/RFC9710, February 2025, . [IEEE8021Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE Std 802.1Q- 2022, 2022, . [IEEE8023] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, 2022, . [IANA-IPFIX] Internet Assigned Numbers Authority, "IP Flow Information Export (IPFIX) Entities", . 11.2. Informative References Dogra, et al. Expires 29 April 2027 [Page 9] Internet-Draft IPFIX PFC Telemetry October 2026 [RFC8038] Aitken, P., Ed., Claise, B., S, S. B., McDowall, C., and J. Schoenwaelder, "Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol", RFC 8038, DOI 10.17487/RFC8038, May 2017, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [IEEE-PFC-MIB] IEEE 802.1, "IEEE8021-PFC-MIB", March 2021, . Authors' Addresses Aditya Dogra Cisco Systems Email: addogra@cisco.com Manish Kumar Cisco Systems Email: mkumar8@cisco.com Sriram Gopalakrishnan Cisco Systems India Email: sriragop@cisco.com Dogra, et al. Expires 29 April 2027 [Page 10]