Résumé

  • Le serveur qui accepte un commit confirmé copie déjà le candidat dans la configuration courante. Le délai de confirmation ne retarde pas l’exécution : il maintient l’obligation de revenir à l’état antérieur si la procédure n’est pas achevée.
  • La perte de la session initiale entraîne le retour arrière dans la forme ordinaire, mais pas dans la forme persistante. Dans celle-ci, une autre session munie du bon persist-id peut prolonger, confirmer ou annuler la décision.
  • Ni <ok>, ni la validation YANG, ni une notification complete ne prouvent que startup est aligné, que le matériel a appliqué l’intention, que les paquets passent ou qu’un ensemble d’équipements a changé de façon atomique.

Quand le silence de la session devient une décision

L’ingénieure est connectée à un routeur éloigné par NETCONF sur SSH. Elle a chargé une modification dans le datastore candidat, l’a validée, puis demande un commit confirmé. La réponse <ok> revient. Quelques secondes plus tard, sa session disparaît et le site ne répond plus.

Dans un changement ordinaire, cette chronologie serait surtout une énigme : la commande a-t-elle été appliquée avant la coupure ? Avec le commit confirmé non persistant, le silence a une signification protocolaire. La nouvelle configuration était déjà devenue courante, mais la session qui l’avait engagée détenait aussi la continuité nécessaire pour la rendre définitive. Sa terminaison impose au serveur de restaurer la configuration précédente.

Le mécanisme a été inventé pour ce cas très concret. Une modification de l’accès d’administration peut couper précisément le canal dont l’opérateur aurait besoin pour la réparer. Le serveur garde donc une issue indépendante de ce canal. Il ne faut pourtant pas embellir ce que cette issue sait faire. Elle sait restaurer un état de configuration sur un serveur. Elle ne sait pas si la demande avait été correctement autorisée, si un autre écrivain a travaillé entre-temps, si le matériel est revenu au même état, ni si le trafic a retrouvé son chemin.

La première discipline consiste ainsi à accepter deux phrases simultanément : le changement avait réussi à s’exécuter ; la décision n’était pas encore finale.

Candidat et courant : le seuil a déjà été franchi

Le protocole de base défini par le RFC 6241 ne présente pas le candidat comme une vague suggestion. Lorsque le serveur annonce la capacité :candidate, le client peut y composer une configuration complète sans toucher immédiatement au datastore courant. L’opération <commit> franchit le seuil : elle établit le courant à partir du candidat.

Le paramètre <confirmed/> ne place pas la copie en attente. Il ajoute une condition temporelle après cette copie. Le serveur doit conserver de quoi restaurer l’état courant antérieur tant qu’un commit de confirmation n’a pas achevé la procédure. Sans confirm-timeout explicite, la valeur par défaut est de 600 secondes. Une nouvelle demande confirmée peut prolonger la fenêtre ; un commit de confirmation la clôt ; <cancel-commit> ou l’expiration la clôt par restauration. Un redémarrage de l’équipement avant l’achèvement exige également le retour à l’état antérieur.

Cette grammaire produit au moins quatre instants qu’un journal sérieux doit distinguer : candidat validé, commit confirmé accepté, configuration confirmée, configuration restaurée. Une seule ligne « changement réussi » ne permet pas de savoir lequel a été observé.

Le RFC 6470 offre justement les événements start, extend, complete, cancel et timeout dans la notification de commit confirmé. Ils donnent un vocabulaire propre à la chronologie. Mais une notification n’est pas une baguette de finalité. Elle peut manquer à un collecteur, arriver en retard ou précéder la convergence opérationnelle. Elle doit être corrélée avec le RPC, la session, l’utilisateur, l’empreinte de configuration, le délai et l’état effectivement constaté après l’événement.

Un délai n’est pas une politique de risque universelle

Dix minutes constituent un défaut d’interopérabilité, pas une vérité sur l’exploitation. Une modification d’une liste de contrôle, la remise en état d’un châssis et une bascule de politique de routage ne présentent ni la même latence d’application ni le même rayon d’impact. Le délai doit être assez long pour mesurer l’effet pertinent et assez court pour limiter l’exposition à un état nuisible.

Il faut aussi définir le moment qui lance la mesure. Le client peut compter depuis l’envoi du RPC, le serveur depuis son acceptation, l’orchestrateur depuis la réception de <ok> et la supervision depuis sa première observation. Sur plusieurs équipements, ces origines s’écartent. Une fenêtre uniforme affichée par le contrôleur peut cacher neuf délais de serveur différents.

Le bon indicateur n’est donc pas seulement « temps restant ». Il associe l’identité du serveur, l’époque du commit, l’heure d’expiration selon le serveur, la dernière notification, le propriétaire actuel de la décision et le temps minimal nécessaire aux preuves opérationnelles. Prolonger sans justification ne crée pas une observation ; cela allonge seulement l’état provisoire.

