OpenFlow, transformé en produit un peu tôt, selon Brocade
Pour David Meyer, le CTO de la division opérateurs de Brocade, OpenFlow est encore un peu jeune pour être utilisé en production sur les réseaux des opérateurs ou au sein des datacenters. Lors d'une conférence et d'une discussion avec SearchNetworking, il revient sur les enjeux des SDN et sur les difficultés à résoudre avant leur adoption en volume.
Le logiciel va transformer les réseaux de demain en un environnement programmable multi-vendeurs et ouvert, mais ce réseau programmable (ou SDN pour Software Defined Network) ne s’appuiera pas forcément sur une architecture à base de contrôleur OpenFlow estime David Meyer, le CTO de la division opérateurs de Brocade.
En fait, on a fait d’OpenFlow un produit de façon trop précoce, a expliqué Meyer lors d’une présentation la semaine passée à la conférence Techs in Paradise 2013 (TIP), sponsorisée par Internet2, ESNet et l’Asia Pacific Advanced Network à Honolulu.
"OpenFlow 1.0 était loin d’être complet d’un point de vie fonctionnalités… Il était bien pour la recherche mais nous rencontrons des difficultés avec bien des aspects du protocole », explique Meyer. Parmi les exemples pointés du doigt figurent notamment des problèmes de correspondance dans les tables de flux où l’information est perdue lors de la communication entre un contrôleur et un commutateur (et vice-versa).
Brocade propose des routeurs compatibles OpenFlow, qui ont été mis en œuvre dans l’infrastructure réseau à 100 Gbit/s d’Internet2 qui interconnecte des centaines de sites de recherche et de formation. L’ingénieur moyen présent à la conférence admet volontiers qu’OpenFlow est un protocole excitant pour le monde de la recherche et qu’il permet de résoudre des problèmes isolés dans les réseaux. Mais il est à des lieux d’être prêt pour la production. Certains travaillent à résoudre les problèmes : par exemple, lorsque les contrôleurs continuent à envoyer des paquets mêmes lorsqu’un lien est tombé ; d’autres travaillent sur la bascule automatique entre contrôleurs en cas de défaillance.
La version 1.3 d’OpenFlow, qui a été approuvée au printemps dernier, devrait permettre de résoudre bon nombre des problèmes rencontrés par les ingénieurs. Mais le fait est qu’il faudra encore de nombreux tests et un environnement dans lequel les ingénieurs soient libres de faire tomber le réseau afin de résoudre les problèmes. Au cours d’une conversation avec SearchNetworking, Meyer a expliqué qu'il s’interrogeait sur le fait que la mise sur le marché rapide de produits pourrait en fait handicaper l’innovation.
« Il nous faut pouvoir tester de nouvelles idées... et créer une culture dans laquelle l’échec n’est pas mal considéré", indique Meyer. Nous n’aurons aucune idée de ce que sera la fonction clé du futur tant que nous n’aurons pas construit un environnement « technique, intellectuel et culturel » qui rende possible l’agilité.
Les contrôleurs centralisés sont-ils une approche trop radicale ?
OpenFlow en tant que langage n’est pas le seul défi des réseaux programmables, estime Meyer. D'une façon générale, les ingénieurs n’ont que des éloges sur le potentiel d’OpenFlow en tant que le langage de communication dans un environnement où ils pourront virtualiser et centraliser le plan de contrôle du réseau en ayant un accès direct au plan de commutation. Pour Meyer, il ne s’agit que de l’une des nombreuses architectures possibles. En fait, centraliser le plan de contrôle est l’une des approches extrêmes dans l’univers des réseaux programmables. A l’autre bout du spectre, il y a l’approche de Nicira qui prône une surcouche logicielle (« overlay ») au-dessus d’une infrastructure physique disposant de son propre plan de contrôle et qui ne se préoccupe pas de la gestion sous-jacente des chemins.
Et puis il y a la voie du milieu qui « permet la programmabilité du plan de contrôle existant ». Par exemple, le groupe de travail I2RS (Interface to the Routing System) de l’IETF travaille sur un framework qui "donne un accès indirect au plan de commutation pour fournir une couche de programmation ", explique Meyer. Cisco a indiqué qu’il entend présenter une stratégie SDN qui prend en compte le plan de contrôle en place. D’autres fournisseurs, comme Brocade, ont affirmé qu’ils supporteront des réseaux OpenFlow hydrides permettant aux ingénieurs de faire fonctionner en parallèle le plan de contrôle existant et OpenFlow.
Le résultat final de ces travaux sera probablement l’apparition d’une approche combinant ces différentes stratégies, explique Meyer – et il semble se moquer de savoir quelle sera l’approche retenue. La vraie magie des SDN sera de rendre possible la création d’environnement disposant d’API ouvertes et permettant à tout constructeur ou éditeur de s’intégrer et de créer un environnement logiciel susceptible d’être intégré dans un framework orchestrant les couches de réseau, de stockage et de calcul.
Cela nécessitera un « langage commun » à même de parler à un commutateur, à une baie de stockage ou à un serveur et l’utilisation d’une infrastructure commune pour administrer l’ensemble », indique Meyer. OpenFlow pourrait bien ne pas faire l’affaire dans ce contexte.
Le plus difficile est que ce type d’environnement va nécessiter de casser les différents silos traditionnels dans les environnements IT, et il faudra aussi que les fournisseurs acceptent d’ouvrir leurs matériels et leurs logiciels. Les fournisseurs redoutent la perspective de tels concepts, indique Meyer. « Ils n’aiment pas les écosystèmes. Ils aiment contrôler les environnements de bout en bout… »
