摘要

  • Bruno Decraene 的公开 IETF 署名记录连接了四个彼此依赖却不能相互替代的环节：RFC 8402 规定 Segment Routing 的指令框架，RFC 8661 处理 SR-MPLS 与既有 LDP 环境的共存，RFC 9681 把 IS-IS 快速泛洪约束在接收端可承受的范围内，RFC 9855 则说明 TI-LFA 如何在正常收敛完成前提供局部修复。
  • 这些文件能够证明 Decraene 是协作式标准工作的共同作者，却不能证明他独自发明或控制了 Segment Routing、LDP、IS-IS、IETF 决策、厂商实现、运营商策略、实际部署或任何可量化的网络结果。规范描述的是接口与预期语义，采用情况和运行效果仍需实现与现场证据。
  • 对运营者最重要的不是把“更快”当成单一目标，而是让每次状态交接都可观察、可追溯、可撤销：指令必须有明确作用域，混合控制平面必须保留边界记录，泛洪速率必须尊重接收能力，本地修复必须有退出条件，最终仍要由收敛后的转发表与真实流量路径确认连续性。

从一份人物记录进入四个工程接口

Bruno Decraene 的 IETF Datatracker 人物档案提供的首先是一条可核验的公开署名线索，而不是一篇完整传记。沿着这条线索，可以看到他与多位作者共同参与了 Segment Routing 架构、SR-MPLS 与 LDP 互通、IS-IS 快速泛洪以及基于 Segment Routing 的拓扑无关快速重路由。这样的记录适合回答一个清晰问题：当网络在旧机制、新指令和故障状态之间切换时，哪些接口决定了连续性。

人物是观察窗口，协议才是分析对象。RFC 的署名能够把 Decraene 与具体技术问题直接联系起来，但署名并不把工作组共识、编辑职责、其他作者贡献、实现选择和部署责任集中到一个人身上。IETF 文件形成于协作过程；文档发布之后，厂商决定如何实现，运营商决定是否采用以及如何配置，运行中的设备则以实际状态给出最后检验。

因此，这篇文章不把 Decraene 塑造成掌控路由体系的单一人物，而是借助他的共同署名记录审视四类边界。第一类是指令边界：一个 segment 到底能表达什么。第二类是迁移边界：SR-MPLS 如何与 LDP 同时存在。第三类是传播边界：发送者希望更快时，接收者能否消化。第四类是修复边界：TI-LFA 的临时路径何时开始、何时结束，以及它与正常收敛后的转发是什么关系。

这四类边界之所以值得放在一起，是因为真实故障不会按文档章节依次发生。一个链路变化可能同时触发本地检测、保护路径启用、链路状态传播、路径重算、转发表更新和修复释放。任何环节都可能很快，也可能成为瓶颈。只有把它们放回同一时间轴，才能避免用某个机制的能力替代对整个系统的证明。

一条连续性链：指令、共存、传播与修复

RFC 8402、RFC 8661、RFC 9681 和 RFC 9855 可以被读成一条连续但分层的工程链。RFC 8402 提供路径指令的通用语言；RFC 8661 处理这种语言进入已有 MPLS 控制环境时的衔接；RFC 9681讨论拓扑变化如何更快抵达其他节点；RFC 9855则处理全网尚未完成正常收敛时，故障附近的节点怎样暂时绕开受保护资源。

链条在故障前就已经开始。segment 标识及其能力需要被分配、通告和正确理解；SR 与 LDP 的状态需要在混合区域中保持可辨认；拓扑数据库要足以支撑正常路径和修复路径的计算；转发平台也要能承载相应的指令序列。若这些先决状态含混，故障发生后再快的反应也可能只是快速执行了错误含义。

故障出现时，本地节点首先得到一个关于邻接、链路或相邻节点不可用的信号。预先计算的 TI-LFA 修复可以让受影响流量暂时避开被保护对象。与此同时，新的链路状态信息开始泛洪，远端节点接收并安装数据库变化，执行路径计算，再把结果写入转发表。正常转发可信之后，本地修复才应退出其临时角色。

