Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 24 Feb 2022 08:58:36 +0530
From:   Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
To:     Arend van Spriel <arend.vanspriel@broadcom.com>
CC:     Veerendranath Jakkam <quic_vjakkam@quicinc.com>,
        <johannes@sipsolutions.net>, <linux-wireless@vger.kernel.org>,
        <quic_usdutt@quicinc.com>
Subject: Re: [PATCH v2 1/3] cfg80211: Add NL80211_IFTYPE_MLO_LINK type for
 MLO links on MLD STA
Message-ID: <20220224032835.GA27737@CDCCSTEX0180100-LIN>
References: <1645613200-30221-1-git-send-email-quic_vjakkam@quicinc.com>
 <1645613200-30221-2-git-send-email-quic_vjakkam@quicinc.com>
 <269dcdce-ca21-211f-9f87-bc1dfc7d29b2@broadcom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <269dcdce-ca21-211f-9f87-bc1dfc7d29b2@broadcom.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Wed, Feb 23, 2022 at 01:39:33PM +0100, Arend van Spriel wrote:
> On 2/23/2022 11:46 AM, Veerendranath Jakkam wrote:
> > In contrast, NL80211_IFTYPE_MLO_LINK can't be used to represent AP MLO
> > link since an MLD AP must support pre-11be and 11be clients
> > simultaneously so each AP MLO link affiliated with AP MLD must also act
> > as independent AP for pre-11be clients so each AP MLO link must be
> 
> Not just for pre-11be clients. 11be clients can opt-out right?
> 
> > represented by NL80211_IFTYPE_AP associated with a separate netdev.
> > 
> > Two link AP MLD representation:
> > 
> >                   AP MLD
> >               (netdev + wdev)
> >                  /      \
> >                 /        \
> >            wlan0          wlan1
> >        IFTYPE_AP       IFTYPE_AP
> >     (netdev + wdev)  (netdev + wdev)
> >             |             |
> >             |             |
> >          radio(2G)      radio(5G)
> 
> So the AP MLD is a new IFTYPE? Earlier discussions were suggesting the AP
> MLO links would be bridged, but then there would be only a netdev at AP MLD
> level, right?

Yes, having a separate interface type for AP MLD sound like a clean approach.
Apart from the data path, AP MLD will be involved in control path as well.
AP MLD has its own wdev. Some of the control path APIs using AP MLD
interface are link affiliation/removal, remote MLD STA add, PTK key installation,
and intra-bss forwarding configuration. Also EAPoL frames are expected on
AP MLD interface.

Vasanth