摘要

  • RFC 9731 的 vn-compute RPC 发生在实例化之前；它可以返回计算后的 VN 与连接矩阵引用，但明确不会创建 VN，也不会预留资源。
  • 计算依赖当时可见的拓扑、策略、约束和容量。审批等待期间任何一项变化，都可能让原本正确的结果失去当前效力。
  • 稳健的交付链应分别保存计算快照、配置决定、各资源域准入、实际隧道或 LSP、运行收敛、流量观察与客户结果，不能让一份计算结果替后续所有环节作证。

周一上午，协调器算出了一张完整拓扑。路径满足约束，所有成员都有对应的连接矩阵条目，审批材料也把结果画成了绿色。

周三下午，资源团队终于准备执行。期间一个域调整了维护窗口，另一个域把可用带宽分给了更早提交的请求。计算没有出错；它只是属于周一。

RFC 9731 对这种误判给出了极为清楚的边界。vn-compute 是预实例化操作。它让调用者先看到计算后的完整 VN，却不创建 VN，也不预留系统资源。

这句话不是保守措辞，而是在区分两类权力：计算者可以说明在某个信息快照下“可能怎样建”，资源所有者才能决定容量“是否已经给出”。

客户视图有意省略底层现实

RFC 9731 定义了虚拟网络操作的 YANG 模型，并以 ACTN 作为主要场景。客户网络控制器 CNC 表达客户视角与需求，多域服务协调器 MDSC 组织跨域信息和计算。接入点描述客户端点特征，虚拟网络接入点把接入点在不同 VN 之间划分，并指向提供方边缘。

Type 1 VN 可以只表现为边到边的抽象链路。Type 2 VN 可以展示虚拟节点、虚拟链路以及预期路径。客户不必看到每一台底层设备、每条内部链路和每个域的本地政策。

这种省略不是缺陷，而是抽象的目的。可同一原因也限制了它的证明力：客户视图里的一条连线不能替所有隐藏资源作证，抽象拓扑中的可行性也不能自动继承每个域的承诺。

RFC 9731 所引用的服务模型原则同样重要：服务模型并不假定实际服务将如何工程实现和交付。意图、呈现与执行因此不能压缩成同一条记录。

计算快照有自己的时钟

vn-compute 可以接收 VN 级约束与优化条件，也可以为单个成员提供更具体的条件；成员级取值能够覆盖较宽的设置。输出可以引用单节点抽象拓扑，并让每个 VN 成员指向相应的 connectivity-matrix-id，以便调用者检查路径属性。

这比一句“找到路径”丰富得多，却仍然只是一份基于当时信息的结果。拓扑视图有版本，策略有版本，资源库存有观察时间，依赖控制器也有自身状态。只保存最终矩阵标识而不保存这些上下文，等于把带日期的判断撕掉日期后继续流通。

因此，计算凭证至少应绑定输入约束、成员标识、抽象拓扑版本、连接矩阵版本、策略修订、资源视图时间、参与控制器以及失效条件。审批时间一旦超过允许窗口，就应重新计算，而不是给旧结果盖新章。

“当时可用”不是“现在归你”

模型列出的计算错误包括 MDSC 尚未就绪、依赖 CNC 不可用、没有可用资源、找不到路径以及未知接入点。有人会反过来推断：既然没有返回“没有可用资源”，容量就已经安全。

这个推断多走了一步。没有该错误，只表示计算在所用信息和约束下找到结果。另一请求随后可能占用容量，本地准入政策可能改变，抽象链路可能重新映射，某个域也可能在真正配置时拒绝。

“可用”是快照中的属性。“已预留”是有权处分资源的主体完成的动作。前者由计算系统陈述，后者必须由资源所有者留下记录。即使两个动作相隔几秒，也不应由同一个布尔值代表。

一个成功响应只能证明它完成的事

成功的 vn-compute 响应可以证明：请求被接受；计算没有以规定的错误结束；结果在某时刻包含哪些成员、拓扑引用与矩阵引用；输入里有哪些约束和优化目标。

它不能单独证明调用者有权创建实时 VN，不能证明配置已进入预期数据存储，也不能证明每个域完成准入。它还不能证明隧道或标签交换路径已安装、运行状态已收敛、流量已通过、性能满足承诺，更不能证明客户已经验收。

保持这种窄而精确的语义，不是贬低计算结果。相反，只有不让它替未知事件背书，它才是一份可靠凭证。

配置与运行状态同树，不等于同一现实

RFC 9731 遵循网络管理数据存储架构，把配置与运行状态组织在同一模型树中。这便于客户端沿着一致路径读取相关数据，但界面上的邻近不等于因果上的同一。

