摘要

  • IESG 于 9 月 9 日就 ACTN 应用于分组光网络集成的第 20 版草案发起最后征求意见，截止日为 9 月 23 日，预期文档类型为 Informational；截稿时尚未批准或发布为 RFC。
  • 在“部分汇总”模式下，多域业务协调器可以完整掌握分组 TE 拓扑，却只看到光网络的抽象视图；光层 PNC 保留域内路径计算，也可以依政策隐藏内部和厂商特有信息。
  • 抽象视图证明的是特定政策下的潜在连接，不自动证明物理库存、资源预留、配置成功或端到端服务。每一次状态跨越都需要自己的回执。

这次发生的是公开征求意见

IESG 9 月 9 日公告请 IETF 社群对 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) 提交最后意见，期限到 9 月 23 日，目标是 Informational RFC。Datatracker 页面在本文截稿时仍明确标为“In Last Call”。

所以，当前可确认的是 IESG 已启动审议阶段，而不是已经批准、已经分配 RFC 编号或已经要求运营商部署。Informational 文档若日后发布，可以成为工程判断的重要依据，却不会因此变成任何一家网络的运行证明。

Document shepherd 说明概括了技术范围，并列出 shepherd 与负责的 Area Director；但模板中关于工作组争议、现有实现和厂商计划的问题没有填写公开答案。这里的空白既不能证明“无人实现”，也不能拿来证明“产业已经采用”。

同一个域可以有不止一张真地图

物理清单要回答设备、端口和线路“有什么”。流量工程拓扑要回答控制平面“可以考虑什么”。客户最终关心的则是服务“实际发生了什么”。三张图可能引用相同节点，却不处于同一证据层。

RFC 8453把 ACTN 抽象明确放在网络政策之下。PNC 可以隐藏光学参数、内部拓扑或其他机密细节，只向 MDSC 提供潜在连接。拓扑交给谁、提供多少细节，应当经过认证、访问限制，并能按政策配置。

RFC 7926进一步说明，抽象拓扑可以公布边界点之间的潜在连接，并附带带宽、时延等参数。底层网络或资源使用一旦变化，视图可能需要定期或增量更新。由此可见，抽象值必须连同生成时间与更新规则理解；昨天准确的可用量，今天可能已经过期。

RFC 8795则区分了服务提供者的原生 TE 拓扑与面向某个客户定制的拓扑。不同客户收到不同视图，可以是权限和偏好不同的正常结果。该 RFC 还把跨层的“过渡 TE 链路”描述为潜在连接的辅助结构：只有底层通道真正建立后，状态才向前推进。

因此，抽象并不是“少报了一半的库存”。它是另一个对象：在政策 P、面向客户 C、基于时间 T 的底层状态，哪些选择可以交给上层计算。要质疑的不是“为何不把全部光纤给我看”，而是“这是谁的视图、适用哪项政策、根据什么底层状态、多久更新一次”。

部分汇总把决定权留在域内

第 20 版草案比较了不同信息分配方式。在部分汇总下，MDSC 完整看到分组域的 TE 拓扑，只收到光域的抽象拓扑，由光层 PNC 在本地算路。若采用“完整知识”，协调器可以得到更多分组与光层细节，但文档也指出规模问题，以及光路计算依赖不同厂商特有属性的困难。

这不是从“低质量数据”升级到“高质量数据”的单向阶梯。完整视图扩大中心的计算能力，也扩大泄露面、耦合度和维护成本；抽象视图保护域自治和机密性，却要求上下游把委托与回执做得更清楚。

MDSC 可以给出严格路径，也可以只给出松散路径。松散路径情况下，PNC 在自己的域内选择完整路线，再把所选路径回报给 MDSC。光层 PNC 采用什么机制发现内部拓扑、建立光路，通常具有厂商特性，草案把这些工作留在范围之外。

于是，MDSC 日志最多先证明“协调器根据当时看到的视图计算出一种可能”。如果没有域内回执，它不能证明 PNC 选择了哪条实际光路、是否占住了资源、设备是否接受配置、保护路径后来是否切换。

“链路可用”必须带上动词

分组与光层结合后，状态最容易在简洁界面里被压平。一条视图可以公布容量；路径引擎可以计算方案；域控制器可以承诺资源；设备可以执行配置；遥测才会观察结果。这五个动词相邻，却不能互相替代。

