摘要

  • RFC 9752 允许 Vendor Information 对象进入 PCRpt、PCUpd 与 PCInitiate 等有状态 PCEP 消息，并把 Enterprise Number 的来源明确指向 IANA 私有企业编号注册表。
  • 收到带正确 PEN 的字节，只能证明一个自称属于该命名空间的载荷经过协议；它不证明语义版本、发布者身份、接收端支持、变更权限或设备与业务结果。
  • 可审计链必须继续记录解析器、能力约定、本地授权、SRP/PLSP 关联、PCE/PCC 对账、设备应用、RIB/FIB 或标签状态、流量观测、回滚及跨厂商退路。

先看一个并不需要故障才会发生的场景。PCE 发出一条合法 PCUpd，其中的标准 LSP 对象旁边放着 Vendor Information。TLS 会话正常，PEN 在 IANA 表中存在，PCC 也回送了带对应 SRP-ID 的 PCRpt。如果观测系统只问“消息是否到达”“编号是否存在”“是否收到报告”，它会给出三个绿色答案。可是载荷由谁发布、PCC 用哪一版字典解码、谁允许它改这条 LSP、设备究竟装了什么，仍然没有答案。

RFC 9752 于 2025 年 4 月作为 IETF Proposed Standard 发布。RFC Editor 记录与 Datatracker说明它更新 RFC 7470：原来用于无状态 PCEP 的厂商信息承载，被扩展到有状态操作。标准化的是承载位置，不是厂商私有语义本身。

三类消息，三种不同后果

在 RFC 7470 中，VENDOR-INFORMATION 对象为 Class 34、Type 1，VENDOR-INFORMATION-TLV 为 Type 7。两者都由 32 位 Enterprise Number 和后续私有信息组成。后者的格式与解释由该编号所指的企业决定，可以通过 Informational RFC 或商业文档公布。这意味着协议外还存在一份必须被识别、版本化和验证的语义合同。

RFC 9752 让 Vendor Information 对象出现在三条有状态路径上。PCRpt 是 PCC 向 PCE 报告 LSP 当前状态；PCUpd 是 PCE 要求 PCC 更新 LSP 属性；PCInitiate 可触发 LSP 创建或删除，其中更新后的创建语法容纳厂商对象。TLV 则早已能放入支持 TLV 的 SRP、LSP 等对象。

它们不能被混称为“一个厂商扩展”。报告中的私有字段可能只是补充指标，更新中的字段可能改变选路约束，创建中的字段可能参与资源或行为选择。RFC 9752 允许一个 PCRpt 中出现多个对象，且可以带不同 PEN，却没有规定多个私有含义冲突时谁优先。报文位置给出上下文，不能替代冲突规则。

PEN 是登记坐标，不是密码学签章

RFC 9752 把 Enterprise Number 的注册表准确改为 IANA Private Enterprise Numbers，并引用 RFC 9371。这项修订很重要，因为它消除了引用歧义；但它没有把整数变成来源证明。

RFC 9371 对此没有留下想象空间：PEN 按 First Come First Served 分配；IANA 可验证注册记录的修改请求，却无法控制持有人如何使用，也无法阻止第三方在自己的数据里使用别人的 PEN。注册表记录能说明某个时点登记了谁，不能说明当前报文一定由该主体、其现有产品团队或其授权合作方产生。

所以“PEN 匹配”之后至少还要有发布者签名、语义规范版本、发布与撤销时间、规范和解析器哈希、适用消息/对象位置、支持期限。企业并购、产品分拆、代码仓库迁移或维护团队更换时，这些证据尤其不能由注册表联系人代替。

能读对象，不等于支持含义

RFC 9752 要求：实现若认识 Vendor Information 对象、却不支持其中的 Enterprise Number，应按继承规则忽略；发送端若认为接收端不支持，也不应发送。RFC 7470 进一步指出，厂商私有信息若没有厂商间合作协议，本来就不能保证功能级互通；对支持 PEN 和私有信息的能力通告，标准也只说“可能有益”，实际机制在范围之外。

由此应把能力拆成四层：能解析对象头；认识 PEN；支持某一精确私有语义版本；本地策略允许该版本在这位对端、这类消息和这条 LSP 上生效。忽略未知对象可以保护基本协议，却可能悄悄抹掉发送端依赖的策略效果。成功解码也未必安全，因为“能做”不是“获准做”。

真正的版本约定应当独立留痕：双方身份、版本、适用操作、过期时间、降级规则与基线退路。跨厂商退路必须经过测试，证明拿掉私有字段后，标准对象的解释不会偷偷改变；否则兼容性只存在于采购演示里。

会话身份与操作授权不能合并

RFC 9752 沿用既有安全考虑，并建议在 PCE/PCC 之间使用 RFC 8253 的认证加密会话。TLS 可以证明本次连接持有某份凭据并保护传输字节，但它既不认证私有语义文档的作者，也不自动授予修改特定 LSP 的业务权限。

RFC 8231 给出了关键边界：PCC 只有在网络管理员配置的本地策略允许时才对 LSP Update Request 采取行动；行动会触发 LSP setup，并用状态报告回报结果。委托可以被撤销，非委托 LSP 的更新有明确错误。RFC 8281 还要求双方声明 PCE-initiated 能力，并区分参数不可接受、内部错误与信令失败。

这些是不同收据。TLS 身份、LSP 委托、本地授权、解析结果、PCC 报告不得折叠成一个“accepted”。即使 PCRpt 表示成功，它仍是 PCC 对协议状态的报告，而不是线卡、RIB、FIB、标签表或真实包流的独立读取。

对账要跨过重启与回滚

完整记录从原始对象/TLV 字节开始，包含 PEN、消息类型、对象位置、P/I 处理、会话与证书上下文、能力快照、解析器版本、语义验证与冲突选择。然后用 SRP-ID、PLSP-ID、对端和会话 epoch 将 PCUpd/PCInitiate 与 PCRpt/PCErr 关联，并保存委托状态与本地授权理由。

PCEP 之外还要加入设备事务、意图与实际配置差异、已编程路由/标签、流量探测、业务观测和回滚结果。一次转发表读取只是某个时点的已安装状态；一次探测只是观测到的一条路径。证据强度可以逐层增加，却不能通过命名把较低层“升级”为较高层。

RFC 9752 自己也说明了边界：它没有新增存活检测，没有新增正确操作验证，也没有给其他协议增加要求。标准 YANG 模型或许能报告厂商对象/TLV 与 PEN 的出现，却不会公开其中的私有细节。安全章节还提醒该字段可能成为隐蔽信道，运营者需要知道解码机制并检查使用情况。只保留“出现次数”会把最重要的风险删掉。

文档证明协议，不证明部署

当前 IANA PCEP 参数表确认对象和 TLV 代码点。RFC 9752、7470、8231、8281、9371 与 8253 证明本文所述协议规则；它们没有证明任何具名厂商已经部署、发生缺陷、成功互通、改变转发或改善性能。

Heng Lu 的 Running-Code Primacy、Minimum Initial Specification 与 Reality Layers 在这里是公开披露的分析框架，而非 IETF 规范。它们要求把共同承载看作薄协调层，把私有语义、采用、拒绝与兼容留给参与者以可验证证据决定。因而本文的结论只到观察边界为止：报文通过，证明承载；后面的每一步，都应另有证人。