SR Policy : qui décide du score qui déplace les flux ?

Résumé

Un Internet-Draft individuel daté du 28 octobre 2026 propose de mesurer la qualité des chemins, de calculer une note par Segment List et d’ajuster leurs poids à l’intérieur du Candidate Path actif. La définition de la qualité et la fonction de calcul restent configurables.
RFC 9256 convertit le poids relatif en proportion de flux orientés vers chaque Segment List ; la précision dépend de la plateforme. Une note plus haute peut changer la règle de répartition sans prouver le débit, les octets transportés ou la performance de l’application.

Le thermomètre commande l’aiguillage

Le projet actuel dessine une situation séduisante pour tout exploitant : trois Segment Lists, des poids égaux et un trajet qui perd de sa qualité. Selon son exemple, la répartition statique continue d’y envoyer un tiers du trafic. Pourquoi laisser le routeur s’obstiner lorsque les mesures indiquent une meilleure voie ? Les auteurs proposent une boucle qui recueille les indicateurs, compare les trajets et modifie les poids. La réponse semble mécanique. Elle dépend pourtant d’une question politique au sens le plus concret : qui choisit la définition de « meilleur » quand plusieurs usages de la même infrastructure se disputent la voie ?

La boucle décrite comporte des rôles précis. Des nœuds intermédiaires ou terminaux mesurent des valeurs comme le délai, la perte de paquets et l’utilisation. Leurs rapports vont vers une entité logique appelée Candidate Path Quality Agent, ou CPQA. Celle-ci agrège les observations en une note de qualité pour chaque Segment List, applique une fonction F et produit de nouveaux poids. Le head-end installe la pondération et oriente les flux. Le projet précise le trajet des données et de la décision ; il laisse la combinaison des mesures configurable. Deux équipes peuvent ainsi employer la même architecture et donner des classements contraires aux mêmes chemins.

Une latence faible n’est pas une promesse de débit soutenu. Un lien encore disponible peut être mauvais pour les paquets courts à cause d’une longue traîne de délai et suffisant pour un transfert volumineux. La version 01 ajoute justement une motivation liée à la coexistence, dans les calculs d’IA, de longues communications collectives et de petites requêtes d’inférence ou de contrôle. Les premières privilégient un débit durable ; les secondes sont sensibles au temps de réponse. Cette description vient des auteurs du projet. Elle ne fournit aucune mesure d’un réseau nommé.

Elle montre surtout pourquoi la note unique n’est pas un simple constat : son concepteur prend parti pour une classe de trafic.

Le dénominateur du RFC compte des flux

RFC 9256 donne une règle plus étroite que le vocabulaire commercial des « meilleurs chemins ». Une politique SR peut comporter plusieurs Candidate Paths ; le chemin actif fournit les Segment Lists utilisées pour transférer le trafic. Si plusieurs listes sont présentes, le head-end répartit les flux par ECMP pondéré. Pour une liste de poids w, la fraction visée est w / somme des poids. Le RFC ajoute que la précision de cette répartition dépend de la plateforme. Le poids n’est ni un compteur d’octets, ni une capacité réservée, ni une mesure du temps de réponse.

Dans l’illustration à trois listes égales, un tiers signifie une part théorique des flux. Un gros flux peut remplir une voie pendant que dix petits flux occupent l’autre. Après recalcul, une liste dont le poids augmente peut gagner des flux et transporter relativement peu d’octets ; une liste dont le poids baisse peut garder un transfert particulièrement lourd. Pour juger le changement, il faut lire à la fois la pondération installée, la distribution réelle et le résultat des applications. Confondre ces trois données permet à une belle courbe de qualité de s’attribuer des gains que le réseau n’a pas démontrés.

Le champ d’action du projet est limité : les poids des Segment Lists dans le Candidate Path actif changeraient, sans modifier la priorité du chemin ni la composition des listes. Le même document décrit séparément un mode de redirection de flux congestionnés : au lieu de retoucher seulement les poids relatifs, le head-end déplacerait des flux identifiés vers une liste moins chargée. Ce sont deux interventions différentes. La première ajuste une règle de partage, la seconde choisit des flux particuliers. Une politique d’exploitation doit préciser l’activation, l’arrêt et la preuve d’effet de chacune ; le projet n’apporte pas un résultat de déploiement qui permettrait de les confondre.

Même fonction, deux sièges possibles

Le CPQA peut siéger au contrôleur central. Dans ce mode, le contrôleur reçoit les rapports, calcule les scores et envoie le tuple de poids au head-end par une interface vers le sud, PCEP étant cité comme exemple. Il peut aussi siéger au head-end : les moniteurs lui envoient directement les rapports et il applique localement sa décision. Le document ne crée pas de nouveau format PCEP et sa section IANA ne demande aucune allocation actuelle ; de futurs textes d’extension pourraient en avoir besoin. Il s’agit d’un cadre de décision, pas d’un bouton normalisé que tous les routeurs possèdent déjà.

Le choix du siège modifie la responsabilité opérationnelle. Un contrôleur peut comparer plusieurs chemins avec une vue plus large et imposer une politique commune. Une erreur dans son calcul peut également voyager largement. Un head-end peut agir sur ses observations locales, mais deux head-ends peuvent définir différemment « qualité ». Le projet autorise cette latitude. Elle exige donc une trace de la politique effectivement retenue : quels moniteurs, quelle fenêtre de mesure, quelle agrégation, quelle version de F, quels anciens et nouveaux poids, et quel état de transfert constaté ensuite ?

La sécurité des messages ne répond qu’à une partie du problème. Le texte exige l’authentification des échanges entre moniteurs, CPQA et entité qui applique les poids ; il recommande TLS ou TCP-AO. Les rapports peuvent révéler l’état interne du réseau, et le chiffrement devrait être envisagé lorsque cette confidentialité importe. Le projet demande une résistance aux faux rapports diffusés en masse, avec limitation de débit et validation des sources. Une signature valide dit d’où vient un rapport. Elle ne prouve pas que le moniteur était bien placé, que son échantillon représentait le chemin entier ou que F protégeait la bonne application. La qualité des entrées et le droit de décider restent des sujets séparés.

Le projet prévoit aussi un amortissement pour éviter que les poids oscillent après chaque variation passagère. Il ne fixe pas dans ce cadre de seuil ou d’algorithme valable partout. Une boucle trop nerveuse peut poursuivre le trafic qu’elle vient elle-même de déplacer : nouvelle utilisation, nouvelle note, nouvelle décision. Une boucle trop lente peut continuer d’alimenter la voie dégradée. Le réglage appartient à l’opérateur et mérite d’être enregistré comme un changement de politique, pas enfoui dans une option « automatique ».

La chronologie évite une autre confusion. La version 00 de juillet proposait déjà la boucle mesure-rapport-calcul-application. La version 01 d’octobre ajoute l’exemple des charges d’IA et un troisième auteur ; elle ne crée pas le mécanisme à partir de rien. Datatracker classe le texte comme Internet-Draft individuel. Les originaux consultés ne contiennent ni essai d’interopérabilité nommé ni mesure qui relie une configuration de F, des poids installés et une amélioration d’application. Une telle trace changerait le jugement pour une mise en œuvre donnée.