Résumé

  • La révision 07 décrit deux modules YANG proposés : l’un pour un test OAM unitaire, l’autre pour une séquence ordonnée par l’utilisateur, avec période, récurrence, état et modèles d’équipement montés dans le schéma.
  • Un état success peut être exact dans l’orchestrateur sans prouver que la bonne version a tourné au bon moment, que toutes les étapes sont comparables, qu’une cause est unique, qu’un changement est autorisé ou que le service est rétabli.

Rendre le diagnostic programmable

Un dépannage réseau suit souvent une logique implicite : vérifier la continuité, tracer un chemin, mesurer perte ou délai, isoler un segment, puis répéter pendant la fenêtre suspecte. Le mérite de draft-ietf-opsawg-scheduling-oam-tests-07 est de transformer cette logique en objet déclaratif. ietf-oam-unitary-test rassemble le test, ses nœuds cibles et le modèle OAM de l’équipement. ietf-oam-test-sequence fixe l’ordre choisi par l’utilisateur, la période ou la récurrence et le nombre d’exécutions.

Mais cette lisibilité peut créer une illusion. Une console affiche un plan, un compteur et un état final ; l’organisation voit alors une preuve complète là où le modèle ne fournit qu’un registre d’orchestration.

Le Datatracker impose déjà une limite : il s’agit de la révision 07 d’un Internet-Draft actif du groupe OPSAWG, destiné à la filière Standards Track, sans numéro RFC et sans traitement commencé par l’IESG. L’historique enregistre deux revues anticipées conclues par Has Issues et une revue YANG Doctors encore incomplète. Aucun de ces éléments ne démontre une mise en œuvre ou un déploiement.

1. Le reçu du plan

Le projet réutilise les groupements de RFC 9922 : état, version, heure locale, dernière et prochaine occurrence, compteurs d’exécution et d’échec. La version peut toutefois être entretenue par l’entité qui réutilise le groupement, et RFC 9922 admet qu’elle puisse ne pas être utilisée.

Il faut donc figer davantage qu’un nom. Le reçu du plan associe un identifiant stable au digest exact de la configuration, à l’ordre des tests, aux nœuds ciblés, aux paramètres, à la règle temporelle, au fuseau, aux révisions des modèles montés et au responsable qui a approuvé cette composition. Sans cette liaison, une modification entre la revue et l’occurrence est invisible.

2. Le reçu d’application

Les états planned, configured, ready, on-going, stop, error et success décrivent un cycle local. La séquence ajoute failure. L’acceptation d’une modification NETCONF ou RESTCONF prouve qu’un serveur a reçu une opération valide ; elle ne prouve pas que chaque équipement a appliqué la configuration.

RFC 8342 sépare précisément configuration courante, voulue, appliquée et état opérationnel. Un élément peut exister dans <intended> sans apparaître dans <operational>. Le reçu d’application doit donc confronter ces vues sur chaque nœud, conserver les capacités et le schéma employés, et rendre visible toute application partielle.

La revue OPSDIR renforce cette prudence. Le texte parle d’usage à la demande, mais ne définit aucune RPC ni action normative pour le déclencher. Il ne faut pas attribuer au projet une fonction qu’il n’a pas encore spécifiée.

3. Le reçu d’occurrence

Une récurrence est une règle. Elle n’est pas l’instance qui s’est exécutée. last-occurrence ou un compteur indiquent ce que le planificateur croit avoir fait, mais ne suffisent pas face aux retards, redémarrages, reprises, bascules de contrôleur ou changements d’horloge.

Chaque occurrence doit recevoir un identifiant propre, l’instant prévu, le début et la fin réels, la version du plan, l’identité de l’orchestrateur, la qualité de l’horloge, la filiation des reprises et la liste effective des nœuds. Un test terminé après la fenêtre de panne ne décrit pas forcément la panne.

4. Le reçu d’exhaustivité

La séquence est ordered-by user, et la révision 07 précise qu’une erreur d’un test n’empêche pas les tests suivants. C’est utile pour recueillir ce qui reste observable. Cela interdit cependant de traduire « séquence terminée » par « procédure complète ».

La revue PERFMETRDIR relève même que stop conduit à success dans le diagramme unitaire et à failure dans celui de la séquence. OPSDIR demande en outre des règles plus claires sur notifications, corrélation, cohérence multi-nœuds et retour arrière. Le reçu d’exhaustivité doit énumérer les étapes requises, les dépendances, les sauts, les erreurs et l’effet de chaque absence sur les hypothèses encore possibles.

5. Le reçu de mesure

Le modèle de programmation ne redéfinit pas les résultats détaillés. Il les attend de modèles OAM montés, par exemple le modèle TWAMP de RFC 8913. Or RFC 8528 définit le montage de schéma sans présumer la source des données d’instance ; l’instanciation et le contrôle du point de montage peuvent rester hors périmètre.

Le reçu de mesure doit franchir cette frontière : type et révision du test, paramètres, population de paquets, sens, classe, débit, fenêtre, unité, horloge, identité de l’équipement, résultat brut ou digest, et conservation. Une référence vers une feuille montée n’est pas encore cette preuve.

RFC 7799 distingue méthodes actives, passives et hybrides. Cette classification décide si le système a généré des paquets spécifiques ou observé le trafic existant. Elle interdit de substituer l’expérience de la sonde à celle du service sans justification.

6. Le reçu de comparabilité

RFC 10014 sépare la congruence topologique du traitement de transfert égal. Deux flux peuvent traverser les mêmes nœuds et liens tout en prenant des files, marques QoS, branches ECMP, politiques de mise en forme ou de police différentes.

Le reçu doit dire exactement ce que la sonde partage avec le trafic touché : chemin, traitement, encapsulation, classe, période, charge et mode de défaillance. Si seule la topologie est commune, la conclusion doit rester topologique. Programmer le bon type de test n’accorde aucune congruence par décret.

7. Le reçu de diagnostic et d’autorité

Le cas d’usage de dépannage du projet parle de « candidate root cause ». C’est le bon niveau de certitude. RFC 9940 distingue événement, faute, problème, symptôme, cause, alerte, alarme et incident. RFC 8632 précise que les ressources candidates à la cause racine sont des indices pour l’application cliente.

Le diagnostic doit conserver les observations, les explications concurrentes, les hypothèses exclues, le niveau de confiance et le test qui pourrait l’infirmer. Une perte localisée après un saut ne distingue pas automatiquement congestion, défaut optique, politique de file, bug, reroutage transitoire ou artefact de mesure.

Puis vient une autorité distincte. Le compte habilité à créer des tests n’est pas nécessairement habilité à modifier le routage ou le service. RFC 8341 fournit le modèle de contrôle d’accès ; le reçu de changement doit nommer le décideur, la base d’autorisation, le changement exact, le rayon d’impact, la fenêtre et le retour arrière.

8. Le reçu de résultat

Après un changement, la même sonde peut redevenir verte alors que le client reste affecté. Le correctif peut déplacer le trafic, masquer un symptôme ou créer un autre risque. Le résultat doit donc être observé sur la surface qui porte la promesse : population de service, critère SLA, signaux indépendants, alarmes résiduelles et stabilité dans le temps.

Le projet rend les premières pièces du diagnostic plus faciles à coordonner. Sa valeur augmente quand l’organisation n’en fait pas un verdict universel. Plan, application, occurrence, étapes, mesure, comparabilité, cause, autorité et résultat peuvent être reliés ; ils ne doivent jamais être confondus.