| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Mark, Thank you for your mail. The point I am trying to raise is to clarify the LLDP scope vs GLK MIB manageability….
And let me try to clarify the “coherency” point: -
Currently, an AP could be identified by the LLDP for management reason as indicated by Norm. My guess is since STAs are “passive”
leaf devices they are not identified because as leaf these devices are obviously not part of the network management. Make sense (to me)… -
What I meant with “coherency” has 2 parts:
a)
Coherency between GLK AP and GLK STA: GLK STA are not leaf devices anymore. Although a GLK link is a pseudo wire transparent
to LLDP the question is: should the GLK attributes of an AP be MIB manageable ? If the answer is yes, then shouldn’t the GLK attributes of an STA be manageable too ? If the answer is no, (the GLK attributes are not MIB manageable) what is the meaning of the
AP bit for a GLK only AP ?
b)
“Backward” coherency: If the GLK attributes of an AP are not MIB manageable should the AP bit still be set for other AP MIB
attributes if the AP is configured as GLK only? I hope this mail clarifies a bit my questions. /Philippe From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
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 _______________________________________________________________________________ |