Système d’exploitation réseau SONiC et désagrégation

Résumé exécutif

Microsoft a développé SONiC pour Azure et l’a publié via l’Open Compute Project en 2016, créant une architecture partagée Linux, de conteneurs et de bases de données pour des commutateurs de plusieurs fournisseurs de matériel.
L’interface d’abstraction de commutation (Switch Abstraction Interface, SAI) fournit à SONiC un vocabulaire commun pour programmer différents ASIC, mais les capacités de la plateforme, l’échelle, le comportement en cas d’erreur et le support dépendent toujours des implémentations des fournisseurs et des SDK propriétaires.
La gouvernance de la Linux Foundation a élargi la participation sans supprimer l’influence de Microsoft. L’autorité technique, le financement du projet, le développement de SAI et le support en production restent répartis entre plusieurs institutions et entités commerciaux.
SONiC s’étend aux systèmes de châssis, à la commutation d’entreprise et aux fabrics d’IA avant que la conformité uniforme et la propriété de la sécurité ne soient pleinement matures. Sa crédibilité dépend de comportements mesurables, et non de l’étendue de ses listes de support.

Une route BGP atteint le silicium à travers une chaîne de transferts

Une route du protocole de passerelle frontière (BGP) dans SONiC ne passe pas directement d’un processus de routage à la table de transfert d’un commutateur. FRRouting reçoit la mise à jour, applique la politique et sélectionne la route. Zebra transmet l’état de transfert via l’interface Forwarding Plane Manager, fpmsyncd écrit l’intention applicative dans APPL_DB, et le Switch State Service résout les voisins, les prochains sauts et les interfaces nécessaires.

La demande est ensuite sérialisée via ASIC_DB, consommée par syncd, traduite par une implémentation de l’interface d’abstraction de commutation (SAI) du fournisseur et un kit de développement logiciel propriétaire, et finalement programmée dans l’ASIC.

Cette chaîne explique à la fois l’importance et la difficulté de SONiC. Chaque frontière permet à une partie du système de se développer sans connaître directement tous les autres composants. Le logiciel de routage peut fonctionner sur un modèle applicatif commun, tandis que les fournisseurs de matériel traduisent les objets de commutation standard en instructions requises par leur silicium. Cette même séparation crée davantage d’endroits où l’état souhaité, l’état rapporté et le comportement réel de transfert peuvent diverger.

Les commutateurs réseau traditionnels étaient généralement des produits intégrés verticalement. Le fournisseur combinait le matériel, le système d’exploitation, la feuille de route fonctionnelle et la relation de support, offrant à l’acheteur un interlocuteur unique en cas de défaillance. Cette organisation simplifiait la responsabilité mais liait le choix logiciel, les interfaces d’automatisation et l’approvisionnement matériel au même fournisseur. Les grands opérateurs cloud gérant des dizaines de milliers de commutateurs globalement similaires devaient accepter ce couplage ou construire une plus grande partie de la pile eux-mêmes.

SONiC a suivi la seconde voie. Il utilise Linux comme base, divise les fonctions réseau en services logiciels, échange l’état via des bases de données Redis et place une couche d’abstraction matérielle sous les applications réseau. Le projet ne supprime pas les différences matérielles et ne fournit pas un contrat de support global unique. Il crée une couche logicielle commune qui peut survivre à un changement de fournisseur de commutateur, de fabricant de conception d’origine ou de famille d’ASIC, à condition que quelqu’un réalise et prenne en charge le travail spécifique à la plateforme sous-jacente.

La promesse économique est la désagrégation. Un opérateur peut faire des choix distincts concernant le matériel, le silicium, la distribution du système d’exploitation, l’intégration et le support au lieu de les acheter comme un seul produit. La conséquence opérationnelle est la responsabilité partagée. Une fonctionnalité peut exister dans la version communautaire mais rester indisponible ou se comporter différemment sur une plateforme donnée parce que la limitation décisive se situe dans le micrologiciel, les pilotes, le code SAI du fournisseur, un SDK ou le pipeline physique.

Azure a transformé un problème de flotte en plateforme ouverte

Microsoft a développé SONiC pour Azure avant de le présenter publiquement. Son origine était donc un problème de production plutôt qu’une proposition abstraite de réseau ouvert. Les opérateurs hyperscale ont besoin d’automatiser de grands parcs de commutateurs, de modifier les logiciels plus rapidement que ne le permettent les cycles de produits conventionnels et d’acheter du matériel auprès de plusieurs fournisseurs sans maintenir un modèle opérationnel complètement différent pour chacun.

Microsoft a annoncé sa contribution de SONiC à l’Open Compute Project le 9 mars 2016. Le nom signifie « Software for Open Networking in the Cloud ». Microsoft l’a décrit comme un ensemble de composants de réseau logiciel pour commutateurs et l’a associé à la Switch Abstraction Interface, ou SAI. Cette association était essentielle car une pile supérieure portable aurait offert une valeur limitée si chaque application de routage, d’orchestration et de gestion nécessitait encore une connaissance directe de l’interface de chaque fournisseur de silicium.

SAI fournissait un vocabulaire de programmation commun pour des objets incluant les ports, les VLAN, les routes, les prochains sauts, les voisins, les entrées de contrôle d’accès, les files d’attente, les tampons, les tunnels et les compteurs. Un fournisseur d’ASIC ou de plateforme pouvait implémenter ces objets à l’aide de son propre SDK et de son pipeline de transfert. Les applications SONiC pouvaient alors demander un objet standard au lieu d’intégrer des appels matériels propriétaires dans l’ensemble du code commun.

La participation à l’Open Compute Project a relié le logiciel aux opérateurs de centres de données, aux fabricants de conception d’origine, aux fournisseurs de commutateurs et aux entreprises de silicium qui travaillaient déjà sur le matériel ouvert et la co-conception matériel-logiciel. Microsoft apportait un véritable environnement opérationnel, tandis que le groupe élargi fournissait la diversité matérielle nécessaire pour tester la promesse du projet. Aucun de ces facteurs ne rendait la portabilité complète.

Chaque plateforme nécessitait encore une intégration de démarrage, des pilotes, une gestion thermique, la gestion des optiques, une implémentation de SAI, un support SDK et des tests continus.

Le travail moins visible est devenu le fondement de l’écosystème. Le code commun de routage, d’orchestration et de gestion pouvait être partagé, tandis que les entreprises les plus proches du matériel maintenaient les couches spécifiques à la plateforme. Microsoft continuait de fournir de l’ingénierie et des exigences issues d’Azure, mais d’autres opérateurs cloud, fournisseurs et intégrateurs ont acquis un accès au projet qui ne dépendait pas uniquement de la feuille de route interne d’une seule entreprise.