这里没有任何一个环节可以代替另一个环节的证据。segment 标识存在，不等于对应邻接仍然可用；修复路径已经装入，不等于其他节点已经收敛；链路状态报文已经发出，不等于接收者完成处理；路由计算结束，也不等于硬件转发已经生效。连续性来自这些状态的正确衔接，而不是来自某个孤立的“已启用”标志。

把四份 RFC 视为有边界的接口，还有一个方法论收益：它迫使分析者区分“规范允许什么”“实现支持什么”“配置要求什么”和“现场发生了什么”。前者可以从标准文本查证，后面三项则必须分别依靠软件与硬件文档、运营策略、实时控制平面记录以及转发观测来回答。

RFC 8402：路径指令的力量来自明确作用域

RFC 8402《Segment Routing Architecture》于 2018 年 7 月发布。Clarence Filsfils 与 Stefano Previdi 担任编辑，Les Ginsberg、Bruno Decraene、Stephane Litkowski 和 Rob Shakir作为共同作者参与。这样的署名方式本身说明了归因边界：架构是多人协作成果，Decraene 的贡献应被准确承认，但不能被扩展为独自发明或独自决定 IETF 结论。

这份架构把路径表达为有序的 segment 指令列表。segment 可以关联节点、邻接、服务或域内定义的其他行为；头端选择指令序列，沿途节点执行自己能够识别的行为。这个模型给路径控制带来更明确的表达能力，却不意味着头端因此获得对所有网络的无限权力。它仍然受域、拓扑知识、节点能力、标识分配和运营策略约束。

“源路由”有时会被误解为一个中心能够替代分布式网络。RFC 所描述的更准确图景，是头端在既有拓扑与能力信息之上编码一条指令序列。IGP 仍可传播可达性和拓扑，节点仍可进行最短路径计算，沿途系统仍需正确理解标识。Segment Routing 改变了一部分状态的表示与放置位置，却没有让拓扑、策略、故障检测或转发验证消失。

因此，segment list 更像一份有时效、有范围的执行记录。它说明某一时刻、某一域内，数据包预期经历哪些处理。其有效性依赖标识在相应范围内是否唯一，所指行为是否存在，拓扑是否仍然准确，以及转发平台是否能够执行完整序列。若列表引用了过期邻接、不可用行为或超出平台能力的指令，再清晰的架构也不能把它自动变成可用路径。

这也是为什么 SR-MPLS 与 SRv6 虽可共享架构层面的推理，数据平面差异仍不能被一句“采用 Segment Routing”抹平。不同表示方式会带来不同的封装、处理和设备能力问题。本文所聚焦的后续共存与修复，主要围绕 SR-MPLS 的标签指令展开；它们不能被外推为所有 Segment Routing 形态在所有环境中的统一实施结论。

状态并未消失，而是换了位置和表达方式

Segment Routing 常被概括为减少中间节点上的某类按路径状态。这种表述只有在限定语境时才有意义。头端可能需要更完整的拓扑信息和策略逻辑，segment 标识需要分配与通告，转发设备需要处理指令栈，观测系统还要重建“预期指令序列”与“实际经过路径”之间的关系。状态不是凭空消失，而是重新分布。

这种重新分布改变了故障排查的重心。传统的目的前缀可达，并不足以证明数据包执行了预期的 segment 序列。运营团队还需要知道是谁生成了列表、列表基于哪个拓扑视图、每个标识在处理节点上意味着什么、设备是否支持相应行为，以及实际流量是否沿着可接受路径前进。

标识作用域尤其关键。一个数值只有在明确分配范围和处理上下文时才构成可靠指令。若两个系统对同一数值的来源、意义或有效期理解不同，设备完全按照各自实现执行，也可能把流量导向错误行为。准确的记录并不直接转发数据包，却为不同实现提供共同参照，使错误能够被定位而不是被归咎于笼统的“网络异常”。

