learn
部署与回滚：配置失败时网络要进入可解释状态
学习 Qcc 配置上线时如何处理分批下发、部分失败、回滚、安全状态和验证窗口，避免自动化配置造成不可控中间态。
第七章：流级配置编排资源IEEE 802.1Qcc20 分钟
本节学习目标
- 理解 TSN 配置部署要处理部分成功和部分失败。
- 知道回滚和安全状态是配置系统的一部分。
- 能设计一个基础上线检查清单。
建议先读
核心概念
partial deploymentrollbacksafe statechange window
本章目录
- 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 配置上线时如何处理分批下发、部分失败、回滚、安全状态和验证窗口，避免自动化配置造成不可控中间态。
解决什么问题
Qcc 让配置更集中，但集中不等于没有失败。上线过程中可能出现某台设备超时、某个端口拒绝参数、某条链路状态变化、某个 GCL 版本没有切换。此时网络可能处在最危险的中间态：看起来已经更新，实际只有一部分更新。
本节解决部署与回滚问题。自动化配置也必须有失败路径。
背景与直觉
数据库迁移需要事务和回滚，网络配置也需要类似思维。TSN 更敏感，因为端到端一致性依赖多台设备共同成立。
怎么解决
一次 TSN 配置上线至少包含这些阶段。
| 阶段 | 动作 |
|---|---|
| pre-check | 拓扑、设备能力、现有状态、时间同步 |
| stage | 下发但不立即生效，准备未来 base time |
| activate | 在计划时间切换配置 |
| verify | 检查 applied state、抓包和计数器 |
| rollback | 失败时恢复旧版本或进入安全状态 |
| report | 记录版本、结果和异常 |
安全状态不一定是继续转发。有时拒绝新流、降级到 best effort、关闭某条关键流或回滚旧表，比半成功配置更可解释。
带来了什么新问题
回滚本身也要验证。旧配置是否仍然可用？新旧配置的数据结构是否兼容？设备是否能在运行中回退？这些都需要提前设计，而不是故障发生后临时决定。
同时，自动化配置带来权限和审计问题。谁可以触发变更，变更依据是什么，失败后谁负责确认，这些都影响工程可靠性。
检查点
- 为什么“部分设备更新成功”比“全部失败”更危险？
- 一次 Qbv/Qcc 配置上线后，你至少要用哪些证据确认它真的生效？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能说明部分设备更新成功、部分失败时为什么危险。
- 2能列出一次 TSN 配置上线前后的验证动作。