Résumé

  • Dans RFC 3139, une politique telle que « service gold » devait être combinée à la topologie, aux capacités et à l’état du réseau avant de devenir des configurations propres à chaque équipement.
  • Plusieurs traducteurs pouvaient coopérer sur l’ensemble du réseau, mais un seul devait agir sur un équipement à un instant donné. L’approbation de la politique ne prouvait donc ni l’installation cohérente ni le service obtenu.

Le mot commun cachait des commandes différentes

Une direction peut décider qu’un groupe de clients recevra un service « gold ». Le terme facilite la discussion parce qu’il évite de nommer chaque file, chaque classificateur et chaque ordonnanceur. Mais le routeur ne configure pas une couleur commerciale. Il attend des objets et des valeurs adaptés à son système.

Sur une plateforme, « gold » peut devenir une file prioritaire avec un plafond. Sur une autre, une classe DiffServ, un filtre et plusieurs paramètres. Le chemin de secours peut nécessiter une configuration différente du chemin principal. Une interface nouvelle peut déplacer le point où le trafic doit être classé.

RFC 3139 utilisait précisément cet exemple pour montrer la distance entre comportement attendu et commandes locales. La politique était utile au niveau réseau ; elle n’était pas encore la configuration, encore moins une preuve de traitement des paquets.

Publié en juin 2001 avec le statut Informational, le document recueillait des exigences et ne choisissait pas un protocole. Il venait d’une inquiétude : plusieurs groupes de l’IETF adaptaient COPS, PIB, SNMP ou MIB à leurs propres technologies, au risque de créer des solutions fragmentées. Une réunion de 1999 n’avait pas trouvé de consensus sur tous les choix. Le groupe de conception a donc défini ce qu’une solution intégrée devait pouvoir faire.

Les MUST de RFC 3139 sont les exigences de cette réflexion. Ils ne transforment pas le mémo en Internet Standard et ne prouvent pas qu’un mécanisme existant remplissait déjà le contrat.

Trois couches de configuration, trois responsabilités

Le document distinguait les données de haut niveau, la configuration network-wide et la configuration device-local. La première exprimait modèle et comportement. La deuxième décrivait un état partagé sans appartenir à un équipement précis. La dernière contenait les détails destinés à une machine.

La fonction de configuration-data translator passait d’une couche à l’autre. Elle pouvait être humaine, centralisée, intermédiaire ou co-localisée avec l’équipement. RFC 3139 définissait la transformation, non l’emplacement physique du logiciel.

Le traducteur ne lisait pas seulement la politique. Il pouvait avoir besoin de la topologie, des capacités, du statut, de la performance et du monitoring. Une règle de qualité de service compilée avec une ancienne carte des chemins peut être syntaxiquement parfaite et déployée au mauvais endroit.

RFC 3139 exigeait que le système détecte l’absence d’une information nécessaire à une conversion sans erreur et agisse en conséquence. Il ne disait pas si l’action correcte était l’arrêt, l’attente, la restriction ou l’intervention humaine. Il interdisait surtout que l’inconnu devienne silencieusement une traduction sûre.

Une chaîne de traducteurs, jamais deux auteurs simultanés

Plusieurs traducteurs pouvaient travailler en tandem. Une étape pouvait convertir l’objectif commercial en configuration network-wide ; une autre choisir un profil technologique ; une troisième produire les valeurs propres à un constructeur.

À la frontière de l’équipement, le texte posait une exclusivité : un seul configuration-data translator pouvait opérer sur un device à un instant donné. La chaîne pouvait être multiple ; l’acte d’écriture ne devait pas avoir deux auteurs concurrents.

Ce n’était pas un protocole de verrouillage. RFC 3139 ne définissait ni élection, ni lease, ni fencing, ni reprise après crash. Il définissait une propriété à préserver. Deux contrôleurs peuvent traduire des révisions différentes et produire chacun une sortie raisonnable. Leur entrelacement peut créer un état que personne n’a demandé.

Imaginez qu’un processus installe une nouvelle file pendant qu’un autre restaure un profil antérieur. Le classificateur peut venir du premier, l’ordonnanceur du second et l’expiration n’appartenir à aucun ensemble cohérent. Deux réponses positives aux commandes ne prouvent pas une politique finale complète.

L’exigence d’éliminer les mauvaises configurations dues à l’accès d’écriture partagé concurrent répondait au même problème. Il fallait connaître l’identité du writer, la révision de politique, le snapshot d’entrée et la durée d’exclusion. « Le dernier gagne » décide un ordre de stockage ; il ne restaure pas l’intention.

La faute pouvait vivre entre deux routeurs corrects

Certaines transitions réseau dépendent de plusieurs équipements. RFC 3139 demandait de pouvoir ajouter, modifier, supprimer, exporter ou restaurer une configuration complète ou partielle simultanément ou de façon synchronisée lorsque nécessaire.

Le qualificatif compte. Toute modification partielle n’est pas mauvaise. Une nouvelle entrée passive peut précéder sans risque sa mise en service. Mais une route installée avant son filtre peut exposer du trafic ; une classe d’entrée peut être activée alors que le cœur n’en connaît pas le code ; une moitié de bascule peut produire une boucle ou un trou noir.

Le système devait détecter les erreurs, y compris propres aux données, récupérer des échecs et empêcher les configurations partiellement inappropriées quand le contexte l’exigeait. RFC 3139 ne promettait pas une transaction distribuée atomique. Aucun message prepare/commit universel, aucun rollback garanti, aucune définition unique du partial n’y figuraient.

Il faut donc distinguer le batch déclaré complet, les réponses individuelles, l’état stocké, l’état appliqué et le comportement réseau. Le contrôleur possède le reçu de l’orchestration ; chaque device possède celui de l’acceptation ; les paquets fournissent une autre preuve.