安全与可管理性也来自这一边界。一个语法有效的指令列表，不等于它符合组织授权；能够到达某个节点，也不等于这条路径符合运营策略。授权、过滤、域边界和观测必须把抽象指令与当前配置连接起来。否则，路径表达能力越强，错误或未经允许的表达所能造成的影响也可能越大。

RFC 8402 因而不是部署成绩单。它给出架构词汇与预期语义，不证明任一厂商已经完整实现，也不证明任一运营商采用，更不证明实际网络获得了特定收敛、成本或安全结果。把规范视为接口，而非采用证明，是后续讨论共存、泛洪与修复的必要起点。

RFC 8661：迁移期不是脚注，而是一种真实架构

RFC 8661《Segment Routing MPLS Interworking with LDP》于 2019 年 12 月发布。Ahmed Bashandy 与 Clarence Filsfils 担任编辑，Stefano Previdi、Bruno Decraene 和 Stephane Litkowski 为共同作者。该文件属于标准轨道，讨论的并非一个完全空白的网络，而是 SR-MPLS 进入已经使用 LDP 的 MPLS 环境时，流量如何跨越两种控制方式的边界。

LDP 为转发等价类分发标签，长期以来被用于建立 MPLS 传输路径；SR-MPLS 也使用 MPLS 标签表示 segment，但标签含义来自 Segment Routing 的指令模型。两者可以共享数据平面，却通过不同控制机制赋予标签意义。共存问题因此不只是“旧协议是否还开着”，而是每个标签、前缀、边界节点和路径段由什么状态解释。

现实迁移通常无法在同一维护窗口内替换全部设备、软件与操作程序。能力会因节点、区域、厂商、版本和服务依赖而不同，混合状态可能持续相当长时间。RFC 8661 的价值正在于承认这一点：SR 能力的引入必须面对 LDP 仍然承担转发职责的区域，而不是把旧环境当成架构图之外的例外。

当流量跨越 SR 与 LDP 区域时，映射和通告关系需要保留语义。一个标签值并不是全球通用、脱离上下文即可解释的名称；它的意义取决于分配、作用域和处理它的节点。边界处理必须让 SR 侧的指令与 LDP 侧的转发状态衔接，否则数据包可能携带格式完全合法、运营含义却错误的标签栈。

这类互通规则提供了部署选项，却不保证迁移轻松，也不规定任何运营商必须采用何种顺序。它更不证明某个具体网络已经按文档方案运行。标准能够说明可互操作行为，实际成败仍取决于拓扑、能力、配置、测试和遥测是否显示流量在边界两侧按预期行进。

可逆共存比“最终形态”更能保护连续性

把混合网络称为“过渡态”，很容易让团队低估它的寿命和治理要求。硬件更新、软件发布、组织流程与客户服务各有节奏，SR-MPLS 和 LDP 可能长期并存。只要它们仍在共同承载业务，共存就应被当成需要完整设计、监控和演练的生产架构，而不是等待删除的临时注释。

首先需要的是边界清单。运营者应知道哪些节点具备 SR-MPLS 能力，哪些区域仍依赖 LDP，哪些前缀拥有相应 segment 标识，哪些服务跨越混合区域，以及映射从何处产生。用“全网已开启 SR”概括复杂能力分布，会掩盖真正可能发生语义断裂的位置。

其次需要映射的来源与时效。若一个前缀移动、标识发生变化或提供映射的组件不可用，团队必须知道哪些状态仍有效，哪些需要撤销，以及 SR 与 LDP 信息不一致时如何退回安全路径。看似完整但已经过期的映射，往往比明确缺失更危险，因为它会诱导系统继续执行。

再次需要可逆性。新路径产生意外行为时，团队应能沿着 segment 列表、边界节点、映射来源和 LDP 状态追溯原因，并恢复到已知安全的转发方式，而不是要求先完成整个迁移才能排错。回退能力不是对新架构缺乏信心，而是让新架构能够在证据不足时停止扩大影响。

