摘要

  • RFC 9791 第 2.1 节把 NFFRR 描述为 MNA 用例：第一次 FRR 后给数据包做标记，以阻止可能造成环路的再次 FRR；它是 2025 年 7 月发布的 Informational 文档，不是完整动作定义。
  • NFFRR 的治理含义比“一个比特”更大：第一处本地修复点实际上获得了委托否决权，它把“第二次修复也许能成功”与“第二次修复可能形成环路”之间的风险判断传给下游。
  • 截至 2026-09-20，IANA 的 Network Action Flags Without Ancillary Data 注册表没有 NFFRR；两份 NFFRR Internet-Draft 都已过期，TBA 位、信令方案和动作语义不能当成现行分配，更不能当成部署证据。
  • 现有来源不证明已测量事故、厂商实现、互操作性、普及率或量化效果。可审计性因此必须与机制讨论分开：标准文本说明“为什么需要”，并不等于运行网络已经证明“怎样做最优”。

从“救包”到“禁止再救”

RFC 4090 把 RSVP-TE FRR 建立在预计算的局部备份上，RFC 5286 与 RFC 7490 又把 LFA 和 Remote LFA 的安全性明确系于拓扑与故障模型：保护的是某类失败，超出假设的并发或更广故障可能重新引入环路。2025 年的 RFC 9855 继续发展 TI-LFA，但同样区分局部失败保护与其他收敛问题。

因此，NFFRR 不是对 FRR 的否定，而是给 FRR 加“停止条件”。RFC 9791 第 2.1 节只提出用例：一个包已经被 FRR 改道后，再次 FRR 可能让它在激活保护的 LSR 之间循环，造成链路拥塞与额外丢包。它没有给 NFFRR 分配最终动作编码，也没有定义完整信令、鉴权、过期或部署流程。

这正是责任边界出现的地方。第一 PLR 一旦给包附上“不要再 FRR”的含义，下游就不再只根据自己的局部故障视图行动。它必须尊重上游关于“再修一次更危险”的判断。换言之，标记不是单纯状态，而是一项委托：上游把对后续修复的否决权带进了数据平面。

谁可以牺牲第二次交付机会

这种否决只有在假设可说明时才站得住。至少有四层前提。

第一是拓扑假设：第一 PLR 必须有理由相信后续可见的失败与自己观察到的失败相关，或第二次修复会把流量送回已走过的保护域。EVPN 示例成立，正因为一个 CE 故障在 PE2、PE3 两侧表现成两个局部接入失败。

第二是故障模型：链路故障、节点故障、SRLG、CE 故障或多个独立故障不能被混为一谈。RFC 5286 已说明，超出替代路径原先保护范围的失败可能造成临时环路。若第二个失败其实独立且存在安全出口，禁止第二次 FRR 就可能把可交付流量提前丢弃。

第三是能力假设。RFC 9789 要求运营者知道哪些节点支持哪些 MNA，并确保相关能力被信令；可读标签深度也是硬件能力的一部分。混合能力路径上，“我插入了标记”不能自动推出“所有下游都能读、会读、按同一语义处理”。

第四是信任假设。RFC 5920 对 MPLS/GMPLS 的安全框架强调转发平面并非天然可信；RFC 9789 也指出应防止网络处理来自域外的 MPLS 标签。过期的 draft-kompella-mpls-nffrr-04 更直接警告：恶意或被控制的 LSR 可以插入 NFFRR，使本来可能成功的保护不启动，制造不必要丢包。一个假标记因此不是普通格式错误，而是伪造的否决授权。

新编码并没有替 NFFRR 完成标准化

RFC 9994 于 2026 年 6 月以 Proposed Standard 发布，规定 MNA 通用栈内子栈、作用域、动作顺序和未知动作处理。对不认识的网络动作，U=0 表示跳到下一个动作；U=1 表示丢弃数据包，并应维护本地计数器，还可以限速通知运营者。它也规定 I2E、Hop-by-Hop 和 Select 等作用域。

但 RFC 9994 没有定义 NFFRR。当前 IANA “Network Action Flags Without Ancillary Data” 注册表仍为空，因此不能把历史草案里的建议位号、TBA 值或 SPL 建议映射成现行 NFFRR。draft-kompella-mpls-nffrr-04 已于 2024 年 4 月过期；draft-li-mpls-mna-nffrr-01 早在 2023 年 4 月过期，其中 NFFRR 的 Network Action Indication 仍写作 TBA1。机制设想、信令草案与实际分配之间必须保持这条证据线。

这也让错误状态更复杂：缺失标记可能让第二次 FRR 继续发生；错误标记可能阻断本来安全的修复；过期标记可能基于旧拓扑、旧能力或旧故障关联继续生效；伪造标记把攻击者的意图伪装成第一 PLR 的风险判断；误读标记则可能来自作用域、栈位置或能力理解不一致。混合能力节点再叠加 U 位行为，结果可能从“忽略”一路跨到“丢弃”，而不是单一失败模式。

Daniel Kade 的编辑建议：建立“FRR 克制凭证”

下面不是 RFC 要求，而是 Daniel Kade 的编辑建议：凡是采用“第一次修复可以压制第二次修复”这一治理逻辑的网络，都应把决定留成一张可复核的 FRR 克制凭证。至少记录：

  • 服务类别；第一次与第二次故障观察；第一 PLR 与其修复方法；
  • 拓扑版本与故障模型；动作身份、作用域、插入点与栈位置；
  • 预期节点能力证据，包括 MNA 支持、可读深度以及能力信令来源；
  • 边界来源与入口过滤，说明哪些节点或域被允许创建、保留或清除该标记；
  • 下游识别结果与最终处置，是继续转发、跳过未知动作、丢弃还是其他已定义结果；
  • 相关计数器、拥塞与丢包观察；策略责任人，以及复审和过期触发器。

这张凭证的价值不在于增加文档，而在于把“主动丢包是为了保护共享容量”从口号变成可质询的因果链。若环路会持续占用保护链路并扩大损失，克制可能保护更多流量；若第二次 FRR 本可成功，克制就是对单个流的主动牺牲。没有故障关联、能力证明与处置证据，就无法判断是哪一种。

来源