Résumé

  • RFC 9884 permet à la sortie d’un chemin SR-MPLS de vérifier qu’un PSID correspond à la politique, au Candidate Path ou à la Segment List annoncés dans la requête.
  • Lorsqu’un PSID représente seulement certaines listes, chaque liste exige son propre LSP Ping. Plusieurs sous-TLV PSID dans le même message ne produisent pas un contrôle collectif : seul le premier est traité.
  • Les nœuds de transit ne traitent pas le PSID, d’où l’absence de LSP Traceroute dans ce RFC. Avec ECMP, le PSID désigne la liste d’instructions, pas le trajet effectif du paquet.

Le code de retour 3 vient d’arriver. L’équipement qui répond se reconnaît comme sortie du FEC testé et confirme que l’étiquette reçue correspond au contexte présenté. Dans une salle d’exploitation pressée, « chemin validé » devient vite le résumé officiel.

Ce raccourci efface l’objet du test. Le message a atteint une sortie et cette sortie a reconnu une association. Aucun nœud intermédiaire n’a attesté son passage. Rien ne démontre que le trafic client a suivi le même partage ECMP, ni que toutes les listes regroupées sous le PSID ont été interrogées.

Une mémoire locale après la disparition des instructions

Dans SR-MPLS, le headend inscrit une suite ordonnée d’instructions dans la pile MPLS. Les étiquettes sont ensuite échangées ou retirées. RFC 9545 part de ce constat : à l’arrivée, la pile ne suffit plus nécessairement à savoir par quel chemin SR le paquet est venu.

Le Path Segment Identifier est une étiquette locale allouée par la sortie. L’entrée l’insère immédiatement après la dernière étiquette du chemin ; la sortie la retire. Ce repère peut servir à corréler compteurs et horodatages ou à associer deux directions. Avant de s’en servir, il faut toutefois vérifier qu’il pointe vers le bon objet de contrôle.

RFC 9884 ajoute ce contrôle à LSP Ping. Le headend, ou un système central connaissant la topologie, construit un Target FEC Stack qui décrit le contexte attendu. La sortie compare la demande avec l’état qu’elle a reçu par signalisation ou configuration.

Trois portées qui ne s’héritent pas

Une même étiquette PSID peut représenter toutes les Segment Lists d’une SR Policy, toutes celles d’un Candidate Path, une liste précise ou une sélection de listes. Le RFC définit donc trois familles de sous-TLV, chacune en IPv4 et en IPv6.

Au niveau Policy, le contrôle porte sur Headend, Color et Endpoint. Au niveau Candidate Path s’ajoutent Protocol-Origin, Originator et Discriminator. Au niveau Segment List, Segment-List-ID complète la clé. Cette progression suit le modèle de RFC 9256 : la politique, sa voie candidate et la liste d’instructions sont des objets imbriqués, non des synonymes.

Le résultat doit conserver la portée choisie. Une réussite au niveau Policy ne prouve pas quelle liste a transporté un flux. Une réussite du Candidate Path ne signifie pas que chaque liste membre a été testée. Et un résultat portant sur une liste ne s’étend pas automatiquement à sa voisine.

Le texte verrouille ce dernier point : si le PSID agrège certaines listes, il faut envoyer plusieurs requêtes, une par Segment List. Empiler plusieurs nouveaux sous-TLV dans une requête ne contourne pas la règle, car seul le premier est traité.

La réponse décrit une correspondance

Un sous-TLV mal formé appelle le code 1. Si le PSID n’est pas associé aux champs fournis, la sortie utilise le code 10 : le FEC ne correspond pas à cette étiquette à la profondeur indiquée. Si toutes les comparaisons réussissent, le code 3 indique que le routeur répondant est la sortie de ce FEC.

Cette réponse est utile. Elle peut révéler une configuration périmée ou une divergence entre contrôleur et sortie. Elle relie aussi une requête, une profondeur de pile, une étiquette et un contexte précis.

Elle n’est pas un relevé de route. RFC 9884 écarte LSP Traceroute puisque les transits ne participent pas au traitement du PSID. Son témoin est la sortie. Demander à ce témoin s’il connaît l’étiquette n’équivaut pas à demander à tous les intermédiaires où ils ont acheminé le paquet.

ECMP résiste à l’identité symbolique

RFC 9545 apporte une limite supplémentaire : sous ECMP, une liste de SID peut conduire les paquets sur plusieurs chemins physiques. Le PSID identifie alors la liste, pas l’itinéraire effectivement suivi. L’ajout du PSID peut même modifier le choix ECMP d’un flux existant et fausser certaines utilisations de mesure.

Il faut donc conserver séparément l’intention SR, l’association du PSID, le résultat de la sonde, le trajet de cette sonde et celui du trafic de production. RFC 8403 montre comment un dispositif connaissant la topologie peut corréler plusieurs sondes et l’état IGP. RFC 8029 fournit des outils plus vastes de ping et de traceroute. Ces preuves complémentaires ne sont pas cachées dans le code 3.

Le retour possède aussi une politique d’acceptation

Les sous-TLV PSID peuvent également figurer dans les structures de chemin retour ou de réponse. La sortie les renvoie, puis le headend refait les contrôles. En cas d’échec, il doit abandonner la réponse et devrait journaliser ou signaler l’erreur, sans réécrire le code de la sortie.

Une absence de résultat peut donc recouvrir plusieurs réalités : aucune réponse, réponse mal formée, association refusée à la sortie ou validation inverse rejetée au headend. Les transformer en un même « timeout » détruit l’information nécessaire au diagnostic.

Sources