Résumé

  • Le module YANG du RFC 9617 exprime l’activation d’IOAM, les profils, filtres, protocoles porteurs et options prises en charge ; il ne rend pas compte à lui seul du passage d’un paquet.
  • Le paquet doit encore correspondre à l’ACE référencée avec une action accept, recevoir l’encapsulation, traverser des nœuds participants et produire une donnée en bande ou un export effectivement collecté.
  • Il faut des reçus séparés pour la configuration active, la sélection, l’insertion, les contributions par nœud, les limites, la séquence d’export, la garde du collecteur, l’analyse, l’action autorisée et son résultat.

La conformité du modèle a précédé toute observation

Le contrôleur lit le datastore actif : admin-config/enabled vaut vrai, le profil demandé existe, le filtre pointe vers la bonne ACE et le type de protocole indique IPv6. Les branches de trace souhaitées apparaissent parmi les fonctions prises en charge. Rien n’empêche alors une interface d’administration de déclarer la configuration saine.

Pourtant, l’absence d’un enregistrement après le passage d’un flux reste compatible avec cet état. Le paquet a pu manquer l’ACE, rencontrer une règle antérieure, arriver sur une autre interface, ne pas être encapsulé, traverser un nœud sans la fonction requise, dépasser l’espace prévu ou perdre son export avant la collecte.

Le RFC 9617 résout un vrai problème : différents équipements peuvent recevoir une intention commune sans dialecte propriétaire. Cette réussite ne doit pas devenir un verdict sur un événement que le modèle n’a pas observé.

L’arbre YANG décrit une commande structurée

Le module ietf-ioam suit NMDA. Il comprend des informations en lecture seule, une activation administrative et une liste de profils nommés. Chaque profil peut associer un filtre, un protocole porteur et des sous-profils pour la trace incrémentale, la trace préallouée, l’export direct, la preuve de transit ou les données de bord à bord.

Les références d’interface et d’ACL, les identités, les types et les déclarations de fonctions bornent les valeurs admissibles. La validation du schéma prouve que l’instance respecte ces contraintes. La présence d’une fonction prouve que l’implémentation l’annonce. La relecture du datastore prouve qu’une valeur y réside.

Ces trois reçus sont utiles et différents. Aucun n’est un paquet capturé, un enregistrement exporté ou une preuve de réception. La précision syntaxique ne doit pas absorber la réalité d’exécution.

enabled=true ouvre la possibilité, pas l’historique

Le texte indique que l’activation administrative rend disponibles la configuration IOAM et la fonction du plan de données. Mais tous les paquets ne reçoivent pas pour autant une option. Les profils, filtres, protocoles, interfaces et rôles de nœud déterminent encore la portée.

Une relecture actuelle ne prouve pas non plus que le paramètre était actif au moment d’un paquet antérieur. Pour soutenir cette affirmation, il faut conserver les époques de configuration et les relier à l’heure de l’encapsulation ou de l’export. Le présent du datastore n’est pas une machine à réécrire le passé.

Ainsi, le booléen constitue un préalable. Le reçu d’exécution doit nommer le flux, le profil et l’événement qui ont effectivement utilisé ce préalable.

L’ACE est la charnière entre politique et trafic

Un profil peut référencer une ACE. Le RFC impose que les actions IOAM soient déclenchées par les paquets acceptés lorsque l’action de transfert de l’ACE correspondante est accept.

Cette condition empêche de traiter la simple référence comme une étiquette universelle. L’ordre des ACL, l’interface, la direction, la famille d’adresses et le comportement local participent au résultat. Une règle antérieure peut gagner. Le paquet peut ne correspondre à rien. Une ACE de même nom peut appartenir à une révision différente.

L’enquête doit donc conserver la révision active, l’identité de l’ACE, le sélecteur du paquet, le résultat de correspondance, l’action de transfert et l’époque. « Le profil vise cette ACE » décrit le dessin ; « ce paquet a correspondu à cette ACE et a déclenché IOAM » décrit l’exécution.

Le protocole porteur ne prouve pas l’enveloppe réelle

protocol-type indique le niveau d’encapsulation, notamment IPv6 ou NSH. Cette abstraction permet au profil de sélectionner les règles applicables.

Une valeur IPv6 stockée ne prouve cependant pas que le paquet considéré contenait l’option IOAM. Le paquet peut être entré ailleurs, un tunnel peut avoir changé l’enveloppe, une politique de taille peut avoir refusé l’insertion ou un nœud aval peut ne pas avoir reconnu l’option.

Le reçu doit relier l’identité du paquet avant l’ingress au résultat après encapsulation : profil, type d’option, taille, espace de noms, types de trace et identifiant de corrélation. Sans cette jointure, la configuration indique un chemin vers la preuve, non la preuve.

Une fonction annoncée peut produire une trace partielle

Les profils incrémentaux et préalloués choisissent action du nœud, espace de noms, types de trace et longueur maximale. Les méthodes d’allocation diffèrent, mais toutes deux dépendent de la participation effective des nœuds.

Le support est local. Un nœud peut comprendre une option qu’un autre ignore. Une donnée demandée peut être indisponible. L’espace préalloué peut limiter le nombre de contributions. Quatre entrées dans la trace ne prouvent donc pas que le chemin ne comptait que quatre nœuds.

Un nœud absent peut signifier chemin différent, fonction manquante, non-participation, espace épuisé, option supprimée, export perdu ou décodage impossible. La configuration n’attribue pas automatiquement une cause à cette absence.

L’export direct ouvre une seconde chaîne de garde

Le sous-profil d’export direct peut fournir un identifiant de flux et activer un numéro de séquence. Le premier aide à corréler des enregistrements ; le second rend certaines lacunes visibles.

Une séquence n’établit pas la complétude. Le collecteur peut commencer après les premiers événements, manquer un préfixe sans saut visible, perdre un paquet avant observation ou confondre un redémarrage avec une continuité. Plusieurs exportateurs peuvent avoir des espaces locaux.

Il faut enregistrer l’identité et l’époque de l’exportateur, la portée du flow-id, la règle de séquence, l’heure d’envoi, le transport, l’heure de réception, le décodage et la rétention. Alors seulement un trou devient un constat borné.

Le nom « preuve de transit » n’émet pas une preuve

Le profil POT du RFC 9617 fournit un type de base ; une variante particulière doit augmenter le module. La branche configurée n’invente donc ni propriété cryptographique ni résultat opérationnel.

De même, le profil bord à bord décrit des données ajoutées à l’encapsulation et interprétées à la décapsulation. Sa présence ne prouve pas que les deux extrémités ont traité le même paquet, ni que le service a réussi.

Cette séparation évite aussi de doubler l’analyse IOAM sur l’intégrité. La validation d’un ICV répond à une question de modification sous une méthode définie. Le RFC 9617 répond à une question de configuration. Aucune réponse ne contient silencieusement l’autre.

Une échelle de reçus qui accepte l’échec

Le premier niveau est le datastore actif : version du module, fonctions, interfaces, profil, ACL, protocole et champs. Le deuxième est la sélection du paquet. Le troisième est l’insertion ou le déclenchement réel.

Viennent ensuite les contributions par nœud, les limites et lacunes déclarées, l’export, la réception, le décodage et la rétention. L’analyse produit enfin une hypothèse. Toute action décidée à partir de cette hypothèse exige encore autorisation, installation et mesure du résultat.

Le RFC 9617 rend le premier niveau interopérable. Le promouvoir au sommet de l’échelle détruirait justement la clarté qu’il apporte.

Sources