On 9/10/14 16:03, Brent Marquis wrote:
It just gets slightly more confusing…. [...]
Which would mean your interpretation is that CFI on 802.1q only applies
if there is also an 88a8 802.1ad tag preceding it.
Based on looking at the 802.1Q-2005 specification and 802.1ad-2005
specification that Nathan linked to, it seems to me that the intent of
both 802.1Q-2005 and 802.1ad-2005 was that ethertype=0x8100 would mean
"interpret the header as a 802.1Q VLAN Tag/802.1ad CVLAN Tag", both of
which have the same bit pattern, and semantics -- including a CFI bit
rather than a DEI bit. This is section 9.6 in both specifications
(which makes sense since 802.1ad was based on 802.1Q).
By contrast, in 802.1ad there is a SVLAN tag, with a separate ethertype
(0x88a8), which is the same except that it has a DEI bit in the same bit
position that 802.1Q/802.1ad has the CFI bit. This is section 9.7 in
the 802.1ad specification.
It seems to me that the intent was: if ethertype=0x8100 then bit is
interpreted as CFI, else if ethertype=0x88a8 then bit is interpreted as
DEI. Which gives an unambiguous interpretation, without needing any
context (much easier for an ASCI implementation). So I'm pleased IEEE
seem to have thought of this problem in advance and tried to avoid
However, setting DEI on an 802.1ad frame with ethertype 0x88a8, then
changing the ethertype of the outer tag to 0x8100 ("for compatibility"
:-) ) seems to either (a) require force-clearing that bit to avoid
confusion, or (b) lead to a potential for misinterpretation that causes
traffic to be discarded.
IMO, our interface is .1ad and we don’t believe being
nice and tweaking
the ethertype at RSP request changes that :) but let me see what I can
find out from our Vendor.
FWIW, it appears to me that sending two 0x8100 tags stacked is not
802.1ad, but some "pre-standard" double tagging. Even if the frames
started out 802.1ad compliant. 802.1ad seems to require a SVLAN tag
(0x88a8) around a CVLAN tag (0x8100). Although it appears the
difference mostly only matters for the interpretation of this one bit
(DEI or CFI).
If Chorus is going to offer 0x8100-double-tagging (ie, two 0x8100 tags
stacked, pre-802.1ad Q-in-Q) it seems like it'd maximise compatibility
if you were able to clear bit 5 (CFI on 0x8100/DEI on 0x88a8) of the tag
in that specific case (ie, two stacked 0x8100 tags).
PS: For reference, Nathan's links:
beware the 802.1ad one is a revision 4 draft (they went to revision 6
before the release AFAICT: http://www.ieee802.org/1/pages/802.1ad.html
if you want to argue with vendors it might pay to get the official
standard from IEEE directly.