Résumé

  • Dans l'exemple du projet de la SPRING Working Group, CP1 répartit 200 Mbit/s entre deux listes de segments de 100 Mbit/s supposés chacune. La disparition de l'une laisse un chemin candidat encore « valide » selon le critère recommandé par la RFC 9256, avec une capacité supposée divisée par deux.
  • Deux seuils proposés, nombre minimal de listes valides et somme minimale de leurs poids, permettent de décider plus tôt que CP1 doit sortir de la sélection. Le chiffre choisi n'a de sens que si l'exploitant tient à jour la capacité qu'il prétend protéger.

Le mot valide a trouvé un alibi

Une paire de listes de segments porte 200 Mbit/s, 100 Mbit/s par liste. L'une devient invalide. Selon le projet de la SPRING Working Group, la survivante ne peut pas absorber seule les 200 Mbit/s de l'exemple. Pourtant CP1, le chemin candidat qui les réunit, peut rester actif. La RFC 9256 recommande qu'au moins une liste constitutive soit valide pour que le chemin candidat le soit. Le protocole a répondu à la question posée; l'exploitation lui en prête une autre, celle de la capacité disponible.

POL1, la politique de l'exemple, comporte CP1 et CP2. CP1 est préféré et actif. Ses deux listes, SL1 et SL2, ont chacune un poids de 1 et une capacité maximale supposée de 100 Mbit/s; le hachage des flux répartit la charge par moitié. Après la perte d'une liste, le critère de base laisse une liste valide. CP1 garde donc sa place, tandis que l'hypothèse économique et technique qui justifiait sa charge de 200 Mbit/s vient de disparaître. Le projet ne chiffre pas la capacité de CP2. Il serait commode d'appeler CP2 le sauveur; aucun chiffre du dossier ne permet de lui confier ce rôle.

La nuance intéresse quiconque achète, vend ou garantit une capacité. « Il reste une route » est une observation utile. « La route porte encore le service » exige une autre preuve. Sur un écran, ces deux propositions tiennent parfois dans la même pastille verte. C'est ainsi que l'instrument de contrôle peut masquer une perte avant même que la politique entière ne tombe en panne.

Deux seuils, une responsabilité

Le premier paramètre proposé est un minimum de listes de segments valides, codé sur 8 bits. Dans l'exemple, le fixer à 2 invalide CP1 dès qu'une des deux listes échoue. La valeur 0 supprime cette exigence supplémentaire; 0xff exige que toutes les listes soient valides. Le second paramètre porte sur la somme des poids des listes encore valides, sur 32 bits. Avec deux poids de 1, un minimum de 2 produit le même verdict après la perte d'une liste: la somme n'est plus que 1. Zéro retire l'exigence; 0xffffffff impose toutes les listes. Les deux conditions doivent être satisfaites lorsqu'elles sont renseignées. Deux zéros ramènent au fonctionnement de la RFC 9256.

Le minimum de listes a la netteté d'un compteur et la brutalité d'un compteur. Deux listes valides peuvent avoir des capacités très différentes. La somme des poids paraît plus fine, mais un poids relatif de répartition n'est pas une mesure de débit. Les auteurs font correspondre 1 et 1 à 100 et 100 Mbit/s parce que c'est l'hypothèse de leur exemple. Si le lien physique, la réservation ou la charge changent sans révision des poids, le seuil peut valider un ancien plan de capacité. L'exactitude arithmétique du contrôle ne sauvera pas une donnée d'entrée périmée.

Le projet prévoit que la tête de réseau puisse recevoir ces paramètres par configuration, PCEP ou BGP. Les extensions protocolaires précises sont renvoyées à un autre texte et aucune allocation IANA n'est demandée ici. Cette liberté place la décision là où se trouve le risque: chez l'opérateur qui connaît la charge promise. Celui-ci doit dire qui fixe le minimum, comment la valeur atteint la tête de réseau, comment une modification est confirmée et à quel événement la valeur est recalibrée. Sans cette chaîne, l'ajout de champs donnera surtout des captures d'écran plus riches.

La panne a plusieurs étages

Une liste de segments peut devenir invalide selon les règles de résolution ou de vérification de la RFC 9256. Son chemin candidat peut rester valide si une autre liste survit. La politique SR entière devient invalide quand tous ses chemins candidats le sont. Une modification de la validité d'un chemin déclenche une nouvelle sélection; le chemin valide de préférence la plus élevée l'emporte. Les nouveaux seuils agissent sur ce niveau intermédiaire. Ils peuvent écarter CP1 avant que sa dernière liste ne disparaisse.

La distinction importe face à l'option Drop-Upon-Invalid de la RFC 9256, qui traite la politique entière devenue invalide. Le litige de capacité commence plus tôt. L'outil peut afficher CP1 comme actif avec une seule liste restante, alors que les 200 Mbit/s qui motivent son emploi ne tiennent plus dans la capacité supposée de cette liste. Rendre CP1 invalide relance une décision de chemin; cela ne certifie ni la capacité de CP2 ni le destin des paquets.

Le projet fournit un scénario calculé, sans trace d'un réseau en production ni mesure de congestion. Pour établir un effet réel, il faudrait rapprocher les seuils déployés, les capacités vérifiées, la charge observée et le résultat de la sélection. Les nombres du projet suffisent à démontrer le décalage possible entre critère et usage; ils ne nomment aucune victime d'une surcharge.

Le registre qui manque derrière le voyant

Une preuve opérationnelle simple enregistrerait la charge attribuée à CP1, la validité de SL1 et SL2, le nombre et le poids des survivantes, les deux minima appliqués et leur origine. Si le contrôleur émet 2 et que la tête de réseau utilise 0, la différence est un fait de gouvernance, pas une note de bas de page. Si les capacités changent, le registre doit montrer quand les poids et les minima ont été révisés. L'exploitant peut alors expliquer ce que le voyant vert garantissait à une heure précise.

Sources