Cette histoire rend le rôle actuel de Microsoft plus facile à comprendre. L’entreprise a créé SONiC et accumulé des années de connaissances opérationnelles avant qu’une gouvernance neutre ne soit établie. Le déplacement du projet n’a pas effacé cet avantage. Il a créé un cadre dans lequel d’autres entreprises pouvaient investir, gouverner et contribuer sans prétendre que l’expérience de production du créateur était devenue interchangeable du jour au lendemain.

Linux et Redis ont rendu le commutateur modulaire — et avec état

SONiC est généralement décrit comme un système d’exploitation réseau basé sur Linux, mais Linux seul n’explique pas son architecture. Le système hôte fournit le noyau, l’accès aux périphériques et les services de base. Les principales fonctions réseau s’exécutent dans des conteneurs distincts, tandis que les bases de données Redis fournissent l’état partagé et les interfaces de messagerie par lesquelles ces services se coordonnent. Le Switch State Service convertit l’intention applicative en opérations SAI, et un processus orienté matériel relie ces opérations à l’implémentation du fournisseur.

La structure en conteneurs a historiquement séparé des fonctions telles que le routage, le protocole de découverte de la couche liaison (LLDP), le protocole simple de gestion de réseau (SNMP), l’agrégation de liaisons, la surveillance de la plateforme, les bases de données, SWSS et la synchronisation ASIC. La séparation améliore l’empaquetage et la propriété organisationnelle, mais il ne faut pas la confondre avec une frontière de sécurité forte dans tous les cas. Les services réseau peuvent partager les ressources de l’hôte et nécessiter des privilèges élevés pour interagir avec le noyau et le matériel.

Leur valeur réside principalement dans le fait de permettre le développement, le redémarrage et la mise à niveau des composants sans compiler l’ensemble du commutateur en un processus opaque.

Redis fournit le langage commun. CONFIG_DB contient la configuration souhaitée. APPL_DB transporte l’intention de transfert et de service au niveau applicatif vers la couche d’orchestration. ASIC_DB représente les objets SAI sérialisés pour le processus orienté matériel, tandis que STATE_DB enregistre l’état de préparation d’exécution et les dépendances. COUNTERS_DB stocke les statistiques d’interface et de matériel utilisées par les outils opérationnels et la télémétrie.

La configuration peut être introduite par des fichiers, des outils en ligne de commande, gNMI, REST ou d’autres logiciels de gestion. Les processus de gestion traduisent cette entrée en opérations applicatives, et SWSS consomme l’état résultant. orchagent résout les dépendances et crée des requêtes SAI, sairedis les sérialise dans ASIC_DB, et syncd appelle la bibliothèque SAI et le SDK du fournisseur. Des composants écrits dans différents langages et maintenus par différentes équipes peuvent ainsi se coordonner via un état défini plutôt qu’un maillage dense d’appels privés.

Le résultat est une machine à états distribuée. Une clé de base de données peut devenir obsolète, un rédacteur peut concurrencer un autre, et une application peut accepter un état souhaité avant que le matériel ne le rejette. Les compteurs peuvent exercer une pression sur le chemin de la base de données, tandis que les redémarrages nécessitent que plusieurs conteneurs reconstruisent une vue cohérente de ce que le commutateur devrait faire. Redis n’est pas un détail d’implémentation passif. Ses schémas, sa persistance et son comportement en cas de défaillance influencent la fiabilité de l’ensemble du système.

La modularité rend ces transitions plus visibles. Les opérateurs peuvent inspecter où une demande est parvenue et identifier quel service possède l’étape suivante. La visibilité ne garantit toutefois pas la correction. Une route sélectionnée dans FRRouting, écrite dans APPL_DB et représentée dans ASIC_DB peut encore être absente du matériel de transfert. Le système a besoin de réconciliation, de diagnostics et de preuves de trafic capables de distinguer l’acceptation administrative de la remise effective des paquets.

SAI a déplacé la frontière propriétaire sans la supprimer

SAI est la principale raison pour laquelle SONiC peut maintenir une architecture supérieure largement commune à travers plusieurs familles d’ASIC. orchagent peut demander une route, un port, un prochain saut, une entrée de contrôle d’accès, une file d’attente, un tunnel ou un compteur sans contenir les appels SDK d’un fournisseur. Cela réduit le couplage et donne aux applications réseau un modèle objet stable même lorsque le fournisseur de commutateur sous-jacent change.

L’interface ne peut pas rendre équivalents des ASIC physiquement différents. Le silicium varie en capacité de table, conception de pipeline, architecture de tampon, combinaisons d’objets prises en charge, sémantique des compteurs, fonctions de télémétrie, atomicité des mises à jour, traitement des tunnels et comportement de redémarrage. Un fournisseur doit faire correspondre les objets SAI à ces ressources, souvent par le biais de code propriétaire et d’un SDK que les mainteneurs de la communauté ne peuvent pas inspecter.

Deux plateformes peuvent donc annoncer la même version de SAI tout en offrant un comportement sensiblement différent. L’une peut prendre en charge une plus grande table EVPN, une politique de contrôle d’accès plus complexe ou un redémarrage plus chaud qu’une autre. Une fonctionnalité peut nécessiter une capacité de silicium ou une extension SAI absente d’une puce antérieure. L’interface commune réduit les modifications nécessaires dans les logiciels supérieurs, mais elle ne certifie pas l’échelle ni le résultat.

La frontière de gouvernance renforce la frontière technique. SONiC a été transféré à la Linux Foundation en avril 2022, tandis que SAI est resté sous l’égide de l’Open Compute Project. Les deux communautés se coordonnent, mais elles ne partagent pas des structures de décision identiques. Une nouvelle exigence en matière de télémétrie, de réseau d’IA ou d’Ethernet de montée en puissance peut nécessiter des modifications simultanées des applications SONiC, des définitions SAI, des implémentations des fournisseurs, des SDK et du silicium.

Le dépannage suit la même chaîne. Une demande valide peut échouer dans le code d’orchestration commun, un adaptateur fournisseur, un SDK ou le matériel lui-même. Les mainteneurs de la communauté peuvent voir l’erreur SAI sans avoir accès à la couche propriétaire qui l’a produite, tandis qu’un fournisseur de matériel peut ne prendre en charge qu’une combinaison spécifique d’image et de SDK. Une distribution commerciale peut assumer une plus grande partie de cette charge d’intégration, mais la version communautaire de SONiC ne crée pas un chemin d’escalade universel unique.

