摘要

  • RFC 9835 在网络侧 AC 中保留服务侧 AC 引用，使客户请求能够关联到实际配置对象；这只能证明“指的是哪个对象”，不能证明链路连续、转发成功或客户已收到服务。
  • 网络 AC 名称只在节点范围内唯一。配置还要解析全局配置档、局部覆盖、父子继承、管理状态和运行状态；把它们压成一个绿色字段，会丢掉模型最重要的边界。
  • 真正的交付证据必须继续走到正确目标、有效配置、可观测状态、限定范围的 OAM、全业务状态以及客户流量或应用探针。

订单已经完成，分支机构却没有网络

设想企业为新办公室订购一条连接。门户生成服务引用，编排器选择 PE 并建立接入电路。商业系统和网络库存都能显示同一个引用，于是流程被标为完成。但物理或逻辑 bearer 可能中断，VLAN 可能写错，路由策略可能继承了旧版本，另一端 VPN 接入也可能尚未就绪。

引用没有失败。它完成了自己的工作：说明两个系统谈论的是同一项请求。它没有资格替设备和客户报告结果。

RFC 9835 在 2025 年 9 月发布为标准轨文档，RFC Editor 记录固定了它的身份与状态。它定义 ietf-ac-ntw，用于在服务开通前或开通过程中配置运营商网络里的接入电路，并在网络 AC 中保存服务侧引用。

因此，服务请求、服务引用、网络 AC、观测到的 AC 状态和客户实际获得的连接，是一条链上的不同记录，不是同一个字段的五种写法。

bearer 与 AC 回答不同问题

RFC 9833 把连接客户节点或站点与运营商网络的物理或逻辑链路称为 bearer；AC 则是建立在该承载上的配置，使数据交换成为可能。一个 bearer 可以承载多个 AC，一个 AC 可以绑定多个对端 SAP，一个 SAP 也可以终结多个 AC。

这意味着故障与对象不是一对一的。bearer 故障可能同时影响多条 AC；某条 AC 的 VLAN 或 IP 配置错误，并不说明 bearer 本身失效。bearer 引用能告诉客户“服务要放在哪里”，却不能证明服务已经正确放上去。

RFC 9834 把 bearer 与 AC 暴露为客户可请求的服务模型；RFC 9835 描述网络侧对象；RFC 9836 再把这些引用接到 L2VPN、L3VPN 的服务和网络模型。标准没有抹平边界，而是让边界之间的映射可检查。

可审计记录至少要保存：服务引用、网络 ID、节点 ID、节点内 AC 名称、SAP、bearer，以及映射生效的时间段。把它们事后拼成一个所谓全局电路号，可能让界面整齐，却会让迁移与故障历史失真。

svc-ref 是连接键，不是裁决书

RFC 9835 明确说，网络模型利用服务模型暴露的 AC 引用，把服务请求与网络中实际配置的 AC 关联起来。这个 svc-ref 很重要，但它的证据上限同样重要。

网络 AC 名称只在某个节点内唯一，不在全网唯一。服务层与网络层是否使用相同命名规则，也由部署决定。因此，两台设备都可以有 ac-17；一个稳定的客户引用也可以在迁移后指向另一节点的实现。只比较裸名称，会把不同对象错误合并。

映射收据应记录完整元组：服务引用、网络、节点、本地 AC、SAP、作出映射的编排器，以及映射版本或时代。实现迁移时，外部引用可以不变，但旧映射与新映射不能同时假装是唯一真相。

RFC 8969 区分客户服务模型、网络模型和设备模型。模型间翻译本身就是需要负责人的运行行为。共同模式减少歧义，不会自动保证翻译正确。

有效配置是计算结果

RFC 9835 允许在网络层定义配置档，由多条 AC 继承。若 AC 对同一数据节点作局部细化，本地值优先。于是，真正下发的配置并不存在于单一位置，而要由配置档版本、继承值与局部覆盖共同计算。

审计若只存配置档名称，就看不到例外；只存局部覆盖，又丢掉共同基础。应冻结每个获胜值的来源、配置档修订号、有效配置指纹和目标。否则未来修改配置档，可能把历史部署“重新解释”为今天的状态。

RFC 9836 还有另一条优先规则：当引用 AC 的信息与 VPN 接入内联信息重叠时，引用信息优先。这解决的是哪份意图获胜，不证明控制器已原子下发、设备解释一致或回滚完全。

RFC 8342 的 NMDA 把意图/配置与运行状态分开；RFC 8345 是 RFC 9835 扩展的基础网络模型。对象“存在”只说明调查开始了。真正的问题是：要求了什么、计算出的有效状态是什么、网络实际报告了什么。

删除父 AC，会扩大一条命令的范围

对于同一 AC 下多个对端 SAP，模型可以建立父 AC 保存共同属性，再以子 AC 保存各对端特有信息。子项继承父项。RFC 9835 要求：父 AC 删除时，所有子 AC 必须删除。

这条规则避免数据模型留下孤儿，却也建立了级联权力。一项管理动作可能影响多条子 AC、多个 SAP 和服务。模式本身不能证明控制器枚举了正确依赖、按顺序撤销设备状态、没有碰到无关服务，也不能证明计费与客户通知同步完成。

删除前应生成影响收据：父项、全部子项、绑定 SAP、服务、bearer、有效配置与当前运行状态。删除后再用设备状态和客户探针核对。数据库里父行消失，只证明模型发生了变化，不证明残留转发已清空或客户没有损失。

管理状态必须允许被运行状态反驳

RFC 9835 分开维护管理状态与运行状态，并把二者不一致视为异常触发器。RFC 9833 定义等待批准、等待处理、管理禁止与拒绝等状态。这些是工作流事实，不是报文事实。

获批不等于激活；配置存在不等于链路可用；接口 up 不等于 VLAN、地址或路由正确；一个本地 AC 健康，也不等于整个 VPN 健康。

RFC 9408 将 SAP 描述为运营商侧服务参考点，并强调某个 SAP 上观察到的服务状态，不是连接多个 SAP 的全网服务状态。RFC 9181、RFC 9182 与 RFC 9291 提供 VPN 公共类型和网络模型；RFC 9543 又给出网络切片服务框架。任何单点绿色状态都不能替这些更大范围作证。

完整证据链至少区分九步：客户请求；服务接受并分配引用；映射到网络/节点/SAP/AC；解析继承与覆盖；提交正确目标；读取运行状态；执行限定范围的 OAM 或协议测试；检查端到端服务；以客户流量或应用 canary 验证消费结果。

这些 RFC 没有证明某个运营商部署、产品合规、故障案例、采用率、节省金额或 SLA 成果。本文提出的是运行证据方法，不是新的 IETF 强制要求。

读取映射也会产生权力

RFC 9835 的安全章节警告，未授权读取可能暴露客户 peer-sap-id；写操作还可能影响路由、过滤、加密、密钥与服务绑定。能改写服务引用到网络 AC 映射的账户，改变的不只是元数据。

商业系统可以有权创建请求，却不应自动获得路由密钥写权；控制器可以写网络意图，却不应重写客户身份；观察者可以读运行状态，却不应修改 AC。日志要保存认证主体、作用范围、旧值、新值与结果，不能只写“API 成功”。

RFC 9835 的长期价值，是把承诺与执行之间的接缝变成可追踪对象。只有当引用继续通向独立观测与客户结果时，自动化才具有问责能力；如果引用本身就是结案依据，系统只是把承诺自动化了。

来源