摘要

  • RFC 9617 定义了用于启用 IOAM、把 profile 绑定到流量过滤器、承载协议和可选功能的 YANG 模型；它规范配置意图，不提供端到端观察结论。
  • 报文仍需实际命中转发动作是 accept 的 ACE，完成封装，经过参与节点，在长度和能力边界内产生数据，并由带内或直接导出链路送达证据接收端。
  • 可靠运维要分别保存活动 datastore、报文选择、封装、逐节点贡献、导出序列、采集保管、分析判断、授权动作和服务结果的凭证。

绿色来自控制器，不来自报文

控制器读取活动 datastore，发现 admin-config/enabled 为 true。目标 profile 存在，过滤器指向预期 ACE，protocol-type 选择 IPv6，所需 trace 分支也出现在设备宣告的 feature 中。配置界面显示绿色并没有错。

但一个业务报文随后穿过网络，却没有留下预期记录。绿色状态无法解释它是否命中 ACE、是否被更早的 ACL 规则截获、是否从目标接口进入、入口是否真正插入选项、沿途节点是否支持所需字段、预分配空间是否耗尽，或导出记录是否在采集前丢失。

RFC 9617 的价值正是让配置变得清晰。风险来自把这种清晰扩大成观察事实。模型实例说明系统被要求且可能做什么；数据平面才说明某个报文实际经历了什么。

YANG 树是控制面，不是抓包

ietf-ioam 遵循 NMDA，提供只读信息、系统级管理开关和命名 profile 列表。每个 profile 可以组合过滤器、承载协议，以及增量 trace、预分配 trace、直接导出、Proof of Transit 或端到端子 profile。

类型、identity、接口引用、ACL 引用和 feature 能够拒绝不合法配置。通过 schema 校验证明实例符合模型；feature 存在证明实现宣告支持；从活动 datastore 读回证明值当前存放在那里。

这三张凭证都有用，却没有一张是具体报文。它们不包含节点写入，不包含导出传输，也不包含采集器接收。语法和结构越精确，越需要把执行层边界写清楚。

enabled=true 是必要条件，不是历史结论

规范说明，管理开关为 true 时，系统启用 IOAM 配置和数据平面功能。这并不意味着所有报文都携带 IOAM。profile、过滤器、接口、协议和节点角色继续限制适用范围。

当前读回也不能证明某个历史报文经过时开关已经为 true。要作出这样的判断，系统必须保存配置 epoch，并把它与封装或导出时间关联。今天的活动状态不会自动成为昨天的事实。

因此，启用状态只是允许相应行为发生。执行凭证还要明确哪个流量、哪版配置、哪个事件实际调用了这项能力。

ACE 是配置意图接触报文的关节

profile 可以引用 ACL 中的 ACE。RFC 9617 还规定：只有匹配 ACE 的 forwarding 动作为 accept 时，接受的报文才应驱动 IOAM 动作。

这使“引用了某条 ACE”和“报文命中了某条 ACE”成为两回事。ACL 顺序、接口、方向、地址族和实现行为都会影响结果。更早规则可能先决定报文；报文也可能完全不匹配；同名 ACE 还可能属于另一版策略。

取证需要保存活动 ACL revision、ACE 身份、接口与方向、报文选择字段、匹配结果、forwarding 动作和配置 epoch。“profile 指向 ACE-7”是设计；“此报文在 revision X 下命中 ACE-7 并触发 IOAM”才是执行。

承载协议名称不等于观察到的封装

protocol-type 表示 IOAM 数据要嵌入哪个层和协议，例如 IPv6 或 NSH。这个抽象使不同设备可以共享对承载方式的表达。

datastore 中的 IPv6 值并不能证明某个报文实际带有 IPv6 IOAM 选项。报文可能从另一个入口进入，外层可能被隧道改变，尺寸政策可能阻止插入，下游节点也可能不识别该选项。

配置凭证必须与入口观察相连：原始报文身份、命中的 profile、封装动作、生成的选项类型与大小、namespace、trace-type 以及可用的关联值。缺少这条连接，模型只描述了证据应从哪里出现。

支持某 feature 仍可能得到残缺 trace

增量和预分配 trace profile 会选择节点动作、namespace、trace 类型和最大长度。两种分配方法不同，但都依赖实际节点参与并提供所需信息。

feature 宣告是本地事实。一台设备支持增量 trace，不代表路径上每台设备都支持。节点可能无法提供某个字段，预分配空间也可能限制 node-data 条目数。因此，记录中出现四个节点并不能单独证明路径只有四跳。

缺少节点可能意味着路径绕开、能力缺失、未参与、空间耗尽、选项被移除、导出丢失或解码失败。RFC 9617 配置机制，但不会替观察者把这些原因压成一个结论。

直接导出增加了另一条证据链

直接导出 profile 可以提供 flow-id，并选择是否启用序列号。flow-id 帮助关联同一流的记录；序列号能暴露部分缺口。

它们都不能保证完整性。采集器可能在首批记录之后才启动，于是丢失前缀不会形成序列跳号。重启和回绕需要 epoch。记录可能已生成却在网络或队列中丢失。多个导出器还可能各自使用局部序列空间。

导出凭证应包括导出器身份、启动或配置 epoch、flow-id 作用域、序列规则、发送时间、传输结果、采集时间、解码和保留状态。只有这样，一个缺号才能支持有边界的丢失判断。

“Proof of Transit” 分支不会自动产生证明

RFC 9617 只为 POT 定义基础类型，具体变体需要扩展模块。配置树中存在该分支，不会凭名称创造密码学或运行证明。

端到端 profile 同样只是配置由封装节点加入、由解封装节点解释的数据。它不能证明两个端点处理了同一个报文，更不能证明中间服务成功。

这也保留了与现有 IOAM 完整性研究的边界。ICV 验证回答受保护字段在特定方法下是否被检测到修改；RFC 9617 回答 IOAM 行为如何被配置。两种答案都不能替代对方。

建立能够诚实失败的凭证阶梯

第一层是活动配置：模块 revision、datastore、feature、接口、profile、ACL、协议和子 profile 字段。第二层是选择：报文确实命中预期 ACE 并被接受。第三层是执行：入口真正插入或触发了配置的选项。

随后才是逐节点贡献、长度与能力限制、直接导出、采集接收、解码和保留。分析形成判断后，控制器若要据此改变网络，还需动作授权、安装确认和结果观察。

不能让一个绿色状态冒充整座阶梯。RFC 9617 把第一层变成可互操作协议；运行事实来自后续每一层独立留下的收据。

来源