一个 VN 成员可以已经配置，运行状态却仍为 down；系统也可能在收敛期间继续报告与旧配置有关的状态。合并读取返回一棵树，不代表所有叶子由同一动作、同一主体或同一时刻生成。

记录需要明确这是计算输出、预期配置、运行配置还是 operational 状态；需要保留控制器身份、模型修订与观察时间。若只截一张同屏画面，审批者看到的是布局，不是状态演进。

连接矩阵引用不是一条隧道

计算输出把 VN 成员关联到抽象拓扑中的连接矩阵条目。条目能表达抽象节点里的有效交换组合与潜在 TE 路径性质，这对客户检查需求非常有价值。

但引用不会分配带宽，也不会向底层设备下发配置。它没有说明每一段路径都被域控制器接受，没有证明 LSP 建立，更没有记录实际转发。

如果工单系统复制矩阵标识后把状态改为“已开通”，系统只是给同一个标识换了标签，并没有增加证据。真正的实例化必须留下底层对象标识、安装结果与运行观察。

多域协调不等于集中拥有资源

MDSC 能够汇总信息并协调一次跨域计算，不代表它因此拥有所有域的容量。每个域可能有独立配额、维护状态、保护要求、竞争请求和准入规则。

客户约束可以塑造结果，却不能绕过这些本地权力。一个端到端抽象路径可能在逻辑上连贯，而实际承诺仍需逐域形成。

可审计的交接应标明每个状态的作者：计算服务签署输入和结果快照；配置权力记录预期 VN；各资源所有者记录接受或拒绝；部署系统记录真实隧道或 LSP；运维记录收敛与健康；边缘观测记录客户流量。自动化可以连接这些动作，却不能抹去作者差异。

新鲜度必须贯穿审批空档

最危险的结果往往不是明显错误，而是正确但过期。审批会议、变更窗口和跨团队排期会在计算与实例化之间制造空档。空档里可能发生拓扑更新、资源消耗、策略变更、接入点撤销或依赖控制器不可用。

因此，新鲜度不应只是报告顶部的时间戳。系统需要能够判断哪些输入发生变化，以及变化是否足以使结果失效。资源视图更新、成员级覆盖变更和矩阵修订都应触发重新计算或人工复核。

若不能回答“这份结果对应哪一版世界”，它就不应进入容量承诺阶段。

计算错误不是全生命周期错误表

RFC 9731 的错误分类能帮助调用者区分协调器未就绪、依赖不可用、资源不足、路径不存在与接入点未知。它们服务于计算阶段，不是整个交付过程的故障本体。

后续预留可能因为新的竞争请求失败，实例化可能只在部分域成功，运行状态可能不收敛，流量也可能在抽象属性成立时仍不满足客户需求。

每一阶段都需要自己的失败记录。把“计算成功”作为全生命周期的成功状态，会让后来发生的拒绝、部分安装和性能缺口无处归档。

允许计算不等于允许创建

RFC 9731 的安全考虑依赖受保护的 NETCONF 或 RESTCONF，并借助 NACM 限制操作和数据。文档还指出，配置与运行信息具有敏感性，vn-compute 本身可能泄露 VN 信息。

这意味着计算权限也有风险：它可能暴露端点、拓扑、策略和潜在容量。但敏感不意味着它必须与创建权限捆绑。读取、计算、配置、预留和删除应被视为不同能力。

规划系统可以有权请求计算，却无权改变实时网络。真正的变更由另一个经过批准的身份执行。这样，计算保留为决策支持，而不是隐藏的变更授权。

丢弃计算不是回滚生产

预实例化计算没有创建 VN，也没有预留资源，因此放弃结果通常只是停止使用并在需要时重算。它不会释放一条并不存在的隧道。

资源真正提交以后，撤销就完全不同：可能要删除底层对象、释放容量、恢复策略、协调多个域并保护现有流量。这才是改变运行系统的回滚，需要证明服务恢复到什么状态。

若把两者都叫“回滚”，组织就看不见真实成本从哪一步开始出现。承诺之前是取消方案，承诺之后才是逆转生产变更。

建立逐层凭证链

第一，保存被接受的计算请求及其信息快照。第二，保存计算结果、成员引用和所有错误。第三，形成独立的配置决定并记录批准者。第四，收集每个必要资源域的准入。第五，记录实际隧道或 LSP 标识和安装状态。第六，观察运行状态收敛。第七，在客户边缘验证流量。最后，保存客户可见结果或未解决差距。

这些凭证不需要互相模仿。它们通过稳定标识和时间连接，强度正来自每一份只陈述自己知道的事实。

RFC 9731 把第一条边界写得足够明确：计算里的网络还不是生产里的网络。

来源