Azure / Azure/AzureLocal-Supportability
docs: Clarify DCBX requirement vs DCBX willing mode in TOR QoS reference
- Langage dominant
- PowerShell
- Étoiles
- 78
- Forks
- 60
- Merge moyen
- 1 j 6 h
- PR mergées (30 j)
- 5
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](https://github.com/Azure/AzureLocal-Supportability/blob/main/TSG/Networking/Top-Of-Rack-Switch/Reference-TOR-QOS-Policy-Configuration.md)
**Referenced from:** [Physical network requirements](https://learn.microsoft.com/en-us/azure/azure-local/concepts/physical-network-requirements?view=azloc-2604&tabs=24H2reqs)
## 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:
1. Explicitly state that DCBX **willing mode must be disabled / false** (static configuration only).
2. Distinguish between "DCBX enabled (for TLV advertisement)" and "DCBX willing mode (not supported)".
3. 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.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par TSG/Networking/Top-Of-Rack-Switch/Reference-TOR-QOS-Policy-Configuration.md et comparez sa formulation concernant DCBX avec la page référencée sur les exigences du réseau physique. Mettez à jour la référence afin que DCBX reste activé pour l’annonce des TLV, tandis que le willing mode soit explicitement non pris en charge et qu’une configuration statique soit requise, avec notamment la justification pour RDMA et le storage. La tâche est terminée lorsque les trois distinctions demandées sont claires, sans laisser entendre une modification du comportement.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- azure
- Domaine
- documentation, networking
- Type d'issue
- Documentation
- Difficulté
- 1/5
- Temps estimé
- 1-3 heures
- Activité
- Calme
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 88/100