La forme persistante déplace le pouvoir

La perte de session ne doit pas toujours décider. Un orchestrateur peut vouloir déclencher une modification, fermer une connexion fragile puis confier la validation à un autre processus. La version 1.1 de la capacité prévoit cette situation. Le client fournit une valeur opaque persist. Le commit confirmé devient persistant et survit à la fin de la session initiale.

Une autre session peut ensuite présenter la valeur correspondante dans persist-id afin de confirmer, de prolonger ou d’annuler la procédure lorsque le RPC l’autorise. Ce transfert est techniquement élégant : la continuité de la décision ne dépend plus d’un socket. Il ouvre aussi une nouvelle question de souveraineté pratique. Qui garde la valeur ? Qui peut la récupérer pendant un incident ? Quel service peut l’utiliser ? Que se passe-t-il si l’orchestrateur initial meurt mais que la configuration nuisible continue ?

Le protocole n’appelle pas cette valeur une identité ni une approbation indépendante. Il demande une correspondance opaque. Une organisation qui présente persist-id comme la signature d’un second opérateur raconte plus que le mécanisme ne prouve. La séparation du proposant et du confirmant exige deux identités, des droits distincts, une attribution de tâche et un journal que le proposant ne peut pas réécrire seul.

Il serait tout aussi imprudent de verser le jeton brut dans tous les logs. Une preuve d’audit deviendrait une capacité réutilisable. Une empreinte protégée peut servir à la corrélation ; la valeur vivante doit rester dans une chaîne de garde explicite. Posséder le jeton, être authentifié par SSH et être autorisé sur les nœuds de données sont trois propriétés différentes.

Le retour arrière peut emporter le travail d’autrui

On imagine volontiers le rollback comme la génération automatique du patch inverse. Le commit confirmé promet une restauration d’état. Si d’autres modifications atteignent la configuration courante pendant la fenêtre, elles peuvent être altérées ou supprimées lorsque le serveur revient au point antérieur. Le RFC 6241 avertit explicitement de cette possibilité.

Prenons une fenêtre de cinq minutes. Le changement A touche la politique d’accès et devient courant. Deux minutes plus tard, un changement B ajuste une télémétrie apparemment indépendante. A expire. Si la restauration replace le datastore à l’image conservée avant A, B peut disparaître. Le fait que les deux équipes aient édité des branches différentes dans leurs outils ne prouve rien sur la frontière de restauration du serveur.

Le verrouillage fournit alors une partie de la réponse. Un verrou global NETCONF peut exclure les autres sessions du datastore concerné. Le RFC 5717 ajoute les verrous partiels, mais son interaction avec le commit confirmé révèle la contrainte : le serveur doit refuser un verrou partiel sur running lorsqu’un commit confirmé est en cours, car il pourrait avoir besoin de restaurer une portée plus large.

Un verrou ne valide pas la configuration. Il prouve au mieux une exclusion sur une portée précise, respectée par les chemins d’écriture auxquels il s’applique. Il faut encore connaître son propriétaire, ses nœuds, sa durée, la cause de sa libération et les API qui partagent le même datastore. Sans ces éléments, « nous verrouillons » reste une formule symbolique.

RESTCONF peut fermer la fenêtre ouverte par NETCONF

Le pouvoir de confirmation ne réside pas toujours dans le protocole qui a commencé le changement. Le RFC 8040 décrit RESTCONF au-dessus des datastores conceptuels d’un serveur NETCONF colocalisé. Si ce serveur utilise candidate, une édition RESTCONF valide entraîne automatiquement le commit du candidat.

Lorsqu’un commit confirmé NETCONF non persistant est en cours, ce nouveau commit agit comme confirmation. Une écriture RESTCONF peut donc rendre définitive la configuration provisoire, même si son auteur venait modifier un autre objet et ignorait la fenêtre ouverte. La topologie réelle du contrôle dépasse la frontière entre équipes « NETCONF » et « RESTCONF ».

La variante persistante impose une autre conduite. RESTCONF ne transporte pas persist-id. Si le commit en cours exige ce jeton, l’édition doit échouer avec le statut HTTP 409 in-use. Un verrou NETCONF incompatible peut produire le même statut. Les 409 ne sont alors pas de simples erreurs applicatives : ils signalent qu’une autre autorité détient encore la finalité ou l’exclusion du datastore.

Il existe également une nuance de persistance. Sur un serveur colocalisé qui annonce startup, RESTCONF met automatiquement startup à jour après une édition réussie. Cette règle ne permet pas de déduire qu’un commit NETCONF ordinaire a fait la même chose. Le chemin d’écriture fait partie de la preuve.

