Summary

  • Dans l’architecture SR Policy, « active » signifie que la tête de réseau a retenu le meilleur chemin candidat valide. Ce mot ne dit pas qu’un flux donné a satisfait la règle d’aiguillage.
  • La preuve utile relie l’identité de la politique et le candidat retenu à la liste de segments, au BSID et au FIB, au sélecteur de trafic, à l’encodage du paquet, au chemin observé et à l’objectif de service mesuré.
  • Selon le comportement par défaut décrit pour l’aiguillage BGP, une route sans couleur autorisée ou sans politique valide correspondante reste résolue par l’IGP, même si une autre politique apparaît active sur la tête de réseau.

Le voyant vert qui n’a pas déplacé le flux

Imaginons un opérateur qui examine une dégradation de latence. Le contrôleur indique que la politique SR prévue est valide et active. Le candidat préféré est présent et sa liste de segments paraît cohérente. Pourtant, une sonde lancée depuis l’entrée concernée suit le plus court chemin IGP.

Il n’y a pas de contradiction. L’écran de politique répond à une question de sélection : quel candidat valide a gagné pour cette politique sur cette tête de réseau ? La sonde répond à une question de transfert : quelles instructions ce paquet a-t-il réellement reçues, et où l’ont-elles conduit ? Si la route ne satisfait pas l’association entre couleur autorisée et prochain saut, elle peut manquer la règle d’aiguillage et conserver sa résolution IGP. La politique reste active sans transporter le trafic examiné.

Le mot « active » est séduisant parce qu’il est bref, lisible par une machine et généralement vert. Mais il se trouve au début de la chaîne causale, non à son terme.

Ce que l’état actif établit réellement

La RFC 9256 identifie une politique SR par le triplet <Headend, Color, Endpoint> ; sur une tête de réseau donnée, <Color, Endpoint> suffit. Plusieurs chemins candidats peuvent coexister. Un candidat est utilisable lorsqu’il est valide, et le candidat actif est le meilleur candidat valide, choisi principalement selon sa préférence. Toute évolution pertinente impose une nouvelle sélection.

C’est une preuve substantielle : elle nomme précisément l’objet et le candidat qui le représente à cet instant. Elle peut également exposer une ou plusieurs listes de segments actives et leurs pondérations. Elle ne démontre toutefois pas que le trafic ciblé a été dirigé vers la politique. La RFC 9256 conditionne l’emploi du chemin actif au fait que le trafic soit effectivement aiguillé vers lui, sous réserve des mécanismes de protection.

Lorsque plusieurs listes sont actives, la répartition pondérée peut s’effectuer par flux et sa précision dépend de l’implémentation. Une sonde réussie ne certifie donc pas toute la distribution ; une sonde inattendue ne prouve pas non plus que tous les flux ont échappé à la politique.

L’aiguillage constitue une décision distincte

Pour l’aiguillage BGP par destination, le comportement par défaut présenté dans la RFC 9256 réunit trois faits : le prochain saut de la route, une Color Extended Community autorisée et une politique SR valide correspondant à ce prochain saut et à cette couleur. Si l’association existe, la route peut être résolue sur la politique. Sinon, le comportement par défaut est la résolution IGP ordinaire vers le prochain saut.

Un tableau de bord peut condenser à tort plusieurs états en une ligne rassurante. La politique peut être active mais la route dépourvue de couleur ; la couleur peut être présente mais non autorisée ; le prochain saut peut désigner un autre endpoint ; la politique correspondante peut être devenue invalide. Un déploiement peut aussi exiger l’abandon du trafic en cas d’invalidité au lieu du repli IGP. Tous ces faits concernent l’aiguillage et la résolution, pas le choix du candidat.

Le Binding SID ne doit pas devenir une identité de substitution. Il appartient au chemin candidat actif, fournit une instruction de transfert vers la politique, doit être disponible et peut changer d’association au cours de la vie de celle-ci. La RFC 9256 précise donc qu’il ne faut pas l’utiliser pour identifier la politique. Le triplet reste l’identité stable ; le BSID est un état de transfert courant à vérifier.

Les instructions décisives sont dans le paquet

La RFC 8402 décrit Segment Routing comme une suite ordonnée d’instructions imposées à la tête de réseau. En SR-MPLS, elles prennent la forme d’une pile de labels ; en SRv6, d’une liste ordonnée de SID, souvent portée par un SRH. Lorsqu’un segment actif local correspond au BSID d’une politique, le paquet est dirigé vers cette politique.

L’encodage du paquet apporte ainsi une preuve qu’aucun statut de contrôle ne remplace. Une capture de labels ou de SID indique si les instructions attendues ont été imposées. Les compteurs montrent si l’action programmée a été exercée. Une sonde sensible au chemin teste la route obtenue ; les mesures de latence et de perte testent l’objectif de service. Ensemble, ces observations relient l’intention sélectionnée au comportement livré.

La protection nuance encore l’interprétation. TI-LFA peut protéger un segment IGP constitutif ; pendant la réparation rapide, le trajet temporaire peut ne pas respecter exactement toutes les contraintes de la politique SR. Une politique active et un détour transitoire peuvent donc être tous deux légitimes. Le dossier d’incident doit conserver le temps et l’état de protection au lieu d’assimiler tout écart à un échec de sélection.

Sources