[STDS-802-11] FW: [STDS-802-11-TGAK] Proposal about 802.1Qbz
--- This message came from the IEEE 802.11 Working Group Reflector ---
Pardon the repeat for TGak mailer users. Donald Eastlake suggested I
forward this to the whole 802.11 mailer.
-- Norm
-----Original Message-----
From: Norman Finn <nfinn@xxxxxxxxx>
Date: Friday, August 9, 2013 13:37 PM
To: "STDS-802-1-L@xxxxxxxxxxxxxxxxx" <STDS-802-1-L@xxxxxxxxxxxxxxxxx>,
"STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx" <STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGAK] Proposal about 802.1Qbz
>Some of the reasons in favor of this:
>
>I've put that comment in on the current TG ballot to this effect. Two of
>the reasons are:
>
>a. Most importantly, I can delete clauses 12 and 17, I don't have to
>create a MIB to support the option.
>
>b. As a minor side issue, nobody has to implement two ways of decoding a
>tagged frame in their ASICs.
>
>
>Relative priorities aside :) I would also point out that, if some station
>has some kind of tagging protocol today that uses the LLC-Only scheme
>(other than 802.1Q tags!!!), then it will continue to work, because the
>bridge won't notice it any more than it does, today.
>
>The only danger I see to the whole scheme is if anybody today is shipping
>Wi-Fi stations that add Q-tags using the LLC-Only format, e.g.:
>
>|AA AA 03 00 00 00 81 00|01 23|AA AA 03 00 00 00 08 00|ipheader
>| LLC/SNAP |EthT |CVID | LLCSNAP |EthT | Ipgram
>
>(NOTE: There is no length field, anywhere, there.)
>
>If anybody does this, today, then PLEASE SPEAK UP!!! Otherwise, we can
>get rid of this obnoxious and expensive option.
>
>-- Norm
>
>-----Original Message-----
>From: Norman Finn <nfinn@xxxxxxxxx>
>Reply-To: Norman Finn <nfinn@xxxxxxxxx>
>Date: Friday, August 9, 2013 13:19 PM
>To: "STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx"
><STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx>
>Subject: [STDS-802-11-TGAK] Proposal about 802.1Qbz
>
>>Let me raise a technical issue about 802.1Qbz on the mailing lists.
>>
>>1. REMINDER OF CURRENT STATE
>>
>>As we discussed in Geneva, P802.1Qbz D1.1 (and D1.2, now out for
>>balloting) uses a new way of stacking tags on LLC media. The result of
>>this method, applied consistently, is that everything in the frame is
>>length/type encoded except for the outermost tag or PDU, which is LLC
>>encoded. For example, an 802.11 IPgram with both a VLAN tag and a CN-tag
>>(never mind for a moment that we may not allow CN tags) would look like:
>>
>>a: LLC-Ether encoding:
>>
>>|AA AA 03 00 00 00 81 00|00 17|22 E9|12 34|08 00|ipheader ...
>>| LLC/SNAP |EthT |CVID |EthT |FloID|EthT | IPgram ...
>>
>>
>>This is different than the way that 802.1Q-2013, if applied as I read it,
>>says it would look like, which is:
>>
>>b. LLC-Only encoding:
>>
>>|AA AA 03 00 00 00 81 00|00 17|AA AA 03 00 00 00 22 E9|12 34|AA AA 03 00
>>00 00 08 00|ipheader ...
>>| LLC/SNAP |EthT |CVID | LLC/SNAP |EthT |FloID| LLC/SNAP
>> |EthT | IPgram Š
>>
>>c. VLAN-tagged BPDU:
>>
>>Just for contrast, an S-tagged 802.1D customer-tagged BPDU (which is
>>perfectly legal) encoded in LLC-Ether format would look like:
>>
>>|AA AA 03 00 00 00 88 A8|00 48|00 26|42 42 03|BPDU Š
>>| LLC/SNAP |EthT |SVID |Lngth|D/SSAP C| protocol ID, Š
>>
>>(The length field would not be present using the LLC-Only encoding)
>>
>>d. Making a choice
>>
>>
>>In D1.1 and D1.2, the default operation is to use LLC-Ether encoding on
>>LLC media, and we have a variable that says, "Use LLC-Only encoding on
>>this port, instead of the default LLC-Ether encoding, if this is an LLC
>>medium. (We always use EtherType encoding on non-LLC media.)
>>
>>2. THE QUESTION
>>
>>Can we get rid of this variable, always do LLC-Ether encoding, and forget
>>about the LLC-Only encoding?
>>
>>I'll follow up this question with my arguments in its favor, and invite
>>others to speak up on the issue, whether you agree with me or not. Feel
>>free, also, to ask questions about how and why we arrived at the point
>>where we are, now.
>>
>>-- Norm
>>
>>_________________________________________________________________________
>>_
>>_____
>>
>>IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
>>request to this
>>CLOSED reflector. We use this valuable tool to communicate on the issues
>>at hand.
>>
>>SELF SERVICE OPTION:
>>Point your Browser to -
>>http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and
>>then amend your subscription on the form provided. If you require
>>removal from the reflector
>>press the LEAVE button.
>>
>>Further information can be found at:
>>http://www.ieee802.org/11/Email_Subscribe.html
>>_________________________________________________________________________
>>_
>>_____
>
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________