| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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] 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 From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx] 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 From: Huizhao Wang [mailto:h_z_w@xxxxxxxxx]
_______________________________________________________________________________ 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 _______________________________________________________________________________ _______________________________________________________________________________ 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 _______________________________________________________________________________ |