| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Duncan, I agree with Mark that we need to add text to address the legacy operation in your document, rather than after this text is accepted. BTW, in order to differentiate the MAC SAP for the MLO from the MAC SAPs for the legacy operation, could you replace MAC SAP by MLD MAC SAP? Similarly, replace the authenticator
with MLD authenticator. Regards Guogang Huang
发件人: Duncan Ho [mailto:dho@xxxxxxxxxxxxxxxx]
Hi Mark, Sorry for the delayed reply. I’ve missed a bunch of responses in this thread. Please see my responses inline below. For now, I keep the latest version locally and will upload it as an R1 later after we finished all the
discussion in the ARC group. From:
mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
CAUTION: This email
originated from outside of the organization. Hi, Duncan, Thanks for this. Good progress! A few mostly minor (I think) comments:
-
As I think you know, I struggle with the Reference model figure (Figure 4-xxx), just stylistically ? I think it is hard to understand/visualize. I’d be happy to work more with you off-line, to see if we can
find an alternative. And, whatever we end up doing with this Figure, we may want to consider a contribution to REVme to do something similar to Figure 4-28 (REVme D0.0), and maybe Figure 4-29. (If nothing else, the NOTEs you have in 4.9.5 would be good to
add in the baseline 4.9.4.) [DH] I saw that Mike already replied and I agree with his preference. I think we can keep polishing this figure stylistically in the ARC mtg.
-
I also think Figure 4-xxx and the text in 4.9.5 is a bit confusing because it doesn’t show/describe that many (most, in fact) of these components are actually shared with the legacy operation STA(s). What is
“shared” and what is not is left to the reader to figure out, and I think that could lead to interoperability problems due to differing assumptions. Also, for example, the text is clear about the link-specific operations, including SAs for GTK/IGTK/BIGTK,
but the figure implies there is only one Authenticator/Supplicant and RSNA Key manager. [DH] I also agree with Mike here that this section is complete for MLO (no legacy) and we could add text and figures to describe legacy operation after this text is accepted.
-
4.9.5, 6th paragraph (counting the NOTEs), I don’t think the MLD MAC address can identify the SME. That doesn’t fit the MAC addressing model from IEEE Std 802. The MLD MAC address is actually identifying
the (single) MAC SAP (or the entity(ies) supporting that MAC SAP, if you’d prefer), which you have described in a later paragraph. [DH] This was fixed during the ARC meeting last week (now it says “The Authenticator and MAC-SAP SME are identified by an MLD MAC address.”
-
5.1.5.1, in the new paragraph that starts “During reception, …”: if we’re mentioning the multiplexing, we probably also need to mention the split between the MLD stack processing and the legacy stack(s) processing,
based on stored knowledge of the peer device/association type. [DH] Agree with Mike we could describe legacy operation separately.
-
Also in that same paragraph, it is not MSDUs from the PHY SAPs that do the multiplexing, but the _MPDUs_ (they haven’t been decrypted/unpacked yet) from the _top of the Lower MACs_ that do this. [DH] Agreed and fixed now in the latest version.
-
I’m not sure why you have changed the order of the functional blocks in Figure 5-3 (compared to the baseline Figure 5-1). We should discuss this re-ordering, and if agreed, update Figures 5-1 and 5-2 to match.
Also, why were some blocks left out completely? [DH] I’ve fixed the order now in the latest version.
-
Comparing the new text to the baseline, I am now realizing that I have no idea what to think of a combination of FST and MLO. I’m not sure that is even useful. Has that been discussed? Can we just rule it
out? [DH] As Mike rightly pointed out, FST and MLO should be exclusive of each other.
-
A nit, but should we really add new subclauses for 5.1.5.10 and 5.1.5.11, or just “fix up” the language in 5.1.5.2 and 5.1.5.3?
[DH] That crossed my mind but at the end I decided to add new subclauses so everything is cleaner.
-
Those subclauses (just above) point out a question I hadn’t tried to think about yet ? is there any reason we can’t do GLK with MLD, or is the plan to support GLK MLD? [DH] I need to think about this. This was never discussed in TGbe as far as I remember.
-
The DA address filtering (and other discussion about MAC addresses) makes me realize that we need to say somewhere that when an MSDU is directed to/from an AP MLD or non-AP MLD, the DA/SA (respectively) are
the MLD address for the AP MLD or non-AP MLD. Do we say that anywhere? That is, to external devices, it is the “MLD address” that is visible on the broader 802 network (I think). [DH] Like Mike pointed out, it’s covered in 35.3.3.
-
For the diagram in 7.1 (new Figure 7-1), this is another spot where I find it confusing that the AP MLD does not have any indication of how the legacy operation works. Especially in this figure, where the legacy
APs also have access to the DS (separately from the MLD AP) I think that really needs to be shown in the figure. I don’t know if you’ve seen the figure I did in 11-21/0396r2 slide 6? I think adding that figure (as a new 7-1a, rather than making Figure 7-1
any more complicated) would be a better approach. [DH] I think we have had more discussion of this diagram in the ARC mtg since this email so hopefully we’re converging.
-
At the end of subclause 7.1, do we need to add “Accept non-AP-MLD-to-AP-MLD mapping updates from the AP MLDs.”? Similarly, in the paragraph above, “mapping of STAs _and non-AP MLDs_ to APs, _AP MLDs_,
or to mesh gates.” [DH] Agreed and added to the latest version. Let me know if it would be better to embed these comments/questions in a document. I’m not sure if reflector dialog is preferred, or document comments… Thanks. Mark Thanks, Duncan From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Hi all, Please see
https://mentor.ieee.org/802.11/dcn/21/11-21-0577-00-00be-cr-mld-architecture.docx and let me know if you have any comments or questions. Thanks, Duncan To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |