摘要

  • RFC 9992 为 RIFT 的 Key/Value TIE 提供可互操作的键类型、标识符和可变值结构，却明确不应把这一通道用于 RIFT 自身分布式计算所依赖的拓扑信息。
  • 洪泛、目标受众、解析、选择、控制器采纳、RIB/FIB 写入和包到达，是不同层的事实，不能用一条成功日志替代。
  • 同键冲突时的确定性胜者用于避免僵持；它不证明该值最新、正确、获授权或已经在转发面生效。

RFC 9992 允许 KV TIE 的值服务于“任何可以想象的目的”。这不是让任意负载变成路由真相的许可。标准紧接着提醒：不要用它承载 RIFT 用于分布式计算的拓扑信息，否则可能出现收敛竞争、振荡或次优行为。

这条提醒应当直接改变治理问题。先问“谁定义这条键的语义、谁能发、谁能收、何时过期、下游允许做什么”，再问“字段是否合法”。Key Type、Key Identifier 和变量值形成了信封；相关标识为零是非法值，接收方必须丢弃并至少记录一次。Experimental、Well-Known 与 OUI 命名空间，以及必要的子类型，防止的是语义冲突，不是错误决策。

RFC 9692 的洪泛规则也不能被误读。未知 KV TIE 仍可正常传播。看到对象越过多台设备，只能说明字节被带走；不能说明每台设备理解了它，更不能说明每台设备批准了某项策略。一个节点可以不知道；另一个可以知道却忽略；第三个可以仅作可观测性用途。传播与采纳之间，应留下明确的本地准入记录。

Key Target 同样不是命令。它是 southbound 的可选目标标识，说明哪些节点被期望接收。不会处理 Key Target 的节点仍按规则发送相应 KV TIE。因而“写了目标”“目标范围内的节点见过”“节点依据它采取行动”必须分别证明。

故障时更容易看见这一差别。若多个 northbound 邻居送来同一键、不同值，RIFT 只能选一个。RFC 9992 建议各节点独立而一致地确定值；否则两个 ToF 分裂时，按较高 System ID 的选择可能产生意外效果。确定性让系统继续运行，却没有裁决哪一边描述了现实。审计必须保留双方的 System ID、方向、目标、寿命、值指纹、选择时刻与被拒原因，而不是只保留“成功”。

IANA 的 RIFT 注册表 以及专家审查负责公共命名空间。注册号能减少碰撞，也要求支持材料说明语义和模型；它不能替本地运营者授权一个动作。RFC 9719 的管理模型也不会把意图配置、已见 TIE、已选值、计算路由、硬件 FIB 和探测结果合成为一条证据。

衡路的“运行代码优先”和“现实层”在这里是公开的编辑分析框架：共同规范应尽量小；未来决定留给实际承担后果的一方。只有运行中的来源、协议轨迹、本地策略、控制面、转发面和探测共同出现，才能说明一条键值真的改变了网络。