摘要

  • 10 月 28 日的个人 Internet-Draft提出五种可在有序 IPFIX 模板中重复出现的通用 MPLS 信息元素。某一栈位 K 的 IPv4 地址、IPv6 地址或前缀长度若无法取得，导出端就不得为该属性导出 K 位及更深的值；它不能跳过空位，再让收集端把下一项当作 K 位。
  • 草案保留 IANA 现行登记簿中的位置专用字段，依赖另行提出的有序导出机制。不懂新模板的收集端可能悄悄丢掉整组记录；五种新字段的编号目前仍是 TBD。

缺的是地址，不是标签本身

设想一个三层标签栈。测量进程看见三枚标签，第二枚的下一跳地址却无从取得，第一枚和第三枚的地址都知道。导出端若只送出两个地址，收集端会按出现顺序把它们读作第一层与第二层。第三层的地址就此坐上第二层的位置。报表没有空格，判断却从这里开始偏航。

新草案第 4.7 节把这条捷径封死：mplsLabelIPv4Address、mplsLabelIPv6Address 或 mplsLabelPrefixLength 在第 K 层不可用时，同一属性在 K 层及以下均不得再导出。每种属性的出现次数必须从第一层连续排列。标签栈仍有第三层；只是这一属性无法以连续次序对第三层做出可靠声明。草案明确把稀疏位置集合排除在范围外。

标签类型另有处理。某层 mplsLabelType 的控制协议类型不明，导出端填入 0，也就是 Unknown。这一项保留层位，同时承认类型未知。地址和前缀字段在草案里没有对应的“未知”占位规则，遇到空格就必须截断。把两种缺失混成同一种处理，会再次把层位和观察值混淆。

问题从老式导出字典开始。IANA 的 IPFIX 信息元素表列着编号 70 至 79 的十个位置专用标签栈字段，字段名称把顶层、第二层一直写到第十层。新草案希望用一个可重复的 mplsLabelStackEntry 表示各层，再配四个通用属性字段。它没有注销旧字段：仍使用旧收集端的网络，继续需要旧格式。改进词汇不等于一夜之间换掉每个听众。

新字段还多带一个字节。RFC 3032把完整 MPLS 标签栈项定义为四字节，包含标签值、流量类别、栈底位和 TTL。旧的位置专用栈字段只有三字节，没有 TTL；草案的通用栈项导出完整四字节，使较深层的 TTL 也可见。若操作方根本不需要 TTL，每层就多付一个字节。内容更全与成本更低并非同一张账单。

顺序承诺要走过三道手

RFC 7011允许同一信息元素在模板里多次出现，但普通模板不会保证其排列就是测量进程的观察顺序。配套草案提出 Ordered Template Set 和 Ordered Options Template Set：测量进程按观察次序记录，导出进程保留并声明该次序，收集进程才把第 n 次出现读作观察点的第 n 项。任一环节若把次序当成可随意整理的排版，这张保证就变成漂亮的假标签。

而且保证是对每一种信息元素分别成立。第二次出现的 mplsLabelStackEntry 与第二次出现的 mplsLabelType 指向同一层，是因为两个字段的定义都把第二次出现绑定到第二层；协议没有额外承诺不同字段在报文里的相对先后。读者或软件若自行补上这条承诺，就会从正确的字节里读出错误的结构。

迁移还藏着另一笔损失。草案第 7 节要求操作方只对已知支持有序模板的收集端开启新导出。不认识新集合的收集端可能悄悄丢掉整组内容。因此旧的位置字段和新通用字段得并存一段时间。导出端升级当天，若收集端没跟上，报表反而可能更空。

Datatracker将这份文件列为活跃的个人 Internet-Draft。五个新信息元素在 IANA 申请表里仍写 TBD。若有一份故意让中间层属性缺失的导出端—收集端联测记录，展示实际模板、发出的值与收集后栈位，就能判断软件是否守住了草案要求的层位。

来源