Module 3 : Standards industriels (YANG) et approche Cloud/SDN

Limites des approches vues au Module 2

• les API REST/JSON-RPC propriétaires (MikroTik, FortiOS, ubus…) diffèrent d’un constructeur à l’autre,
• pas de modèle de données commun → chaque intégration est à refaire.

L’industrie réseau a normalisé une partie de cela avec YANG, NETCONF et RESTCONF.

Modélisation des données avec YANG

Définition

YANG (Yet Another Next Generation) est un langage de modélisation de données qui décrit la structure de la configuration et de l’état d’un équipement, indépendamment du protocole de transport.

Structure d’un modèle

• module : unité de plus haut niveau (ex. ietf-interfaces),
• container : regroupe des données (ex. interfaces),
• list : ensemble d’éléments répétés, avec une clé (ex. une liste d’interfaces),
• leaf : une donnée simple (ex. enabled, de type boolean).

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; }
    }
  }
}

module → container → list (clé) → leaf, appliqué à l’exemple ci-dessus.

Modèles natifs vs OpenConfig

OpenConfig vise la portabilité entre équipements de marques différentes ; les modèles natifs exposent des fonctionnalités spécifiques non couvertes par OpenConfig.

NETCONF

Définition

Protocole de gestion de configuration réseau, transporté sur SSH, encodé en XML.

Datastores

• running : configuration active,
• candidate : configuration en préparation, à valider avant application.

edit-config modifie “candidate” ; “commit” l’applique dans “running” ; lock/unlock protège pendant la modification.

Opérations principales

<rpc>
  <get-config>
    <source><running/></source>
  </get-config>
</rpc>

RESTCONF

Définition

Expose les mêmes modèles YANG que NETCONF, mais via HTTP avec un encodage JSON (ou XML), en respectant les principes REST vus au Module 2.

Correspondance avec YANG

Chaque container/list YANG devient une ressource adressable par une URL :

GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

NETCONF vs RESTCONF

Même modèle YANG, deux piles différentes : SSH/XML/candidate côté NETCONF, HTTPS/JSON/running côté RESTCONF.

Télémétrie réseau

Pull vs push

• Pull (traditionnel) : le collecteur interroge l’équipement à intervalle régulier (SNMP polling, get NETCONF/RESTCONF répété) → charge et latence.
• Push (streaming telemetry) : l’équipement envoie ses données automatiquement dès qu’elles changent, vers un collecteur abonné.

Intérêt

• données quasi temps réel,
• moins de charge sur l’équipement et le réseau de management,
• base des architectures d’observabilité modernes (dashboards, alerting).

Notion de SDN (Software-Defined Networking)

Principe

Séparer le plan de contrôle (décisions) du plan de données (transfert des paquets), et centraliser les décisions dans un contrôleur.

Interfaces

• Northbound : entre le contrôleur et les applications (souvent REST/RESTCONF),
• Southbound : entre le contrôleur et les équipements (NETCONF, OpenFlow, gNMI…).

Applications
     |  (Northbound API)
 Contrôleur SDN
     |  (Southbound : NETCONF / OpenFlow / gNMI)
Équipements réseau

Le contrôleur centralise le plan de contrôle ; le plan de données reste sur les équipements.

Un script Python qui pilote directement plusieurs équipements via NETCONF/RESTCONF (comme dans ce module) préfigure le rôle que joue un contrôleur SDN à plus grande échelle.

À retenir

• YANG modélise les données, indépendamment du protocole de transport.
• NETCONF (SSH/XML, avec candidate et verrouillage) vise les changements transactionnels ; RESTCONF (HTTPS/JSON) vise l’intégration légère.
• La télémétrie push remplace progressivement le polling SNMP/NETCONF classique.
• Le SDN centralise le plan de contrôle ; NETCONF/RESTCONF sont des protocoles southbound courants.