La configuration de secours devait précéder la panne

Le document demandait de pouvoir précharger plusieurs configurations locales afin d’assurer une bascule rapide sans télécharger de grands volumes vers de nombreux équipements au moment de l’incident. La vitesse future dépendait d’un travail antérieur.

Précharger n’est pas activer. Activer ne prouve pas que le candidat reste adapté. La topologie, l’inventaire ou le contrat client peuvent évoluer après la préparation. Une sauvegarde correcte hier peut devenir dangereuse aujourd’hui.

Les plateformes de configuration et éléments réseau redondants faisaient aussi partie des exigences. La redondance introduit la question du writer : qui détient l’autorité, quel état a été repris, comment l’ancien leader est-il empêché de revenir ? Deux contrôleurs vivants ne constituent pas automatiquement une continuité sûre.

Le feedback confirmait une étape, pas le service

RFC 3139 exigeait un retour des devices : confirmation de configuration, statut, monitoring et événements. Sans feedback, le système ne fait que publier. Avec lui, il peut rapprocher intention et déclaration locale.

Encore faut-il nommer la confirmation. Le device a-t-il parsé, validé, stocké en candidate, commis, rendu effectif, conservé après redémarrage ou appliqué au forwarding ? « Success » change de portée selon le mécanisme.

Le management devait interpréter configuration locale, statut et monitoring dans le contexte network-wide. Une file peut être correctement installée mais ne plus correspondre à la politique parce que le chemin a changé. Une différence locale peut inversement être l’expression nécessaire d’un objectif commun sur un matériel distinct.

Même un retour exact de tous les routeurs n’est pas une mesure de bout en bout. Le trafic peut prendre un autre chemin ; le classificateur peut manquer les paquets ; une capacité réservée peut rester inutilisée. « Gold installé » et « gold fourni » appartiennent à deux observateurs.

La configuration avait une durée d’autorité

RFC 3139 demandait une date d’effet et une expiration. Certains objets devaient finir ; d’autres pouvaient ne jamais expirer. Une valeur valide pouvait être future, stockée mais inactive, ou présente après la fin de son autorité.

Les horloges compliquent le tableau. Un contrôleur peut considérer une exception comme expirée tandis qu’un équipement au temps décalé continue de l’appliquer. Restaurer un snapshot peut ressusciter une règle dont la fenêtre est passée.

Le reçu doit donc inclure création, entrée en vigueur, sémantique d’expiration, base de temps, état actif et intervalle observé. La présence dans le fichier ne répond pas à « gouverne-t-elle les paquets maintenant ? ».

Le provisioning dynamique déclenché par un événement ajoute la même question. Quelle version de l’événement ? Quelle politique était encore valable ? Un autre translator a-t-il réagi ? La configuration de récupération avait-elle une échéance ? Sans identité et temps, l’automatisation peut osciller.

La traçabilité faisait partie de la validité

Le document exigeait contrôle d’accès, authentification, intégrité, protection contre le replay et, selon le besoin, confidentialité. L’hôte était le minimum ; les rôles et utilisateurs devaient pouvoir recevoir des droits différents. Les changements devaient être retraçables au niveau de l’hôte et de l’utilisateur.

Une configuration ne se juge pas seulement par sa syntaxe. Il faut savoir qui l’a produite, avec quelle révision, à partir de quels inputs et sous quelle autorisation. Une file correctement formée écrite par un acteur non autorisé reste une transition invalide.

Le replay rappelle qu’une ancienne configuration légitime peut être nuisible. L’authentification identifie l’émetteur ; l’intégrité protège les octets ; la fraîcheur et l’autorisation disent s’il peut accomplir cette action maintenant.

Lors d’une divergence, le diff final ne suffit pas. L’enquête doit retrouver politique, projection network-wide, translator propriétaire du device, candidat local, commandes acceptées, erreurs et feedback avant l’arrivée du writer suivant.

Faire évoluer le modèle sans feindre l’équivalence

RFC 3139 voulait accueillir l’évolution des modèles, messages et types sans casser l’interopérabilité ni remplacer de vastes parcs. Il demandait aussi de réutiliser l’expérience des MIB et de SMI.

Une extension inconnue à un ancien translator crée pourtant une nouvelle frontière. Le device peut connaître le champ et ne pas offrir toute sa capacité. Le contrôleur peut omettre ce qu’il ne rend pas. Une sortie valide peut alors ne représenter qu’une partie de l’intention.

L’évolution sûre exige découverte de capacités, gestion explicite de l’inconnu et dégradation visible. Le RFC ne garantissait pas que chaque vieux routeur accomplirait chaque nouvelle policy. Il demandait une architecture capable d’évoluer sans faire passer une perte de sens pour une traduction exacte.

Les successeurs ont rendu certaines distinctions concrètes

Le workshop IAB de 2002, rapporté par RFC 3535, a enregistré la pression des opérateurs pour des outils de configuration mieux adaptés et une séparation plus nette entre configuration et données opérationnelles. NETCONF a ensuite défini datastores, verrous, validation, commit et erreurs. NMDA a plus tard distingué configuration intended, applied et état opérationnel.

Ces textes montrent la persistance du problème. Ils ne permettent pas d’attribuer rétroactivement à RFC 3139 un candidate datastore, un lock NETCONF ou une réconciliation NMDA déjà déployés en 2001.

La leçon originale reste plus simple. Une politique globale peut être compréhensible et localement inexécutable. Une traduction peut être correcte selon des faits périmés. Un device peut accepter sans fournir le service. RFC 3139 n’a pas laissé le mot « gold » franchir ces preuves sans contrôle.