Operating System: All
Platform: All

After re-reading the model, this is a bit more convoluted.

1. There is an ethertype for 802.1ad mentioned in the yang model, however it is not in use. It is not part of the header8021q-type definition.

2. header8021q-type misses the mentioning of 802.1ad ethertype

3. The model is too weak - it does not enforce header field order.

3.1. The first header is either a 802.1ad or 802.1q. If it is 802.1q there are no subsequent headers
3.2. If the first header is 802.1ad and the standard is followed strictly the second header must be 802.1q (some equipment allows multiple stacking).

4. The partial easy fix is to add 802.1ad to the enum - this will enable it in the packet handler. I will submit a patch to that effect shortly.

5. We need to tighten up the model a bit in order for builders, etc to function correctly and as expected (based on model) by the consumers.

Partial fix.

The yang model is too lose to enforce some of the finer points of Ethernet header ordering so we only allow the correct header type here. We do not limit it to perform ordering checks (f.e. - 802.1q can presently be insterted before an ad header which is an incorrect combination).