Bon nombre des concepts qui ont été effleurés dans ce mini guide n’en sont plus au stade de l’expérimentation mais sont déjà massivement utilisés et ceci depuis des années. Dans un document de synthèse réseau [2] Google explique comment les architectures Clos et la centralisation du contrôle leur ont permis de résoudre, depuis dix ans, des problèmes de coûts, de complexité et d’évolutivité de leurs DataCenters.
Facebook a très largement utilisé le concept « Open Hardware » tant pour le réseau que pour beaucoup d’autres composantes des DataCenters.
La NSA (National Security Agency) a utilisé, massivement, le protocole OpenFlow pour organiser son système d’information. Ceci est d’autant plus rassurant que l’objection de la sécurité pouvait être avancée à l’encontre de la centralisation du contrôle [3].
Si on ne prend en compte que le domaine « Open SDN », c’est à dire SDN et le protocole OpenFlow, on a le sentiment d’avoir à faire à un « Patch Panel » virtuel permettant de reconfigurer une matrice de flux à la volée en utilisant les APIs REST pour faire du TE (Traffic Engineering). L’intérêt est mis en avant dans certains domaines d’application comme les gros DataCenters (SDDC), le WAN (SDWAN) et le LAN (SDLAN), mais la vision peut se trouver rapidement étendue. Dès que l’on s’ouvre à d’autres aspects du SDN, alors on se rend compte de l’omniprésence du concept dans de nombreux domaines d’applications et tout l’intérêt qui y est porté dans les secteurs du LAN, du WAN de la sécurité, … Imaginez comment il est possible de mixer la technologie sFlow et la technologie OpenFlow pour contrer des attaques sur des réseaux, comment le concept de NFV peut permettre d’implémenter des VNSFs (Virtual Network Security Functions), comment l’approche « Overlay » peut permettre de reconfigurer un réseau WAN à la volée, comment la pression des commutateurs « Bare-metal » peut pousser les constructeurs historiques à sortir de leurs modèles propriétaires, comment l’automatisation peut accélérer les déploiements et structurer l’intégration continue…
Le positionnement de beaucoup de constructeurs d’équipements est encore sur le mode « OpenFlow-hybrid switch » dans lequel on peut faire coexister un environnement basé sur les VLANs et les filtres sur certains ports, appelés « Normal Ports », avec un environnement basé sur OpenFlow pour d’autres ports. Par opposition, le mode « Green Field » ou « OpenFlow-only switch » appelé aussi « dumb switch » ou switch sans « Control Plane », consisterait à avoir un déploiement homogène basé sur OpenFlow uniquement et sans contrainte d’interopérabilité et de rétrocompatibilité [8].
De la même manière, certains système comme PicOS de Pica8 ou AOS d’Alcatel-Lucent Enterprise utilisent Open vSwitch pour apporter des fonctionnalités de commutateur virtuel et s’interfacer avec des outils de configurations supportant OVSDB, tout en ayant des passerelles entre le système natif et les configurations OVSDB. Nuage Networks VSP, VMware NSX ou OpenStack Neutron associé à OpenDaylight sont réputés s’intégrer avec des commutateurs OmniSwitch Alcatel-Lucent Enterprise.
