Summary

  • RFC 9892 gives DLEP Ethernet classification a 12-bit VID: zero ignores the VLAN, 0xFFF is reserved and explicit values end at 0xFFE.
  • RFC 9895 depends on that format but its management section prints 0x0000, 0xFFFF and 0x00010xFFFE; no matching RFC Editor erratum was listed at publication time.

The conformance review had two browser tabs open. Both were official RFC Editor pages. Both described the VLAN Identifier used by the same DLEP extension family. One allowed twelve bits. The other appeared to allow sixteen. A configuration schema could not implement both.

RFC 9895 defines the IEEE 802.1Q Aware Credit Window Extension for the Dynamic Link Exchange Protocol. A modem describes which Ethernet traffic belongs to which logical credit window; a router must have enough credit before it sends that traffic toward the modem. The mapping may use a DLEP destination, VLAN Identifier and Priority Code Point, and a window may serve one flow or several.

The document does not invent its own classifier. It explicitly builds on RFC 9892 and the credit machinery in RFC 9893. A peer that advertises Ethernet Credit Extension Type 5 must support the relevant messages, Data Items, Ethernet classification Sub-Data Item and processing from those two specifications.

That dependency makes the field boundary concrete. RFC 9892’s Ethernet Sub-Data Item places NumPCPs and VID in one 16-bit word: four bits for the count and twelve for VID. Its prose agrees with the diagram. 0x000 means the VID is ignored, 0xFFF is reserved, and explicit classifier values run from 0x001 through 0xFFE.

Section 3 of RFC 9895 gives different literals. It writes the ignored value as 0x0000, reserves 0xFFFF, and says 0x0001 through 0xFFFE may be used. Those are sixteen-bit bounds. The discrepancy is present in both the RFC Editor’s HTML and XML, so it is not a local line-wrap or browser artefact. The public RFC errata search returned no matching entry when this Article was prepared.

That does not make this Article an erratum ruling. The authors or responsible standards process may clarify the text later. Nor does it prove a shipping product accepts an illegal VLAN value. It establishes a narrower fact: two normative-looking parts of the published dependency chain cannot both describe the size of this field.

For the wire, the defensible implementation inference is straightforward. RFC 9895 mandates RFC 9892 processing, and RFC 9892 supplies the actual bit layout. A value above 0xFFE cannot be serialized as an explicit VID without losing information or invading the adjacent field. Implementers should not treat the later management paragraph as permission to expand the packet.

The operational danger begins before serialization. A command line, YANG-like model, REST schema or orchestration system might copy the larger range. One component could reject 0x1234; another could mask it to twelve bits; another could store it and fail only when building the Data Item. A controller might read back the original value while the modem installed a truncated value. Every component would then have a plausible green status and a different classifier.

Silent masking is worse than a loud failure. 0x1001 reduced to twelve bits becomes 0x001. A value intended for an impossible namespace could select a real VLAN. 0x1FFF could collapse onto the reserved wildcard boundary. The exact outcome depends on code, which is why these are test scenarios rather than reported incidents. The review question is whether the system rejects impossible state at admission, not whether a happy-path packet happens to pass.

The classifier also has precedence. Under RFC 9892, when Ethernet and Diffserv descriptions both match, VLAN/PCP wins. A mistaken Ethernet mapping can therefore override the DSCP path an operator expected to govern the packet. RFC 9894 defines the parallel Diffserv-aware credit extension, but its existence is not a fallback guarantee.

Wildcards enlarge the blast radius. RFC 9895 warns that VID or PCP wildcards may catch unexpected flows or new traffic that appears after the rule is installed, and recommends using them only when clearly needed. If an invalid explicit value is rejected while a wildcard remains, the system may continue forwarding through a default window. Availability looks preserved while isolation has changed.

Capability negotiation does not settle configuration semantics either. The extension must be announced during DLEP initialization, and a router faced with more modem windows than it supports may use a subset or reset the session. The mismatch should be exposed through normal management mechanisms. A peer saying “Extension Type 5 supported” proves a protocol capability, not that its northbound API enforces the same VID range or that two implementations truncate identically.

Credit itself remains a separate witness. RFC 9893 tells the router when it may send toward a modem queue. It does not repair a classifier that put the packet in the wrong window, and it does not prove delivery beyond the local boundary. RFC 2475 likewise distinguishes classification, conditioning, per-hop behaviour and service. A tag match is not a service promise.

A useful conformance suite starts at the edges: accept 0x001 and 0xFFE; reject 0xFFF, 0x1000, 0xFFFF, negative values and values with stray high bits; preserve zero only with the documented ignore semantics. It should verify configuration write, stored state, emitted bytes, peer parse, installed classifier and readback as one round trip. It should also test mixed Ethernet/Diffserv matches, wildcard fall-through, session restart, capability subset and rejection logs.

The IANA DLEP registry records Extension Type 5. That shared code point protects interoperability, but it does not watch a controller’s validator or decide which local field accepted an impossible number. Registration is coordination evidence, not execution evidence.

Heng Lu’s Running-Code Primacy supplies the right discipline: ask what the implemented, locally verifiable transition actually accepts and emits. Minimum Initial Specification keeps the common layer narrow enough to test. Reality Layers prevents the document’s status from being mistaken for proof that every implementation converged.

Running code cannot secretly amend an RFC, and a local workaround is not a standards resolution. The proper sequence is to constrain implementations to the defined wire field, document the interpretation, test the boundary, and send the discrepancy into the RFC errata process. Until that happens, an operator should be able to answer one exact question: where is the first component that refuses the thirteenth VID bit?

Sources