摘要

  • 能力通告、LSP 状态同步、PCUpd 和 PCInitiate 都是边界明确的协议行为，不能相互替代为“已完成控制”的证据。
  • RFC 8231 中的委托仅允许 PCE 在存续期间更新特定 LSP 属性；PCC 始终保有状态所有权、当地策略判断和撤回权。

控制室里最容易被误读的词之一是“委托”。仪表板显示某个 LSP 已 delegated，或者 PCE 已发出更新，叙事便很容易跨越好几层：仿佛网络已经由 PCE 接管，仿佛资源必然已经配置，仿佛业务也已经获得结果。协议没有说这些话。

RFC 9504 把有状态 PCEP 的能力延伸到 GMPLS 受控网络。PCE 与 PCC 可以通告功能、交换和同步 LSP 状态、请求更新属性，或请求端节点建立 LSP。这些机制的价值在于它们将互动写成可检查的记录；其约束也正来自这种精确。记录一项能力，不等于资源被预留；报告状态，不等于转发面已按意图安装；发送请求，更不等于本地策略已经同意。

能力是第一道边界。RFC 9504 对 GMPLS 相关的报告、更新和发起设定了双方支持且允许的前提。PCC 与 PCE 都要声明并允许相应行为，才谈得上使用该行为。这是参与者之间的协议资格，不是对设备、光层资源、维护时段或客户承诺的授权书。IANA 的 PCEP 注册表记录了代码点和对象；登记同样不是部署和运行的证明。

状态是第二道边界。RFC 8231 要求有状态 PCE 在计算或更新前了解 PCC 的 LSP 状态。一份 State Report 是状态变化的报告；Update Request 是修改属性的请求。委托使 PCE 可以更新一个或多个 LSP 的某些属性，但这种权利有对象、有范围、也有期限。RFC 8231 同时明确：状态所有权仍在 PCC，PCE 属性受 PCC 当地策略约束，PCC 可以随时撤回委托。把“PCE 在被委托期间对属性具有权威”扩写为“PCE 拥有网络”，恰好抹掉了规范保留的限定语。

PCInitiate 也不能承担更多含义。RFC 8281 将 PCE 发起的 LSP 描述为因 PCE 请求而实例化的 LSP；RFC 9504 的 GMPLS 扩展沿用了这一路径。请求可以触发端节点去建立 LSP，但触发不是接受的审计记录，也不是资源分配、交叉连接建立或实际转发路径存在的独立证明。即使 PCRpt 同时携带意图路径和实际路径相关信息，仍应先问：它具体报告了什么、由谁在何时报告、它没有测量什么。

因此，可靠的证据链不是一个醒目的 controller 标签，而是一串不能省略的事实：双方允许的能力；PCC 保有的已同步状态；针对特定属性的委托；一次请求；当地策略的接受或拒绝；设备和资源动作；已安装的路径状态；再到独立的流量、保护和服务观察。前一步可以让后一步成为可检验的问题，但不能自动把后一步写进前一步。

这并非反自动化的谨慎。恰好相反，它让自动化承担它真正能够承担的责任。Heng Lu 所说的最小初始规范提醒我们，共同层应规定可互操作的最小事实，后续采用和有风险的决定应留在本地。运行中的代码可以证明机制正在工作，却不能替代“谁接受了什么后果”的记录。

运营者应把问题从“PCE 是否控制网络”改为：它被授权更新哪一个 PCC 的哪几个 LSP 属性？授权能持续多久？当地策略在何处作出判断？哪一份证据连接了请求、设备动作和被观察到的服务？这样提问既不会贬低协议，也不会让协议被夸大为制度权力。

来源