RFC 8661 不能替运营者定义全部回退政策，却使一个原则清晰可见：连续性依赖共存规则，而不是依赖对旧机制迅速消失的愿望。迁移完成的判断也不应只看日历或配置数量，而应看新旧路径是否都可观察、边界是否可解释、异常是否可撤销。

RFC 9681：发送更快之前，先承认接收端的权利

RFC 9681《IS-IS Fast Flooding》于 2024 年 11 月发布，作者包括 Bruno Decraene、Les Ginsberg、Tony Li、Guillaume Solignac、Marek Karasek、Gunter Van de Velde 和 Tony Przygienda。它是一份实验性 RFC。这个状态不应被隐藏，也不等于工作缺乏价值；它明确划定了成熟度和证据范围，提醒采用者保留测试、平台限制与回退条件。

IS-IS 泛洪只是收敛链条中的一段。拓扑发生变化后，节点生成或更新链路状态信息并发送给邻居；邻居需要接收、校验、存储、确认并继续传播，之后还要执行路径计算与转发表编程。缩短信息抵达时间可能有帮助，但它不会自动缩短其余阶段，也不能让下游处理能力凭空增加。

接口带宽不能证明控制平面有同等处理能力。一个发送者可以很快发出报文，接收者却可能同时处理多个邻居的突发流量、更新数据库、生成确认、安排计算并保护其他协议任务。若队列溢出或处理落后，更高发送速率可能带来重传和额外争用，最终使“发得更多”与“有效推进更快”背道而驰。

RFC 9681 将约束放回接收者一侧，体现了一种重要的权力分配：发送者知道自己能多快地产生报文，接收者更接近自己在当前平台、负载与扇入条件下能够持续处理多少。速率与反馈机制应让这种能力可见，发送端则需要遵守最严格的适用边界，而不能把自身性能当成整个邻接关系的能力。

确认进度在这里具有证据意义。报文离开发送接口，只能证明发送动作发生；接收、处理到协议可以确认的程度，才说明状态传播取得了可观察进展。若监控只统计发包速率而忽略确认、重传、队列和数据库安装，就可能把高速输出误认成快速收敛。

快速泛洪优化的是一段时间，不是整个收敛结果

“更快泛洪”容易被传播成“更快恢复”，但两者之间隔着多个独立阶段。故障检测可能延迟，接收端处理可能拥塞，最短路径计算可能排队，转发表编程可能受平台限制，业务流量也可能在控制平面看似完成后仍未恢复。RFC 9681 能约束的是信息传播方法，不是对全链路结果的保证。

扇入场景进一步说明了为什么单邻接测试不足。一个邻居以某一速率发送可能完全安全，多个邻居同时向同一节点突发却可能超过接收能力。短时峰值与持续处理上限也不同：设备可以吸收一次突发，不代表它能够无限期维持相同速率。参数应被理解为随软件、负载、拓扑和平台变化的运营元数据，而不是设备的永恒属性。

因此，调整泛洪行为需要接收端证据。队列深度、处理速率、确认进度、重传、扇入、处理器负载和数据库安装时间，都比接口标称速率更接近问题。若确认停止推进或队列持续增长，降低发送强度可能比继续加速更有利于实际收敛。

实验性规范尤其要求把回退写进评估。团队需要知道在哪些节点启用、以什么参数启用、哪些指标表示接收端仍有余量、什么现象触发降速或关闭，以及关闭后如何验证状态恢复稳定。文档发布本身不是普遍适用性的证明；实现版本、设备平台和现场压力条件仍需要单独验证。

Decraene 的共同署名把他与这个工程问题直接联系起来，但不能说明他为任何网络选择过具体速率，也不能证明 RFC 9681 已被广泛采用或产生了量化收敛收益。恰当的结论是：这份协作文件把“速度”重新定义为受接收能力和反馈约束的操作选择。

RFC 9855：本地修复的任务是跨过收敛空档

RFC 9855《Topology Independent Fast Reroute Using Segment Routing》于 2025 年 10 月发布，作者为 Ahmed Bashandy、Stephane Litkowski、Clarence Filsfils、Pierre Francois、Bruno Decraene 和 Daniel Voyer。它是一份标准轨道 RFC，规定了使用 Segment Routing 的 TI-LFA 方法，但规范地位仍不能代替厂商支持、配置正确性、拓扑覆盖或现场效果的证据。

快速重路由所处理的是一个有限时间段。本地节点发现受保护链路、邻接或相邻节点发生故障时，网络其他位置可能还没有收到新拓扑，也没有完成路径重算和转发表更新。在这个空档中，受影响流量可能继续指向失效资源。预先计算的本地修复可以暂时改变转发，让流量绕开被保护对象。

执行修复的本地节点常被描述为本地修复点。它需要一条避开受保护资源、并能把流量送向可继续到达目的地位置的路径。Segment Routing 允许它通过 segment 序列表达这条临时绕行路径，无需要求每个中间节点都保存专属于该修复的状态。这是指令表达上的优势，却仍依赖沿途节点理解并执行相应 segment。

“拓扑无关”不能被读成“无需拓扑”。修复路径正是依据拓扑、保护目标和可用 segment 计算出来的。这个名称强调的是方法可以借助指令序列为广泛拓扑构造保护，而不是允许修复忽视实际连接关系。过期拓扑、错误保护对象或不可用指令，都可能让数学上成立的结果失去运营意义。

修复路径也不等于正常路由的新永久版本。它是故障前转发与正常收敛后转发之间的桥梁。好的修复不仅要避开失效资源，还要把流量引向与预期收敛结果兼容的位置。它是否成立，取决于当前拓扑、策略、segment 可用性和平台处理能力；它何时退出，则取决于正常状态何时真正可信。

修复路径必须带着退出条件出生

讨论快速重路由时，人们常把注意力集中在“多快切入”，却忽略“何时退出”。本地修复启动过慢，流量会继续撞向故障；启动过于敏感，短暂波动也可能触发不必要的切换。正常转发尚未稳定就过早释放修复，可能暴露不一致状态；修复保留过久，又可能让流量长期停留在绕行、容量更敏感或不符合最新策略的路径上。

因此，修复状态应当可观察。运营者需要知道哪些受保护资源和目的类别有有效修复，修复避开什么，使用哪组 segment，以及哪些位置没有覆盖。一个粗粒度的“TI-LFA 已开启”标志无法说明特定链路、特定目的或特定约束是否真的存在可执行方案。

平台能力也是硬边界。修复序列可能需要多个 segment，软件和硬件对可施加、可处理的指令深度存在限制。控制平面能够计算出路径，不代表转发平台就能按该表示执行。超出平台限制的修复必须在流量依赖它之前被明确暴露，而不能在故障发生后才以丢包形式出现。

修复还会与策略和算法选择相遇。局部绕行在拓扑上安全，不代表它自动符合所有端到端意图。若保护计算依据的允许路径与业务策略不同，局部正确可能产生全局不合意的结果。修复验证必须同时检查“避开了什么”和“经过了什么”，而不能只确认数据包离开了故障邻接。

RFC 9855 不证明零丢包、固定收敛时间、所有拓扑均有覆盖，也不证明任一厂商版本或运营商配置的具体行为。它给出方法和互操作语义。实际网络必须用故障注入、状态时间戳、转发表变化和流量观测，确定临时路径确实存在、确实可执行，并能在正确时点交还给正常转发。

把故障时间线拆开，才能知道“快”发生在哪里

一个可信的连续性分析，应把故障恢复拆成多个时间点。首先是物理或逻辑变化发生，其次是本地节点检测到变化，再次是修复路径被激活。与此同时，新的链路状态信息被产生、发送、确认和安装；节点随后完成路径计算，转发系统写入新结果；最终，业务流量在正常路径上稳定，本地修复被释放。

这些时间点不应被压成一个无法解释的“收敛时间”。如果恢复慢，团队需要分辨是检测迟、修复装入迟、泛洪受阻、接收处理积压、路径计算排队，还是转发表编程或业务恢复落后。若只保留一个总数，就算总数变好，也不知道改进来自哪里，更不知道下一种故障是否仍会受益。

四份 RFC 分别照亮这条时间线的不同部分。RFC 8402 帮助解释修复与正常路径使用的指令语义；RFC 8661 提醒路径可能跨越 SR 与 LDP 边界；RFC 9681约束拓扑变化传播；RFC 9855 则定义本地修复与正常收敛后路径之间的关系。它们不是一套保证书，而是一组可以组合检查的接口。

时间线还应连接到流量。控制平面通告、数据库安装和路由计算都可能显示正常，实际转发却因编程延迟、指令解释或平台资源而不同。反过来，业务探测短时可达，也不一定说明所有目的类别、保护对象和策略均已稳定。只有把协议事件、路由状态、转发表和流量观测关联起来，才能对连续性作出有限而可靠的判断。

这种拆分也能防止不当归因。某个 RFC 描述的机制即使被实现，也不能独自承担端到端结果；某位共同作者参与标准，也不能被视为对所有实现与部署结果负责。工程链越清楚，个人贡献、规范范围和现场责任就越容易各归其位。

面向运营者的证据矩阵：每个状态都要能被追问

在指令层，运营者应能够回答：segment 标识由何处分配，在哪个范围内唯一，哪些节点通告和理解它，列表基于哪个拓扑视图生成，平台是否能处理完整序列。验证不应止于配置存在，还要观察实际转发是否符合列表所表达的意图。

在共存层，需要回答：哪些节点属于 SR 区域，哪些仍依赖 LDP，前缀与 segment 的映射从何而来，跨边界服务经过哪些节点，信息不一致时以何种安全状态处理。映射变化应有时间和来源记录，使团队能区分当前事实与残留状态。

在传播层，需要回答：接收者在当前负载下能持续处理多快，多个邻居同时发送时是否出现扇入压力，确认是否持续推进，队列、重传和数据库安装是否稳定。发送速率是输入，接收与安装进度才是结果的一部分。

在修复层，需要回答：哪些资源得到保护，哪些目的具有有效修复，segment 序列避开什么，平台是否支持该深度，修复何时启用、何时释放，以及正常转发表在释放前是否已经可信。覆盖缺口应该明确显示为缺口，而不是被全局功能开关遮蔽。

最后是业务层：故障期间实际流量走了哪里，是否到达，延迟和损失如何变化，恢复是否与控制平面时间线一致。本文引用的 RFC 没有提供某个指定部署的量化结果，因此不能填入假定数字。证据矩阵的作用，是说明要证明结果还缺哪些现场数据，而不是用规范文本替代那些数据。

这套矩阵也适用于跨团队协作。架构人员负责预期语义，平台人员确认实现限制，运营人员决定拓扑与策略，观测人员关联控制和转发证据，变更负责人维护回退条件。任何团队都不应把自己掌握的一层记录，当作其他层已经通过的替代证明。

标识记录是参照，不是能够命令网络的权威

Segment Routing 的路径能力建立在标识纪律之上。segment 标识若发生冲突、通告过期或映射含混，即使每台设备都忠实执行本地状态，数据包仍可能完成错误指令。标识必须在适用范围内唯一、含义准确、变更可追溯，并带有足以发现异常修改的上下文。

这里的记录可能属于协议、网络域或具体实现，并不一定是全球编号资源体系。原则仍然一致：记录让独立实现拥有共同参照，却不会亲自把数据包送到目的地。它不能让失效邻接重新可用，不能让过载接收者处理得更快，也不能让不符合平台能力的修复序列变得可执行。

LDP 共存把这一点表现得最直观。标签值和转发等价类的意义依赖具体节点上的控制平面状态；SR 映射又建立前缀与 segment 标识之间的关系。运营者必须能说明映射来源、处理范围和当前有效性。只保存最终数值而丢失来源，会让故障排查失去语义。

