Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577

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>
Sent: Tuesday, May 4, 2021 3:49 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577

 

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>
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