Hi Omar,
please my comments inline in *red* ..
On Mon, Mar 21, 2016 at 8:40 PM, Omar Baldonado <o...@fb.com> wrote:
> Hi Rajat,
>
> This looks really interesting – thanks for stepping forward with this. I
> had a couple of notes/questions to get this started:
>
> - It would be great in your diagram to understand which pieces are
> open source vs. not.
>
> *>>>>> All of it should be open source (assuming the Wi-Fi SoC providers
will open source their drivers / SDK as well). The A-SAI module built on
on top of such open SDKs will be community driven and open source. It will
have the APIs that provide a common provisioning & programming interface
for various such SoC partners like Broadcom, Qualcomm (Atheros) , Intel &
may be the new 'up and coming' Wi-Fi chipset providers like Quantenna and
Celeno { Hopefully they are listening or we can reach out to them to join
the cause}. Obviously A-SAI does not exist today .. however many such
constructs do, we have been using combination of linux iw (
**https://wireless.wiki.kernel.org/en/users/Documentation/iw
<https://wireless.wiki.kernel.org/en/users/Documentation/iw> ) +
chipset/SoC specific drivers to accomplish the similar task that A-SAI
would hope to accomplish. *
> - Also, regarding the open source “cloud" AP manager, do you have a
> particular package/system in mind?
>
>
*>>>>> When branch networking gear like WI-Fi APs and PoEs are part of a
large install base e.g. tens of thousands of units, it is necessary to
automate on-boarding/bootstrapping, initital provisioning as well as CI/CD
aspects of IT automation of such remote units. Such automation can be
accomplished using open source frameworks like Ansible recipes or Salt
Masters (we prefer Ansible for its ease of use but i don't want to invite
the wrath of Salt lovers :) ). But it gets better from there, depending
on network design approach, if the remote branches have a L2 design , then
such APs will be provisioned in a 'transparent bridge' mode where the APs
will backhaul all the user L2 traffic transparently over provisioned L2
overlay (GRE, VXLAN) to some DC site. In an alternative design, these
branch / AP are provisioned as L3 switches , there user traffic aggregation
is not required, however IP services like DHCP, NAT etc need to be remote
managed and automated. Lastly, centralized coordination of Wi-Fi resources
(channels , TX power adjustment etc) is also needed for best possible of
WI-Fi throughput to combat interference scenarios. The goal to provide a
baseline IT automation controller as a open source package.*
>
> -
> - Are you really thinking “cloud”? Or did you mean an open source
> package someone can install “locally” to manage their APs?
>
> *>>>> The latter , i.e. an open source package that can be used locally
or centrally in a private/public cloud based on the deployment model and
size.*
>
> -
> - I’ve generally seen potentially a bunch of functionality in the
> “central controller” or manager, depending on thick/thin AP, but even
> besides that, there’s a bunch of mgmt functionality like upgrading
> images,
> centralized configuration/monitoring/troubleshooting
>
> *>>>> Yes, a disaggregated controller would be required to support
provisioning aspects, user traffic aggregation aspects, RF coordination
aspects etc. Hopefully, as set of open source packages that act as building
blocks. I believe SoNIC can be adapted to a play role here as well , as
layer 2 agg.*
>
> -
> - Regarding SAI or the applicability of any other OCP projects (ONIE,
> ONL), it would be great to get a readout on the available options, just so
> we can all get a sense of the landscape.
>
>
*>>>>> I believe that is where a lot of innovation will happen once a A-SAI
like open source framework is made available. For example, there are many
places where there is no wired connectivity to the branches. Once the chip
vendors provide open Access to SDKs , one could use a Wi-Fi radio as
backhaul as well e.g. provisioning Wi-Fi radios (and maybe tweaking the mac
layer) as specialized backhaul with high gain antennas. possibilities are
endless ! In upcoming calls we can propose an initial set of API semantics
that A-SAI (or whatever name the group chooses for it) should support.*
> Thanks!
>
> Omar
>
BR
Rajat Ghai
CTO
Benu Networks
>
>
> From: <opencompute-networking-boun...@lists.opencompute.org> on behalf of
> Rajat Ghai <rajatg...@gmail.com>
> Date: Monday, March 21, 2016 at 4:55 PM
> To: Jeff Catlin <jeff_cat...@edge-core.com>, Rajat Ghai <
> rg...@benunets.com>
> Cc: "opencompute-networking@lists.opencompute.org" <
> opencompute-networking@lists.opencompute.org>
> Subject: [Opencompute-networking] Work Item proposal for OCP Wi-Fi AP
>
> Hi,
>
> I might be jumping the gun here a little bit , however we @ Benu Networks
> are very interested in pursuing, facilitating & participating in Open
> Branch platforms (specially an Open Wi-Fi AP).
>
> We believe that open desegregated Wi-Fi AP can kickstart a new wave of
> innovation that can radically disrupt the branch office / SMB , similar to
> what is already been happening to OCP based Data Center Switching.
>
> We would love to open up a discussion in the group and see if we can find
> fellow travelers to join us. As a starting point we'd like to offer a high
> level proposal the looks like the one shown below :
>
>
>
> Wi-Fi APs are not your typical switches as 802.11 has big WLAN (RF)
> component that needs a whole different class of management e.g.
>
> - ICM : Interference Counter Measure (Ability to automate interference
> mitigation)
> - 802.1r fast mobility (Ability to provide fast handovers from one AP to
> another) ,
> - 802.11k handoff steering (Ability to interact with user
> devices for AP attach)
> - Band steering policies (2.4 Ghz v/s 5 GHz)
> - Network (SSID) steering policies (Virtual SSID scenarios)
> - Other Network policies like MCS threshold settings for better QoE &
> Service discovery
> - Wi-Fi Telemetry,
>
> Apart from WLAN specific interface, the Wi-Fi AP also has networking setup
> (bridges, tunnels etc.)
> that are also common to non-Wi-Fi capable branch switches .
>
> Finally, Wi-Fi APs also require to have a branch IP router capability that
> includes other networking stacks that are not present in DC switches e.g.
> UPnP (DLNA), PCP etc.
>
> We could create a SAI equivalent for Branch {in this case i have called it
> *A-SAI
> i.e. AP SAI*) ; Such SAI would be common to all Wi-Fi SoCs e.g. from
> Broadcom , Qualcomm, Intel etc.
>
> If the group agrees to move it forward, we (Benu) would be happy to
> facilitate the process as well as contribute user land components mentioned
> above.
>
> BR
> Rajat Ghai
> CTO
> Benu Networks
>
>
>
>
>
> On Mon, Mar 21, 2016 at 5:21 PM, Jeff Catlin <jeff_cat...@edge-core.com>
> wrote:
>
>> That will work for Accton / Edgecore
>>
>>
>>
>> Jeff
>>
>>
>>
>> Jeffrey D Catlin
>>
>> Associate Vice President of Technology
>>
>> Accton Technology Corporation
>>
>> jeff_cat...@accton.com
>>
>> 603-531-1286
>>
>>
>>
>> *From:* opencompute-networking-boun...@lists.opencompute.org [mailto:
>> opencompute-networking-boun...@lists.opencompute.org] *On Behalf Of *Carlos
>> Cardenas
>> *Sent:* Monday, March 21, 2016 1:01 PM
>> *To:* opencompute-networking@lists.opencompute.org
>> *Subject:* [Opencompute-networking] Record # of hardware submissions
>>
>>
>>
>> Howdy,
>>
>>
>>
>> Well, I hope everyone has fully recovered from the OCP Summit a couple
>> weeks ago, because we got some serious work ahead.
>>
>>
>>
>> In the weeks preceding/during/after summit, we received 12 new hardware
>> submissions representing 16 different SKUs across: data center, edge
>> routing, access/campus!!!
>>
>>
>>
>> Now it's time that we review them as a community and this is where the
>> rub is. Prior to the summit, our process was to present submission during
>> the monthly project call allotting 10min for presentation and 5+ min for
>> Q/A. To review the 12 hardware submissions would take us about 3 - 4
>> months; by then, we would have started to receive more submissions
>> therefore staying in a backlog.
>>
>>
>>
>> This is a good problem to have since it only validates the open
>> networking model is not only thriving in data center but expanding into
>> other areas of networking.
>>
>>
>>
>> I would like to propose the following: over the next couple of weeks, we
>> hold 3 hardware submission meetings prior to the next project call (which
>> is April 11) and present a summary then.
>>
>>
>>
>> If this is acceptable, the following vendors and submissions will need to
>> be scheduled (
>> http://www.opencompute.org/wiki/Networking/SpecsAndDesigns#Shared_hardware_specifications_still_under_review
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opencompute.org_wiki_Networking_SpecsAndDesigns-23Shared-5Fhardware-5Fspecifications-5Fstill-5Funder-5Freview&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9OXeVvb4F_3KpIM1FO0Uig&m=al57GC5fUCsKSiqHZRneWVS4zX5ZSz6_Ki_ZZgNKFKs&s=57zdRyLgkpV9PUI8_Egp5X009zJSFtemMl3NR1_2_cI&e=>
>> ):
>>
>> * Agema - POE switch
>>
>> * Alpha - 10GT and 100G (revisit with updated specs)
>>
>> * Edgecore - chassis, edge router, POE switch, wireless APs
>>
>> * Facebook - Wedge100 and 6pack40
>>
>> * Nephos - 10G with Nephos ASIC (this is our first contribution that is
>> based on an accepted switch design: AS5712)
>>
>>
>>
>> Does this work for everyone?
>>
>>
>> +--+
>>
>> Carlos
>>
>> _______________________________________________
>> opencompute-networking mailing list
>> Unsubscribe:
>> http://lists.opencompute.org/mailman/options/opencompute-networking
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencompute.org_mailman_options_opencompute-2Dnetworking&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9OXeVvb4F_3KpIM1FO0Uig&m=al57GC5fUCsKSiqHZRneWVS4zX5ZSz6_Ki_ZZgNKFKs&s=NRW3i1NkRa1r0oD1FPJA-gUELJADDAhSRNMl8xwIAKA&e=>
>>
>> opencompute-networking@lists.opencompute.org
>> http://lists.opencompute.org/mailman/listinfo/opencompute-networking
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencompute.org_mailman_listinfo_opencompute-2Dnetworking&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9OXeVvb4F_3KpIM1FO0Uig&m=al57GC5fUCsKSiqHZRneWVS4zX5ZSz6_Ki_ZZgNKFKs&s=RKBHz7ILqqAiPPw9D-1541P7TT6ey0cP4qs3camEie4&e=>
>>
>>
>
_______________________________________________
opencompute-networking mailing list
Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking
opencompute-networking@lists.opencompute.org
http://lists.opencompute.org/mailman/listinfo/opencompute-networking
