摘要

  • RFC 9857 允许 SR Policy 头端直接作为 BGP-LS Producer，也允许 PCE 代表一个或多个头端发布候选路径状态。
  • 无论由谁发布，NLRI 的 Local Node Descriptors 都标识头端；Protocol-Origin 说明候选由何种机制实例化，却不是观察时间戳，也不是完整的报告者链。
  • 可审计的自动化决策必须把通告绑定到 producer 与会话纪元，再连接同一时段的 SRPM 状态、独立 FIB 回执、流量观测和业务测量。

一条格式正确、时间不明的状态

控制器收到一条 BGP-LS 更新：头端、Color、Endpoint、Originator 和 Discriminator 都能对上；Candidate Path State TLV 中 E、V 与 A 为真；BSID 与 SID list 也完整。若看板只问“有没有这条状态”，答案当然是肯定的。

但若问题变成“现在能不能据此迁移业务”，同一条记录还缺少关键连接。

RFC 9857 的价值，在于把节点本地可用的 SR Policy 信息交给外部组件，用于路径计算、再优化、业务放置和网络可视化。它与 RFC 9830 方向相反而功能互补：RFC 9830 把候选路径从控制器送往头端，RFC 9857 则把运行状态从头端一侧送回控制器。前一条链问的是“候选是否送达并进入后续选择”，后一条链问的是“收到的状态是谁的观察、何时仍然成立”。

RFC 9857 给出了描述状态的精确词汇，但并未把观察时刻、设备执行和业务结果压缩进同一个字段。正因为如此，使用者必须为不同证据保留各自边界。

NLRI 说的是头端，不一定说的是直接观察者

最容易混淆的不是候选路径身份，而是生产者身份。RFC 9857 规定，BGP-LS Producer 可以是 SR Policy 头端；也可以是 PCE，后者先从作为 PCC 的头端经 PCEP 获取状态，再代表头端发布。

两种模式下，Local Node Descriptors TLV 都只标识 SR Policy 头端。PCE 作为 producer 时，不得把自己的标识塞进 NLRI 的 Node Descriptor；它可以在 BGP-LS Attribute 中携带自身 BGP Router-ID、AS 或联盟成员信息。规范还为 “in PCEP / producer 为 PCE” 情形安排了不同的 Protocol-Origin 值。

这说明 Protocol-Origin 与 producer provenance 不是同一件事。前者表示由哪个协议或组件负责实例化候选；后者需要回答当前 BGP 邻居是谁、最初发布者是谁、状态来自头端直报还是 PCE 代理，以及 PCE 代理时所依据的 PCC/PCEP 报告是哪一份。RFC 8231 定义了 PCC 向 PCE 发送 LSP State Report 以及状态同步语境，但 RFC 9857 的每条 BGP-LS 通告并不携带完整 PCEP 报告账本。

因此，不能仅凭 NLRI 里出现头端标识，就说“头端刚刚亲自报告”。正确做法是把“被描述的对象”和“谁把描述交给我”拆成两个可追溯字段。

A 很有分量，却不是独立硬件回执

Candidate Path State TLV 报告优先级、Preference 和多组状态位：S 表示管理关闭，A 表示 active，B 表示备份，E 表示完成有效性评估，V 表示至少存在一个有效 SID list，另有委派、PCE 配置、transit policy 与 Drop-Upon-Invalid 相关标志。E 与 V 必须结合解释；未评估不能被当成已验证。

尤其不能把 A 降格成“控制器数据库里选中了”。RFC 9857 借用 RFC 9256 的语义，明确把 active candidate 描述为已 provision 到 forwarding plane 的候选。这是一项有实质内容的运行状态声明。

问题在于，声明和独立回执仍是两张纸。producer 可以同时报告 BSID 的分配、不可用与 fallback，亦可报告各 SID list 的计算、验证、首段解析、拓扑/算法一致性，以及被监测机制从转发面移除等状态。这些字段能显著提高解释力，但仍由同一报告源发出。它们不等于芯片或目标 FIB 对具体对象的独立接收确认，也不等于计数器已经移动，更不等于业务达标。

把这一界限说清，并非贬低 RFC 9857；恰恰是尊重它对每一位状态的有限而精确的定义。

报告中没有自动化所需的时间拼接

RFC 9857 的候选路径记录没有 producer 观察时间戳、单调递增的报告代次、SRPM 事务号或转发芯片确认号。BGP-LS Instance Identifier 表示路由实例，不是时间纪元。

基础规范 RFC 9552 还指出，BGP-LS 分发受策略控制，speaker 可以为了减少信息流量而决定何时向 consumer 更新信息。于是，“这是控制器表里最新一条”与“它足够新，可以支撑这次动作”是两个结论。

接收方应自行记录接收时间、BGP 会话代次、重置与重同步、替换与撤回历史，以及不同动作允许的最大年龄。若 PCE 是 producer，还要记录前一跳 PCC/PCEP 报告的身份和年龄。可视化页面可以容忍的延迟，不一定适合自动再优化；自动再优化的时效，也不一定足以支撑客户影响声明。

从状态通告到业务结果，需要五次闭环

第一张回执就是 BGP-LS：精确候选身份、状态位、属性、producer 和接收纪元。

第二张来自指定头端的 SR Policy Manager：它应在同一纪元复现候选身份、评估、有效性、active 选择、BSID 和 SID list。若不一致，控制器持有的可能是旧版本或不同作用域的事实。

第三张来自 FIB、硬件编程通道或同等直接的设备读回：记录实际接受的 BSID 与处理、安装代次、成功或拒绝以及目标硬件范围。RFC 9857 的 A 让我们有理由期待该状态，这张回执则独立印证它。

第四张是流量观测：带时间边界与分母的计数器或定向探针，回答目标流量是否实际使用了该处理。控制对象可以完全自洽，而流量因缺失、错配或被导向别处而没有经过它。

第五张是业务结果：时延、丢包、可用性或应用成功率必须针对受影响人群和时间窗测量，不能用路径 metric 或 active 标签代填。

RFC 8402 把 Segment Routing 放在可信 SR domain 内，RFC 9857 也要求限制敏感策略信息的接收者。信任决定谁有资格说话，却不能替代“他说的是直接观察还是转述、观察发生在何时”的记录。

注册表与勘误能证明什么

当前 IANA BGP-LS 参数注册表 登记了 Candidate Path NLRI type 5、Segment Routing Protocol-ID 9，以及 RFC 9857 定义的 descriptor 和 state TLV。Datatracker 记录其标准化历史。这些记录不能证明某家厂商已经实现、某个运营商已经部署或某次业务已经改善。

RFC Editor 勘误页 当前列出已验证的 EID 8709，把 Section 5.1 末段三处 “SR Binding SID sub-TLV” 更正为 “SR Binding SID TLV”。这是术语级编辑更正，不改变 producer、Candidate Path State 或时效边界。

Heng Lu 关于运行代码优先的论述给出更广的判断纪律：发布和登记不会仅凭声明生成运行现实。RFC 9857 已经选择报告状态而不是制造状态；运营者还必须把这份报告同实际执行和结果连接起来。

来源