摘要

  • RFC 9689 的迁移示例允许旧节点继续运行 LDP 或 RSVP-TE，新节点则由 PCECC 直接设置转发段；PCECC 在边界充当代理。
  • 代理解决的是互通，不是原子性。安全迁移仍要分别证明身份对应、逐节点确认、入口切换、孤儿状态接管和旧状态清理。

RFC 9689 附录 A.1 描绘了一条渐进迁移路径。Node1、Node2、Node3 仍按旧方式建立到 Node5 的 LSP，Node3 可以代理信令；PCECC 随后写入 Node3 的出段、Node4 的入段与出段、Node5 的入段。这个设计最吸引人的地方，是新旧节点不必在同一天完成替换。

也正因为如此，它最容易制造一个危险错觉：既然路径连通，控制状态就已经统一。事实相反。旧半段的证据来自邻接、标签映射、预留和本地转发表；新半段的证据来自 PCEP 会话、中央控制指令、CC-ID 与 PCRpt。代理只在两者之间建立对应关系，并没有把它们改写成同一种记录。

还要守住文档边界。RFC 9689 是信息类 RFC；附录中的这些用例在发布时并未处于活跃开发状态。它提供的是架构推演，不是某个厂商已经实现、某个运营商已经验证或某次迁移必然成功的证据。

Node3 不能只留一行“成功”

RFC 9050 为 PCECC 标签指令规定了细粒度标识。CC-ID 在一条 PCEP 会话内唯一；PLSP-ID、源地址与 LSP 标识把各节点上的指令联系起来。但这些坐标不会自动等于 LDP 或 RSVP-TE 一侧的会话与路径身份。

因此，边界节点需要一份可导出的对应账：变更请求、服务身份、旧 LSP 身份、边界接口、代理收到的状态、采用的转换规则、代理发出的状态、PCE 身份、PCEP 会话、PLSP-ID、每个 CC-ID、标签方向、目标代次与回滚代次。输入、判断和输出必须分别保存。否则代理重启后，团队只看得见结果，却无法证明结果从哪条旧信令推导而来。

这不是文书工作。一枚标签可能由 PCC 本地分配，另一枚由 PCE 指定；旧 RSVP-TE 预留可能尚未释放，新的中央指令也可能已经安装。把它们压成一行“LSP UP”，会把资源归属和删除权限一起压没。

多个本地确认不等于一次全路径提交

RFC 9050 要求 PCE 向路径上的每个 PCC 分别发送 PCInitiate。每个节点以 PCRpt 确认；若标签超出预留范围或无法下载指令，则返回明确错误。这些凭证很有价值，但它们证明的是某节点在某会话中处理了某条指令。

控制器仍需确认所有回报属于同一代次，入口、过境与出口位置都已覆盖，而且旧半段在同一时刻保持预期状态。两个节点确认、第三个节点超时，不能被记为“多数成功”；它是一条尚未具备切换资格的部分路径。

更新顺序进一步暴露了风险。RFC 9050 采用先建后拆：先安装新标签指令，再通知入口切换，收到入口回报后，才逐节点清理旧指令。安装、切换和清理是三个不同的决策点。切换前，新状态可能占资源但不承载业务；切换后、清理前，两代状态可能并存；PCECC 清理结束后，旧半段的 LDP 或 RSVP-TE 状态仍可能存在。

所以回滚必须注明从哪一步开始。尚未切换时，只清理不完整的新代次；已经切换时，先恢复可用且获授权的转发，再删新状态；旧信令已撤时，“回退”可能意味着重建，而不是翻转开关。

控制器失联，指令不会立即消失

RFC 9050 有意保留连续性：PCE 故障后，中央控制指令可以留到 State Timeout Interval 到期；新的 PCE 也可以接管孤儿指令。RFC 8283 同时提醒，并行控制器要保持同步并不简单，网络变化可能在故障交接中丢失。

保留状态保护了业务，却改变了责任结构。原控制器不在场时，谁可以切换入口、续接旧信令、收养指令或删除标签？新的 PCE 能连上 PCC，只能证明通信恢复；它并不能证明已经重建代理映射、迁移阶段和变更授权。

恢复凭证至少要列出：最后一个完整代次、已确认节点、未确认节点、入口状态、旧信令状态、待清理项目、超时截止点、孤儿接管事件，以及授权下一步的规则。同步能比较 PCE 视图与 PCC 标签分配，却无法从缺失日志里还原一次管理决策。

把迁移完成定义成可核验条件

“所有节点都出现在控制器里”不是完成条件。更可靠的条件是：迁移边界已命名；新旧协议能力已记录；一条端到端身份已映射到全部本地标识；每个 PCECC 节点的目标代次均有确认；入口切换另有授权；旧半段与代理映射同时完成清理；孤儿接管与超时行为经过演练；独立数据面观察与控制凭证相互印证但不互相替代。

渐进迁移的价值来自最小共同层：允许不同节点保留本地选择，只在必须互通的边界协调。若把代理的协调能力夸大成对全路径的统一权力，就会把真正需要治理的缝隙藏起来。

来源