>
> Hi Omar,
>
> please see 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 internet 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
>
>
>
>
>>> _______________________________________________
>>> 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
