摘要

  • IETF 于 2026 年 9 月 5 日发布 Traffic Steering using BGP FlowSpec with SR Policy 第 18 版。本文核查时，它仍是处于 AD Evaluation::External Party 的 Internet-Draft，并非已批准 RFC。
  • 第 17 版要求：含重定向目标、却缺少有效 Color 的指令，应回退到普通 Redirect-to-IP。第 18 版反转这一处理；只要报文表达了不完整的 SR 意图，支持新版的入口节点就不得普通重定向，而应丢弃匹配流量或执行本地故障策略。
  • 即使对应 SR Policy 已停止、无法解析或未装入 FIB/TCAM，语法有效的 FlowSpec 路由仍可保留在 Loc-RIB 并继续向下游通告。控制面“有路由”不等于数据面“按意图转发”。
  • 现版同时写明：不支持这项扩展的 headend 可以忽略不认识的 Prefix-SID，并按普通 Redirect-to-IP 行为处理。同一条更新在混合设备群里可能一处丢包、另一处重定向。
  • 早先的工作组最后征求意见针对第 13 版。第 17 版之后，负责的 Area Director 已要求 IDR 主席重新征询共识。新结果必须明确覆盖哪个版本、哪张故障矩阵以及哪一种兼容行为。

缺一个 Color，结果从绕行变成中断

FlowSpec 通过 BGP 分发报文匹配条件和相应动作。新草案把它与 Segment Routing Policy 接在一起：Redirect-to-IP 携带目标地址，Color Extended Community 携带颜色，两者组成选择 SR Policy 的 (Endpoint, Color)。在第二种 SRv6 模式下，Prefix-SID 还可携带出口服务 SID，要求尾端执行特定路由表查询或三层交叉连接。

因此，字段缺失并不只是格式不完整。只有 Redirect-to-IP、没有任何 SR 专用线索时，报文仍表示普通 IP 重定向。目标地址和有效 Color 同时存在时，它表示经某条 SR Policy 引导。若目标旁边带着 Prefix-SID，却没有有效 Color，就已经透露“想走 SR”，但缺少确定选择哪条 policy 的关键部分。

第 17 版对此采取宽松解释：忽略 Prefix-SID，回到普通 Redirect-to-IP。第 18 版则把它视为不应猜测的意图。支持新版的 headend 不得寻找默认或“空颜色”policy，不得使用出口服务属性，也不得假装报文从未表达 SR 意图。匹配流量必须被丢弃，或交给运营者预先声明的本地故障策略。

这不是“凡是没有 Color 都丢包”。纯粹、有效的 Redirect-to-IP 仍按原机制工作。新版约束的是既不像完整 SR 指令、又不再是纯重定向的中间状态。它试图避免业务悄悄走上一条不满足约束的路径，代价是可能把路径偏离变成显式中断。

路由还在，动作可以已经死掉

第 18 版更明确地拆开控制面和数据面。若对应 SR Policy 已 Down、无法解析或不能装入转发表，只要 FlowSpec 路由本身通过 BGP 校验，它仍必须留在 Loc-RIB，也应继续按正常 BGP 规则向下游传播。底层或 policy 故障不能单独使路由无效。

真正执行引导的条目却必须保持未激活或标为停止。即便 policy 本身正常，只要携带的出口服务 SID 在本机 RIB/FIB 中不可达，也不得静默改走目标的最短 IP 路径。草案把丢弃列为默认本地动作的“SHOULD”，同时允许运营者制定其他故障策略；限速、DSCP 标记等仍然有效的非引导动作继续执行。

这种分离让恢复更容易：policy 回来后，无须等待重新学习整条 FlowSpec 路由。但它也让一个常见验收办法失效。控制台显示“路由已接收”，只能证明第一步。可审计记录至少要拆成三项：Loc-RIB 是否接纳、FIB 是否安装引导、探测报文究竟被丢弃、重定向还是执行了别的本地动作。

草案要求实现提供失败原因、管理通知和字节/报文计数。若出现路由洪泛、快速抖动或资源耗尽，逐条日志可以被限速、汇总或暂时抑制，以免监控本身拖垮控制面。这个例外有合理性，也意味着“没有告警”不能证明“没有丢包”。抑制状态和汇总分母必须与告警数同时保存。

不支持新版的设备会走另一条分支

兼容性章节给出了最容易被忽略的结果：如果 headend 支持基础 FlowSpec 和 Redirect-to-IP，却不支持本草案，它会把可选传递的 Prefix-SID 当作不认识的属性。它可以继续传播该属性，在自己的转发决策中忽略它，并回到普通 Redirect-to-IP。

于是，完全相同的报文字节并不保证相同业务。第 18 版实现能识别“不完整 SR 意图”，因此拒绝回退；旧实现没有这个语义类别，看到的仍是一条有效重定向。这里不需要解析错误、BGP 会话中断或恶意篡改，只需要发送者不知道接收者支持到哪一版。