SONiC a donc déplacé la dépendance vis-à-vis du fournisseur vers une frontière plus étroite et plus explicite orientée matériel. Il s’agit d’un changement architectural substantiel. Il n’a pas supprimé la dépendance, et en cas de défaillances difficiles, la réponse finale peut encore provenir de l’entreprise qui contrôle l’implémentation propriétaire la plus proche de l’ASIC.

La réconciliation d’état est le prix de la modularité

Une application peut accepter une configuration, l’écrire dans la base de données prévue et signaler l’achèvement avant que la couche orientée matériel ne découvre que l’ASIC ne peut pas créer l’objet demandé. Lorsque l’échec ne remonte pas la chaîne avec suffisamment de contexte, l’état souhaité, l’état applicatif et l’état de transfert réel ne correspondent plus. Un système modulaire rend cette divergence plus facile à localiser, mais lui offre également davantage d’endroits où se produire.

Certaines conceptions historiques de SONiC traitaient les échecs de création ou de définition SAI comme fatals. Arrêter un processus peut être plus sûr que de continuer avec un état matériel inconnu, mais cela peut rendre le commutateur difficile à récupérer. Des travaux ultérieurs de gestion des erreurs ont introduit des conceptions comme ERROR_DB et un retour applicatif pour certains objets tels que les routes et les voisins. L’objectif est de donner à une demande asynchrone un résultat durable que l’application d’origine et le client de gestion peuvent interpréter.

Un changement de configuration peut impliquer plusieurs opérations dépendantes. Le système peut créer un groupe de prochains sauts, ajouter des membres, mettre à jour une route et supprimer un ancien état. Certaines étapes peuvent réussir avant qu’un appel ultérieur n’échoue, et les ressources disponibles du matériel peuvent changer entre la validation et l’exécution. Une annulation littérale peut être impossible ou dangereuse, obligeant le système à corriger vers l’avant pour atteindre un état cohérent.

Le redémarrage à chaud introduit le même problème dans les mises à niveau et la récupération de processus. L’objectif est de redémarrer le logiciel sans abandonner l’état de transfert et sans interrompre tout le trafic. Le nouveau processus doit réconcilier ce que son prédécesseur avait l’intention de faire, ce que Redis contient et ce que l’ASIC continue de faire. Les modifications de schéma, les clés obsolètes ou les dépendances partiellement restaurées peuvent transformer la persistance en une autre source d’incertitude.

Les opérateurs ont donc besoin de plus qu’une réponse de commande réussie. CONFIG_DB peut confirmer qu’une demande a été acceptée, APPL_DB qu’elle a été traduite, et ASIC_DB qu’un objet SAI a été demandé. Aucun ne prouve que les paquets suivent le chemin prévu. Les compteurs matériels, les tests de trafic externes et la réconciliation d’état restent des éléments normaux de la garantie de bon fonctionnement.

L’architecture expose un fait que les systèmes intégrés cachent souvent: la configuration réseau n’est pas une écriture atomique unique. Il s’agit d’une séquence de transitions d’état à travers des composants ayant des comportements temporels et de défaillance différents. La fiabilité de SONiC dépend de la capacité de ces composants à récupérer après un délai, un rejet, un redémarrage et une exécution partielle.

Les systèmes de châssis multiplient à la fois l’échelle et les défaillances

La première image publique de SONiC était étroitement associée à des commutateurs de centres de données à facteur de forme fixe contenant un ASIC de transfert principal. Le projet s’est depuis étendu aux commutateurs haute densité, aux châssis modulaires et aux systèmes distribués de files d’attente virtuelles de sortie avec plusieurs ASIC de transfert, dispositifs de matrice, cartes de ligne et composants de gestion.

Un système multi-ASIC peut exécuter des instances distinctes de Redis, SWSS, syncd, routage, découverte de liens et agrégation de liens pour chaque dispositif de transfert. Chaque ASIC peut avoir sa propre instance de SAI et de SDK. Le logiciel doit déterminer quelles interfaces, quels voisins et quelles routes appartiennent à chaque espace de noms, comment les liaisons internes sont représentées et comment l’état se déplace entre les dispositifs.

Le système plus vaste modifie le domaine de défaillance. Une route peut entrer par un ASIC et sortir par un autre, tandis qu’un lien en face avant dépend d’un chemin de matrice interne. Les compteurs collectés dans des espaces de noms distincts doivent être présentés comme faisant partie d’un commutateur logique unique. Une carte de ligne peut redémarrer tandis que d’autres cartes et le plan de contrôle continuent de fonctionner, obligeant le logiciel à coordonner les versions, la propriété des objets et l’accessibilité de la matrice entre des composants dotés d’un état indépendant.

Les architectures de files d’attente virtuelles de sortie distribuées étendent cette coordination à travers un châssis ou plusieurs instances de commutateur. Les décisions de transfert et de mise en file d’attente peuvent dépendre de la connaissance partagée des ports distants et de l’état de la matrice. Le remplacement de carte de ligne, la redondance du plan de contrôle et la défaillance partielle de la matrice doivent être gérés sans supposer que chaque composant est disponible au même moment.

La version SONiC 202605 comprenait le redémarrage à chaud multi-ASIC limité en tant que fonctionnalité Alpha pour une topologie restreinte. Cette étiquette est aussi importante que la présence de la fonctionnalité. Elle confirme un travail d’implémentation actif tout en indiquant clairement que le redémarrage résilient sur des systèmes multi-ASIC complexes n’était pas encore une capacité universellement qualifiée.

La prise en charge des châssis étend la pertinence de SONiC aux réseaux de télécommunications, aux clouds haute densité et aux infrastructures d’IA. Elle fait également entrer le projet dans des systèmes où les fournisseurs intégrés ont accumulé des années de logique de récupération spécifique à la plateforme. L’architecture ouverte peut rivaliser, mais la couverture de test, le séquencement des mises à niveau et les obligations de support augmentent plus vite que le seul nombre d’ASIC.

La gestion détermine si l’ouverture peut être exploitée

Un système d’exploitation de commutateur commun n’est utile que si les opérateurs peuvent le configurer, l’observer et le mettre à niveau sur l’ensemble d’un parc. SONiC prend en charge les outils en ligne de commande, la configuration statique, SNMP et des travaux impliquant gNMI, YANG, REST, OpenAPI, Translib et des cadres de validation. Les fonctions disponibles dépendent encore de la version, du modèle de données, de la distribution et de la plateforme.

La gestion pilotée par modèle est destinée à traduire une demande externe en système de configuration basé sur Redis. Les modèles YANG définissent des structures valides, tandis que CVL et les composants associés peuvent rejeter les entrées mal formées. Translib et les composants de service mappent les opérations d’API dans des tables SONiC, permettant aux contrôleurs de fonctionner via une interface prise en charge au lieu de manipuler directement les bases de données internes.

La validation de schéma ne peut pas prouver qu’un service demandé est autorisé, compatible avec un autre changement ou réalisable avec les ressources restantes de l’ASIC. Une conception documentée a également décrit des opérations de comparaison et d’échange sans verrouillage général ni annulation. Les développeurs d’applications doivent donc définir la propriété, la concurrence et la compensation au lieu de supposer que la couche de gestion fournit une transaction universelle.

OpenConfig et gNMI montrent la différence entre inclure un composant et finaliser une fonctionnalité opérationnelle. SONiC 202605 incluait sonic-gnmi 0.1, tandis que la télémétrie par envoi OpenConfig YANG restait en Alpha. Une déclaration de support utile doit identifier le modèle, le chemin, l’opération de lecture ou d’écriture, le mode de télémétrie, la version et la distribution du fournisseur. L’affirmation générale selon laquelle un commutateur prend en charge OpenConfig est trop peu informative.

Les interfaces héritées restent nécessaires. SNMP relie les commutateurs aux systèmes de surveillance établis, LLDP fournit des informations sur les voisins, et les services de plateforme exposent les ventilateurs, la température, l’alimentation et les optiques. Le travail sur BMC et Redfish couvre les fonctions de cycle de vie hors bande, mais plusieurs flux de travail associés dans la version 202605 conservaient également le statut Alpha.

La commutation d’entreprise soulève un autre ensemble d’attentes de gestion. SONiC a été conçu pour des environnements hyperscale dont les opérateurs peuvent construire des images, gérer des laboratoires de qualification et entretenir des relations directes avec le matériel. Les réseaux de campus et d’accès nécessitent des fonctions telles que l’alimentation par Ethernet, l’arbre recouvrant, le contrôle d’admission 802.1X et la gestion prévisible des points d’extrémité, souvent pour des équipes sans capacité d’ingénierie à l’échelle du cloud.

Le groupe de travail PENS, couvrant le PoE et les services de réseau d’entreprise, est une tentative de combler cet écart. D’autres groupes abordent la gestion, les systèmes d’exploitation de plateforme, l’intégration BMC, les plans de données virtuels et la documentation. Leur existence montre un travail actif, pas une maturité uniforme. L’adoption en entreprise dépendra du passage des fonctions de la conception et de l’implémentation à l’inclusion dans la version, à la qualification matérielle et à la fourniture commerciale prise en charge.

Les distributions commerciales deviennent particulièrement importantes à cette frontière. Elles peuvent fournir une surface de gestion testée, une politique de mise à niveau, une matrice matérielle et un processus de support autour des composants en amont. La version communautaire de SONiC fournit la base commune; l’opérateur a encore besoin d’une entité possédant le cycle de vie de l’image qui s’exécute réellement sur le commutateur.

Le nom de la Fondation couvre un projet et un fonds affecté

Le nom « SONiC Foundation » peut suggérer une organisation constituée séparément avec son propre conseil statutaire, ses employés et ses comptes. Les archives de gouvernance disponibles appuient une description plus nuancée. La SONiC Foundation est le projet technique et la communauté hébergés par la Linux Foundation, alors qu’aucune société SONiC Foundation constituée séparément ou entité juridique à but non lucratif indépendante n’a été identifiée dans les preuves fournies.

Une structure apparentée, le SONiC Fund, est un fonds affecté de la Linux Foundation. Il collecte et dépense des fonds pour soutenir le projet technique. Son conseil d’administration supervise les adhésions, les budgets, la promotion, les politiques et les éventuels programmes de conformité. Le comité de pilotage technique s’occupe de la direction technique, et bien qu’il soit représenté dans la structure plus large, l’autorité technique et financière reste distincte.

Cette division empêche l’adhésion de devenir un substitut au déploiement ou au commandement technique. Une entreprise peut adhérer au fonds affecté sans exécuter SONiC en production. Un siège au conseil d’administration ne décide pas de chaque discussion de conception, et un contributeur peut influencer le logiciel sans acheter une adhésion Premier. La Linux Foundation administre les fonds et les marques du projet, tandis que les droits sur le code restent régis par les licences et les droits d’auteur des contributeurs concernés.

SAI ajoute une frontière institutionnelle supplémentaire car elle reste une initiative de l’Open Compute Project. Le projet SONiC développe le logiciel d’exploitation commun, le fonds affecté finance et promeut ce travail, l’OCP héberge SAI et les activités matérielles connexes, et les fournisseurs ou opérateurs intègrent les composants résultants avec des commutateurs et un support commercial. Dell Enterprise SONiC et d’autres distributions se situent en aval du projet communautaire plutôt que de transformer la Fondation en un éditeur de logiciels conventionnel.

Cet arrangement identifie où résident les décisions et les responsabilités. Un groupe de travail et le CST peuvent façonner une fonctionnalité, la charte du fonds affecté régit les frais d’adhésion, et les entités de l’OCP développent un objet ou une version de SAI. Un défaut de production peut toujours nécessiter une équipe SDK propriétaire ou le fournisseur qui a qualifié l’image finale. Traiter chaque couche comme une seule Fondation masquerait les frontières que les opérateurs doivent gérer.

La gouvernance neutre n’a pas effacé l’influence de Microsoft

La Linux Foundation a annoncé la transition de SONiC le 14 avril 2022. À ce moment-là, le projet avait dépassé l’apparence d’une pile interne d’une seule entreprise de cloud. Un cadre neutre offrait une adhésion partagée, un financement, des élections, une image de marque et une participation technique à des entreprises qui pourraient autrement hésiter à dépendre d’une gouvernance hébergée par Microsoft.

L’annonce indiquait que SONiC fonctionnait déjà sur des millions de ports et plus de 100 modèles de commutateurs, avec plus de 50 partenaires. Il s’agissait de déclarations du projet et du créateur plutôt que d’un recensement indépendant. Elles montrent néanmoins que le transfert a été présenté comme l’institutionnalisation d’une plateforme déployée, et non l’incubation d’une nouvelle expérience.

La charte du fonds affecté modifiée le 5 mai 2026 permet aux membres Premier de nommer des représentants au conseil d’administration. Les membres Généraux élisent des représentants en tant que catégorie selon la taille de cette adhésion, tandis que les membres Associés n’obtiennent pas de sièges au conseil. Le conseil est normalement limité à 19 représentants votants, sauf augmentation, le quorum est de 50 pour cent, et les décisions ordinaires nécessitent une majorité simple lorsque le quorum est atteint, bien que le consensus soit préféré.

