摘要

  • 理解新机制的节点保护汇合点收到 Conditional PathTear 后，必须保留对应状态；不具备该角色的接收者则可能必须删除，并向下游发送普通拆除消息。
  • Remote PathTear 提供独立的显式清理通道，让局部修复点无需等候备用路径信令完成，就能通知汇合点删除过时状态。
  • 能力协商并非装饰。错误宣告支持，既可能造成状态长期滞留，也可能让本应保留的预约被提前拆除。

先问留下的理由

故障之后，一台路由器删掉了状态，另一台保留了同一标签交换路径的状态。只看状态数量，后者像是清理不彻底；只看拆除消息计数，前者像是执行得更干净。这两种判断都可能错。

2025 年 3 月发布的标准轨道文件 RFC 9705 规定了一类必须保留的情况：收到 Conditional PathTear 的接收节点，如果是具备兼容能力的节点保护汇合点，就不能立即删除该路径的状态。这不是实际事故的复盘，而是规范明确处理的生命周期分歧。

旧的 RFC 4090 设施备份机制依赖刷新超时来收拾部分残留。等待时间短，备用路径信令还未到达，普通拆除消息就可能先破坏汇合点所需的状态；等待时间长，已经失去用途的状态又可能久留。RFC 9705 的增量在这里：让节点依据明确事件和保护角色决定去留，而不是让一个计时器代替这项判断。

汇合点不是设备的永久身份

RSVP 的标签交换路径称为 LSP。PSB 保存路径状态，RSB 保存预约状态。局部修复点 PLR 把受保护路径引向旁路，汇合点 MP 则是保护安排接回后续路径的位置。

这些角色针对具体 LSP 成立。链路保护汇合点 LP-MP 对应前一跳的保护；节点保护汇合点 NP-MP 对应前两跳绕过中间节点的保护。同一台路由器可以对一条路径同时具有两种角色，也可以对另一条路径都没有。

角色还必须有信令依据。路径消息中的 B-SFRR-Ready 关联要把本机标为旁路目的地；本机与指定 PLR 之间须有正常工作的 Node-ID 信令邻接；对方还须宣告相应的 RI-RSVP 能力。关联及其匹配规则来自 RFC 8796。仅支持汇总 FRR，不等于已经实现 RFC 9705 的状态清理。

因此，一张规划拓扑图、一个配置标签，或者“这里应当是汇合点”的推测，都不能独立赋予接收者保留状态的资格。决定消息含义的关系必须在故障前成立。

同一条消息，两个合法结果

规范用 A—B—C—D 的路径说明问题：A 的旁路绕过 B，在 C 汇合，所以 C 是 A 的 NP-MP。A—B 链路失效时，如果 B 不是这条 LSP 的汇合点，B 删除自己的 PSB 和 RSB。在入口请求了节点保护、且 B 没有收到上游 PathTear 的条件下，B 向 C 发送 Conditional PathTear。

C 的正确动作是保留。相反，一个不是 NP-MP 的接收者必须删除 PSB、RSB，去掉可选的 CONDITIONS 对象，再向下游发送普通 PathTear。条件不能不加判断地一路传递。

还有一项容易被忽略的限制：如果消息来自没有宣告支持这些程序的邻居，即使携带条件对象，也要按普通 PathTear 处理，删除并继续传递。条件对象不是绕过能力协商的通行证。

CONDITIONS 使用类号 135、C-Type 1；其中的汇合点标志置位才启用条件处理，未置位则按普通拆除处理。简短的字段说明不能替代具体规则：RFC 9705 第 4.4.2 节保留的是 NP-MP，不是所有被笼统称为 MP 的节点。

保住路径，不等于保住旧角色

继续看 A—B 的故障。假如 B 之前还宣告过由 D 汇合的节点保护，B 删除本地状态后，这项保护关系就失去了原来的依据。C 虽然要替 A 保留 LSP，却不能继续向 D 传达“B 仍能保护你”的旧信息。

