摘要

  • 携带 ERO 的成功 PCRep，只证明 PCE 在特定 TED 快照、约束、目标函数和政策视图下找到了一条可行路径；它没有证明 PCC 接受，也没有证明设备安装。
  • 后续每一层都需要自己的回执：信令或编程、资源预留、RIB/FIB、PCC 状态报告、数据面遥测，最后才是服务与 SLA 结果。

屏幕上的绿色往往来得太早。

一个路径计算客户端向 PCE 发出请求，几毫秒或几秒之后收到正向 PCRep。响应里有 Explicit Route Object，沿途节点排列整齐，成本也符合预期。控制器把它画成一条线，于是“路径已经有了”很容易被口语化成“网络已经按它转发”。

但此时得到的只是计算答案。设备是否接受、是否执行信令、资源是否仍可用、表项是否落入 FIB、数据包是否真的走过这些节点，都还是后面的问题。

RFC 4655 的价值，正是给这些问题划了边界。该文由 Adrian Farrel、Jean-Philippe Vasseur 与 Jerry Ash 合著，并由 IETF PCE 工作组推进。它把 PCE 定义为一种基于网络图、施加计算约束后求得路径或路由的实体。这里没有承诺“中央计算等于网络现实”；相反，架构图把 TED、计算、政策与信令分成不同功能。

计算答案首先属于一份快照

PCE 面对的不是抽象而永恒的网络，而是 Traffic Engineering Database。TED 汇集某个域里的拓扑与资源信息，来源可能是 IGP 扩展，也可能是带外同步或其他机制。

这意味着所有答案都带有时间性。链路带宽、故障状态、维护窗口和预留资源可能在计算之后发生变化。RFC 4655 甚至明确指出，带外或批量同步可能降低 TED 与网络状态的一致性，使计算路径更容易失败或变得次优。所谓“可行”，准确说是“相对于计算时可见的那份信息可行”。

请求本身还会继续缩小这句话的范围。RFC 5440 由 Vasseur 与 Jean-Louis Le Roux 撰写，它规定 PCReq 可以带上起点、终点、带宽、建立与保持优先级等约束。RFC 5541 又为目标函数提供表达方式。约束回答哪些候选不合格；目标函数回答在合格者中如何选择；政策回答管理者允许或偏好什么；TED 则回答算法看见了什么。

四者不能混成一个“算法决定”。如果只保留最终 ERO，不保留输入快照、请求对象、目标函数和政策上下文，故障发生后就很难知道究竟是信息陈旧、约束错误、政策分歧，还是后续执行失败。

PCRep 的“成功”到哪里为止

RFC 5440 对成功流程的描述非常节制：PCE 收到路径计算请求，成功完成计算，再把计算出的路径发送给 PCC。ERO 用来编码这条 TE LSP 的计算路径，并且可供 MPLS 或 GMPLS 控制面立即用于信令。

关键词是“可供使用”，而不是“已经使用”。

如果部署采用 RSVP-TE，RFC 3209 规定的是另一段信令与预留过程。沿途节点仍可能拒绝，计算后的资源状态也可能已经变化。若部署采用 Segment Routing，RFC 9256 会进一步区分候选路径、segment list、headend 上实例化的 SR Policy，以及被导入该策略的数据流。RFC 8664 让 SR 路径信息可以经 PCEP 携带，却不会因此自动完成 headend 编程与流量导入。

两种技术不应被写成同一种安装机制。RSVP-TE 可以逐跳信令并预留资源；SR 的中间节点通常不保存同样的逐路径状态。但它们共同说明：计算对象是下一步的输入，不是下一步的回执。

有状态 PCE 也没有取消边界

后来出现的 stateful PCE、delegation 与 PCE-initiated LSP，让控制循环比原始 PCReq/PCRep 更丰富，也让人更容易误以为控制器“已经拥有”网络。

RFC 8231 恰恰写明：LSP 状态所有权仍由 PCC 保留，来自 PCE 的属性仍要经过 PCC 本地政策。PCC 可以逐条 LSP 撤回 delegation；PCE 也可以归还。这是一项受限的更新权，不是对整个网络的所有权，更不是转发保证。

真正更接近运行状态的证据，是后续 PCRpt。LSP 成为 Up 或 Active 时，PCC 要发送状态报告；如果建立失败，则报告 Down 并给出原因。RFC 8231 还特别说明，PCRep 与 PCRpt 没有直接一一对应关系，一次计算响应之后可能跟着多次状态变化。

因此，成功 PCRep 与 Up PCRpt 的区别不是界面细节，而是两种不同事实。前者由计算实体报告“我找到了结果”；后者由状态持有者报告“这个 LSP 现在处于何种状态”。RFC 8281 允许有状态 PCE 发起 LSP 创建，也只是把控制动作往前推进了一步；设备能力、本地政策和实际执行依然要另行确认。

网络现实需要一串回执

可靠的自动化不该寻找一枚万能印章，而应保留证据链。

第一层是计算溯源：TED 版本与时间、约束、目标函数、政策以及 PCReq/PCRep 标识。第二层是 PCC 接受和控制动作：响应是否被采纳，是否触发 RSVP-TE 信令、SR Policy 编程或别的机制。第三层是设备结果：需要预留的资源是否完成预留，RIB 与 FIB 是否出现预期表项。第四层才是数据包：接口计数、路径探测、流量遥测是否显示业务真的走过这条路。最后一层是服务：在明确测量窗口里，时延、丢包、抖动和可用性是否达到 SLA。

RIB 不是 FIB；FIB 不是数据包；数据包路径也不是完整 SLA。合规结论还要说明适用范围、策略版本和观察窗口。把前一层结果拿去代替后一层，是控制系统最危险的自我欺骗。

实现资料也印证这种分层。Juniper 的 PCEP 配置文档 说明 PCC 收到 PCE 属性后会重新信令，并提供不同命令分别检查 PCEP 会话、PCC 所知 LSP、SPRING-TE 详情和协议路由。其 Paragon 故障指南 还给出一个很直观的场景：控制器收到确认并清除了控制器状态，LSP 仍可能是 Down，因为 PCC 无法完成信令。它只代表一种实现，却把协议边界变成了运营人员能看见的故障。

对 Farrel 的准确评价

Farrel 的 IETF 公开履历 很长，本文只选择其中一项贡献：他与 Vasseur、Ash 在 RFC 4655 中帮助建立了一套不混淆计算、政策、拓扑信息与信令的架构语言。基础 PCEP 规范属于 Vasseur 与 Le Roux；后续 stateful PCE、delegation、LSP initiation 与 SR 扩展由工作组和多位作者继续完成；厂商实现，运营者验证。

这种归因不是礼节问题。PCE 本身就是协作系统。把所有成果都归于一位作者，等于把一个可见文档当成整个运行网络——恰好重演本文反对的错误。

来源登记