Résumé

  • RFC 9516 organise une observation active, locale et utile d’un chemin de fonctions de service ; il ne transforme pas cette observation en attestation de la prestation rendue.
  • Entre un Echo Reply et une affirmation sur le trafic de production se trouvent encore la classification, le chemin réellement rendu, l’instance choisie, le traitement de la fonction et l’effet constaté.

Dans une salle d’exploitation, l’erreur ne commence pas forcément par une mauvaise mesure. Elle commence souvent par une phrase qui élargit une bonne mesure. Le tableau affiche une réponse Echo, un chemin connu et un code de retour sans erreur. Quelqu’un résume alors : « le service de sécurité est sain ». Ce dernier mot n’a pourtant jamais voyagé dans le paquet.

RFC 9516 décrit l’OAM actif pour le Service Function Chaining lorsque le Network Service Header sert d’encapsulation. Il donne une grammaire à la vérification de continuité, au traçage, à la localisation des défauts et aux requêtes à la demande. Dans un domaine opérateur maîtrisé, cette grammaire est préférable au récit intuitif d’un chemin supposé. Elle rend une sonde identifiable et son résultat interprétable.

Mais elle reste une grammaire de sonde.

Le premier écart apparaît avant même que le paquet n’entre dans la chaîne. RFC 7665 définit la classification comme une correspondance locale entre des flux et une politique. Cette politique peut dépendre du client, du réseau ou du service. Deux paquets apparemment semblables peuvent donc être classés différemment par une règle, un état de session, une identité d’abonné, un port, une direction ou une décision locale qui n’existe pas dans le paquet de test.

La sonde montre qu’un paquet conçu par l’opérateur a reçu une certaine mise en chaîne. Elle ne montre pas encore que la population de paquets qu’il veut décrire a franchi la même porte de classification.

Les termes de l’architecture empêchent aussi une simplification abusive. Une SFC est un ordre abstrait de fonctions : par exemple pare-feu, répartiteur ou inspection. Un SFP en est une instanciation logique. Un RSP est la réalisation par des identités précises de Service Function Forwarders et de Service Functions. Cette dernière distinction est décisive lorsqu’un même SFP possède plusieurs réalisations, lorsqu’un SFF dessert plusieurs instances, ou lorsqu’un répartiteur choisit l’une d’elles pour un flux particulier.

Une réponse de cohérence peut signaler les fonctions attachées à un SFF. Elle ne devient pas, pour autant, le journal de l’instance qui a traité le flux de production. Dans le cas d’un équilibrage de charge, RFC 9516 indique justement qu’un flux particulier ne traverse qu’une des fonctions disponibles. Voir une liste de candidats n’est pas voir la sélection qui a eu lieu.

L’OAM actif a besoin de ressembler au trafic observé, et RFC 9516 le prend au sérieux. La requête Echo doit employer l’encapsulation de sous-couche appropriée au SFP surveillé, positionner le bit O de NSH et faire suivre immédiatement NSH par l’en-tête SFC Active OAM. Le but est le fate sharing : la sonde doit emprunter le même chemin et recevoir le même traitement de sous-couche que les données SFC observées.

Cette exigence est une discipline de conception, non un effacement des différences. Un paquet de contrôle peut ne pas reproduire la taille, le protocole applicatif, les métadonnées, les clés de flux, la pression de files d’attente ou l’état nécessaire à une fonction réelle. Une inspection peut répondre au paquet Echo sans que la transaction applicative qui intéresse le client soit correctement inspectée. Une fonction peut être présente dans le RSP mais indisponible pour une classe de trafic, un sens de circulation ou une charge particulière.

Le trajet retour demande la même prudence. La requête suit toujours le SFP indiqué par NSH ; la réponse, elle, est généralement envoyée sans NSH. Elle peut partir en UDP hors bande ou, si cela est demandé, par un chemin SFP spécifié. Un rapport qui dessine une flèche aller et une flèche retour ne doit pas les confondre. Il doit enregistrer le mode de réponse choisi et le chemin que celui-ci prouve réellement.

Le code de retour ne dépasse pas cette frontière. À l’extrémité du SFP, une requête validée reçoit le code End of the SFP. Sur un nœud de transit, No Error signifie que cette requête validée a été traitée selon ce rôle. Ces réponses sont très utiles pour délimiter une investigation. Elles ne disent ni qu’une politique de pare-feu a produit la décision attendue, ni qu’un paquet client a été optimisé, ni qu’un résultat de sécurité ou de disponibilité a été livré.

RFC 9516 ne prétend pas le contraire. Il vise la gestion de défauts. Il précise que la surveillance de performance n’est pas satisfaite par le document et reste hors de son champ. La différence est pratique : continuité, trace et localisation répondent à des questions de chemin ; délai, perte sous charge, capacité et qualité du traitement exigent des observations et des définitions supplémentaires.

Un rapport fiable sépare donc les phrases. Il peut dire : « à 14 h 03, cette sonde, avec cette construction NSH, cette version de SFP, ce mode de réponse et cette base de temps, a atteint cette fin de chemin ». Pour dire : « le service était livré », il faut joindre la preuve de classification, l’époque du RSP, les traces de l’instance de fonction pertinente, l’observation de trafic à l’entrée et à la sortie, ainsi qu’un effet mesuré selon la promesse en cause.

Cette séparation protège aussi le domaine administratif. RFC 9516 limite le déploiement envisagé à un seul domaine opérationnel de fournisseur. C’est là que l’opérateur peut connaître les éléments, construire la sonde et définir la réponse. À une interconnexion, les classifications, les chemins rendus et les autorités de preuve deviennent pluriels. Une réponse locale ne peut pas, par simple prolongement, certifier le service d’un voisin.

La sonde n’est pas insuffisante ; elle est précise. Sa valeur dépend du refus de lui prêter un mandat qu’elle n’a pas reçu.

Sources