摘要

  • RFC 9160 为 mplsTopLabelType(46) 定义五个新值，使 IPFIX 记录能够表达指定的 MPLS Segment Routing 标签分配语境，而不是让观察者从标签数字猜测来源。
  • 有类型的导出记录可以参与一项边界清楚的调查；它不是网络已经迁移、路径正在使用、策略已生效或服务成功的证明。

运维记录中最常见的越界，往往不是伪造数据，而是让一个真实字段承担它并未观察到的结论。MPLS 栈顶标签确实有一个数值；IPFIX 确实可以导出该数值；分析工具也确实可以按数值分类。然而，这一连串真实并没有回答“哪个控制平面协议分配了它”。RFC 9160 的价值正是在数字和归因之间加上一个必须显式保存的区分。

该 IETF 信息性 RFC 于 2021 年 12 月发布，唯一列名作者为 Swisscom 的 Thomas Graf。它为既有 IPFIX 信息元素 mplsTopLabelType(46) 增加五个代码点：Path Computation Element、OSPFv2 Segment Routing、OSPFv3 Segment Routing、IS-IS Segment Routing，以及 BGP Segment Routing Prefix-SID。它们允许导出记录说明：此处所表达的是哪一种指定的 MPLS SR 控制平面协议语境。

为什么仅有数值不够？RFC 9160 明确指出，IGP adjacency SID、LDP 和动态 BGP 标签可能共用一个分配范围。同一个可见数字因此可以落入不止一种分配叙事。把数值直接读成协议来源，是把编码的偶然重合误写成了可验证的来源关系。

文档给出的场景也很克制。运营者可以监测从 LDP 到 IS-IS 或 OSPF Segment Routing 的控制平面迁移，或者从动态 BGP 标签到 BGP Prefix-SID 的迁移。将标签类型与 RFC 列出的其他 IPFIX 元素组合，例如顶层标签地址、标签栈区段和转发状态，记录可以支持关于转发或丢弃报文数量、可能丢弃原因、提供商边缘 loopback 地址和标签协议的推断。这里的关键是“支持推断”：先让记录带上分辨对象所需的标识，再限定它能够回答的问题。

它不是部署证明。RFC 的发布不能说明某个导出器已经启用，采集器已经收到完整数据集，记录具有真实性，或观测覆盖了调查所关心的路径。有类型的字段也不能说明迁移何时开始或结束、某项策略为何被选择、一个报文是否抵达预期目的地，或客户是否得到了某项服务结果。字段的语义更清楚，不等于字段突然拥有了全网运行状态。

RFC 9160 对 BGP 的两个不同含义尤其值得保留。既有 BGP 代码点 4 指向 MP_REACH_NLRI 路径属性中的标签值；新的 BGP Segment Routing Prefix-SID 代码点 10 指向 Label-Index TLV 中的标签索引值。日常语言里的“BGP 标签”可以掩盖这两个不同对象，而 RFC 没有让共同的名称抹平这种区别。标签类型不是装饰性元数据；它说明一条导出记录究竟在描述哪个技术对象。

按 Lu Heng 的 Running-Code Primacy 与 Minimum Initial Specification 方法，协调文档和注册表能让一个主张可读、可复核，却不能把未观察到的运行事实宣布为真实。这里最小且可防御的表述是：在明确的观测点和采集安排下，某导出器在一条 IPFIX 记录中表达了规定的顶层标签分配类型。对控制平面状态、实际转发或用户结果的结论，各自仍需拥有相应证据。

因此，调查应保存原始导出记录、导出器身份、观测点、采集时间段、模板版本、完整性边界以及被用于关联的具体字段。问控制平面，就核对控制平面记录；问流量，就核对转发证据；问服务，就核对服务遥测。标签数值不能替代这些记录。即使标签带有类型，也不能替代。

Graf 的贡献并不是为仪表板提供更响亮的结论，而是防止观察者把裸数字当作它从未携带过的来源证明。真正得到的是一条更干净的证据链：导出事实仍是导出事实，网络故事仍须由实际运行证据来完成。

来源