The change in the CFI to DEI occurred between the 802.1q 2005 and the 2011 versions. In 802.1q 2005 section 9.6 Octet 1 bit 5 was defined for use as CFI (Canonical Format Indicator) whereas in the 2011 version of the standard (also shown in section 9.6), this bit has been redefined as the DEI (Discard Eligible Indicator) bit. The diagram is for a single .Q tag but I assume it also applies to additional tags. Cheers, Peter.
Hi Peter, On 9/10/14 17:09, Peter Ensor wrote:
Thanks for pointing out that the change was between 802.1Q-2005 and 802.1Q-2011, rather than earlier. That clears up my confusion on having looked at the 802.1Q-2005 standard and seeing it clearly saying CFI (and the copy of 802.1ad-2005 I read also clearly saying CFI on CVLAN/0x8100). I am back to being disappointed with IEEE though. Packets with TPID=0x8100 and bit 5 set in them are now ambiguous, since the meaning depends on the version of the standard that the software sending it was following and the interpretation depends on the version of the standard that the software receiving it was following. I can only guess that they thought "it wasn't used much before so they might as well change it to be consistent with 802.1ad/SVLAN as that's a more useful modern meaning". However backwards incompatible changes (without "bumping a version number") almost inevitably cause interoperability issues -- and there's no "in-packet" version number to bump here. (Changing ethertype is the only sane thing at that point, which presumably didn't happen here because it'd require a whole lot more implementation effort.) For anyone else that wants to check, this is section 9.6 of 802.1Q-2011, on page 150 of the standard PDF, which clearly says "DEI"; downloaded from the "getieee802" program: http://standards.ieee.org/findstds/standard/802.1Q-2011.html http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf (which it turns out to allow a blank email address :-) You just need to say what sort of user you are and click accept). For comparison, the official 2005 standard PDF can be downloaded in the same way here: http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf and on page 76 (also section 9.6) it clearly says CFI, as I'd found previously. There is a note about this change on page 151 of the 802.1Q-2011 spec, saying: -=- cut here -=- NOTE—Previous versions of this standard used bit 5 of octet 1 of the TCI in Customer VLAN tags as a Canonical Format Indicator (CFI). Bridges conformant to this version of the standard will not interoperate with bridges that set the CFI as a result of inserting Customer VLAN tags in frames received from an 802.5 Token Ring LAN. Bridges conformant to this version of the standard will interoperate with bridges that forward bit 5 of octet 1 as a CFI but do not have 802.5 Token Ring interfaces. -=- cut here -=- so IEEE were clearly aware of (some of) the implications of this change. But IMHO should have paid more attention to the resulting incompatibility issues. For completeness, the 802.1ad-2005 standard PDF: http://standards.ieee.org/getieee802/download/802.1ad-2005.pdf which does seem to be literally a diff on the 802.1Q-2005 spec, and does still talk about CFI in the CVLAN (page 22 of PDF) as I'd found previously. Finally, there's a pretty good presentation summary here of how what is now in 802.1Q-2011 it has evolved over time and the motivations for it: https://www.ietf.org/meeting/86/tutorials/86-IEEE-8021-Thaler.pdf which includes the explanation that upper case letters are used for primary standards, and lower case letters (ad, ah, etc) are used for amendments (see page 9 of slides). Presumably hence the diff of 802.1ad. Ewen
Thanks Peter, Ewen, et al. Interesting one to get to the bottom of! I can't help but feel that the 802.1ad-2005 was either mistakenly left with the mention of "drop_eligable" and CFI in the same paragraph for 1.Q, or someone got nervous and tried to make it ambiguous. I'm glad to see that the 2011 updates make it definitive. It also restores my confidence in Wikipedia :) We'll keep working with the impacted RSPs, and once the dust settles and everyone is up and running I'll back-fill our documentation. Probably worth me putting together some form of technical white paper to explain exactly what happens with our PCP/COS/policers etc. I'll ensure it gets onto this list. Brent Marquis Layer 2 Network Specialist T +6448964169 M +64272290923 E Brent.Marquis(a)chorus.co.nz -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Ewen McNeill Sent: Thursday, 9 October 2014 7:36 p.m. To: ensor(a)clear.net.nz; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] UFB Upload Issues Hi Peter, On 9/10/14 17:09, Peter Ensor wrote:
Thanks for pointing out that the change was between 802.1Q-2005 and 802.1Q-2011, rather than earlier. That clears up my confusion on having looked at the 802.1Q-2005 standard and seeing it clearly saying CFI (and the copy of 802.1ad-2005 I read also clearly saying CFI on CVLAN/0x8100). I am back to being disappointed with IEEE though. Packets with TPID=0x8100 and bit 5 set in them are now ambiguous, since the meaning depends on the version of the standard that the software sending it was following and the interpretation depends on the version of the standard that the software receiving it was following. I can only guess that they thought "it wasn't used much before so they might as well change it to be consistent with 802.1ad/SVLAN as that's a more useful modern meaning". However backwards incompatible changes (without "bumping a version number") almost inevitably cause interoperability issues -- and there's no "in-packet" version number to bump here. (Changing ethertype is the only sane thing at that point, which presumably didn't happen here because it'd require a whole lot more implementation effort.) For anyone else that wants to check, this is section 9.6 of 802.1Q-2011, on page 150 of the standard PDF, which clearly says "DEI"; downloaded from the "getieee802" program: http://standards.ieee.org/findstds/standard/802.1Q-2011.html http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf (which it turns out to allow a blank email address :-) You just need to say what sort of user you are and click accept). For comparison, the official 2005 standard PDF can be downloaded in the same way here: http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf and on page 76 (also section 9.6) it clearly says CFI, as I'd found previously. There is a note about this change on page 151 of the 802.1Q-2011 spec, saying: -=- cut here -=- NOTE-Previous versions of this standard used bit 5 of octet 1 of the TCI in Customer VLAN tags as a Canonical Format Indicator (CFI). Bridges conformant to this version of the standard will not interoperate with bridges that set the CFI as a result of inserting Customer VLAN tags in frames received from an 802.5 Token Ring LAN. Bridges conformant to this version of the standard will interoperate with bridges that forward bit 5 of octet 1 as a CFI but do not have 802.5 Token Ring interfaces. -=- cut here -=- so IEEE were clearly aware of (some of) the implications of this change. But IMHO should have paid more attention to the resulting incompatibility issues. For completeness, the 802.1ad-2005 standard PDF: http://standards.ieee.org/getieee802/download/802.1ad-2005.pdf which does seem to be literally a diff on the 802.1Q-2005 spec, and does still talk about CFI in the CVLAN (page 22 of PDF) as I'd found previously. Finally, there's a pretty good presentation summary here of how what is now in 802.1Q-2011 it has evolved over time and the motivations for it: https://www.ietf.org/meeting/86/tutorials/86-IEEE-8021-Thaler.pdf which includes the explanation that upper case letters are used for primary standards, and lower case letters (ad, ah, etc) are used for amendments (see page 9 of slides). Presumably hence the diff of 802.1ad. Ewen _______________________________________________ NZNOG mailing list 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.
participants (3)
-
Brent Marquis -
Ewen McNeill -
Peter Ensor