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

Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Mark,

In  my opinion, the features you are asking for go beyond the scope of the comments. 

Even with 11bh with non-MLO, a STA is not required to active scan prior to selecting an AP. 

Furthermore, if the device is multi-link (and likely multi-band) what is the point of band steering? You could use TTLM to steer traffic and possibly use link reconfiguration on BTM to steer traffic flow over multiple links.

In any case, a non-AP MLD can elect to do an ML Probe Request which includes an ML element. I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.

Cheers,

Mike

On Tue, May 7, 2024 at 1:01 PM <mark.hamilton2152@xxxxxxxxx> wrote:

Jay, all,

 

(NOT as chair, but my individual opinion …)

 

I know that I haven’t been very active in this discussion (apologies – too much stuff going on).  However, I find abandoning any identification of an MLD device while it is pre-association to be too much loss of functionality to support.

 

This would eliminate:

  • Pre-association client steering   
    • Which is extremely useful in enterprise and large venue installations
  • Customer support and troubleshooting
    • We are going to extreme lengths to solve the WPA3-Personal transition problems (yes, I know, that’s in WFA, but IEEE is talking about it, also) to help providers with support call overload, but we’re going to shoot ourselves in the foot by bringing back complete opaqueness in helping resolve “I can’t connect” issues?
  • Virtual BSSID
    • This is catching on as a very powerful tool in “multi-tenant” situations.
    • We could solve it by requiring an associated non-AP STA to use its same address (TA?) when scanning/probing for AP-AP handoffs, but I suspect the client devices are not going to want to do probes differently depending on context.

 

These are several of the important advantages that IRM has.  We are balancing between two facilities (IRM and Device ID), each has its advantages and tradeoffs, making each useful in different scenarios.  If we remove all pre-association support from IRM, in my opinion, we might as well remove IRM.  It seems to me that rather than sort out how MAC addresses will be used for MLD devices, we are just “punting” and giving up on trying to solve the problem(s). 

 

I would vote “no” on this direction.

 

Mark

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 9:10
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

 

Hi Jay,


Thanks for producing this document. It looks good to me.

 

Cheers,

 

Mike

 

On Mon, May 6, 2024 at 9:53 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

Hi All,

 

For 24/305, I received new comments from some members to say,  as for the MAC address, the MLD MAC address rather than link MAC address is unique to identify each non-AP MLD.  Based on that, in the latest revision 24/305r5, I change the place of IRM from TA field to ML element. Because some frames, like probe request, public action frame don't include ML element according to 11be baseline. I have to drop the relevent use cases in MLO subclause (Maybe these use case are not very strong in MLO senario) . That's, non-AP MLD may set IRM in MLD MAC address field in basic ML element in authentication and association frame. 

Besides, I have some offline checked with 11bh group members and the Chair Mark, they confirmed that the Reassocation case is out of 11bh scope, and 11bh group intends to git rid of them after initial SA ballot.  To keep this align with the on-going 11bh draft, I change (Re)association to Association in all occurrences in new subclause .  

This is all the change compared with 305r4 that we are ageed with, Welcome futher comments or thought on this.

 

Hi Alfred, 

 

Could you help put 24/305r5 (https://mentor.ieee.org/802.11/dcn/24/11-24-0305-05-00be-cr-for-rcm-relevant-cids.docx  ) to the MAC queue in F2F meeting?

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

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