摘要

  • RFC 9757 可以通过 PCEP 协调 BGP 会话、显式 peer 路由、前缀通告以及 Raw/Tunnel 转发，但合法 PCInitiate 只表示控制器意图，PCRpt 只表示 PCC 在自身边界内的陈述。
  • 生产证据链必须继续覆盖控制器权限与纪元、状态同步、双端 BGP 身份、策略接纳、RIB/FIB 落地、流量探针、有序恢复与可验证清理。

控制器完全可能收到一排整齐的成功回执，而业务仍然没有被证明。某台路由器报告已经处理 BGP peer 指令，沿途设备依次回报显式路由，两个边缘节点称已发送前缀；Symbolic Path Name 和 CC-ID 也都对得上。屏幕可以变绿，但这些消息不一定说明对端接受了路由、每块转发硬件都安装了正确下一跳、切换没有短暂环路，更不说明一只数据包真正走完了路径。

RFC 9757 把这个缺口带进原生 IP 网络的日常机制。它是一份 IETF Experimental RFC，借助 PCE-as-a-Central-Controller，以多条 BGP 会话、peer 主机路由和前缀通告组织 Native IP 流量工程。RFC Editor 记录与 Datatracker 记录确认文档身份和状态；RFC 本身仍要求通过实现与部署反馈理解运营影响、扩展性和稳定性。对象编号与规范步骤不是采用率，也不是运行结果。

三类指令共享路径名，却不共享一个真值

Native IP 指令复用 PCInitiate 与 PCRpt。PCInitiate 必须携带 SRP、LSP、Object-Type 2 的 CCI，并且在 BPI、EPR、PPA 中恰好选择一个：BPI 描述 BGP peer，EPR 描述通往 peer 的主机路由，PPA 描述要向该 peer 通告的前缀。同一条端到端路径的相关对象由 Symbolic Path Name 关联，CC-ID 则标识当前 PCEP 会话中的一项控制指令。

这种关联很强，却不是原子执行。一条路径往往涉及多台 PCC、多个对象和不同时间点；每台设备只陈述自己接到的工作。PCRpt 既可确认指令，也可用于状态同步，但它重复对象并不会自动成为独立证人。它首先是 PCC 的 PCEP 模块及本地控制模块对自身状态的报告。

证据边界从能力协商就已出现。双方必须在 OPEN 阶段通告 PST 4 和 Native-IP capability 位；不一致会触发明确的 PCErr 并终止会话。这能阻止双方在能力认知不一致时悄悄使用扩展，却不能证明 PCE 拥有组织授权、拓扑足够新、PCC 集合完整或变更窗口安全。RFC 9757 要求防范恶意 PCE，并建议认证 PCE、保护 PCEP 信道。运营记录仍需保存控制器身份、权限范围、决策负责人和控制纪元。受保护且可归责的错误指令仍然是错误指令。

“BGP Session Established” 需要另一端作证

BPI 携带 peer AS、本地与远端地址、EBGP TTL、状态/错误以及选择 Raw 或 Tunnel 的 T 位。相关地址必须专用于 Native IP TE，不能与手工建立的会话混用。PCC 应尝试建立 BGP 会话，并报告进行中、已建立、已断开或失败原因。

这里的关键仍是“报告”。RFC 9757 不改变 RFC 4271 的 BGP 状态机，只把关键参数交给本地 BGP 模块，其余参数通常来自默认值。一个 BPI Established 状态是重要的单端证据，却不是双端会话记录。可靠回执还应连接两端的本地/远端地址、AS、AFI/SAFI、传输保护、策略实例、路由器身份、会话代次和建立时间。否则，旧会话、意外默认值甚至错误对端都可能占据同一个绿色标签。

RFC 8821 给出以多条 BGP 会话实现 CCDR 的整体架构，但架构目标不会消除 BGP 进出口策略。PPA 指示边缘 PCC 向指定 peer 通告前缀；RFC 9757 要求 PCC 在成功“发送”后报告。发送只到本地交换边界为止，并不证明 TCP 交付、对端 Adj-RIB-In、进口策略接纳、最佳路径选择、继续传播或实际转发。重要变更应保留 UPDATE 身份、对端接收证据、策略版本、Loc-RIB 选择以及数据包将遇到的 FIB 项。

