Résumé

  • La révision 13 de SIMAP organise le parcours d’un service vers ses ressources logiques et physiques, puis d’une ressource vers les services qui en dépendent.
  • Le résultat atteste la représentation fournie par un serveur à un client autorisé; il n’atteste pas, à lui seul, la complétude du réseau, l’alignement temporel, la cause d’un incident ou l’effet d’une action.

Une dépendance devient convaincante dès qu’elle se dessine comme un chemin continu. On part d’un service client, on traverse son composant logique, son réseau de niveau 3, son support de niveau 2 et l’équipement physique. Dans l’autre sens, on sélectionne une ressource en panne et l’on remonte vers les services exposés. La promesse de la Service & Infrastructure Map est de rendre ce raisonnement inter-couches interrogeable, au lieu de le disperser entre inventaires, contrôleurs et outils d’assurance.

Ce parcours répond cependant à une question plus étroite qu’il n’y paraît. Il dit ce que le serveur SIMAP a choisi de représenter et ce qu’il a été autorisé à montrer. Il ne démontre pas que toutes les couches étaient visibles, que les sources observaient le même instant ni que le graphe correspondait encore au réseau au moment de la décision.

Le texte de référence est la révision 13 de draft-ietf-nmop-simap-concept, datée du 4 septembre 2026. Le Datatracker de l’IETF la présente comme un Internet-Draft actif du groupe NMOP, destiné à devenir un document informatif. Son historique indique un IETF Last Call ouvert jusqu’au 26 septembre. Il ne s’agit donc pas d’un RFC adopté, mais d’un travail encore susceptible d’évoluer.

Deux sens de parcours, plusieurs niveaux de preuve

Le modèle de base repose sur des réseaux, des nœuds, des liens et des points de terminaison. Les relations de support relient des entités d’une même couche ou de couches différentes. Le parcours descendant permet d’identifier les ressources logiques puis physiques utilisées par un service. Le parcours ascendant permet de partir d’une ressource physique, de niveau 2 ou de niveau 3 et de retrouver les services, nœuds, liens et terminaisons qui s’appuient sur elle.

RFC 8345 fournit déjà un modèle YANG de topologies en couches et des références vers les réseaux, nœuds, liens et terminaisons de support. SIMAP étend l’ambition opérationnelle: relier le service à l’infrastructure et donner accès à des modèles externes. Une relation bien formée prouve qu’un lien existe dans l’instance interrogée. Elle ne prouve pas que l’objet externe partage la même identité, la même date de collecte ou le même niveau de confiance.

L’inventaire, les mesures d’observabilité, l’assurance, la configuration et les connaissances d’exploitation peuvent rester en dehors du cœur SIMAP. Cette séparation évite de transformer la carte en monolithe. Elle oblige aussi à conserver la provenance. Un numéro de série issu d’un inventaire, un symptôme issu de l’assurance et une arête topologique peuvent être exacts séparément tout en décrivant trois moments différents.

L’autorisation façonne le résultat

La révision 13 précise que l’accès à une couche dépend toujours de ce que l’application cliente est autorisée à voir. Le serveur peut cacher une couche ou remplacer la topologie native par une abstraction pour des raisons de sécurité, d’administration ou de commerce. La réponse peut donc être conforme et volontairement incomplète.

Dans cette situation, l’absence d’une ressource n’est pas la preuve de son inexistence. Un nœud abstrait peut représenter plusieurs équipements. Un lien logique peut masquer deux chemins physiques dont le partage de risque diffère. Une équipe cliente peut recevoir la vue nécessaire à son service sans obtenir la structure interne du fournisseur. Le problème n’est pas l’abstraction; c’est la disparition de son étiquette lorsque le résultat alimente une autre analyse.

Il faut également distinguer le changement de couche du changement de niveau d’abstraction. Passer d’un lien IP à son support optique répond à une question de dépendance. Passer d’un nœud agrégé aux nœuds natifs répond à une question de granularité. Une preuve exploitable doit indiquer les deux.

La fraîcheur ne tient pas dans le mot «live»

Le projet définit la topologie live comme le dernier instantané du réseau réel et exige des mécanismes de découverte et de synchronisation. Ce sont des exigences destinées aux futures mises en œuvre. Le succès d’une requête ne constitue pas un audit indépendant de leur exécution.

SIMAP doit aussi prendre en charge les instantanés, la topologie potentielle, la topologie voulue et les éléments passifs. La topologie voulue peut omettre des sauts et des équipements intermédiaires. La partie passive peut contenir des ressources impossibles à découvrir automatiquement. Les états et l’historique peuvent être intégrés à la carte ou seulement accessibles par un autre système. Avant toute comparaison, il faut donc demander: quelle instance, quel type de vue, quelle source, quel instant et quel état de synchronisation?

Ce contrôle est crucial lors d’un incident. Si un parcours ressource-vers-service renvoie cinq services, il établit une exposition modélisée. Il n’établit pas que cette ressource a causé les cinq perturbations. Elle peut appartenir à un chemin de secours, être associée à une relation périmée ou avoir changé d’état après la capture. La causalité nécessite une chronologie, des observations du service, l’examen d’explications concurrentes et la vérification de la récupération.

Écrire dans la carte n’agit pas sur le réseau

Le projet sépare explicitement l’écriture dans SIMAP de la configuration du réseau réel. Les opérations d’écriture servent notamment aux scénarios hypothétiques et aux topologies voulues ou passives. Les modifications du réseau passent par les opérations habituelles du contrôleur.

Une chaîne automatisée doit donc produire plusieurs reçus: la vue qui a nourri la décision, la règle et l’acteur qui ont autorisé cette décision, l’opération envoyée au contrôleur ou à l’équipement, puis l’observation du résultat. Une réponse acceptée par l’API de la carte ne vaut ni commande exécutée ni service rétabli.

Il en va de même pour une boucle fermée. La carte peut soutenir la surveillance et l’analyse. Une boucle complète comprend encore le choix d’une correction, son autorisation, son exécution et une mesure ultérieure. Sans cette dernière, le système ne sait pas s’il a corrigé le réseau ou seulement modifié sa propre représentation.

Conserver un reçu de la vue

Une requête importante devrait laisser une trace contenant l’identité du serveur et de l’instance, la version du modèle, le rôle du client, le périmètre d’autorisation, la couche et le niveau d’abstraction, les systèmes sources, les heures d’observation, la direction de la relation parcourue et l’état connu de synchronisation. Si une action suit, sa décision, son autorité, son exécution et son résultat doivent rester des objets distincts.

Cette discipline ne ralentit pas l’automatisation; elle lui évite de fabriquer une certitude. SIMAP peut rendre les dépendances beaucoup plus lisibles. Sa réponse la plus solide demeure une phrase précisément bornée: voici la vue que ce serveur a exposée à ce client, selon ces sources et à cet instant.

Sources

Texte et statut: SIMAP, révision 13 et historique du document. Modèles et interfaces connexes: RFC 8345, RFC 8341, RFC 8040, RFC 9417 et RFC 9408. Le projet YANG SIMAP est un Internet-Draft individuel sans statut formel dans le processus de normalisation. Texte source figé : archive de la révision 13. Contexte d’ingénierie du trafic : RFC 9522.