It just gets slightly more confusing���.
In 802.1ad, 9.6 (in the C-tag section before the S-tag semantics quote you have below)
It says:
���The C-TAG TCI field (Figure 9-1) is two octets in length and encodes the vlan_identifier, drop_eligible,
and priority parameters of the corresponding EISS M_UNITDATA.request as unsigned binary numbers and
a Canonical Format Indicator (CFI) as a single bit.���
And that is for a 802.1q 0x8100 ether type.
Which would mean your interpretation is that CFI on 802.1q only applies if there is also an 88a8 802.1ad tag preceding it. Nothing
in the standard states that kind of relationship.
However 802.1ad specifically calls itself an amendment to 802.1q, so in my mind 802.1Q CFI has become DEI due to 802.1ad ��� which
matches up with the Wikipedia article.
Probably not much value in going around in circles on standards here ��� I���ll go back to ALU to see why their implementation does what
it does and that will give us their position/understanding, etc.
If what ALU is doing is wrong, I would expect this to have been changed long before now.
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.
Cheers,
Brent
|
Brent Marquis | Layer
2 Network Specialist |
|
|
From: nznog-bounces@list.waikato.ac.nz [mailto:nznog-bounces@list.waikato.ac.nz]
On Behalf Of Nathan Ward
Sent: Thursday, 9 October 2014 2:57 p.m.
To: Ewen McNeill; nznog@list.waikato.ac.nz
Subject: Re: [nznog] UFB Upload Issues
I have done some reading, it looks like 802.1ad is an amendment to 802.1q. I assumed it was a separate protocol. tl;dr however, 0x8100 means you have a CFI bit, so, set
it to 0 please.
On 9 October 2014 at 2:02:35 pm, Ewen McNeill (nznog@ewen.mcneill.gen.nz) wrote:
On 9/10/14 13:26, Nathan Ward wrote:
> Key bit is ���802.1ad���, not 802.1q. Using 0x88a8 vs 0x8100/0x9100 is
> signalling that you���re using 802.1ad vs. stacked 802.1q, so should set
> this bit appropriate to the tag type.
For those playing along at home:
- ethertype = 0x8100 means 802.1Q or 802.1aq or some pre-standard tag
stacking
- ethertype = 0x88a8 means 802.1ad (standardised double tagging)
- ethertype = 0x9100, 0x9200, ... is pre-standard double tagging (looks
like 0x9100 was the most common of those alternatives).
See, eg,
http://perlmonkey.blogspot.co.nz/2010/07/cisco-versus-ieee-qinq.html
AFAICT the bit in that position in 802.1Q (0x8100) used to mean CFI (eg,
802.1Q-2003) and was changed by 802.1Q-2005 to mean DEI; the bit in that
position in 802.1ad (0x88a8) seems to have always meant DEI. If the bit
is clear (0), then the difference between 802.1Q-2003 and 802.1Q-2005
probably doesn't matter here; if it is set, it obviously does. Joy.
This is not strictly true. 802.1ad updates 802.1q.
It���s perhaps unfortunate that the article on Wikipedia is worded the way it is, as though CFI is deprecated. CFI is still valid in CVLAN tags, which 802.1ad specifies as having TPID 0x8100.
DEI is only valid in SVLAN frames, which have TPID 0x88a8.
<quote>
A distinct Ethertype has been allocated (Table 9-1) for use in the TPID field (9.4) of each tag type so they can be distinguished from each other, and from other protocols.
</quote>
<quote>
The semantics and structure of the S-TAG is identical to that of the C-TAG, with the exception that bit 5 in octet 1, the Drop Eligible Indicator (DEI) bit, does not convey
a CFI (9.6). The priority and drop_eligible parameters are conveyed in the 3-bit PCP field and the DEI bit as specified in 6.7.3.
</quote>
If you���re sending 0x8100, you���re setting CFI, so, make it 0.
> I���m with Don on this one - the frame type bits signal how to interpret
> the following bits, you can���t just swap them around.
Sadly it looks to be even less clear than that. Using 0x88a8 (as Nathan
suggests) appears to clear up the confusion. But using 0x8100 appears
to require asking "umm, which 802.1Q/802.1aq/pre-standard double-tagging
thing was the sender following" if the CFI/DEI bit was set.
So, eg, force clearing that bit as you receive it into your 0x8100
network (and, eg, apply your own QoS), upgrading everything to speak
only modern 802.1Q (ie assume bit is always DEI), or using 0x88a8
(802.1ad) seem to be the only reasonably compatible options to avoid
equipment confusion.
Definitely looks like something that would benefit from being more
clearly documented by Chorus as a technical item RSPs that choose 0x8100
as their ethertype and use this particular product should watch out for.
My view remains the same - LFCs should implement 802.1ad as written, and use CFI for 0x8100 frames and DEI for 0x88a8 frames.
Ewen
PS: It appears one can get actual IEEE 802.1 standards as PDFs here:
http://standards.ieee.org/about/get/802/802.1.html
if one is willing to give up an email address to IEEE (I haven't
actually tried to give them an email address though).
Already done :-)
You can also get them from:
http://www.stephan-robert.ch/attachments/File/TIN08/802-1Q-2005.pdf
https://github.com/yhaz/homeenv/blob/master/specs/802.1ad-2005.pdf
--
--
Nathan Ward