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, 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
_______________________________________________________________________________