L’architecture SDN (Software Defined Network) revient à percevoir une infrastructure de réseau à travers des couches logicielles. Histoire, entre autre, de ne plus avoir à se déplacer au moindre dysfonctionnement. Un réseau SDN ne peut cependant pas se concevoir de manière fragmentée et encore faut-il que des infrastructures WAN « logicielles », puissent communiquer entre elles. C’est tout le débat qui monte autour d’une future norme dans ce domaine.

Lors de l’ONUG 2017 de San Francisco, une initiative a été suivie de très près, celle de l’Open OW-WAN Exchange (OSE), une API qui doit permettre à plusieurs architectures WAN SDN de communiquer entre elles. Cette initiative est à mettre au crédit de l’ONUG (Open Networking User Group), un forum, comme on dit de ce côté-ci de l’Atlantique, qui regroupe quelques grands utilisateurs, Bank of America, la banque de New york Mellon, Fedex, etc, mais aussi plusieurs fabricants « intéressés » tels que Huawei ou Cisco, qui se doivent d’être présents, sans pour autant cautionner, dès lors qu’il se passe quelque chose quelque part…

L’architecte OSE a pour objet d’interconnecter 2 SDN construits avec des équipements et logiciels différents : une sorte de passerelle logicielle. Très bonne idée, mais qui est loin de mettre tout le monde d’accord. Pour l’instant.

Les tout débuts…

On en est évidemment qu’aux tout débuts de l’initiative ONUG.

Pour l’instant il n’y a que très peu d’affiliés, chaque fabricant travaillant généralement dans son coin sans se préoccuper des autres. Le SDN se limitant pour lui à sa propre infrastructure, sans qu’il cherche à communiquer avec les autres. On exagère à peine.

Sur le principe, l’idée d’OSE est de construire une sorte de réseau de transport intermédiaire totalement logiciel, pour servir de passerelle entre plusieurs SD-WAN (Software Defined – WAN).

Sur le principe l’architecture en cours d’élaboration comporte une couche d’administration avec les fonctions de visibilité, d’orchestration, de gestion des infrastructures et de Policy, ainsi qu’une couche de contrôle des SDN-WAN proprement dits. Ce qui correspond au découpage Northbound et Southbound, tel qu’on le pratique aujourd’hui.

Le réseau de transport logiciel proprement dit sera interfacé avec différentes installations : d’autres domaines SDN, des extranets, des Clouds publics en mode SaaS ou IaaS, tec, à chaque fois avec une interface spécifique, dont on ne connaît pour l’instant que les contours.

Normalement, les spécifications complètes d’OSE devraient être disponibles cet été et les travaux sont semble-t-il très avancés dans ce sens.

Il ne faut cependant pas être trop optimistes et considérer que les problèmes sont tous résolus, car plusieurs projets du même type ont déjà été initialisés par l’ONUG, qui n’ont pas (encore) rencontré un franc succès.

C’est le cas d’un projet mené par le groupe interne « Open Traffic Management Format », pour normaliser les données de gestion dans les échanges entre périphériques réseaux physiques et réels, voire encore celui de l’ « Open Network State Format » sur les données relatives à l’état en cours des dits périphériques.

Il y a même un autre projet qui, pour l’instant, a été abandonné, celui de relier dans un datacenter, les parties d’architectures issues de technologies différentes et plus précisément celles préconisées par OpenStack et VMWare avec vCenter.

Compte tenu de l’ « égoïsme » des fabricants, qui tirent tous la couverture à eux, la tâche a semblé insurmontable et l’ONUG a préféré renoncer.

Ce qui ne veut pas dire que cela ne se fera pas. Sauf que cette fois, l’ONUG n’est pas seul et qu’il existe déjà plusieurs initiatives qui vont dans le même sens. Celle d’OpenStack, en particulier ou celle d’Amazon.

Les mois à venir seront d’autant plus importants que le domaine est crucial et qu’il n’y aura pas de réalité Cloud à long terme si elle ne peut pas s’appuyer sur une pile incontestable de standards. L’ONUG tente d’apporter sa pierre à l’édifice, c’est pourquoi nous le suivrons avec beaucoup d’attention.