Summary

  • Revision 18 orders overlapping VLAN matches from two explicit tags through mixed any, one tag, priority-tagged, untagged and finally default; it also requires rejection of collisions within the same level.
  • That order proves what a conforming classifier should choose. Applied configuration, isolated counters, captures before and after rewrite, FIB or path observations and destination evidence are separate receipts for what a device actually forwarded.

Send one frame with outer S-VLAN 10 and inner C-VLAN 21 toward a trunk. The configuration contains a two-tag rule for 10/21, another rule for outer 10 with any inner value, a single-tag rule for outer 10, and a default sub-interface. Four entries appear interested in the same bytes. Only one may own them.

The current revision of the NETMOD draft makes that choice deterministic. A match on two explicit tags or ranges comes first. A mixed pair—one explicit or ranged tag and one any—comes second. A single explicit outer tag comes third. Priority-tagged, untagged and default occupy the fourth, fifth and sixth positions. Within any one position, a device must refuse configurations whose ranges can select the same frame. The crossed case of outer-explicit/inner-any and outer-any/inner-explicit is also rejected when both can catch the same frame.

This is an important control-plane result. It prevents two peer sub-interfaces from claiming equal authority over one ingress frame. It also gives an operator a testable prediction: 10/21 belongs to the two-tag rule, not to the broader candidates below it.

The result is narrower than it first appears.

Two tags are a reading boundary

The model classifies on a tag stack depth of at most two. With two tags, the outer tag must be an S-VLAN and the second tag a C-VLAN for the defined IEEE 802.1Q interworking. A single-tag rule reads the outermost tag. This is not an unrestricted parser for every nested encapsulation a platform may encounter.

The match-exact-tags leaf sharpens that boundary without moving a rule up or down the order. When present, the matched tags must be the complete 802.1Q stack. When absent, additional tags may follow, but this model treats them as opaque payload: they do not participate in classification or rewrite. A three-tag frame can therefore be rejected by an exact two-tag rule or admitted on the first two tags by a non-exact rule. The same precedence order applies in both cases.

That distinction should appear in an acceptance test. Otherwise a successful 10/21 probe can conceal a different result for 10/21/300, while the configuration still looks internally coherent.

“Default” depends on every peer

Default is not a wildcard of equal standing. It selects traffic that no more-specific peer sub-interface has matched. Proving a default decision therefore requires the peer set, not just the default row. A snapshot that omits one specific rule cannot explain why the fallback won.

Priority-tagged and untagged are equally easy to collapse in a loose test. A priority-tagged frame still carries an 802.1Q tag; its VLAN identifier semantics distinguish it from a frame with no tag EtherType. A capture of the test input is the cleanest way to show which case was exercised. A ping label saying “untagged test” is not packet evidence.

Classification and rewrite are separate acts

After choosing a sub-interface, the flexible model can pop or push up to two outer tags. Translation is expressed as pop plus push. Only matched tags may be popped, so a rule that reads one tag cannot lawfully remove two. Rewrites can be symmetrical or independently specified for ingress and egress when supported.

Those are configured relationships. They say what should happen at each direction boundary. They do not show that the ingress line card selected the intended rule, that the rewritten bytes reached the forwarding instance, or that return traffic executed the inverse operation.

The draft itself supplies a decisive warning. Its L2VPN example includes a sub-interface that can classify traffic and remove a tag but is not bound to a service; the classified traffic is dropped. A correct classifier can terminate in a dead end.

Build a chain of bounded receipts

Start with the model and feature set actually advertised by the device. Record the accepted NETCONF or RESTCONF transaction. Then compare intended configuration with applied state. RFC 8342 explains why intended and operational data can differ: unavailable resources or incomplete application can leave configuration unapplied. Operational presence is stronger than a successful edit, but it is not the last receipt.

Drive one controlled class at a time. Establish counter baselines on the parent and every candidate sub-interface, send frames whose tags are captured at ingress, and record the deltas. The companion interface extensions draft adds in-discard-unknown-encaps; RFC 8343 supplies common interface packet, octet and discard counters. A target counter rising while peer counters remain still supports the classifier claim. An unknown-encapsulation counter rising during a negative test supports the drop claim.

Counters remain aggregate evidence. They do not preserve the bytes or reveal a later drop. Capture at ingress to prove the supplied tag stack, and again after the expected pop, push or translation to prove the observed wire representation. Correlate timestamps and traffic identifiers so background traffic cannot borrow the result.

For L3, a RIB or active-route read is another control-plane receipt. RFC 8349 describes routes and next hops in operational state, but does not turn a RIB entry into proof of hardware forwarding. Add platform-specific FIB and adjacency observations, captures on the expected egress, and a remote observation at the destination. For L2VPN, inspect the service attachment and the remote attachment circuit rather than stopping at the local sub-interface.

The correct conclusion is bounded: these frames, at these times, entered with these tags, incremented this classifier, emerged with these bytes, followed this observed path and arrived at this endpoint. Deterministic configuration makes that statement possible to test. It does not make the statement true by itself.

Primary sources

The closed primary-source set comprises the two published representations of revision 18, its Datatracker record and history, both published representations of the companion interface-extensions draft, and RFC 6241, 7950, 7799, 8040, 8341, 8342, 8343 and 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.