La cotisation annuelle au fonds affecté pour un membre Premier est de 100 000 dollars américains, distincte de l’adhésion d’entreprise requise à la Linux Foundation. Les cotisations des membres Généraux vont de 1 000 dollars pour les organisations comptant jusqu’à 499 employés à 20 000 dollars pour les organisations d’au moins 5 000 employés. Les membres Associés approuvés participent sans cotisation au fonds. La Linux Foundation applique des frais généraux et administratifs de 9 pour cent sur le premier million de dollars de recettes brutes annuelles et de 6 pour cent au-delà.

Ces chiffres expliquent le mécanisme de financement mais ne divulguent pas le budget réel du projet. Aucune recette, dépense, réserve ou allocation annuelle publique du fonds par programme n’a été identifiée. Les réunions du conseil d’administration sont privées par défaut, à moins que le conseil n’en décide autrement, ce qui rend les dépôts techniques et les groupes de travail plus visibles que les choix financiers soutenant les tests, les événements, la promotion ou l’infrastructure.

L’argent n’est qu’une partie du modèle de contribution. Microsoft, les opérateurs cloud, les fabricants de silicium, les fournisseurs de commutateurs et les intégrateurs fournissent de l’ingénierie, des portages de plateforme, des implémentations SAI, des laboratoires, une capacité d’intégration continue, de la documentation et du travail de publication. La valeur de ces contributions n’est pas publiée sous forme de total financier unique, et le projet reste exposé lorsqu’une équipe d’entreprise change de priorités.

Microsoft occupe la concentration la plus visible de leadership actuel. À la date limite de la recherche, Dave Maltz présidait le conseil d’administration, Xin Liu présidait le comité de sensibilisation et Guohan Lu présidait le comité de pilotage technique. Microsoft était également le créateur du projet, un membre Premier, un contributeur actif et un opérateur de production majeur.

La gouvernance plus large est véritablement multi-entreprises. La représentation au conseil d’administration a inclus Alibaba Cloud, Arista, Broadcom, Celestica, Cisco, Dell, Google, Marvell, Nokia, NVIDIA, PLVision, Upscale AI, Nexthop AI et d’autres. L’élection du CST de 2026 a produit un président et huit membres votants associés à Microsoft, Google, Broadcom, NVIDIA, Alibaba Cloud, Cisco, Dell, Marvell et une affiliation indépendante.

Le vote formel ne saisit pas toute l’autorité technique. Le projet décrit un modèle méritocratique et reconnaît un élément de « dictature bienveillante » au niveau des composants ou du projet pour résoudre les conflits. Les mainteneurs et les ingénieurs possédant une connaissance opérationnelle approfondie peuvent influencer les résultats parce que d’autres entités dépendent de leurs examens, même lorsque la gouvernance financière reste distincte.

L’avantage de Microsoft combine des postes de direction avec des preuves opérationnelles d’Azure. Les défaillances, les mises à niveau et les limites d’échelle génèrent des connaissances que les documents de conception publics capturent rarement. Le test de la gouvernance neutre est donc de savoir si d’autres organisations peuvent posséder des sous-systèmes difficiles, contester les choix de conception et maintenir les versions si les priorités de Microsoft changent. La diversité du conseil fournit un cadre; la concentration des contributions et la propriété des mainteneurs fourniraient des preuves plus solides.

Les versions définissent une base de référence, pas un produit certifié

SONiC 202605 montre la quantité de logiciels qu’intègre un système d’exploitation réseau moderne. La version utilisait Debian 13 Trixie, un noyau SONiC 6.12.41, SAI 1.18.1, FRR 10.5.4, Redis 8.0.2, Docker 28.2.1 et Python 3.13.5. Elle rassemblait également la découverte de liens, l’agrégation, SNMP, DHCP, les annonces de routage, la télémétrie et des paquets de plateforme dont la sécurité et le cycle de vie n’évoluent pas selon un calendrier unique.

La liste des dépendances établit une base de référence au niveau de la branche. Cela ne signifie pas que chaque commutateur exécute des binaires identiques. Les images de plateforme peuvent contenir des modules du noyau du fournisseur, des bibliothèques SAI, des SDK, des micrologiciels, des pilotes et de la configuration, tandis que les distributions commerciales peuvent comporter des correctifs absents de la branche communautaire.

Les étiquettes de qualité sont donc essentielles. La version 202605 a classé la télémétrie par envoi OpenConfig YANG, le redémarrage à chaud multi-ASIC limité, les flux de travail BMC Redfish, les opérations de mot de passe de lecteur à chiffrement automatique, la liaison VRF de télémétrie et un cadre d’événements ou d’alarmes comme Alpha. Les utilisateurs peuvent évaluer ces implémentations, mais l’inclusion dans la version n’est pas une promesse de comportement stable sur toutes les plateformes répertoriées.

Les tests doivent couvrir des combinaisons d’ASIC, de commutateur, de topologie, de fonctionnalité, de branche et de chemin de mise à niveau. Les conditions publiques de sonic-mgmt incluent des sauts spécifiques à la plateforme et des échecs attendus. Un saut peut indiquer une fonction non prise en charge, une limitation de test, un problème connu ou un cas non pertinent, et ne doit donc pas être automatiquement traité comme un défaut du produit. La tendance plus large montre néanmoins pourquoi l’expression « prend en charge SONiC » est trop large pour les achats.

Une déclaration de plateforme significative identifie le matériel, l’ASIC, le fournisseur d’image, la version de SONiC, l’implémentation SAI, le SDK, les fonctionnalités testées et le propriétaire du support. Le redémarrage à chaud sur un commutateur fixe donne peu d’indications sur un châssis distribué. Une échelle de contrôle d’accès sur un ASIC ne peut pas être transférée à un autre, et un chemin gNMI dans l’image communautaire peut différer de l’interface offerte par une distribution commerciale.

La communauté peut publier une version commune et un cadre de test, mais la responsabilité de production incombe à l’opérateur et aux parties qui ont qualifié l’image finale. La charte du fonds affecté autorise les programmes de conformité, mais aucune matrice indépendante complète montrant des résultats comparables de réussite et d’échec sur les plateformes actuelles n’a été identifiée. Jusqu’à ce que de telles preuves existent, une version est un contrat d’intégration autour d’un code commun, et non une certification universelle des systèmes construits à partir de celui-ci.

Les fabrics d’IA sont le test le plus rigoureux de la couche commune

