OCP ECS

​

Jun 22nd 2021 - Update

​

​

​

​

​

​

​

Sebastiano Bertani

ONIE

HW SWITCH

​

​

​

ONIE

Built by hw vendor

Bootloader

Built by hw vendor

Operational�NOS

Provided by 3rd parties

ONIE

Application layer

kernel

ONIE

Application layer

kernel

Cross compile environment

Application layer

kernel

Cross compile environment

Application layer

kernel

Cross compile environment

1. Extend the application layer
1. Add the call-home option to the waterfall sequence
2. Mechanism to download the NOS from a remote location in a secure way
3. Tools to configure Wi-Fi per every Wi-Fi to be supported (open source e.g. hostapd; proprietary)

​

2) Improve the cross-compile environment

1. Compile for Wi-Fi, including drivers per every hw to be supported
2. Support recent kernels (e.g. 5.4)

​

open discussion

​

1. In the “call-home” function what is home? Multiple options.
1. Anyone could compile ONIE with an ad-hoc home definition, e.g. edgecore could create home.edgecore.com, where it would be possible to select the NOS of choice from an EdgeCore cloud service. In this case every hardware may have their own “home” definition and cloud service to select the NOS of choice.
2. A cloud repository where a unit can connect and be identified, and where unit owner can select the NOS of choice, so that it will be pulled by the unit. This cloud even be a “home” defined by a consortium, e.g. home.ocp.com, where hardware of all hardware companies could connect.

Next step: investigate similar solutions, e.g. TIP Open Wi-Fi solution to this problem.

​

• Decision of protocol to download the NOS from the internet.�Next step: is the protocol used by ONIE in LAN ok for this or something different is needed?�
• Selection of hardware: which types of Wi-Fi are in scope and which chips? Open source drivers or proprietary drivers or both? What is the best option to configure Wi-Fi in a unified way for multi Wi-Fi generations (e.g. Wi-Fi 5, 6, 7) and multi chipset makers?�
• Potential GDPR implications (especially on item 1).�
• Compliance and multi-region compliance aspects.�

​

Continuation (added June 29th 2021)

​

1. Contributions could be open source code on firmware side; and also on cloud side (home infrastructure).�
2. Divide and conquer approach: split the scope into independent sub-scopes (e.g. call-home and wi-fi, one chipset/sdk at the time) and identify companies that see an advantage in each individually.�
3. Taking inspiration from Cumulus Networks and ONIE, an enlighten corporate (with deep pockets) may be needed.�
4. Look for companies that have expertise in PKI (call-home) on multi-chipset development e.g. engineering teams working for Telcos (cross-compiling and unified wi-fi configurator).�
5. Look for companies that use ONIE: INTEL / BROADCOM / MARVEL / IP INFUSION.�
6. Write one pager with activities that need to be done (high lev. specs) + high-lev. pitch.

​

Continuation (added July 27th 2021)

​

• Replica.one is an option to be evaluated to start as a branch development for ONIE and to add Wi-Fi target devices, edge switches. Then, it will be possible for ONIE to be pulled back when / if needed.�
• Discussion about this approach:
1. Will start as a branch of ONIE
2. ONIE may pull it in the future if/when mature
3. Repository to be used: could be setup as a contribution to ONIE with its own repository.

​

• Next steps:
• Organize the logistics to have the repository live.
• Define the testing approach.
• Define target devices, kernel version, drivers: QCA IPQ40XX + ATH10K + kernel (latest LTS?)
• Organize the Application layer sub-project work

​

• Presentations:
• OCP Symposium (Nov 8th): focused on futuristic techs (as a startup competition). [DEADLINE: July 30th]. NO GO.
• OCP Conference (Nov 9th/10th) [DEADLINE: July 27th]
1. LUKA: Replica. Networking track (even if may go under the enterprise track).
2. SEBASTIANO/JACK: OCP ECS scope and purpose (even if may go under the enterprise track).

​

​

​

thank you