L’autorisation précède le commit sans se confondre avec lui

Le transport SSH du RFC 6242 protège la session et authentifie un pair selon la politique déployée. Cette base ne répond pas à la question : cet utilisateur peut-il invoquer <commit> et modifier ces nœuds précis ?

Le modèle NACM du RFC 8341 traite séparément l’accès aux opérations, aux nœuds de données et aux notifications. Une opération autorisée peut rencontrer un nœud interdit. Un compte de récupération peut bénéficier d’une exception d’implémentation dont le rayon d’action dépasse les règles ordinaires. Le commit confirmé ne transforme pas ces choix en autorisation implicite.

La validité du candidat forme encore une autre couche. Le langage YANG du RFC 7950 permet de vérifier types, structures et contraintes. Une adresse peut être parfaitement conforme au schéma et appartenir au mauvais site. Une politique peut respecter toutes les références et couper un service. La validation modèle la cohérence déclarée, non l’intention métier.

Le RFC 8525 rend observable la bibliothèque YANG : modules, fonctionnalités, déviations, associations de schéma et content-id propre au serveur. Il faut lier le candidat à cet état exact. Une fonctionnalité activée ou une déviation modifiée entre le test et le commit peut changer la signification de « valide ».

Running n’est pas encore le réseau

L’architecture NMDA sépare le courant de l’intention et de l’opérationnel. Le courant contient la configuration soumise à validation. Le système peut la transformer pour produire intended. Il tente ensuite d’appliquer cette intention ; operational décrit ce qui est réellement utilisé.

Cette séparation explique un cas qui surprend les tableaux de bord : une configuration visant une ressource absente peut demeurer dans running et intended sans apparaître comme appliquée dans operational. Des contraintes physiques, des dépendances internes ou un protocole asynchrone peuvent retarder ou modifier l’application. La procédure de commit peut être complete et le dispositif encore divergent.

La preuve doit suivre l’objet du changement. Pour une interface, elle observe présence, état, adresse effective, compteurs et paquets. Pour une politique de routage, elle examine l’état de protocole, les routes sélectionnées, leur installation et des canaris de transfert. Pour l’accès de gestion, elle vérifie le nouveau chemin sans sacrifier le canal de secours. Comparer deux textes de configuration ne suffit pas.

Cette exigence rejoint la primauté du code en exécution : le contrat partagé reste volontairement mince, tandis que le pouvoir réel se lit dans ce que le serveur, le matériel et le réseau ont effectivement fait. Une approbation dans un ticket appartient à la couche symbolique tant que les identités et règles exécutables ne la relient pas au changement.

Cinq équipements ne font pas une seule transaction

L’architecture du RFC 6244 permet de construire une gestion de réseau au-dessus de NETCONF et YANG. Elle ne transforme pas cinq commits confirmés en consensus distribué. Chaque serveur conserve son état antérieur, démarre son délai, applique ses capacités et rencontre ses propres dépendances.

Un contrôleur peut recevoir quatre réponses <ok> et une erreur. Il doit décider s’il confirme les quatre, les annule ou poursuit un déploiement progressif. S’il demande l’annulation, il doit encore constater que les quatre états opérationnels et les chemins de paquets sont revenus. Les délais n’ont pas nécessairement commencé ensemble ; un redémarrage ou un verrou peut séparer davantage les trajectoires.

La transaction réseau est donc une construction supérieure : identifiant commun, empreinte de base par équipement, ordre de confirmation, conditions d’abandon, canaris, compensation et réconciliation. La politique peut être tout ou rien, progressive ou fondée sur une capacité de service. Mais elle ne doit jamais être déduite d’une collection de réussites RPC.

Ce que l’on peut enfin affirmer

Un commit confirmé correctement observé autorise une phrase précise : ce serveur a placé ce candidat validé dans running, a retenu cette base de restauration et a lié sa finalité à ce délai, cette session ou ce jeton ; la procédure s’est ensuite terminée par tel événement et le datastore a atteint telle empreinte.

Pour parler de succès, la phrase doit continuer : l’utilisateur et les nœuds étaient autorisés ; aucun écrivain non coordonné n’a traversé la frontière ; startup a reçu l’état requis ; intended et operational ont convergé sur les ressources visées ; les paquets et services ont satisfait leurs canaris ; tous les équipements ont été réconciliés.

Le mécanisme mérite d’être utilisé justement parce qu’il ne prétend pas faire ce travail à notre place. Il fournit une charnière interopérable entre exécution provisoire et restauration. L’organisation reste responsable de savoir qui tient la porte, qui peut la fermer et comment elle prouve ce qui se trouve de l’autre côté.

Sources