Les grands clusters de GPU modifient les exigences imposées aux réseaux de centres de données. L’apprentissage distribué peut générer des flux synchronisés de longue durée, une faible entropie du trafic, des micro-rafales et des performances limitées par le entité le plus lent. Les opérateurs ont besoin d’une bande passante élevée, d’une convergence rapide en cas de défaillance, d’une échelle dense de voisins et de sessions, de preuves de congestion précises et de fonctionnalités pouvant dépendre d’un nouveau silicium de commutateur.

Un article de juillet 2026 de la SONiC Foundation, rédigé par Guohan Lu de Microsoft et Mehak Mahajan de Broadcom, décrivait l’architecture Fairwater de Microsoft et quatre capacités censées être disponibles avec la version 2025.11: une échelle BGP plus élevée, une distribution du trafic sélectionnée à la source basée sur SRv6, le découpage de paquets et la télémétrie de streaming haute fréquence. Le même article décrivait une conception multi-plans et multi-voies destinée à prendre en charge jusqu’à 512 000 GPU.

Il s’agissait de déclarations du projet et des praticiens, non de preuves auditées indépendamment que la totalité du nombre fonctionnait simultanément.

Le travail BGP était décrit comme prenant en charge 512 sessions par commutateur, environ 1 000 routes et 512 prochains sauts dans la conception concernée. FRR 10 et environ 20 correctifs ciblés étaient censés produire une convergence du plan de données inférieure à 100 millisecondes. L’article ne fournissait pas de topologie complète, de distribution en centiles, de spécification matérielle ou de méthode reproductible indépendamment, de sorte que le chiffre appartient à l’architecture rapportée plutôt qu’à SONiC en tant que garantie de performance universelle.

SRv6 et uSID traitent le problème de l’entropie limitée créée par un petit nombre de flux très volumineux. Les chemins sélectionnés par le point d’extrémité peuvent distribuer le trafic de manière plus délibérée que le hachage conventionnel, mais le mécanisme nécessite des points d’extrémité ou des NIC compatibles, une analyse ASIC adaptée, une capacité de table, un support de routage et une récupération en cas de défaillance. La fonctionnalité du système d’exploitation ne fonctionne que dans le cadre d’une pile coordonnée.

Le découpage de paquets préserve un en-tête court d’un paquet abandonné et le transmet afin que la destination puisse détecter la perte plus rapidement. L’article de la Fondation décrivait un cas spécifique au matériel dans lequel les en-têtes découpés provenant de jusqu’à 18 ports d’entrée pouvaient s’écouler par une seule sortie sur un matériel actuel de 512 ports. Le résultat dépend de l’ASIC et du modèle de trafic et ne montre pas que chaque plateforme ou point d’extrémité SONiC prend en charge le mécanisme.

La télémétrie haute fréquence est destinée à capturer des événements manqués par une interrogation plus lente. Le chemin décrit utilise l’exportation de compteurs IPFIX par l’ASIC, Counter SyncD, COUNTERS_DB et soit une analyse sur le commutateur, soit une exportation OpenTelemetry vers des systèmes tels que Prometheus ou InfluxDB. Cette conception place Redis et le traitement de télémétrie à l’intérieur de la boucle de rétroaction du fabric d’IA, augmentant à la fois leur valeur opérationnelle et leur charge de performance.

L’adhésion a suivi la même direction. Upscale AI est devenu membre Premier en février 2026. Supranett a rejoint au niveau Premier le 28 juillet, tandis qu’Exaware, TeraHop et Infrawaves sont devenus membres Généraux. Nexthop AI et d’autres entreprises de réseau d’IA occupent également des rôles de gouvernance ou de groupe de travail. L’adhésion montre un investissement et une intention, non un déploiement, mais elle identifie les problèmes que les entreprises s’attendent à ce que la plateforme commune résolve.

L’Ethernet de montée en puissance rapproche SONiC des systèmes d’accélération qui ont historiquement utilisé des interconnexions spécialisées. Le groupe de travail Scale-Up Ethernet est destiné à traduire les exigences émergentes, y compris les travaux alignés sur OCP E-SUN, en implémentations couvrant la réémission au niveau des liaisons, le contrôle de flux basé sur les crédits, le hachage de flux adaptatif, les en-têtes de paquets de montée en puissance et des fabrics de points d’extrémité plus grands.

L’opportunité est significative. Une implémentation mature pourrait permettre à un seul environnement de système d’exploitation réseau ouvert de desservir de grands fabrics de montée en charge et des parties d’un marché émergent de l’Ethernet de montée en puissance. Les opérateurs pourraient réutiliser les pratiques de gestion, de télémétrie et de plateforme sur une plus grande partie du réseau d’IA.

Le travail n’avait pas atteint une norme universelle achevée ni un large déploiement à la date limite de la recherche. Les exigences évoluaient encore, les fournisseurs pouvaient exposer des fonctions essentielles par le biais d’extensions, et les modifications devaient traverser SONiC, SAI, les logiciels de point d’extrémité, les NIC, les micrologiciels et le silicium. À mesure que SONiC se rapproche du comportement spécialisé des accélérateurs, une sémantique matérielle précise devient plus importante. La couche commune peut s’étendre tandis que la frontière propriétaire sous-jacente devient plus conséquente.

La sécurité est devenue formelle alors que la plateforme était déjà en production

Une image SONiC combine Debian, le noyau Linux, un environnement d’exécution de conteneurs, Redis, FRRouting, des services de gestion, LLDP, SNMP, des composants DHCP, des paquets Python, des pilotes de plateforme, des bibliothèques SAI de fournisseurs, des SDK propriétaires, des micrologiciels et une infrastructure de construction. Une vulnérabilité dans l’une de ces couches peut affecter le commutateur ou son plan de gestion, tandis que la responsabilité de la correction peut être répartie entre plusieurs projets et fournisseurs.

Un groupe de travail public sur la sécurité a été approuvé en juin 2026. Son champ d’application comprenait les nomenclatures logicielles, les informations d’échange sur l’exploitabilité des vulnérabilités, l’hygiène des dépendances, l’analyse statique et dynamique, le fuzzing, les tests d’intrusion, la sécurité de la chaîne d’approvisionnement, le durcissement et le démarrage sécurisé ou mesuré. Brad House de Nexthop AI a été identifié comme président et Qi Luo de Microsoft comme coprésident.

Le document de création reconnaissait qu’un travail de sécurité substantiel manquait auparavant d’une propriété suffisamment claire. La sécurité n’était pas absente: les projets en amont, les mainteneurs et les fournisseurs avaient géré des vulnérabilités, et un processus de signalement existait. L’aveu était que la responsabilité à travers le système intégré n’avait pas été organisée en un flux de travail public visible à la mesure de l’utilisation en production de la plateforme.