草案提出的防线是按邻居、按业务控制 SRv6 服务引导属性是否发送，并在管理边界过滤。它能缩小风险，却不会自动发现设备能力。运营者仍需维护接收端版本与功能清单，把兼容设备和旧设备分组启用；否则，一条更新能原样抵达所有节点，却在最后一步得到两种互斥的解释。

验收必须主动制造缺失。测试应分别向新版和旧版节点发送纯 Redirect-to-IP、完整 Mode 1、完整 Mode 2、缺失或损坏 Color 的组合；再令 policy 停止、服务 SID 不可达、FIB 资源不足。每个格子都应记录 Loc-RIB、下游通告、FIB、丢弃/重定向计数、探测流量、告警、日志抑制与恢复结果。只测成功引导，看不到这次修订真正改变的地方。

第 13 版的共识不能替第 18 版表态

Document shepherd 记录显示，此前 IDR 进行的是一次为期一周的短暂 WGLC，对象是第 13 版，并获得积极支持。随后，Area Director 审查推动文档加入两种运行模式、顺序化属性解析、更广的出口服务动作、失败处理、兼容规则以及更完整的运营和安全约束。

8 月 26 日，在第 17 版发布后，负责的 Area Director 明确要求 IDR 主席重新询问工作组，确认这些变化之后是否仍有共识；文档状态转为 External Party。9 月 5 日的第 18 版又进一步改变关键动作：不完整意图不再回到普通重定向，并增加服务 SID 不可达、替换或追加 SID、边界控制和可观测性细节。

重新征询不是多走一道形式。参与者可以支持 FlowSpec 与 SR Policy 对接的总目标，却反对某一条 fail-open 或 fail-closed 规则。承载安全缓解流量的网络可能更怕越过约束，另一类业务可能更怕可避免的中断。粗略共识要证明技术反对意见已经被理解并处理，不能让一个曾经写着“重定向”的版本自动授权后来写着“不得重定向”的版本。

因此，征询问题应明确指向第 18 版及其故障表：是否接受不完整 SR 意图禁止普通回退，是否接受路由保留而引导停止，谁决定本地故障策略，以及旧设备会如何处理。结束记录还应保留反对意见和主席判断理由，而不是只留下一个脱离版本的“有共识”。

2021 年的运行代码不能穿越到今天

实现状态章节列出四种路由器和四种控制器，称其在 2021 年 7 月至 10 月参加了 China Mobile 组织的多厂商互通测试；文档还称该机制自 2022 年 8 月起在 China Mobile 骨干网生产使用。这些材料有参考价值，但同一章节也明示：信息由贡献者提供，IETF 未投入精力独立核验，列出产品不构成背书。

日期还限定了证明力。所查资料没有说明 2021 年测试覆盖了第 18 版今天的故障矩阵、服务 SID 不可达分支、SID 替换/追加规则，或新旧 headend 混合运行。旧测试可以继续证明它当时实际测过的功能，却不能因为后来文档增加了句子，就自动获得新测试项目。

正确做法不是贬低旧经验，而是给它加版本。每条实现证据应注明草案版次、软件构建、启用功能、属性组合、负面用例、对端能力和报文实测结果。

给共识和转发各留一份收据

版本化共识收据首先固定第 18 版的源码哈希、征询起止、完整问题、回复归档、重大反对意见和主席判断。互通收据使用同一版次，逐项列出纯重定向、有效 Mode 1/2、Color 缺失或损坏、policy 停止、SID 不可达和安装失败。

每项都需要分别给出新版节点与旧节点的结果，并分开记录路由接纳、继续通告、转发动作安装和探测报文。丢弃、重定向、限速计数以及日志抑制状态补齐证据链。

部署部分再写清发送者、接收组、能力版本、边界过滤、获准 SID 范围、本地故障策略、重试/退避、金丝雀与回滚触发器。敏感地址可以稳定匿名化，版本与动作不能隐藏。纠错只能追加，不应覆盖第一次失败。

Heng Lu 的最小规范原则在这里仅作为编辑判断：共同语义应足够精简、确定且可验证；未来选择可以留给本地，但必须留下责任人和运行证据。标准不能替运营者决定哪一种损失可接受，运营者也不能用“本地选择”掩盖设备实际执行了什么。

第 18 版也许比第 17 版更安全。眼下最重要的不是抢先给它结论，而是让工作组同意当前这条规则，让运营者证明新旧设备在失败时分别做了什么，再决定是否让它获得标准的权威。

来源

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — 第 18 版正文
  3. IETF — 第 17 版正文
  4. IETF Author Tools — 第 17 版与第 18 版差异
  5. IETF Datatracker — 文档历史
  6. IDR 邮件列表 — 重新检查共识的请求
  7. IETF — Document shepherd write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification