Résumé

  • RFC 9947 définit un TLV AltMark expérimental dans le SRH, limité à un domaine SRv6 coordonné. Il donne une grammaire à une observation ; il ne certifie ni une mise en œuvre publique ni un résultat de service.
  • Les bits L et D, le FlowMonID, un horodatage ou un numéro de séquence ne deviennent probants qu’après rapprochement entre admission du domaine, fonctions SID participantes, périodes, collisions possibles, collecteurs et résultat applicatif indépendant.
  • La bonne question n’est pas « une marque a-t-elle circulé ? », mais « qui a configuré quel périmètre, quels points ont réellement traité la marque et quelle preuve séparée porte la conclusion maintenant avancée ? »

Déplacer le champ ne déplace pas la charge de preuve

La méthode Alternate Marking distingue des lots successifs de paquets afin d’observer perte, délai et gigue sur du trafic vivant. RFC 9341 décrit cette méthode. RFC 9343 la place dans des en-têtes d’options IPv6. RFC 9947 propose un autre emplacement : un TLV expérimental porté par le SRH.

Ce choix peut avoir une valeur pratique, sans que celle-ci soit acquise d’avance. Le RFC relève que les nœuds SR sont conçus pour analyser rapidement le SRH, alors que certaines implémentations ne traitent pas les Destination Options, n’acceptent pas plusieurs en-têtes d’extension ou les envoient sur un chemin lent. Mais il formule cela comme une hypothèse à tester : survie des paquets, coût de traitement et effet sur le plan de transfert doivent être comparés. Un raisonnement de conception n’est pas une mesure. Un RFC publié n’est pas l’inventaire des capacités d’un routeur particulier.

Le domaine contrôlé borne l’expérience, il ne la rend pas universelle

RFC 9947 exige que l’expérience reste dans un domaine SR contrôlé. Les participants doivent coordonner une valeur issue de la plage expérimentale de TLV, et les paquets marqués ne doivent ni entrer dans le domaine ni en sortir. Le texte ne demande aucune action IANA. Une coordination locale peut donc être rigoureuse sans devenir un fait protocolaire global.

Cette frontière est aussi une condition de sécurité. L’opérateur choisit les nœuds, contrôle l’accès et doit empêcher injection ou fuite de paquets marqués. Pourtant, « domaine de confiance » ne veut pas dire « conclusion digne de confiance ». Le périmètre ne prouve pas l’unicité de l’identifiant, la stabilité d’une liste de segments, l’activation de chaque fonction SID ou l’identité entre le chemin de 10 h 00 et celui de 10 h 15.

Le premier artefact utile n’est donc pas un percentile de tableau de bord. C’est une fiche de mesure : propriétaire du domaine, valeur de TLV, frontières, révision de politique SR, liste de segments attendue, fonctions SID participantes, sélection du trafic, période, collecteur et liste explicite des faits non démontrés. Ce registre léger permet à un lecteur ultérieur de séparer une observation reproductible d’une capture spectaculaire.

Un identifiant de flux peut désigner plusieurs candidats

Le TLV de base contient un FlowMonID de 20 bits et les indicateurs perte (L) et délai (D). Il aide à retrouver un flux surveillé parce que le Flow Label IPv6 ne peut pas tenir ce rôle. Il n’est ni une identité client, ni une autorité, ni une clé universellement unique.

Le RFC prévient expressément qu’un FlowMonID choisi au point d’entrée peut entrer en collision, même si l’allocation est pseudo-aléatoire. Les champs améliorés peuvent étendre l’identifiant et porter des informations de désambiguïsation. Cela réduit le risque seulement si le domaine les provisionne et les interprète de façon cohérente. Sans règle de correspondance conservée avec les attributs du flux, la révision de politique et l’intervalle observé, une phrase telle que « le flux 41718 a perdu 0,02 % » ne dit pas assez. Elle peut décrire un flux stable ; elle peut aussi confondre deux sélecteurs ou deux versions de règle.

Les points de terminaison de segment gardent la décision de lecture