TI-LFA 则增加了一类临时记录：修复列表来自某个拓扑快照和保护目标。拓扑、能力或策略变化后，旧修复可能不再合适。快速泛洪又引入速率与接收能力记录，它们会随软件版本、负载和邻接关系变化。所有这些状态都需要被当作当前运营事实，而不是一次配置后永久正确的静态资产。

最终优先级仍属于运行证据。记录告诉系统应该如何解释，运行代码与转发观测说明它实际上如何执行。二者不应互相排斥：没有记录，现场现象难以解释；没有运行证据，记录只能说明意图。连续性来自二者持续对账。

规范、实现、部署与结果之间必须保留四道隔离

第一道隔离在规范与实现之间。RFC 可以规定预期语义、消息与行为边界，却不能证明某个软件版本或硬件平台已经完整、正确地实现。实现文档、互操作测试和平台限制必须另行核验。把 RFC 编号当成功能可用证明，会让采购与变更决策建立在错误层级上。

第二道隔离在实现与部署之间。厂商支持某项能力，不代表运营者已经启用，也不代表配置符合本地拓扑、策略和风险条件。部署需要节点清单、边界设计、容量评估、回退计划与变更记录。本文证据没有列出采用这些机制的具体运营商，因此不能推断普遍部署。

第三道隔离在部署与结果之间。功能已启用，不证明故障期间一定减少丢包、缩短恢复或改善安全。实际结果受检测、拓扑、负载、接收处理、转发编程和流量分布影响，需要现场测试与遥测。引用 RFC 不能填补缺失的测量。

第四道隔离在个人署名与组织控制之间。Decraene 作为共同作者与这些工程问题有直接关系，但这不意味着他控制 IETF 共识、厂商路线、运营商政策或具体网络运行。RFC 8402、8661、9681 和 9855 均有多位作者，也经过更广泛的工作组过程。准确署名应当扩大对协作成果的理解，而不是制造个人英雄叙事。

保留这四道隔离并不会削弱文章，反而提高结论的可审计性。我们可以有把握地说，Decraene 的公开记录涵盖了四个连续性接口；也可以分析这些接口如何相互依赖。我们不能据此宣称采用范围、厂商行为或量化收益，这正是负责任技术写作应当明确的停止线。

现实层的判断：让当前转发状态高于口号

路由现代化最容易出现的偏差，是用目标架构的名称掩盖混合状态。“采用 Segment Routing”听起来像完成式，但实际网络可能仍包含 LDP 区域、能力差异、未覆盖的修复对象和受限的接收节点。治理应从当前运行状态出发，而不是从项目口号反推事实。

当前状态需要一组可以相互校验的记录：segment 与能力通告说明可用指令，SR 与 LDP 表项说明迁移如何呈现，故障事件说明本地节点何时改变模式，修复列表说明临时绕行意图，确认和数据库时间说明传播进度，路由与转发表说明正常收敛，流量观测说明用户可见结果。

这些记录之间没有任何一层天然高于现实。架构定义预期，记录保存身份与来源，实现生成可执行状态，运营者则把这些状态与数据包行为比较。若两者冲突，不能因为规范更优雅就忽略转发事实，也不能因为流量暂时可达就放弃追查错误标识或过期映射。

连续性还要求可逆。SR 与 LDP 的共存要有安全退路，快速泛洪要尊重接收容量并可降速，本地修复要有明确释放条件，路径指令要能追溯到当前拓扑。可逆性使团队能够在证据变化时缩小影响，而不必把一次架构选择包装成不可撤销的承诺。

四份 RFC 的共同价值，就在于它们没有把一个口号扩展成无限保证。指令有作用域，共存有边界，速度受接收者限制，修复是临时桥梁。Decraene 的人物记录因而呈现的不是对整个路由世界的控制，而是对这些边界的协作式技术参与。