摘要

  • RFC 5654 是 2009 年 9 月发布的 Standards Track 文档，Deborah Brungard 是五位编辑之一。它说明 MPLS-TP 要求涉及构成模块的协议机制和程序的行为；文本明确表示，这些不是实现要求，也不描述某个 MPLS-TP 实现支持的功能。
  • 文档允许传送路径采用静态或动态配置，并称网络及路径即使没有控制平面，也可以连同 OAM 和保护能力一起完整运行。这些是受标准保留的技术选择，不是某运营商已经作出选择、某路径已安装、某次保护已发生或某项 SLA 已达成的证据。

“配置”不是替人作出的网络选择

“传送配置”容易让人想到一个已经完成的网络：设备已经一致、拓扑已经确定、服务已经交付。RFC 5654 实际上更克制。其摘要说它规定的是 MPLS Transport Profile 的要求，这些要求面对的是组成配置的协议机制和程序的行为；紧接着便说明它们不是实现要求。

引言把这种克制落在具体位置上。RFC 所识别的是 MPLS 工具箱中应当可取得的功能，以及可能需要新增的协议工作；它不描述某个 MPLS-TP 实现支持什么功能。它是一份要求说明，之所以处于 Standards Track，是为了能在 ITU-T 工作中被规范性引用。一份共同参考可以很重要，却仍然不是产品功能清单、设备库存、已部署设置，或强制运营商选择某种运行模型的指令。

因此，不能把四个不同层次压成一句话。工具箱说的是本地系统可采用的能力；实现有自己的版本、支持范围和互操作约束；运营商还要选择拓扑、开通方式、保护策略、迁移节奏和服务界线；最后，服务保障系统仍须观察某条具体路径或流量是否达到声明。RFC 中出现某种能力，并不会自动生成这些后来事实的回执。

静态、动态和没有控制平面是三种不同的陈述

RFC 5654 说 MPLS-TP 传送路径可以通过静态或动态配置建立，并特别指出网络及其路径即使不存在任何控制平面，仍可以完整运行，包括 OAM 和保护能力。这里保存的是可供负责网络的人选择的运行面，而不是替某个已知网络选定其中一种。

控制平面一节同样保持了这个分界。文档要求网络能够在不使用控制平面的情况下运行；如果使用控制平面，它必须支持控制平面拓扑和数据平面拓扑的独立性，因此控制平面故障不意味着数据平面也故障。它还必须能够独立于某一特定客户层或服务器层控制平面运行。

这些表述最重要的作用，是阻止错误推论。动态能力可用，不等于动态控制已启用；静态开通被允许，不等于静态配置已经存在；两种故障可被区分，不等于任一平面在某一时刻健康。OAM 或保护的要求也不证明发生过保护切换、配置正确，或客户流量得到保护。每一种断言，都必须由拥有该状态的系统给出证据。

共同规则保留而非抹去管理边界

RFC 还承认，不同的管理群体可能负责同一个层网络，也可能分别负责不同层网络。它要求 MPLS-TP 层网络地址和其他信息（例如拓扑）能够对客户层隐藏；同时，运营商可自行选择泄露有限的汇总信息，例如共享风险链路组或可达性。

这是一条刻意节制的共同规则：它使边界成为可能，但不取消边界。客户层不会因为标准存在就自动有权看到下层的全部拓扑；实现本身也不会暴露运营商的管理模式。如果网络公布汇总信息，信息的来源、范围、时效和策略仍是可核验的事实。如果网络没有公布，阅读者不能从 RFC 所允许的机制反推出一幅虚构的统一拓扑。

真正运行的系统仍要交出自己的凭据

任何关于传送网络的具体陈述，都需要比一份 RFC 更长的证据链。实现记录可以说明软件版本和支持功能；管理或控制系统可以显示开通方法、路径意图和信令动作；转发平面可以显示已安装状态与计数器；OAM 可以说明测试了什么、何时测试、端点在哪里；保护记录可以说明触发条件、动作和结果；服务测量才可在约定的客户边界上说明结果。

RFC 不会替代其中任何一项。它提供的是这些特定系统得以设计和互通的共同语言，而不是供应商支持矩阵、现网拓扑、活动路径、流量、故障、保护事件或客户体验的证明。把标准当作这些证据，会把标准误当运营者，把可用能力误当已发生部署。

这与 Heng Lu 对“最小初始规范”和“本地化未来决定”的区分相呼应。共同规范协调必须共同的部分；后来的选择仍属于运行系统的参与者。一个协调工件不会因为发布就自动变成操作现实。RFC 5654 没有把工具箱变成普遍的实现命令，恰恰是其价值所在。

对 Brungard 的归属不应借来不属于她的权力

RFC 5654 列出的编辑是 Ben Niven-Jenkins、Deborah Brungard、Malcolm Betts、Nurit Sprecher 和 Shigeru Ueno。Brungard 的 IETF Datatracker 资料页能够识别其身份，并提供本编辑肖像所依据的公开照片来源。这足以支持一项有限归属：她是这份协作要求文档的编辑之一。

这些资料不能证明她单独写成 RFC、选择了后续实现、控制当前 IETF 或 ITU-T 决定、运营某家承运商网络，或保证某项传送服务。准确而有限的归属反而更有分量：它承认共同技术边界上的工作，同时把实施、配置、观测和对现实网络负责的权力留在本地参与者手中。

证据边界

来源能够证明 RFC 5654 写了什么以及明确未声称什么；它们不能证明某运营商目前使用 MPLS-TP、某地点已经部署、某路径正在运行、某拓扑存在、控制平面状态、OAM 结果、保护动作、流量或客户体验。本文的证据链是对这些边界的操作性解读，不是向 RFC 添加新的要求。

来源