摘要

  • RFC 7471 是 2015 年 3 月发布、由 Alia Atlas 等人共同署名的 Proposed Standard。它规定 OSPF TE 可分发单向链路时延、时延变化、丢包和带宽性能信息；文档明确说，这些机制只分发网络性能信息，测量方法和分发后的行动不在其范围内。
  • RFC 7823 进一步说明，路径计算功能可以使用这类信息，计算出的路径也可以经 RSVP-TE 信令或由入口路由器使用。这里的“可以”不证明某个网络已经选择、安装或使用某条路径，更不能证明服务结果。

这个值描述的是哪一段

RFC 7471 的单向时延指从发布节点到其直接连接的 OSPF 邻居的时延。它不是端到端路径时延，更不是应用事务或用户体验。规范还提供最小和最大单向时延、时延变化、单向链路丢包、剩余带宽、可用带宽和已用带宽的表示。微秒、百分比和每秒字节等单位让不同实现能识别字段的含义，却不会把不同测量条件、不同目标和不同运营政策变成同一种事实。

关键限制在于，RFC 7471 只做信息分发。它没有把采样方法、计算口径、优化目标或运行决策带进 OSPF 的共同层。一个运营者可以把数值用于局部策略，另一个可以因约束不同而不采用它。数值穿过协议，并不带走测量系统、控制器或网络经营者的责任。

稳定发布不是网络的连续快照

除剩余带宽外，RFC 7471 的性能值都是可配置窗口上的滚动平均。它定义门限、过滤、门限越界位、重用门限和通告节流；两次通告之间默认 120 秒，且不得短于测量间隔。每个扩展可以启用或禁用；在迁移期间或动态测量不可用时，动态值也可以被手工配置或静态值替代。

这些安排不是缺陷，而是让控制面避免无意义震荡的选择。它也带来明确的证据边界：看到一个通告，不等于看到了此刻的网络。该值可能经过平均、过滤、保留或覆盖，也可能根本没有被后续决策使用。它可以是一个合理的输入，却不是路径成功的结论。

分发以后仍有多道本地决定

RFC 7823 描述的下一层同样没有自动发生。路径计算功能可以针对时延、抖动或丢包使用 TE 信息；结果路径可以用 RSVP-TE 信令，也可以由入口路由器结合 Segment Routing 使用。多目标优化本身可能很复杂，并会使用启发式方法。路径请求、约束、拓扑视图、可行性和取舍，仍是本地系统的决定。

此后还要经过信令、安装和转发。计算器可能收到信息却拒绝候选路径；可能算出候选却不安装；信令可能失败；状态可以安装却未承载所关注的流；流量存在也不能自动说明时延、丢包或服务体验。每一步都应该有自己的凭据：测量系统给出方法和窗口，OSPF 给出通告和年龄，路径计算器给出输入和选择理由，转发表给出已安装状态，独立探针或计数器才可以支持交付主张。

共同层应当小，本地判断应当可追问

这与 Heng Lu 的最小初始规范和本地化未来决策相呼应。互操作只需要一个可共同理解的字段、单位、方向和更新语义；它不需要把每个实验室的测量方法、每个运营者的目标或每个控制器的决策一并标准化。RFC 的存在，或子 TLV 的出现，也不是具体网络采用某种行动的证明。

RFC 7471 将作者列为 Stefano Giacalone、David Ward、John Drake、Alia Atlas 和 Stefano Previdi；Atlas 的公开 IETF Datatracker 资料支持这种可验证的署名与肖像来源。它不证明 Atlas 独自写成文档，也不证明她控制今天的运营商、遥测、路径计算或服务承诺。可验证的贡献是划定可移植的信息边界，而不是替后来每项本地选择背书。

证据边界

所引 RFC 不证明当前部署、当前拓扑、当前数值、实际路径选择、RSVP-TE 信令、Segment Routing 指令、已安装转发状态、流量承载、端到端可达性或用户体验。本文提出的凭据链只是尊重这些边界的运行做法，而不是 RFC 新增的要求。

来源