Absolutely agree.
Both 8100 and 88a8 now use DEI
Even the 2005 .1ad standard says the 0x8100 c-tag includes "drop_eligable" despite then mentioning CFI.
To further support this RFC7180 says:
In May 2011, the IEEE promulgated [802.1Q-2011http://tools.ietf.org/html/rfc7180#ref-802.1Q-2011], which changes the
meaning of the bit between the priority and VLAN ID bits in the
payload of C-VLAN tags. Previously, this bit was called the CFI
(Canonical Format Indicator) bit [802http://tools.ietf.org/html/rfc7180#ref-802] and had a special meaning in
connection with IEEE 802.5 (Token Ring) frames. Now, under
[802.1Q-2011http://tools.ietf.org/html/rfc7180#ref-802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar
to that bit in S-VLAN/B-VLAN tags where this bit has always been a
DEI bit
Thanks,
Brent
On 9/10/2014, at 5:20 pm, Peter Ensor mailto:ensor(a)clear.net.nz> wrote:
Just for clarification, a 802.1ad (TPID = 88a8) does not
need to have both a SVLAN and CVLAN. It is allowed to only
be a single VLAN tag. This will occur when a an untagged
packet ingresses a BS3/3a/4 type service at the UNI
(Upstream frame). This frame will be wrapped with a SVLAN
but because it did not contain any original CVLAN tag, there
will not be any CVLAN tag in the packet that egresses the
UFB Handover connection.
My reading is that on a 802.1ad interface. the TPID = 88a8
indicates that it is a SVLAN whereas a TPID = 8100 would
indicate that it is CVLAN or QinQ.
Since both TPID's now use the DEI bit (since the 2011
standard) I'm not sure how else the two frames would be
different.
Cheers,
Peter.
Hi Brent,
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
ambiguity.
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).
Ewen
PS: For reference, Nathan's links:
http://www.stephan-robert.ch/attachments/File/TIN08/802-1Q-2005.pdf
https://github.com/yhaz/homeenv/blob/master/specs/802.1ad-2005.pdf
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.
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
This communication, including any attachments, is confidential and may be legally privileged. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. No confidentiality or privilege is waived or lost by any mis-transmission or error. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
