Item f) of 5.4.1 VLAN Bridge component options’ is support of PFC, referencing 5.11 (see below), item ab) is support of DCBX referencing 5.4.1.7. • aa) of 5.4.1 is support of Enhanced Transmission Selection (ETS) referencing 5.4.1.6 ‘ETS Bridge requirements’ which: — mandates bandwidth allocation configuration with a granularity of 1% or finer, and actual allocation with a precision of 10%; — mentions PFC only as a footnote; — requires support of DCBX, referencing Clause 38. • 5.4.1.7 ‘DCBX Bridge requirements’ but requires support of LLDP and the DCBX state machines with the following: — ETS Configuration and ETS Recommendation TLVs; — PFC Configuration TLV; — Application Priority TLV and Application VLAN TLVs. All of which specify transmission of the TLV as an option ‘may’. • 5.11 ‘System requirements for ... (PFC)’ references Clause 36 details, and also requires: — ‘Enable use of PFC only in a domain controlled by DCBX (Clause 38).’ Clause 38 does not include the word ‘domain’. None of the remaining 1,094 uses of the word ‘domain’ are associated with DCBX, so there is no explanation of how a system can determine that it is ‘in a domain controlled by DCBX’. • 5.13.1 ‘MAC Bridge component options’ item k) is support of PFC (referencing 5.11) and item l) is support of DCBX, but DCBX requires support of the Application VLAN TLV. Taken together the combination of the above provisions could be taken to mean that PFC cannot be used in the absence of support for DCBX, for ETS (with the required accuracy), and for Application VLAN TLVs. This is at odds with real world use of PFC. However transmission of each of the DCBX TLVs is (stated as noted above) optional, so since there is no definition of "a domain controlled by DCBX " it could be argued that, since conformance is only in respect of externally observable behavior, that any link is potentially 'in a domain controlled by DCBX' and all the above text mandating use of the full set of DCBX capabilities is moot. There is real experience that it is desirable to require a definite indication that a peer will act on a receipt of a PFC pausing transmission for a given priority before PFCs are sent for that priority. If such PFCs are sent to a peer that does not act upon them then a 'PFC storm' can result, with the transmitter continually sending PFCs at a high rate in a futile attempt to prevent loss. However, despite the current text of the standard requiring implementation (but not use) of a full set of DCBX features if PFC is implemented, there is nothing that requires receipt of a suitable PFC Configuration TLV before PFCs are transmitted for a given priority. This should at least be specified as a configurable option (bearing in mind that PFC has been in use for over a decade, and some implementations may use other methods to avoid triggering a PFC storm). Clarity in this area might reduce issues encountered in multi-vendor deployments of PFC. The above detail has been extracted, with minor revision, from https://www.ieee802.org/1/files/public/docs2024/dt-seaman-pfc-management-0924-v02.pdf, discussed by the 802.1 Security Task Group during the September 2024 Interim Meeting as part of P802.1Qdt development.