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 [cid:image001.png(a)01CFE3D9.6D0DE7F0] Chorus | T : +6448964169 | M :+64272290923 From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Nathan Ward Sent: Thursday, 9 October 2014 2:57 p.m. To: Ewen McNeill; nznog(a)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(a)ewen.mcneill.gen.nzmailto:nznog(a)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 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.