草案列出的缺口说明了原因。例如，某些 LAG 模型还缺少“至少多少成员保持活动才算正常”的属性。一个聚合链路仍显示 up，并不一定保有业务承诺所需的冗余。某些 muxponder 的客户端口存在固定配对约束，汇总容量看似足够，本地检查仍可能拒绝具体连接。非常规流量拆分也可能让“总量可行”与“每条流实际去向”之间出现差异。

所以，一张图上的绿色状态不能替代下面的链条：

视图已发布 ≠ 路径已算出 ≠ 域已承诺 ≠ 配置已落地 ≠ 服务已观测。

即使这些动作在自动化系统中只相隔几秒，也应保留各自的主体、输入、时间和结果。否则发生争议时，所有人只能看到最后一个“成功”，却找不到成功究竟指哪一步。

明说缺口，不等于报告故障

草案还记录了路径计算扩展、SR-TE 建立、LAG 最小活动成员、部分流量拆分和 muxponder 约束等尚需补充的模型或机制。运营者还需要确认具体厂商是否支持所需组合。

公开这些边界是标准工作的优点。它让采购方与网络团队知道，哪些地方不能只靠共同模型。它并不证明任何现网发生过中断，也没有给出某家厂商缺失功能、某次互通测试失败或某项 SLA 未达标的事实。

运行部分特别强调跨层监测。分组现象可能来自光层故障，一层的保护动作也可能改变另一层的路径。集成使日常调度更统一，却可能让故障隔离更复杂。协调器显示的是简化视图，取证时仍需追到各 PNC 留下的本地状态。

有权限发起，不等于已经交付

跨域接口会读取拓扑、请求连接甚至触发配置，权限控制因此不可缺少。草案要求为 RESTCONF、NETCONF 与 PCEP 提供安全传输，并以细粒度方式限制资源请求。RFC 8341定义 NACM，RFC 8040规定 RESTCONF，RFC 6241给出 NETCONF 的协议基础。

认证回答“谁在操作”，授权回答“他可以尝试什么”。它们不回答“光资源是否已经预留”“设备配置是否成功”或“业务是否达到目标”。一个完全合法的请求仍可能遇到本地约束；一个安全传输的计算结果也仍只是计算结果。

把权限证据与运行证据分开，还能避免把安全日志误当成商业保证。“经授权的 MDSC 发出了请求”不能被改写成“整个测量窗口内带宽均已交付”。

给跨层决定留一张回执

可问责并不要求公开原生拓扑。我建议为每次关键变更保存一张受机密边界保护的跨层决定回执。

回执首先标识抽象视图：拓扑 ID 与版本、目标客户、发布它的 PNC、抽象政策负责人、生成时间、有效期和新鲜度声明。详细光纤与设备清单仍由域所有者保管；公开记录只需保存可核验的摘要或内部引用。

第二部分记录业务意图和权限：请求者、约束、访问决定、MDSC 软件与政策版本，以及哪些计算在中心完成、哪些委托给 PNC。对于松散路径，只记录交给域控制器的边界点和约束，不能虚构一条由 MDSC 选择的域内路线。

第三部分把资源承诺与配置结果拆开。每个域说明是否预留或承诺、范围和到期时间，再另行记录分组与光层配置时间、实际路径引用、阻断约束和保护状态。最后才接入观测窗口、可达性、性能、告警、恢复、回滚与更正。

这张回执是 Daniel Kade 的编辑建议，不是 IETF 或 ACTN 的既定字段。它把 Heng Lu 的《政策之镜》用于分层控制：每个状态都要看清决策者、政策与适当证据。《最低初始规范》支持一个不剥夺本地实现选择的窄接口；《为何 BTW Media 存在》则提醒我们，不把架构可能性写成运行事实。

ACTN 的抽象可以同时保护协同和自治。前提不是把抽象视图伪装成物理账本，而是让从“可以”走向“已经”的每一次交接都能被找回来。

来源

  1. IESG 最后征求意见公告
  2. IETF Datatracker 记录
  3. Internet-Draft 第 20 版
  4. Document shepherd 说明
  5. RFC 8453
  6. RFC 7926
  7. RFC 8795
  8. RFC 8341
  9. RFC 8040
  10. RFC 6241
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists