摘要

  • RFC 9502 所定义的是前缀与 IP Flexible Algorithm 的可达性关联；它并没有证明某个数据流走过某条路径。
  • 最可审计的做法不是写一条“已启用”状态，而是分别保存 FAD、各 IP 平面的参与状态、局部计算和 FIB 安装的证据。

一次网络变更最容易失真的时刻，往往不是设备报错，而是报告太早宣布成功。工程师把一个 IPv6 前缀和某个 Flex-Algorithm 标识符关联；管理层看到“算法已发布”；业务团队随即把它理解为“关键流量已迁移”。从第一句到最后一句，每一步都可能合理，却没有任何一步自动推出下一步。

RFC 9502 的价值，正是把这种不自动推出写进协议边界。它扩展 IGP Flexible Algorithm 的工作，使 IPv4、IPv6 前缀可在特定算法下表达可达性。该 RFC 不是一个端到端业务交付协议，也不是一张“流量轨迹收据”。它处理的是控制平面在满足条件时如何得出特定算法的前缀路径，并说明哪些节点可参加，哪些节点必须被剪除。

先看定义。Flexible Algorithm Definition（FAD）并不是一个任意标签。根据 RFC 9350，参与节点需要对定义达成一致；若一个节点无法接受、无法支持或发现定义无效，它会停止对该算法的参与。于是，仪表盘上“129 已配置”并不表示整个域内每一台设备都在同一语义下工作。它只说明某处存在编号和配置。对审计而言，关键问题是：哪些节点看到同一份定义，哪一版定义被接受，何时发生过拒绝或撤回？

再看参与。RFC 9502 不是把“加入算法”视作一个对全协议栈不可分割的开关。IPv4 与 IPv6 是各自的数据平面。一个节点可以在其中一个平面参与而在另一个平面不参与；一个域也可能对两个地址族形成不同的可用范围。把它们压缩为“网络使用 Flex-Algorithm 129”会抹掉实际运行中最值得关注的差异。编号相同，不代表作用相同；同一台设备，也不必然在两个平面交付相同的结果。

第三本账是计算。前缀公告进入的是与算法相关的 SPF 或约束计算，不是一条直接写入转发表的命令。算法定义中的度量、亲和性、管理员纳入或排除的链路、拓扑视图和局部策略都会改变结果。前缀被看见，不等于它在该算法下可达；被判为可达，不等于它是本节点的优选；成为候选，也不等于它最终被安装。RFC 9502 对参与节点被剪除的描述很重要：没有参与的节点不只是“缺少一个指标”，它们不应被视为这个算法计算的一部分。

第四本账是 FIB。RFC 9502 明确将参与者的算法路径落实为转发表条目，同时限制同一个 IP 数据平面对同一前缀只使用一个算法路径。这一点经常被营销语言遮蔽：多了一个算法号，并不自动多了一条同时生产使用的路径。对一个具体路由器，最终仍有一次选择。要说明“发生了什么”，必须显示该路由器、该表、该时间点、该前缀和安装原因；仅展示控制平面中的候选或配置文本并不够。

协议还给出了一个很有价值的负面证据规则。若同一前缀带着冲突的算法信息，相关信息应被忽略，路径不应被安装。许多运营报告把“没有 FIB”视为监控缺口，随后用配置截图填补空白。这里恰恰相反：没有安装可能是协议按设计拒绝一条不可靠推论的结果。把“不安装”列为可解释状态，比强行给出“已生效”的绿灯更有用。

因此，负责变更的人不应要求一份笼统的“Flex-Algorithm 正常”证明，而应要求四份相互不能替代的记录。第一份是 FAD 记录：算法号、约束、版本、发布者和已知的一致性。第二份是参与记录：按节点、按 IPv4/IPv6 列出进入、退出或不支持。第三份是计算记录：目的前缀、采样时间、合格路径与排除理由。第四份是转发与观测记录：FIB、接口计数器、合成探针或流量样本，以及测量窗口。若还要宣称业务可用，就应另加业务层 SLO 与用户路径证据。

这四本账不是繁文缛节，而是避免责任错位的最小结构。网络架构师负责算法意图与 FAD；平台团队负责设备能力与编排；NOC 负责计算和 FIB 的现场状态；业务运营负责服务体验。任何一方都不应被一行状态文本迫使为另一个层级的事实背书。越接近关键业务，越不能把“可配置”写成“已兑现”。

IANA 的 IGP Parameters 注册表 让算法编号处于公共可查的命名空间，其中 128 到 255 为 Flexible Algorithms 预留。登记一个号码有助于互操作和避免编号冲突，却不会验证拓扑、能力、配置一致性或包的实际经过。命名空间是治理的输入，不是运营结果的输出。

Heng Lu 在关于最小初始规范的论述中提出，一个能让未来决策定位的机制，不会替未来决策本身作答。放到此处，这意味着 FAD 把“允许按什么约束计算”界定出来，并不替每台路由器作出接受、参与或安装的决定。阅读 RFC 9502 时，正该保留这些局部选择，而不是把它们涂成中央命令已经完成的幻象。

另一篇关于运行代码与原始设计的文章也提醒，某项代码已经运行，不会自动使它在未经同意的范围内取得正当性。反过来，一条 FIB 已经安装，也不自动成为业务承诺的证据。它是很强的局部转发证据，强到足以解释一个节点的决定；但它没有观察到用户体验、跨域路径或应用失败。证据必须与主张同层，不能借邻近事实向上跳跃。

规范性词语的边界同样值得保留。RFC 8174 规定如何理解 MUST、SHOULD 等术语。它帮助读者区分协议要求和实现选择，不能把未观测的数据平面状态补写进报告。一张“均为绿色”的幻灯片若没有说明 green 指的是定义、参与、计算、FIB 还是探针，就没有提供足够的信息来支持高后果决定。

更成熟的变更复盘也应把失败路径写进去：哪个节点因定义不一致没有参与？哪个地址族没有可用路径？哪个前缀因为冲突而未安装？哪个变更窗口中 FIB 已就绪却探针未成功？这些不是对工程的否定，而是将故障域和决策权交代清楚。它们使下一次扩展不必靠记忆和口头解释。

Leadership Alliance 的读者真正需要的不是更简化的路由术语，而是能防止层级串用的问法。应先问“你要证明哪一个层级？”再决定要哪一种记录。只有在答案明确为“定义已一致”“某地址族已参与”“某节点已安装”或“某测量窗口内流量被观察到”时，证据才会匹配问题。RFC 9502 提供的并不是一条万能路径，而是一条避免把设计承诺误报为交付事实的清晰边界。