Un groupe de travail ne termine pas cette tâche. Un programme mature nécessite des SBOM à jour, des enregistrements de provenance, un tri des vulnérabilités, des constructions signées ou reproductibles, des politiques de correctifs, une gestion des divulgations privées, des rétroportages et des avis spécifiques à la plateforme. Les bibliothèques SAI propriétaires, les SDK et les micrologiciels compliquent la vision en amont parce que la communauté ne peut ni inspecter leur source ni contrôler leurs calendriers de publication.

Les services de gestion méritent une attention particulière. gNMI, REST, SSH et SNMP exposent un contrôle ou des informations privilégiés, nécessitant une gestion des certificats, une conception des rôles, un audit, une gestion des secrets et une isolation réseau. Les conteneurs améliorent l’empaquetage mais ne créent pas automatiquement des frontières de sécurité fortes lorsqu’ils partagent les ressources de l’hôte et nécessitent des capacités élevées. Une compromission dans le chemin d’orchestration ou de base de données peut affecter de nombreux objets de transfert.

Les fournisseurs commerciaux publient leurs propres avis car leurs produits contiennent des combinaisons et des politiques de support différentes. Une vulnérabilité dans Dell Enterprise SONiC ne doit pas être automatiquement généralisée à chaque image communautaire, tandis qu’un opérateur ne peut pas supposer que la page du projet en amont couvre tous les composants propriétaires de son commutateur.

Le groupe de travail sur la sécurité est devenu l’un des tests les plus clairs de la maturité du projet. SONiC a montré que la collaboration ouverte peut intégrer le routage, les bases de données et l’abstraction matérielle. Il doit maintenant montrer que le même modèle institutionnel peut attribuer la propriété à travers une chaîne d’approvisionnement dont les couches les plus sensibles ne sont pas toutes ouvertes.

L’open source déplace les coûts de support plutôt que de les supprimer

La version communautaire de SONiC fournit le code source, l’architecture, les versions, les groupes de travail et un cadre de test partagé. Elle ne fournit pas d’accord de niveau de service de production universel. Un opérateur utilisant le projet communautaire doit toujours attribuer la responsabilité de la qualification matérielle, de l’assemblage d’image, des mises à niveau, des rétroportages de sécurité, de la réponse aux incidents et de la relation avec le fournisseur d’ASIC ou de plateforme.

Les opérateurs hyperscale peuvent accepter cette charge car le contrôle de la pile est la raison pour laquelle ils ont poursuivi la désagrégation. Ils peuvent maintenir des équipes Linux, de routage, d’ingénierie de version et de matériel, gérer des laboratoires de qualification et négocier directement avec les fournisseurs de silicium. Leur modèle opérationnel convertit l’indépendance logicielle en un engagement d’ingénierie interne substantiel.

De nombreuses entreprises et fournisseurs de services ont besoin d’un fournisseur pour absorber une plus grande partie du risque d’intégration. Dell propose Enterprise SONiC avec du matériel qualifié et un support commercial. Nokia fournit des images SONiC communautaires et un support sur des plateformes sélectionnées, tandis que d’autres fournisseurs de commutateurs, fabricants de conception d’origine et intégrateurs proposent leurs propres combinaisons.

Ces offres peuvent établir un chemin d’escalade plus clair, mais elles peuvent diverger en termes de correctifs, de fonctions de gestion, de couverture matérielle et de calendrier de publication.

La couche commerciale est l’endroit où le travail de cycle de vie et la responsabilité sont vendus. Les opérateurs cloud gagnent en flexibilité d’approvisionnement; les fournisseurs de commutateurs et de silicium vendent des systèmes; les distributeurs vendent des abonnements et du support; les intégrateurs vendent de l’ingénierie; et les clients peuvent réduire leur dépendance à un fournisseur intégré verticalement unique. Le fonds affecté lui-même n’a pas d’actionnaires, de valorisation d’entreprise ou de bénéfice autonome publié.

Les entités coopèrent autour de la couche partagée tout en se faisant concurrence au-dessus et en dessous d’elle. Arista, Cisco, Dell, Nokia et NVIDIA peuvent contribuer au même projet tout en vendant des produits différents. Les opérateurs cloud peuvent soutenir des interfaces communes tout en négociant de manière agressive avec les fournisseurs de matériel, et les fabricants d’ASIC bénéficient lorsque SONiC rend leur silicium plus facile à intégrer tout en conservant une différenciation en termes de fonctionnalités et de performances.

La couche commune ne réduit le travail en double que lorsque les entités acceptent un comportement commun. Les implémentations SAI privées, les correctifs en aval et les extensions des fournisseurs peuvent affaiblir la portabilité même lorsque les produits partagent le nom SONiC. Les entreprises sont incitées à contribuer suffisamment pour soutenir l’écosystème tout en conservant suffisamment de différences pour vendre leur propre offre.

Les cotisations rendent la participation financière visible, mais l’ingénierie est probablement la devise la plus importante. Une cotisation Premier de 100 000 dollars américains est importante pour le fonds et modeste comparée au coût de maintien d’une équipe spécialisée ou d’un laboratoire matériel. Les organisations qui fournissent des années d’implémentation et de tests peuvent influencer les résultats par la réalité opérationnelle même lorsque la charte sépare formellement le paiement de l’acceptation technique.

L’absence de budget public du fonds limite l’analyse de la manière dont les priorités financières sont choisies. Une plus grande transparence financière aiderait les opérateurs à comparer les priorités déclarées avec les dépenses consacrées à la sécurité, aux tests, à la documentation, à l’intégration continue et à la conformité. La création du groupe de travail sur la sécurité montre qu’un domaine critique peut rester insuffisamment pris en charge même lorsque l’écosystème comprend des membres importants et bien dotés.

Les acheteurs devraient considérer « à base de SONiC » comme le début de la diligence raisonnable plutôt que sa conclusion. Ils ont besoin de la branche, de la version SAI, du SDK, du micrologiciel, du propriétaire de l’image, des fonctionnalités qualifiées, de la politique de sécurité et du chemin de support. Ils doivent également savoir si l’image peut être reproduite et ce qui se passe lorsque les calendriers de publication de la communauté, des fournisseurs et du matériel divergent.

La désagrégation ne crée un choix que lorsque ces frontières restent visibles. Sinon, un opérateur peut remplacer une dépendance vis-à-vis d’un fournisseur par une dépendance à une image personnalisée, à un intégrateur ou à une construction SDK qui ne peut pas être maintenue ailleurs. L’architecture ouverte rend les alternatives possibles; les contrats de support et l’ingénierie interne déterminent si elles restent utilisables.

Le déploiement est substantiel, mais la comparabilité reste faible

