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.