learn
配置漂移与状态反馈：控制器算对了还不够
学习 Qcc 落地时最容易忽略的问题：设备是否真的应用配置，版本是否一致，失败是否被反馈。
第七章：流级配置编排资源IEEE 802.1Qcc18 分钟
本节学习目标
- 理解配置漂移为什么会破坏端到端一致性。
- 知道状态反馈和版本管理是集中式配置的重要组成。
- 能识别部分下发成功带来的风险。
建议先读
核心概念
configuration driftstate feedbackversioningpartial failure
本章目录
- 01stream contract：一条关键流应该怎样被描述从 talker、listener、周期、帧长、截止时间和路径需求理解 802.1Qcc 的流级视角。
- 02CUC 与 CNC：需求侧和网络侧各负责什么理解 802.1Qcc 集中式模型里的 CUC/CNC 分工，避免把应用需求、网络规划和设备下发混在一起。
- 03集中式配置：为什么端到端一致比单点正确更重要理解 CNC/CUC 式集中规划如何减少路径配置漂移，以及它对拓扑、设备能力和状态反馈的依赖。
- 04准入控制：网络什么时候应该拒绝一条新流理解 Qcc 不只是下发配置，还要判断新增关键流是否会破坏已有流的时间、带宽和可靠性边界。
- 05路由与调度耦合：路径选错会让排表变难理解 Qcc 中路径选择、Qbv 调度、FRER 冗余和资源预留互相影响，不能把路由和排表完全分开。
- 06配置漂移与状态反馈：控制器算对了还不够学习 Qcc 落地时最容易忽略的问题：设备是否真的应用配置，版本是否一致，失败是否被反馈。
- 07部署与回滚：配置失败时网络要进入可解释状态学习 Qcc 配置上线时如何处理分批下发、部分失败、回滚、安全状态和验证窗口，避免自动化配置造成不可控中间态。
解决什么问题
集中式配置听起来像终点：控制器算好路径和参数，下发给设备，网络就一致了。现实里，中间还有很多失败可能。某台设备不支持参数，某个端口下发失败，某个旧配置没有清掉，某台交换机重启后回到旧版本。
配置漂移解决的是“目标状态”和“真实状态”不一致的问题。TSN 对端到端一致性敏感，所以漂移会直接破坏时间边界。
背景与直觉
把集中式配置想成乐队指挥。指挥写好了谱子，不代表每个乐手手上都是同一版谱，也不代表每个人都已经翻到正确小节。只有确认每个位置的状态，合奏才可信。
怎么解决
可靠的配置流程至少要包含目标配置、下发结果、设备反馈和版本核对。
| 状态 | 要记录什么 | 风险 |
|---|---|---|
| desired | 控制器希望设备应用什么 | 只有目标，没有现实 |
| applied | 设备报告应用了什么 | 部分失败被忽略 |
| observed | 抓包/计数器看到什么行为 | 报告成功但行为不符 |
| version | 配置版本和更新时间 | 新旧配置混用 |
如果配置更新跨多台设备，最好有事务或回滚策略。至少要知道哪些设备成功、哪些失败、失败后网络是否进入安全状态。
带来了什么新问题
状态反馈会增加系统复杂度。设备接口可能不统一，反馈延迟可能不同，错误码可能不够细，控制器还要处理并发更新和拓扑变化。
但这类复杂度不能省略。没有反馈的集中式配置，只是把人工配置换成自动配置，并没有真正解决端到端一致性问题。
检查点
- 为什么“控制器计算完成”不等于“网络配置完成”？
- 如果 5 台交换机里有 1 台没有应用新 GCL，端到端 Qbv 会出现什么风险？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能说明控制器计算成功和设备应用成功之间的区别。
- 2能列出防止配置漂移需要记录的状态。