docs: Clarify DCBX requirement vs DCBX willing mode in TOR QoS reference
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- azure
- Domain
- documentation, networking
Research direction
Start with TSG/Networking/Top-Of-Rack-Switch/Reference-TOR-QOS-Policy-Configuration.md and compare its DCBX wording with the referenced Physical network requirements page. Update the reference so DCBX remains enabled for TLV advertisement while willing mode is explicitly unsupported and static configuration is required, including the RDMA and storage rationale. Done means the three requested distinctions are clear without implying a behavior change.
Written by the indexing model from the issue text.
Description
Summary
The TOR QoS Policy reference doc creates customer confusion about DCBX configuration. Customers are making a logical leap from "DCBX must be enabled to advertise the required TLVs" to "DCBX willing mode should be true." This is incorrect. Azure Local does not support DCBX willing mode — only a static configuration is supported.
Affected doc: Reference-TOR-QOS-Policy-Configuration.md
Referenced from: Physical network requirements
Customer Confusion
The current language describes enabling DCBX as a required aspect of switch configuration. This is true in the sense that DCBX must be enabled to advertise all the TLV values required for Azure Local (carried in LLDP frames). However, customers are inferring that DCBX willing mode should also be enabled.
What's Correct
- DCBX enabled: required to advertise the necessary TLVs over LLDP.
- DCBX willing mode: not supported in Azure Local. Configuration must be static.
Why DCBX Willing Mode Is Not Supported
DCBX willing mode allows the fabric to dynamically change host-level settings. The fabric does not understand Azure Local's RDMA / storage requirements, and dynamic changes from the fabric can disrupt RDMA traffic and impact the storage layer. If DCBX willing mode were enabled, a rogue configuration could change neighbor settings and break system configurations.
This is not a new requirement — it has been in place since Storage Spaces Direct originally launched.
Requested Change
Update the TOR QoS reference doc to:
- Explicitly state that DCBX willing mode must be disabled / false (static configuration only).
- Distinguish between "DCBX enabled (for TLV advertisement)" and "DCBX willing mode (not supported)".
- Briefly explain why willing mode is not supported (RDMA / storage traffic protection), so customers understand the rationale and don't try to enable it.
Scope
Small documentation fix. No behavior change.
- Dominant language
- PowerShell
- Stars
- 78
- Forks
- 60
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/AzureLocal-Supportability
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/AzureLocal-Supportability#253 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
All issues in Azure/AzureLocal-Supportability
Similar issues
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·