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.)
- 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.
- 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.
- 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.
- 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.
- 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?
- 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?
- 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?
- 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?
- 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).
- 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.
- 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.”
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
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Wednesday, April 28, 2021 12:00 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577 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 |