解决什么问题
集中式配置听起来像终点：控制器算好路径和参数，下发给设备，网络就一致了。现实里，中间还有很多失败可能。某台设备不支持参数，某个端口下发失败，某个旧配置没有清掉，某台交换机重启后回到旧版本。
配置漂移解决的是“目标状态”和“真实状态”不一致的问题。TSN 对端到端一致性敏感，所以漂移会直接破坏时间边界。
背景与直觉
把集中式配置想成乐队指挥。指挥写好了谱子，不代表每个乐手手上都是同一版谱，也不代表每个人都已经翻到正确小节。只有确认每个位置的状态，合奏才可信。
怎么解决
可靠的配置流程至少要包含目标配置、下发结果、设备反馈和版本核对。
| 状态 | 要记录什么 | 风险 |
|---|---|---|
| desired | 控制器希望设备应用什么 | 只有目标，没有现实 |
| applied | 设备报告应用了什么 | 部分失败被忽略 |
| observed | 抓包/计数器看到什么行为 | 报告成功但行为不符 |
| version | 配置版本和更新时间 | 新旧配置混用 |
如果配置更新跨多台设备，最好有事务或回滚策略。至少要知道哪些设备成功、哪些失败、失败后网络是否进入安全状态。
带来了什么新问题
状态反馈会增加系统复杂度。设备接口可能不统一，反馈延迟可能不同，错误码可能不够细，控制器还要处理并发更新和拓扑变化。
但这类复杂度不能省略。没有反馈的集中式配置，只是把人工配置换成自动配置，并没有真正解决端到端一致性问题。
检查点
- 为什么“控制器计算完成”不等于“网络配置完成”？
- 如果 5 台交换机里有 1 台没有应用新 GCL，端到端 Qbv 会出现什么风险？