摘要

  • 第 07 版草案提出两个 YANG 模块，分别描述 OAM 单项测试与由用户排序的测试序列，并复用周期、重复计划、状态和设备模型挂载能力。
  • 即使序列显示为 success，它也不能独自证明预定版本在预定窗口执行、所有步骤和数据具有可比性、根因唯一、变更获授权，或者服务已经恢复。

把诊断过程写下来，不等于得出诊断结论

网络排障常靠经验串联多个动作：先做连通性检查，再追踪路径，然后测量时延与丢包，缩小到某个节点或链路，并在故障窗口内重复。draft-ietf-opsawg-scheduling-oam-tests-07 的价值，是把这类隐含步骤变成共享结构。ietf-oam-unitary-test 描述单项测试、目标节点和设备级 OAM 模型；ietf-oam-test-sequence 把多个测试按用户指定顺序排列，并加入时段、重复规则和执行次数。

这解决的是协调问题。它没有解决知识边界问题。界面上出现计划、计数器和绿色终态后，组织很容易把“编排系统完成了它所记录的流程”误读成“网络故障已经找到唯一根因”。

IETF Datatracker 先给出最基本的限制：第 07 版仍是 OPSAWG 工作组的活动 Internet-Draft，目标为 Standards Track，没有 RFC 编号，IESG 尚未开始处理。变更历史 显示 OPSDIR 与 PERFMETRDIR 的早期审查均为 Has Issues，YANG Doctors 审查仍未完成。这不是实现、部署、合规或运行效果的证据。

如果要让诊断结果具有运营权威，至少需要八份相互关联、但不能互相替代的回执。

第一份：计划身份与版本

草案复用 RFC 9922 的计划状态、版本、本地时间、上次与下次触发、成功和失败计数。单项测试还可列出多个 ne-config 目标，并在 root 下挂载具体设备 OAM 模型。

计划回执必须冻结的不只是名称：准确配置摘要、测试顺序、目标节点、参数、时区、时间规则、挂载模块与 YANG library 身份，以及批准该版本的人。RFC 9922 明确说版本由复用该 grouping 的实体维护，有些场景也可以不用。版本字段因此不是天然的内容哈希。若审核后有人更改顺序或参数，具体执行实例必须能指回真正触发的版本。

第二份：配置已应用，而不只是请求被接受

第 07 版使用 planned、configured、ready、on-going、stop、error 和 success；序列另有 failure。这些状态有用，但只说明报告它们的实现如何理解自身生命周期。

NETCONF 或 RESTCONF 接受一次写入，只能证明服务器处理了请求，不能证明每台设备都进入预期状态。RFC 8342 把 running、intended、applied 与 operational 明确分开：配置可以存在于预期状态，却因为资源或转换而没有实际生效。应用回执应逐节点比较 intended 与 operational，记录能力、schema 版本与所有部分失败。

OPSDIR 早期审查 还指出，草案虽然使用“按需诊断”的表述，却没有定义即时调用的规范 RPC 或 action。本文不会把下层设备可能存在的动作接口误写成该草案已经定义的功能。

第三份：哪一次触发真正执行

重复规则描述“应该何时运行”，并不等于一项不可混淆的执行实例。控制器重启、故障转移、排队延迟、重试、时钟调整或重复窗口重叠，都可能让 last-occurrence 和一个简单计数器失去足够语境。

每次触发需要单独身份，并绑定预定时间、实际开始和结束、计划版本、编排器身份、时钟来源与误差界限、重试谱系，以及真正到达的节点集合。一次测试即使最终成功，若它错过故障窗口，也不能证明当时的网络状态。

第四份：步骤与依赖是否完整

序列由用户排序。草案同时规定，某些单项测试出错后，后续测试仍可继续。这能保留剩余观测，却使“序列结束”与“诊断过程完整”成为两件事。

PERFMETRDIR 早期审查 特别询问：为什么单项测试的 stop 转向 success，而序列的 stop 转向 failure。OPSDIR 还要求澄清 failure/error、通知、跨节点一致性、关联与回滚。完整性回执应列出每项必需测试、前置条件、节点、时间、结果引用、跳过或错误，以及缺失步骤使哪些解释仍无法排除。没有记录不等于通过。

第五份：测量值究竟代表什么

计划化草案故意不重新定义每种 OAM 的详细输入与输出，而是依赖设备级模型，例如 RFC 8913 的 TWAMP YANG 模型。它通过 RFC 8528 的 schema mount 把这些模型置于父模型之下。但 schema mount 只定义模型结构，并不预设实例数据来自哪里；挂载点如何实例化与受控也可能在标准范围之外。

测量回执因此必须跨过挂载边界：测试类型及版本、参数、源与目的、方向、包群、转发类别、包大小与速率、实际时间窗、单位、时钟语义、设备身份、原始结果或摘要，以及保管位置。状态叶指向某个挂载结果，不等于结果本身；孤立数值也不等于运营结论。

RFC 7799 区分主动、被动与混合测量。主动测试产生的新包与原有业务流量不是同一观测对象。每份记录都应保留这种来源差异。

第六份：探测包是否与受影响业务具有可比性

RFC 10014 把路径同一性与相同转发处理分开。探测包可以经过同样的节点和链路，却进入另一条队列、使用不同 QoS、选择不同 ECMP 分支、避开业务流量遇到的 policer，或没有承受造成故障的负载。

可比性回执需要说明探测与业务共同拥有的事实：拓扑、封装、转发类别、哈希输入、维护域、时间窗、负载与故障模式。若只共享拓扑，结论就只能限于拓扑。编排器可以安排一种测试，却不能通过配置声明它与业务 fate sharing。

第七份：候选根因与变更权力

草案的排障章节使用“candidate root cause”，这是准确措辞。RFC 9940 分开事件、故障、问题、症状、原因、告警与事故，原因往往需要多项输入。RFC 8632 也把可能的根因资源称为提供给客户端应用的提示。

诊断回执应保存推理过程：所用观测、竞争解释、已排除假设、置信度、适用范围，以及什么新证据会推翻结论。某一跳之后出现丢包，可以缩小搜索范围，却不能自动区分拥塞、光层问题、队列策略、软件缺陷、瞬时重路由与测量伪影。

即便诊断很强，也没有自动取得变更权。能创建测试的人未必能改路由、QoS、接口或客户服务。RFC 8341 把 YANG 访问控制单独建模。变更回执必须说明授权主体、政策依据、准确改动、影响半径、维护窗口、前置条件与回滚方案。

第八份：修复后的业务现实

控制器可以接受变更，设备可以显示新状态，原测试也可以转绿，而客户问题仍未消失。流量也许被移到另一条更差路径；一个症状消失，却出现另一类退化。

结果回执必须来自能够观察承诺结果的表面：业务人群、SLA 条件、后续时间窗、独立信号、残余告警、回滚状态与持续稳定时间。重新运行同一探测仍有价值，但当争议正是探测与业务的可比性时，它不能被当作独立证明。

这份草案让计划、执行和状态更容易组织。真正可靠的系统不需要一个全知结论，而需要多份边界清晰的回执能够被连接。计划启动证据链；它绝不能冒充证据链的终点。