L’annonce de transition de 2022 par la Linux Foundation indiquait que SONiC fonctionnait sur des millions de ports et plus de 100 modèles de commutateurs. En avril 2024, la Fondation faisait état de 4 250 contributeurs issus de plus de 520 organisations et d’une croissance annuelle de la communauté de 20 pour cent. Une biographie de gouvernance indiquait qu’Alibaba exploitait près de 100 000 commutateurs, passerelles et routeurs basés sur SONiC.

Chaque chiffre indique une échelle, mais aucun n’est un recensement audité indépendant. Les totaux de contributeurs peuvent inclure des entités historiques plutôt que des mainteneurs actifs, un modèle pris en charge peut avoir peu de volume de production, et l’adhésion à la Fondation ne prouve pas le déploiement. Les déclarations publiques décrivent des unités différentes et ne peuvent pas être combinées en une part de marché fiable unique.

Des cas nommés fournissent des preuves plus solides d’utilisation. Microsoft a développé et exploite SONiC dans Azure. Alibaba, eBay et l’EPFL ont soutenu la transition vers la Linux Foundation et décrit leur utilisation. Orange a signalé un premier déploiement en production d’environ 90 commutateurs en 2024 et une intention de l’étendre, tandis que les documents de la Fondation ont par la suite mis en avant les déploiements de SAKURAONE, Tokyo-1, Rakuten et des paiements en Inde. Dell et Nokia proposent des produits pris en charge liés à du matériel sélectionné.

Les preuves sont plus que suffisantes pour rejeter la description de SONiC comme un projet de laboratoire expérimental. Il a une origine de production, des dépôts actifs, plusieurs partenaires silicium et matériels, des distributions commerciales et des déploiements opérateurs nommés. Ce qui reste indisponible, c’est une mesure cohérente des systèmes actifs, des ensembles de fonctionnalités prises en charge et d’un comportement comparable entre les plateformes.

Cette limitation devient plus importante à mesure que SONiC s’étend aux réseaux d’entreprise et aux fabrics d’IA. Les chiffres agrégés de ports offrent une confiance de catégorie, tandis que les preuves au niveau de la plateforme déterminent si un déploiement particulier est réalisable. Les opérateurs ont besoin de la version, de l’ASIC, de l’image, de la matrice de fonctionnalités, de l’historique des mises à niveau, de l’historique des incidents et du fournisseur responsable.

SONiC se situe entre les logiciels hyperscale personnalisés et les produits réseau commerciaux intégrés verticalement. Arista EOS, Cisco NX-OS, Junos et Nokia SR Linux proposent des systèmes matures avec une relation de produit prise en charge unique. NVIDIA Cumulus Linux offre une autre approche commerciale basée sur Linux. Dell Enterprise SONiC et les offres Nokia prises en charge commercialisent la base SONiC, tandis que DENT, FBOSS, Open Network Linux, Stratum et Linux switchdev représentent des architectures ouvertes ou développées par des opérateurs adjacents.

L’avantage de SONiC est l’échelle de l’écosystème partagé autour d’un seul modèle Linux, conteneur, Redis, SWSS et SAI. Les opérateurs peuvent inspecter et modifier le code commun, choisir parmi plusieurs voies matérielles et réutiliser des parties de leur automatisation entre les fournisseurs. Son inconvénient est la matrice d’intégration créée par cette liberté. Les performances et le support dépendent de la réussite avec laquelle les couches ont été réassemblées.

La mise en réseau pour l’IA augmente les enjeux parce que les acheteurs acquièrent de grands volumes de commutateurs tout en exigeant rapidement de nouvelles fonctions. Un système d’exploitation commun peut réduire les doublons d’intégration entre les fournisseurs de systèmes et de silicium. La même urgence peut encourager des extensions qui résolvent un déploiement tout en affaiblissant la portabilité. La position de SONiC sur le marché dépendra de la capacité de ses interfaces à suivre le rythme sans devenir des abstractions nominales sur des implémentations incompatibles.

La frontière est visible; la responsabilité doit encore être prouvée

SONiC a changé la commutation réseau en transformant l’architecture interne d’un opérateur cloud en une plateforme logicielle partagée. Linux, les conteneurs et Redis ont créé un plan d’exploitation commun. SWSS a séparé l’intention applicative des opérations matérielles, et SAI a donné à plusieurs familles d’ASIC un modèle objet commun. La gouvernance de la Linux Foundation a fourni une structure plus neutre par laquelle des entreprises concurrentes pouvaient financer et développer le logiciel.

Le projet n’a pas rendu les commutateurs interchangeables. Il ne certifie pas toutes les plateformes répertoriées, ne supprime pas les SDK propriétaires et n’offre pas une expérience de support unique. Une version communautaire peut contenir des fonctions Alpha, tandis qu’une version SAI partagée peut cacher des capacités, des comportements en cas d’erreur et des caractéristiques de redémarrage différents. La coordination de la sécurité ne peut pas contrôler les composants que le projet en amont ne possède ni ne voit.

Ces limites révèlent la véritable contribution du projet. Avant la désagrégation, la frontière matériel-logiciel se trouvait en grande partie au sein d’un seul fournisseur. SONiC en a rendu une plus grande part explicite et contestable, permettant aux opérateurs d’identifier quelles fonctions sont communes, lesquelles restent spécifiques à la plateforme et quel acteur a accepté la responsabilité du système final.

La prochaine phase testera si cette frontière peut rester cohérente à mesure que la plateforme s’étend. Les fabrics de montée en charge pour l’IA exigent une convergence rapide et une télémétrie haute fréquence. L’Ethernet de montée en puissance se rapproche des systèmes d’accélération, les châssis multi-ASIC augmentent la complexité de l’état, le travail en entreprise élargit la base d’utilisateurs, et la gouvernance de la sécurité doit couvrir une grande chaîne d’approvisionnement multi-sources.

SONiC a séparé une partie importante et précieuse du système d’exploitation du commutateur de la pile matérielle d’un seul fournisseur. Il n’a pas séparé le transfert du silicium, et aucune architecture logicielle ne pourrait le faire. L’interopérabilité dépend toujours des implémentations SAI, des SDK, des pilotes, des micrologiciels, des optiques, de la qualification et du support.

Le test observable n’est donc pas le nombre de produits qui portent le nom SONiC. Il s’agit de savoir si différentes plateformes peuvent démontrer un comportement comparable, si la propriété de la sécurité et de la maintenance survit aux changements d’entreprise, et si un opérateur peut passer d’un système pris en charge à un autre sans reconstruire le modèle opérationnel autour d’une autre dépendance non documentée.

SONiC et la séparation inachevée du logiciel de commutation du matériel

Pourquoi c'est important