C 删除路径消息中属于 B 的 B-SFRR-Ready 关联，并触发新的 Path 消息。D 据此删除对应 B 的远端路径状态。如果变化仅仅是这一关联被移除，D 不再把该 Path 向后传播。这里发生的是两种不同动作：C 保留受保护路径，D 撤下过时的保护者关联。

远端路径状态本身是为了匹配后续显式清理而建立的信令记录，其中 RSVP_HOP 使用 PLR 的 Node-ID 信令地址。它不是额外的一份客户预约。删除这个记录，不能一概写成“受保护路径的 PSB、RSB 已被删除”。

保留也有明确终点。LP-MP 在前一跳链路失效、但相应 PLR 邻接仍存活时可保留；前一跳节点失效则须普通拆除。NP-MP 可以跨过中间链路或节点的失效保留状态，直到更远的 PLR 邻接失效，或收到相应的普通、远端路径拆除及预约拆除事件。兼具两种角色时，前一跳链路故障后失去其中一条邻接，不一定足以结束保留。判断邻接失效还须尊重优雅重启的宽限期，不能把单次 Hello 缺失直接当成清空理由。

不等备用信令完成，也要能撤销

Conditional PathTear 避免过早删除；Remote PathTear 则解决不该再等的问题。入口收到管理指令，要撤销一条正在局部修复的 LSP，备用路径信令却尚未完成。若 PLR 只删除自己的状态，汇合点可能继续等待一项已经取消的修复。

PLR 因此可以直接向汇合点的 Node-ID 地址发送 Remote PathTear，以既有信令邻接身份匹配远端记录。消息使用 TTL 255，不要求旁路已经可用，也不要求备用信令已完成。PLR 删除本地状态，汇合点再删除相应 PSB、RSB。局部修复失败时也要发出这类远端拆除；汇合点处理后，把清理向出口方向继续推进。

路径变化也能触发这项责任。如果新的 Resv 路由记录 RRO 不再包含原先的 NP-MP，PLR 要直接通知那个旧汇合点。规范示例中，B 已经完成通往 D 的备用信令，A 随后清理旧汇合点 C；C 再向 D 发送普通拆除，但 D 保留由 B 已完成的备用信令支撑的状态。因此，远端拆除不是“下游所有状态都必须消失”的总命令。

抢占会改变另一条时间线。前一跳链路已经失效、备用信令尚未来到时，汇合点若失去预约，就要普通拆除并清理状态。规范描述了随后到来的备用 Path 因所需状态已不存在而被拒绝的情况。这是要验证的处理顺序，不是对某家产品已发生缺陷的指控。

错报能力，可能向两个方向出错

RFC 8370 通过可靠信令、确认及邻接失效检测，降低对短刷新周期的依赖；RFC 2961 提供可靠消息交付基础。RFC 9705 补上设施保护中的清理环节。使用设施备份的实现，只有支持新文件全部扩展，才可以宣告 RI-RSVP 能力。

误报并不只有一种表现。不能执行新程序的 B 若宣告支持，可能不发送所需条件或远端拆除，留下长期滞留的状态；同样不能执行新程序的 C 若宣告支持，则可能忽略条件对象，把消息当普通拆除，毁掉本应存活的路径。前者看起来是清得太慢，后者却是清得太快。

正确的混合部署有意回退。下游节点缺乏支持，要缩短 Path 中的刷新周期，并停止向该段发送新的条件或远端拆除；上游缺乏支持，则调整相关 Resv 刷新值，在部分情况下也调整 Path，并停用新的汇合点保留规则。节点保护还要求中间节点支持，不能只检查旁路两端。同一台设备对同一条 LSP 的上游和下游，可能合法地执行不同模式。

这些来源说明了标准要求，没有给出产品普及率、清理时延或服务结果。值得记录的不是单独一个“拆除已到达”，而是它在当时那个角色上按规范触发了什么动作。

来源