802.1 Tools
  • Home
  • Maintenance
    • All items
    • Open items
    • Closed items
    • Items for review
    • Status
  • Meetings
  • Help
  • Log in
  1. Maintenance Items
  2. 0379
  3. Request
Requested revision
Standard:802.1QClause:5.11
Clause title:System requirements for Priority-based Flow Control
Rationale for revision
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.
Proposed text
Replace f) of 5.11 which currently reads

"Enable use of PFC only in a domain controlled by DCBX (Clause 38)."

with:

"Exchange and process Priority-based Flow Control Configuration TLVs as 
specified in Clause 36 (Priority-based Flow Control) and Clause 38 (Data 
Center Bridging eXchange protocol)."


That change limits the dependency of PFC on DCBX to the implementation 
*and* use of PFC. I believe that both Clauses 36 and 38 require serious 
improvement for effective standards compliant multi-vendor use, but that 
improvement does not depend on making this chance  which resolves some 
of the ambiguity/conflict in the existing text.


I believe this change could be included in 802.1Q-2022-Rev.
Impact on existing networks
This change relaxes a current restrictive interpretation of the text and should have no impact on existing networks and implementations, which are believed to ignore such a restrictive interpretation.
Originator
Name:Mick SeamanEmail:mickseaman@gmail.com
Affiliation:Mick Seaman
Submitted:2024-11-02