路由确认不是线卡读数

EPR 为 BGP peer 地址安装主机路由。其优先级通常高于动态 IGP 路由、低于手工或其他静态方式配置的路由。PCC 必须检查下一跳可达。为避免短暂环路，PCE 在新增 EPR 时按端到端路径的反序下发，删除时按正序下发；更新下一跳时先安装新 CCI/EPR，再删除旧项。

因此，顺序本身就是控制面。变更记录应保存路径版本、逐设备依赖顺序、下发和确认时刻、下一跳解析以及旧状态被移除的时点。成功 PCRpt 能说明 PCC 按实现接受或完成了 EPR 操作，但仍需独立读取 RIB、FIB 和邻接状态，并用流量观察闭环。路由可能存在于控制表却输掉优先级竞争，可能未写入硬件，可能指向过期邻接，也可能在另一台设备已经撤旧之后才姗姗到达。

Raw 与 Tunnel 也必须分开核验。Raw 模式按原始目的地址转发，只能提供中等程度的路径控制；不同入口到同一目的地的流量可能共享优先路径的一段。Tunnel 模式默认在选定入口与出口之间使用 IP-in-IP，以更严格地限定入口/出口组合。T 位只表示选择了哪种策略，不证明封装、解封装、MTU、安全过滤、隧道端点身份或实际路径。流量探针应带上入口身份、流类别、报文大小、时间和预期出口；Tunnel 模式还要由两端分别提供状态证据。

故障把对象关联变成时间问题

RFC 9757 把同一 Symbolic Path Name 下的 BPI、EPR、PPA 作为 LSP-DB 中同一路径的属性，并引用 RFC 8232 的同步程序。RFC 8231、RFC 8281 与 RFC 9050 提供状态、PCE 发起和 CCI 的委派与超时机制。

同步只能证明某个数据库版本和会话语境内报告了什么，不能冻结网络。如果 PCC 脱离控制，PCE 必须在仍活跃的 PCC 上重算和重新部署，并避免故障期间的短暂环路。PCE 故障后，CCI 可以移交给新 PCE；既有状态可能保留到 State Timeout Interval 才清理。因此，证据必须带上控制器纪元、PCEP 会话代次、数据库版本、PCC 成员集合以及每项指令何时更换控制权。

清理也不是一次 Delete。PCE 要分别发送 PPA、EPR、BPI 的明确删除指令。安全闭环需要确认目标前缀已撤回、旧转发已消失且没有过早切断剩余路径、BGP 会话和配置已清除，并确认 RIB、FIB、隧道表和同步数据库不再残留。最后还要做正反两类流量测试：退役路径不再承载探针，而保留或回滚路径仍能承载。

Heng Lu 的 Running-Code Primacy 提供了合适的编辑纪律：协调文档不能高于真实实现、验证、部署和使用。Minimum Initial Specification 又把共享技术语言与后续本地决定分开。应用到 RFC 9757，就是承认其关联能力的价值，同时不让它替未观察到的事实作证。

领导层最终需要十类相连回执：控制器权限与纪元；双向能力协商；完整同步；逐对象请求与报告；双端 BGP 身份；路由策略接纳；RIB/FIB 落地；Raw/Tunnel 状态；数据包与服务探针；重算、撤回与回滚。RFC 9757 加强了证据链的前半段。它的贡献不是把 PCRpt 变成数据包证明，而是让这条边界能在绿色屏幕被误当成业务事实之前写清楚。

来源登记

当前文档状态可通过 RFC 9757 勘误检索核对。PCEP 基线来自 RFC 5440，RFC 8408 与 RFC 8283分别补充路径建立类型和 PCECC 背景。编辑判断也参考 Heng Lu 的 Reality, Not Advocacy 与 Reality Layers。