摘要

  • draft-ietf-ccamp-fgotn-yang-02 要求 fgODUflex 双向调整的两个方向都完成，才可视为成功；最终状态却由源控制器单独向 MDSC 汇报。
  • lsp-bandwidth-modified-ok 是控制面的汇总结论，不会自行证明时隙已在所有域正确落地、工作与保护路径一致、强制修复没有造成中断，或客户流量保持无损。
  • 运营方需要一张可追溯的调整凭证：保留每个参与者的原始观察，对齐配置与运行状态，并以真实业务测量关闭“无损”这一主张。

MDSC 发出扩容请求。Controller 1 启动 Node 1 到 Node 6 的正向调整。到达远端后，数据面自动触发反向调整。Controller 3 报告反向流程开始。最后，Controller 1 向 MDSC 发回 lsp-bandwidth-modified-ok。

仪表盘变绿了。

这条消息究竟证明了什么？

它证明源控制器已经走到自己认定的完成节点。它没有天然证明，中间每个域都提交了同一代事务的资源变化；没有证明正反两向采用同一目标带宽；没有证明 1+1 保护路径同步完成；更没有证明客户在调整期间没有丢帧、误码或抖动。

草案本身没有把这些事实混为一谈。它明确写道，双向调整只有在两个方向均完成时才算成功；所有域控制器都要向 MDSC 报告拓扑和隧道资源变化；配置 1+1 保护时，工作路径与保护路径都要启动调整协议和信令。如果一个方向成功、另一个方向失败，控制器可以发出强制带宽调整命令以恢复一致，但这种动作可能影响业务。

2026 年 9 月 30 日发布的第 02 版，是 CCAMP 工作组的活跃 Internet-Draft。Datatracker 没有记录目标 RFC 级别、负责 AD 或 IESG 状态；管理性、安全性和 IANA 章节仍保留待补占位。它不是 RFC，也不是实施或互通报告。这里最值得研究的不是一个成熟标准，而是它提前暴露出的治理难题：分布式调整可以只有一个最终汇报者，却不可能只有一个全知观察者。

时隙可被命名，不代表容量已经交付

fgOTN 的目标，是让低于 1 Gbit/s 等低速客户信号更有效地共享较大的 OTN 承载容量。草案给出 fgODUflex 类型，把隧道带宽表示为 1 到 119 个细粒度支路时隙，并允许 fgts-numbers 出现在正向主路径、反向主路径、正向备路径、反向备路径与实际路由信息中。

这套模型让资源可以被控制器精确指称，却没有让资源自动变成事实。

控制器请求 20 个时隙，配置库显示 20，路由对象列出一段时隙，拓扑视图也显示可用带宽减少。这四项都可以正确，设备仍可能尚未在同一时刻应用；也可能工作路径已经变化，而保护路径尚未变化；甚至某个域依据旧拓扑把相同资源承诺给另一项业务。

真正需要维护的不变量不是“字段等于 20”，而是“同一项获授权事务，在每个必经段与方向上，预留并应用了互不冲突的目标时隙，且业务后置条件成立”。这个不变量需要服务身份、服务器层上下文、事务代次、时隙集合、冲突检查、设备回读和流量测量共同支撑。

RFC 8342 的 NMDA 分层尤其重要：意图、应用配置与运行状态不是同一层。即使设备运行状态已经显示目标值，也仍不等于客户业务的丢包、时延和吞吐结果。

双向业务有两条失败历史

调整从 fgODUflex 标识与目标带宽开始。草案要求先预留或标记对应资源，再触发实际变化。正向逐节点修改，到达远端后再自动触发反向。

“两个方向都完成”还缺一项条件：它们必须属于同一项事务。

一次旧尝试的迟到成功，不能与新尝试的反向完成拼成双向成功。源控制器重启后复用本地编号，不能让之前的事件获得新含义。反向流程开始前预留已经过期，也不能因为数值相同就当作连续的资源承诺。

因此，正反两向各自都需要请求摘要、事务代次、目标、拓扑版本、参与域、预留集合、开始时间、应用结果与运行回读。端到端凭证可以把两条历史连接起来，却不能把它们压扁成一个布尔值。之后若某个方向回退，分歧必须继续可见，不能被早先的绿色状态覆盖。

最终汇报者不是唯一真相来源

附录 A 的流程很方便：Controller 1 报告开始，Controller 3 报告反向开始，Controller 1 最终报告成功或失败。同时，所有域控制器都要持续报告隧道与资源变化。

