Thanks, Philippe,
You and I are aligned on the MAC Bridge bit. I think Huizhao is, too. And Norm… Anybody not in alignment?
But, on the MAC Access Point bit, I’m a bit confused. First, I’m trying to understand how or why the LLDP “layer” would have such a bit, or care. In fact, I’m not sure why LLDP would even “see” an AP in the first place. The AP is transparent to everything above the 802.11 layers. External (outside, or above 802.11) devices only see Portals and non-AP STAs (and mesh STAs, and IBSS/PBSS STAs, but I’m ignoring those for the moment). The AP in the middle of 802.11 communications is no more interesting than a repeater.
Now, having said that, and probably worked everybody up, let me change my mind and recognize that the AP is an important device in the overall network management, however, so we do want LLDP to “see” it. OK. So, the point is that we want to be able to manage the network, and knowing that there is a device that is not a leaf node (but also not a bridge), and knowing that its MIB is an “AP-style MIB” is useful to be able to remotely manage it. I’m good with this view.
Then, the question becomes how we want to treat a GLK-only AP (an AP that only allows GLK-STAs to associate). (Yes, Philippe, I not only agree with you that 11ak does not prevent GLK-only APs, it in fact explicitly enables them on purpose.) I think the most logical view is that these are non-leaf nodes in the network, and they generally have an “AP-style MIB”. They will have a few differences from an AP that supports non-GLK links, but I don’t see that the differences are that significant to overall network management. So, I will still set the MAC Access Point bit to one for such an AP.
Your rationale for the opposite view seems to be related to coherency, but I’m not seeing what coherency you’re referencing. Could you expand on that a bit? Maybe I’ll be convinced.
Mark
From: Philippe Klein [mailto:philippe@xxxxxxxxxxxx]
Sent: Monday, May 25, 2015 3:09 PM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK)
Sorry for the typos. See the fixed text below:
Mark,
MAC Bridge bit:
I agree with you that, for LLDP, the GLK link is transparent and therefore the setting of the MAC Bridge if a function of the implementation of a bridge function “above” the GLK link.
MAC Access Point bit:
For both GLK coherency and backward coherency, it seems to me that the bit must be set only if the Access Point support non GLK links. In other words what I am trying to say is that if an AP is configured to allow the association of GLK-STAs only (nothing in the11.ak standard prevents an AP to be configured this way) then the MAC Access Point bit must probably not be set…
What is your opinion?
/Philippe
Huizhao,
I assume you mean setting the MAC Bridge bit should be based on whether the bridge function is implemented or not, correct?
And, the MAC Access Point bit is set based on whether this is an AP or non-AP device.
Finally, we have no need for a GLK bit, agreed?
Mark
GLk is just one way MAC bridge is implemented, whether setting the bit or not, should be based on whether the bridge function is implemented or not though
From:"Mark Hamilton" <mark.hamilton2152@xxxxxxxxx>
Date:Thu, May 21, 2015 at 12:29 PM
Subject:Re: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK) This is a bitmap, I believe, so can’t it have both WLAN Access Point and MAC Bridge set at the same time, and that implies it is a GLK-capable AP. (There would be no way to distinguish the specific case of a GLK-capable AP that has the “GLK Required” mode set, but I don’t think that level of detail is needed here.) Mark I exactly meant that. That GLK & non-GLK will not be discriminated by the system capabilities word. The question though is what system capability a GLK-STA should use? Mark suggested that a GLK STA is a MAC Bridge and this makes sense but what about the AP as there is already an entry for WLAN access Point and is GLK capable? To be consistent with the GLK STA the system capability must be MAC Bridge too but in the same time the AP could concurrently be a AP for non GLK STAs so what is the System Capabilities word in this case ? Thx /Ph There are only 32 bits in the System capabilities word. I think that distinguishing between GLK and non-GLK is too detailed to be reflected in a word intended to distinguish among bridges, end stations, routers, etc. But, perhaps that’s not what you meant. Hi Don, Please see the message below from the 802.1AB-Rev Editors. Table 8-4—System capabilities (page 32) includes an entry for “WLAN Access Point” [4] and I guess a new entry for STA GLK will be needed as well. (The discrimination between a GLK and non-GLK capable AP could probably be done by querying the referenced 802.11 MIB isn’t ? ) Could you please have a look and contact either John or Tony ? Thank you /Philippe Hi, Regards, -- John _______________________________________________________________________________ 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.
_______________________________________________________________________________ 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. |
|
_______________________________________________________________________________
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.
_______________________________________________________________________________
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.
_______________________________________________________________________________
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.