Juniper : «Le SDN au service des problématiques réseau»

Silicon.fr - Vous annoncez votre stratégie pour SDN, pourquoi ?

Ahmed Guetari - Nous adoptons en effet une stratégie délibérée pour SDN, qui répond à la demande du marché, mais nous l'annonçons sans apporter de perturbations. Nous ne répondons pas à un phénomène de mode. Juniper a toujours pour objectif de résoudre les problèmes les plus complexes du réseau, c'est comme cela que nous avons fait la différence. De plus, la définition de SDN, qui est de centraliser un point de contrôle du réseau, est exactement ce qu'a été le rôle de Juniper depuis le début. Nous séparons le point de contrôle et le point de données et d'exécution, mais nous mettons tout cela dans la même boîte. Nous faisons exactement la même chose avec SDN, la première règle est de centraliser tout ce qu'il est possible, et la seconde d'automatiser tout ce qui peut l'être. Cela se traduit par un mélange du protocole OpenFlow et de workflows SDN.

Nous avons deux premiers domaines d'application : le datacenter, pour les opérateurs ou pour les entreprises, pour répondre à leurs problèmes d'automatisation et d'orchestration entre le monde des serveurs et le monde des réseaux ; et le réseau EDGE, là où est la valeur ajoutée par l'automatisation qu'apporte SDN. Concernant EDGE, l'objectif est la connexion de plusieurs services, la sécurité, la voix, etc. Tous les services doivent être implémentés sur le EDGE du réseau. C'est compliqué sur un routeur, mais dans un contexte à la demande, SDN permet de virtualiser les services dans le routeur ou liés au client. SDN permet de virtualiser les fonctions et de les connecter au routeur et aux serveurs déployés à proximité ou dans le cloud, provisionnés par des connecteurs SDN.

Que vous apporte SDN ?

SDN s'annonce comme une nouvelle approche pour régler les problématiques de réseau, en particulier les problématiques techniques au niveau de l'architecture. La configuration du réseau est chère et complexe, l'opex commence à aller au delà de ce qui est acceptable. De plus, le développement des fonctionnalités est un processus qui peut prendre de an à un an et demi. Nous devons prendre en compte la complexité du logiciel, le nombre de versions multiplié par le nombre d'équipementiers. Il faut valider que tout marche avec tout. Offrir un packaging de toutes ces fonctions devient compliqué, avec un facteur d'échelle limité car c'est lent et cher. La fiabilité des réseaux est en dessous des attentes, et elle baisse avec la complexité.

Par ailleurs, les outils développés pour l'automatisation coûtent plus que l'infrastructure derrière. Idem pour le changement des règles, qui restent très manuelles. Les réseaux sont monolithiques, avec des fonctionnalités indépendantes, et en silo. Or ce n'est pas l'infrastructure qui doit piloter l'offre, c'est le contraire. Les applications doivent définir ce qu'il y a dans les couches de réseau.

Avec SDN, nous avons trouvé un moyen de répondre à la configuration statique par l'automatisation. Comment ? En étendant la séparation des différents plans, le contrôle, la donnée, le service, le management. Nous commençons par centraliser les plans de management et de contrôle. Le plan de service peut être distribué, centralisé dans le cloud pour offrir différents services avec plus de capacités. Nous utilisons le modèle Google, « fast lane », pour lancer des lignes d'applications. Si une application ne fonctionne pas, elle est retirée sans dommage. Nous nous efforçons de disposer de plateformes communes afin de limiter la complexité. La standardisation permet de ne pas utiliser de protocoles propriétaires.

Par standard, entendez-vous OpenFlow ?

OpenFlow n'est pas forcément le standard, il en existe d'ailleurs de multiples versions. OpenFlow est même loin d'être parfait, ni d'avoir fait ses preuves. Et il lui manque la granularité de la standardisation. Nous ne sommes pas convaincus de l'intérêt d'OpenFlow, mais nous supportons les versions 1.1, 1.2 et bientôt 1.3 sur nos équipements. Nous montrons notre bonne volonté. Tout en continuant de nous interroger sur le protocole pour faire communiquer les API et le plan de contrôle, vertical et horizontal.

SDN est-il un hyperviseur ? Et vos outils d'administration peuvent-ils le supporter ?

Avec SDN, on imagine le matériel comme une commodité. C'est faux ! La couche de contrôle doit régler des problèmes particuliers dans des environnements hétérogènes, or il faudrait autant de couches de contrôle que de fabricants. Pour standardiser la communication avec SDN, il faut exploiter les protocoles existants. Sur les outils de l'IT, les protocoles sont définis, ce sont ceux que nous utilisons.

Vous évoquez le datacenter. Quelle y est votre légitimité ?

Il est vrai que nos chiffres n'affichent pas une importante base installée. 137 réseaux déploient Q fabric et GFX. La tendance n'est plus à la consolidation mais aux petits datacenters régionaux. Mais un problème n'est pas encore réglé, l'orchestration de l'overlay dans un datacenter ou un cloud. Seul Amazon le peut. Et notre solution ! Nous offrons la même agilité que AWS, ce qui est très important. L'allocation des ressources et le mouvement des VM ne prennent que quelques secondes chez AWS, au mieux quelques heures chez un opérateur. Cet écart ne peut tenir, c'est pourquoi nos recherches portent également sur l'orchestration instantanée.

Jusqu'à la mi 2012, le SDN présentait un intérêt pour la R&D, mais pas pour les patrons opérationnels. Avec la forte demande de tests, nous avons fait la démonstration du règlement du modèle de complexité. Il faut en finir avec l'approche de l'overlay à l'aveugle. Nous sommes conscients du réseau, à compléter d'une fonction d'analytique pour la visibilité de ce qui se passe. Mais nous avons également la crainte de la commoditisation à outrance. Notre objectif est de savoir tout ce qui se passe dans le réseau et de disposer d'un tableau de bord qui montre le risque que prennent ceux qui parlent de SDN sans connaître le réseau.

Notre approche est pragmatique. Nous ne nous intéressons pas au SDN parce que c'est la mode. Nous réglons les problèmes par étape, tout en restant fidèles à notre ligne.

Voir aussi

Silicon.fr étend son site dédié à l'emploi IT
Silicon.fr en direct sur les smartphones et tablettes