摘要

  • RFC 9833–9836 分别描述承载链路、面向客户的接入电路服务、运营商网络中的接入电路，以及把这些对象连到二层或三层 VPN 的引用关系。
  • 请求可以已经验证并获准，却仍处于 awaiting-processing。服务层 AC 与网络层 AC 也不必使用同一个名称；订单被接受和名称相同都不能证明网络已经实现。
  • 完整证据必须继续覆盖网络映射、PE/SAP 资源、VPN 绑定、预期配置、实际应用、运行状态、OAM 与真实流量。任何一张回执都不能替代其余回执。

客户看到的是一条电路。运营商内部还没有建成客户以为那个名称所代表的网络对象。

这句话并不自动指向欺诈、故障或违规。它描述的是 RFC 9833、RFC 9834、RFC 9835 与 RFC 9836 有意保留的层次。四份标准于 2025 年 9 月发布，把一项接入电路服务拆成几个相关却不等价的模型。真正重要的不是多了几张表，而是任何一层都不能借用另一层的名称，冒充自己并未掌握的事实。

RFC 9833、RFC 9834、RFC 9835 和 RFC 9836 的出版记录证明它们是获得 IETF 共识和 IESG 批准的标准轨文档。出版并不证明某家运营商已经部署，也不证明某笔订单已落到设备、更不证明任何报文已经通过。

承载链路不是接入电路

Bearer 是有线或无线的底层承载。AC 是在承载之上建立的接入安排，使客户终端能够与运营商网络交换数据。一条 bearer 可以承载多个 AC；一个 AC 可以关联多个客户边缘或对端 SAP；同一个客户边缘也可以通过相同或不同 bearer 终结多个 AC。

这种多对多关系直接决定故障的形状。“承载正常”不等于某个客户 AC 已经正确绑定；删除一项服务，也不等于获得了删除共享 bearer 或同路其他服务的权限。若监控平台只保留一个绿色灯，它隐藏的恰好是资源共享最危险的部分。

RFC 9834 允许运营商先分配 bearer reference，客户取回后再把它写进 AC 服务请求。运营商还可以接受或拒绝客户给出的标识符。AC 标识符只要求在运营商域内唯一，因此它是带范围的句柄，不是全球身份。判断其价值必须同时问：谁签发、在哪个域解析、当前是否仍指向原先那条承载。

客户模型故意不知道设备位置

RFC 8309 将客户服务模型定义为客户请求或体验到的服务，而不是运营商如何在内部工程实现它。RFC 9834 延续这一边界。客户表达想要什么；PE 节点、SAP、接口、拓扑和技术选择仍由运营商决定。

这种抽象让共同服务语义保持可移植，也允许不同网络作出本地决策。代价是一项严格的证据纪律：一个本来就不公开 PE 和接口映射的客户对象，不能被拿来证明某台设备已经完成配置。

因此，服务请求需要自己的回执：请求者身份、授权范围、bearer 或 peer-SAP 引用、稳定的服务层 AC 标识符、参数、验证结果和管理状态。它们只回答“运营商如何处理这项请求”，并未回答“网络里现在有什么”。

RFC 9833 的状态包括 awaiting-validation、awaiting-processing、admin-prohibited 和 rejected。其中 awaiting-processing 尤其关键：请求可能已经批准、已经验证，但激活之前的工作仍未完成。把它渲染成“active”的仪表盘，不是简化术语，而是抹掉了标准明确留下的事实差异。

网络层必须有自己的身份

RFC 9835 定义 ietf-ac-ntw。它把服务引用映射到运营商实际管理的网络 AC，并保存客户模型没有暴露的 PE/SAP 位置。订单到此才开始成为具体网络资源。

文档明确指出，服务层与网络层 AC 是否采用同一种命名约定取决于部署。两个名称可以相同，但系统无权假设它们相同。真正的证据是引用边。若控制器只因为字符串一致就关联记录，迁移、改名、导入或复用之后，遥测很容易被挂到错误订单上。

网络模型里有一行记录仍然不是完成证明。RFC 8969 把网络模型置于服务意图与设备配置之间，并要求运行状态和统计向上暴露。网络模型可以表达编排器打算实例化什么，却不能凭自身存在证明下游系统已经应用。

Glue 只证明关系存在

RFC 9836 的 ietf-ac-glue 为 VPN 模型补上 AC 引用。它让 RFC 8299 的 L3VPN 服务模型、RFC 8466 的 L2VPN 服务模型、RFC 9181 的 L3VPN 网络模型 以及相关结构能够指向正确的服务 AC 和网络 AC。RFC 8345 与 RFC 9543 则提供拓扑和服务保障方面的相邻背景。

Glue 回答的是“这个 VPN 对象关联哪一个 AC”。它不证明资源已分配、设备配置已应用、端点可达或 SLA 达标。一条 AC 可以承载多项服务，某个 VPN 的生命周期操作也不能因此获得处置所有共用服务的权限。

最隐蔽的失败不是对象缺失，而是关系错了：服务 AC 正确映射到网络 AC A，VPN glue 却指向网络 AC B。每个对象都存在，每个字段都能解析，但整个图是错的。只检查“有没有对象”的健康页会对此全绿。

预期、应用和观察是三种事实

RFC 8342 区分配置值、预期配置和运行状态。传播延迟、硬件交互、协议和其他系统都可能让预期与运行态不同。比较 <intended> 与 <operational>，才能知道多少预期配置真正投入使用。

所以，一条 AC 的证据链必须从请求继续向下：验证并授权主体；签发或解析 bearer reference；接受 AC 服务请求；把服务标识映射到网络 AC；选择 PE/SAP/接口；绑定正确 VPN；生成预期设备配置；观察实际应用与运行态；最后另行测量 OAM、可达性、流量和服务结果。

这并不要求所有运营商使用同一套编排器。RFC 7950 提供 YANG 语言，各网络仍可选择自己的实现。共同规则只需做到一件事：不要丢失可确定的语义和可追溯的引用。

安全边界也必须按对象划分。YANG 的可写字段与详细拓扑可能敏感，RFC 9408 提供更广的 YANG 安全评估框架。但这些资料没有证明任何具体运营商泄露数据或控制器被攻破。它们只说明授权必须落在正确层级：一个通过认证的订单，不等于有权更改所有共享 bearer 的资源。

Heng Lu 关于最小初始规范、本地未来决策与自愿采用的观点，在这里成为具体控制方法：共同层只固定参与者必须共享的确定语义，拓扑、资源选择和执行顺序留给真正拥有网络的运营者。他的运行代码优先要求继续追问这些边界是否活在生产软件中；而现实而非倡议则限制结论。四份标准给出了很好的控制图，但没有替任何一条生产电路签发验收证书。

来源