L’emplacement SRH précise également qui peut traiter la marque. Une Hop-by-Hop Option est examinée par chaque saut ; une Destination Option avant le SRH et le TLV AltMark suivent les extrémités de segment indiquées successivement par l’adresse de destination. Un nœud intermédiaire ou de sortie qui ne sait pas traiter le TLV l’ignore selon les règles du SRH. Un paquet dirigé vers un SID sans fonction Alternate Marking ne doit même pas faire rechercher le TLV.

Cette souplesse autorise une mesure sur les seules extrémités compatibles. Elle interdit en revanche d’écrire sans nuance que « le chemin a été mesuré ». Il est possible que seul le sous-ensemble des extrémités ayant la fonction SID configurée ait produit une observation. Les sauts entre elles, une liste de segments modifiée, un TLV ignoré ou une fonction non participante restent hors du résultat.

Le bit M le rappelle : mesure segment par segment et mesure de bout en bout sont deux modes déclarés différents. Le second est un périmètre demandé dans le domaine, pas une preuve de l’expérience de l’utilisateur hors du domaine. Le premier est une observation locale, pas une garantie de l’application qui dépend de plusieurs domaines.

L’horodatage et la séquence ont eux aussi une chaîne de garde

Les champs améliorés peuvent transporter un horodatage, un numéro de séquence et des contrôles de supervision dans le sens inverse. Les nœuds peuvent comparer l’horodatage à leur heure locale pour calculer un délai unidirectionnel. C’est une capacité, non un résultat déjà validé.

Une affirmation de délai doit donc conserver la source et l’époque de l’horloge, les points de comparaison, le traitement du décalage, le lieu de capture et le calcul transformant les champs du paquet en série publiée. C’est une discipline d’évidence, pas une exigence supplémentaire attribuée au RFC. De même, un numéro de séquence montre l’ordre vu par un collecteur ; une lacune peut aussi venir de l’échantillonnage, d’une perte de capture, d’une révision de règle ou d’une indisponibilité du collecteur. Le bit F évite de compter plusieurs fois un paquet fragmenté ; il ne prouve ni la réception de tous les fragments ni la reconstruction d’un contenu par l’application.

L’expérience pose les questions ; elle n’en anticipe pas les réponses

RFC 9947 demande si le TLV SRH survit mieux ou moins bien que l’alternative par en-tête, s’il aide ou gêne le traitement, ce qu’il fait au plan de transfert et comment ses métadonnées se comparent à d’autres télémétries sur le chemin. Le document attend des évaluations ultérieures. Il ne les fournit pas.

Une expérience sérieuse doit donc comparer plutôt que célébrer. Figer versions logicielles et politique SR ; utiliser, quand cela est sûr, les deux encodages sur des trafics comparables ; enregistrer le traitement aux points attendus, les collisions, les pertes de collecteur, les compteurs de transfert, les ignorances inattendues et une sonde de service indépendante. Un résultat nul — aucune amélioration observable sur ce chemin — reste une information. L’existence d’un TLV ne l’est pas.

Les cinq échelons de la preuve

  1. Déclaration : domaine, valeur expérimentale, sélection, politique SR et fonctions SID ont été configurés.
  2. Observation de paquet : l’entrée a réellement ajouté le TLV et les points prévus l’ont observé ou traité pendant l’intervalle.
  3. Inférence de mesure : identifiants, périodes, séquences et horloges ont été rapprochés pour produire une observation bornée.
  4. Corrélation de service : une transaction, une sonde ou un canari applicatif indépendant voit le comportement pertinent.
  5. Décision : l’opérateur responsable choisit modification, acceptation, escalade ou retour arrière et en consigne le motif.

Chaque échelon autorise une phrase différente. Une configuration autorise « activé ». Une capture autorise « observé ici ». Un collecteur rapproché autorise « mesuré dans ce périmètre ». Seule une preuve de service séparée autorise « impact client » ou « objectif atteint ». La marque ne choisit jamais la remédiation.

Sources