摘要

  • RFC 9994 定义 MPLS Network Action Sub-Stack（NAS）如何承载动作和附属数据；编码出现不等于路径已经准入或完成执行。
  • I2E、HbH、Select 三种范围，加上可读标签深度、已知能力和未知动作规则，决定一个节点实际能做什么。
  • 真正可审计的结论必须分开记录：封装、路径能力、本地处理、转发变化与可观察的业务结果。

RFC 9994 为 MPLS 增加了一种清晰的表达方式。它用值为 4 的 MNA 基础特殊用途标签标识 NAS 的开头；第一个动作条目必须采用 Format B，后续可使用 Format C 和 Format D 来携带更多动作或附属数据。标准说，这些动作可以影响转发决定、传递 OAM 信息，或完成用户定义的操作。

这句话描述的是协议能力边界，不是运行事实报告。一个 opcode 只是指向某类语义。RFC 9994 还要求定义新 Network Action Indicator 的文档说明格式、范围、附属数据的数量和语法、详细处理程序，以及与其他动作的交互。也就是说，分配一个 opcode 并没有把一个完整、无条件的操作命令塞进数据包；动作定义、实现能力和节点的本地选择仍然不可省略。

最容易被忽略的是封装端的责任。它必须确保沿途的 transit 和 egress 节点能够处理 NAS，并且封装后的包不能超过路径 MTU。计算路径的一方需要考虑这些节点的 MNA 能力和 Readable Label Depth。此类信息可以由配置、管理协议或控制协议传播获得，但 RFC 9994 并不规定获取机制。包内的动作指示不能替代对路径状态的了解。

范围规定处理位置，不保证处理事实

Format B 中的 IHS 字段为一个 NAS 中的全部动作设定共同范围。I2E 表示只有 egress 节点处理；HbH 表示路径上所有节点处理；Select 表示只有把 NAS 暴露到标签栈顶部的特定节点处理。一个包若需使用多种范围，必须带有多个 NAS。

这些定义很重要，但它们不是部署证明。HbH 不是“每一跳都已确认支持”的同义词；它是对能够处理 NAS 的相关节点提出的处理规则。Select 也没有自动回答哪些节点被选择、谁验证了它们的能力、选择在何时失效。范围写在标签里，不会替操作者完成能力发现，也不会把异构网络变成同构网络。

未知动作的 U 位把这一点说得更直接：节点不能识别某项动作时，应按该位跳至下一个动作，或丢弃该包。U 位是针对未知语义的处理选择，不是认证令牌、跨域授权、交付回执或执行证明。同一个 NAS 在不同节点上被处理、被跳过或被丢弃，都可能符合规范；仅从发出的包无法推导出其中哪一种已经发生。

RFC 9994 还明确了分工。encapsulating node 可以依据自己的策略、摆放约束和已学习到的能力添加 NAS；transit node 按规定顺序处理，并遵从未知动作规则；penultimate node 不能删除最后一个已暴露的 HbH 或 I2E NAS，以便 egress 继续处理；egress node 必须移除收到的 NAS。若有人声称“该 MPLS 动作已运行”，应逐层追问：哪个节点封装，路径怎样选择，哪些节点真正读取，未知动作怎样处理，egress 看见了什么。把这些问题压缩成一句“包已发送”，并不能形成证据。

附属数据也不能被当成中立载体。RFC 9994 指出，在依赖标签值做 ECMP 哈希的环境中，修改某些标签值位可能改变流量路径并造成同一流乱序。因此可变数据不得放在这些位置；规范给出替代放置方法，却没有承诺任何具体环境中的性能或规模结果。动作的正确编码，仍可能带来需要在本地验证的转发约束。

安全部分同样拒绝夸大。封装节点的动作可能影响路径中的节点；本地定义的动作监督有限；中间节点可能修改附属数据；跨不同管理域进入提供商 MPLS 域的 MNA 包，在部署前必须具备过滤能力。接收 MNA 包、处理 NAS、未知动作跳过或丢弃、格式错误等计数器值得记录，但它们不是一份自动产生的、可将某项意图与业务后果一一对应的执行账本。

Heng Lu 的 Running-Code Primacy 提供了合适的编辑视角：共同规范只应给出互操作所需的最小规则；之后的有效性来自本地可验证的实现、采用和证据。包内语法、已知能力、本地准入、节点处理、转发结果和服务效果属于不同现实层。把第一层误称为最后一层，会让标签承担它从未获得的权力。