摘要

  • revision 18 把可能同时命中的 VLAN 条件依次排为：双标签明确/范围匹配、明确与 any 的双标签组合、单个外层标签、priority-tagged、untagged、default；同一级内能命中同一帧的配置必须被拒绝。
  • 这套顺序证明的是合规分类器“应当选谁”。要证明设备“实际转发了什么”，还要分别核验应用态、隔离后的计数器增量、改写前后抓包、FIB 或服务绑定、路径与远端到达。

设想一帧报文进入以太网 trunk：外层 S-VLAN 是 10，内层 C-VLAN 是 21。设备上同时存在 10/21 的双标签规则、外层 10 加内层 any 的规则、外层 10 的单标签规则，以及 default 子接口。四条规则表面上都对这帧报文感兴趣，但它只能归属一处。

NETMOD 当前草案 revision 18 给出了确定顺序。两个明确标签或范围最优先；一侧明确/范围、另一侧为 any 的双标签组合其次；单个明确外层标签再次；之后才是 priority-tagged、untagged 和 default。设备还必须拒绝同一层级里会选择同一帧的重叠范围，包括“外层明确、内层 any”和“外层 any、内层明确”相互交叉的冲突。

这消除了一类很实际的配置权争夺。它让运维人员可以提出明确预期：10/21 应进入双标签子接口，而不是被更宽的规则拿走。但这个预期仍只是控制面的可检验声明。

两层标签也是模型的观察边界

该模型最多用外层与第二层两个 802.1Q 标签做分类。双标签时，定义的互通约束要求外层为 S-VLAN、第二层为 C-VLAN；单标签规则读取最外层标签。它并不是对任意深度封装的通用解析器。

match-exact-tags 不会改变优先级。它只决定已匹配的标签是否必须构成完整的 802.1Q 标签栈。开启时，后续不能再出现 802.1Q 标签；未开启时，更深的标签可以存在，但在本模型里被当作不透明载荷，不参与分类，也不参与改写。

因此，10/21/300 的三标签帧可能被“精确双标签”规则排除，也可能在非精确规则下凭前两层被接收。若验收只发 10/21，配置看起来再整齐，也没有覆盖这个边界。

default 的证据必须包含所有同级子接口

default 不是与具体规则平起平坐的通配符。它只接收没有被任何更具体 peer sub-interface 捕获的流量。要证明某帧确实由 default 处理，就必须保留完整的同级规则快照，并证明所有更具体候选都没有获得它。只读取 default 自身，无法解释它为何胜出。

priority-tagged 也不能与 untagged 混为一谈。前者仍携带 802.1Q 标签，只是 VLAN ID 语义特殊；后者没有相应标签 EtherType。最可靠的输入证据是入口抓包，而不是测试脚本里一行“untagged”的名称。

分类正确，不代表后续服务存在

柔性封装模型允许在分类后 pop 或 push 最多两层外部标签；标签转换用 pop 加 push 表达。只能弹出已匹配的标签，所以读取一层却删除两层是不允许的。设备还可支持对称改写，或分别定义入口与出口方向。

这些字段说明配置关系，不说明芯片已经执行。入口 line card 是否选中了预期规则、改写后的字节是否交给正确 forwarding instance、返回方向是否执行逆操作，都是新的事实。

草案自己的 L2VPN 示例给出了最干净的反例：一个子接口可以正确分类并移除标签，但因为尚未绑定任何服务，分类后的流量仍被丢弃。分类器完全正确，转发结果仍然是零。

用边界清楚的收据逐层闭合

第一层是设备实际公布的模块、revision 与 feature。第二层是完整的 NETCONF 或 RESTCONF 请求与成功回执。第三层是 intended 和 operational 之间的对照。RFC 8342 明确区分意图与实际使用的配置，并说明资源缺失或应用不成功时，intended 中的数据可以不出现在 operational 中。

但 operational 中出现配置也不是终点。应先记录父接口和所有候选子接口的计数器基线，再一次只发送一种受控帧。接口扩展 revision 19 定义 in-discard-unknown-encaps；RFC 8343 提供通用 packet、octet 与 discard 计数。目标子接口单独增长、peer 不动，支持分类结论；负向报文只推动 unknown-encapsulation discard，则支持丢弃结论。

计数器仍是汇总证据，不能保存具体字节，也看不到路径后段的丢包。入口抓包证明测试帧实际携带什么标签；分类与改写后的抓包证明线上出现了什么字节。两处记录应使用可关联的时间、流标识与基线，避免背景流量借走测试结果。

对于 L3，RFC 8349 中的 RIB 与 active route 仍是控制面状态，不能代替硬件 FIB、邻接与出口抓包。对于 L2VPN，则要继续核对服务绑定、远端 attachment circuit 与目的端观察。最终可以成立的结论应当很具体：这些帧在这些时间以这些标签进入，只推动了这个分类器，以这些改写后的字节离开，沿这条被观察的路径到达这个端点。

确定性配置让这句话可测试，却不会自动让它成真。

主要来源

本稿采用的封闭一手来源集包括 revision 18 的两种公开格式、Datatracker 条目与历史页、配套接口扩展草案的两种公开格式，以及 RFC 6241、7950、7799、8040、8341、8342、8343 与 8349：https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.html; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/history/; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc7799.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8343.html; https://www.rfc-editor.org/rfc/rfc8349.html。