这里实际存在两本账。

第一本是决策账：谁提出请求、谁允许、目标是什么、哪个流程判定结束。第二本是证据账：每个域在何时看到什么资源变化，对应哪个方向与代次，设备回读是什么，是否发生异常。

源控制器可以拥有第一本账中的最终叙述角色，不能冒充第二本账里没有亲自做出的观察。如果 MDSC 只保存最后一条状态，控制器切换、软件升级或结果争议发生时，运营方将无法独立还原依据。

更稳健的最终消息应引用一组证据：事务标识、目标、必需参与者清单、参与者凭证摘要、完成策略版本、未关闭异常与时间界限。各域凭证保持来源归属，源控制器只聚合，不改写。

这也是防止锁定的设计。若真实历史只存在于某个厂商编排器的内存或私有日志中，更换控制器就等于丢失下一次资源决策所需的上下文。应当保存可移交的事实账本，而不是把连续性寄托在当前守门者身上。

保护路径把证据面扩大一倍

在 1+1 保护下，工作路径和保护路径都要启动调整协议与信令；节点还要在状态处理中同时检查两条路径的信令。

这意味着一个受保护的双向业务，至少包含四个需要关闭的面：正向工作、反向工作、正向保护、反向保护。

工作路径达到新带宽时，客户眼前的业务可能完全正常；若保护路径仍停留在旧容量，问题会被推迟到下一次切换才爆发。保护并不是界面上的附加属性，而是对未来故障场景的承诺。今天没有核对它，明天就可能在最需要它时发现它不存在。

完成策略必须明确：保护路径未收敛时，是阻断成功、进入有期限的降级状态，还是允许经审批的例外。不能把它藏在工作路径的绿色状态后面。回读也要区分“标签已配置”和“服务器层资源可在切换时真正承载”这两件事。

强制一致可能花掉“无损”承诺

草案直面一个棘手分支：一个方向成功，另一个失败。控制器可以强制调整，使两边恢复一致，但可能影响业务。

这不是普通的错误处理细节，而是一项授权决定。

系统可以等待、重试失败方向、回滚成功方向，或强制两边进入共同状态。每条路都把风险分配给不同对象。强制一致让控制面更整洁，却可能让正在运行的流量承担中断；回滚可能再次扰动；继续等待则让不对称状态影响后续资源计算。

“状态应该一致”不能自动推出“系统有权中断客户”。强制动作必须记录授权者、原因、备选方案、维护或紧急上下文、受影响业务、预计影响、回滚点与业务验证。若实际用了可能中断的修复，最终结果不能不加说明地继续叫作“hitless”。

控制系统可以执行动作，不能重写动作的后果。是否无损，应由运行流量的证据回答。

YANG 校验通过，不等于分布式事务完整

Datatracker 对第 02 版提取出的模块给出零错误、零警告。它说明模式结构和依赖在工具检查中成立，是有价值的工程证据。

它不会模拟控制器在两个方向之间崩溃，不会模拟重复或乱序通知，不会验证保护路径延迟，也不会检测设备接受配置却没有实际应用。草案目前给出了信息模型和五步场景，并未形成包含全局事务标识、参与者法定集合、超时、幂等、通知顺序、持久审计、回滚与业务后置测试的完整事务协议。

因此，两套系统都可以“支持同一个 YANG”，却在何时发出完成状态上有根本差异。合规验证必须分层：模式、RPC、数据存储变化、设备执行、多控制器收敛、保护就绪、业务结果。上一层通过，不能替下一层签字。

一张可执行的调整凭证

写入前，记录业务与 fgODUflex 身份、当前与目标带宽、服务器层上限、拓扑代次、工作/保护路径摘要、策略版本、获授权主体和维护上下文。

预留时，各域报告拟用时隙、链路与层次、可用性代次、冲突检查、预留到期时间。时隙编号只有和承载上下文绑定才有意义。

执行时，正反两向及工作/保护角色分别保留时间线。每个域提交开始、应用配置、运行回读、资源增减与异常；通知按事务代次幂等处理，不能只按到达顺序解释。

关闭时，源控制器引用证据集摘要，MDSC 核查参与者齐备、方向目标一致、资源守恒、保护状态和强制动作。迟到的旧代成功不得关闭新事务。

最后测量业务：定义前后窗口，检查丢包、误码、时延、吞吐、客户告警与自动回退。只有这一步，才有资格证明“无损”。