Résumé

  • Une valeur Generic Metric maximale reste utilisable comme dernier recours : elle renchérit le lien sans le retirer du calcul Flex-Algorithm.
  • L’absence de la métrique non-IGP choisie par la FAD gagnante entraîne l’élagage du lien. En revanche, l’absence de bande passante ou de délai n’entraîne pas, à elle seule, son exclusion par les contraintes correspondantes.
  • La preuve exploitable doit conserver la présence du champ, sa provenance, la règle qui le consomme, le motif d’élagage, la topologie calculée et les observations ultérieures de FIB et de trafic.

Un lien est signalé « au maximum » pendant une maintenance. Un autre n’annonce plus sa métrique. Un troisième ne fournit aucune mesure de délai. Dans une console sommaire, les trois deviennent des cases rouges : anomalie, donnée manquante, risque élevé. Dans le calcul, ils n’ont pourtant rien d’équivalent.

Le premier peut rester la seule issue. Le deuxième doit disparaître de la topologie concernée. Le troisième poursuit l’examen des règles suivantes, car la contrainte de délai ne dispose pas de la valeur qui lui permettrait de l’écarter. Une couleur d’interface ne peut pas remplacer cette grammaire.

RFC 9843, publié en septembre 2025 sur le Standards Track et décrit dans sa fiche officielle, met à jour RFC 9350. Ses versions texte et XML fixent les publicités de métriques génériques, les contraintes de bande passante minimale et de délai maximal, ainsi que deux méthodes automatiques de calcul d’une Bandwidth Metric pour IS-IS et OSPF. Le document normalise un mécanisme ; il ne prouve ni déploiement, ni route installée, ni résultat de service.

La valeur la plus coûteuse n’est pas un retrait

Pour IS-IS, 0xFFFFFF est la valeur Generic Metric maximale utilisable ; pour OSPF, c’est 0xFFFFFFFF. RFC 9843 exige que le lien demeure disponible comme lien de dernier recours. Cette nuance rend possible un drainage prudent : on détourne le trafic vers les chemins moins coûteux sans supprimer la dernière continuité.

Elle rend aussi dangereuse l’expression « le routeur est sorti ». Si aucun chemin alternatif n’existe, le trafic peut rester sur le lien au maximum. Le changement a exprimé une préférence, pas une interdiction. Une preuve de maintenance doit donc relier l’intention, la métrique et la topologie effectivement recalculée. Le nombre seul n’atteste pas l’isolement.

Le socle RFC 1195 pour IS-IS et RFC 2328 pour OSPF reste pertinent. Les attributs d’ingénierie de trafic de RFC 5305 et RFC 3630 gardent leur forme et leur précédence. RFC 9843 ne transforme pas toutes les métriques existantes en un champ générique interchangeable : une publicité générique qui duplique un type disposant d’un mécanisme historique est ignorée.

L’absence de la métrique choisie ferme le passage

Le calcul Flex-Algorithm commence par une définition gagnante, la FAD. Elle nomme notamment le type de métrique et les contraintes. Selon la procédure ordonnée de RFC 9350, si ce type n’est pas l’IGP ordinaire et qu’un lien ne publie pas la métrique exigée, ce lien est élagué. Il est interdit de lui attribuer implicitement zéro.

Cette interdiction protège le sens. Zéro ferait du lien le moins documenté le chemin le plus attrayant. Une valeur locale implicite ferait diverger les routeurs selon leurs conventions. L’élagage est ici la conséquence d’une entrée indispensable au calcul qui n’existe pas.

Le calcul automatique de bande passante introduit une dérivation contrôlée. Quand la FAD le demande, l’absence d’une Bandwidth Metric explicite peut être compensée par une valeur calculée à partir de la Link Bandwidth annoncée. Si cette donnée de base manque elle aussi, le lien est élagué. « Métrique absente » doit donc être ventilé en au moins deux états : valeur dérivable ou entrée de dérivation indisponible.

L’absence de preuve de contrainte laisse le lien poursuivre

La contrainte FAEMB pose une autre question : la Maximum Link Bandwidth annoncée se situe-t-elle sous le minimum fixé par la FAD ? Si oui, le lien est exclu. Si cette bande passante n’est pas annoncée, RFC 9843 dit de ne pas l’exclure sur cette base ; il poursuit les règles d’élagage suivantes.

FAEMD applique la même logique de preuve au délai. La valeur Min Unidirectional Link Delay, définie dans l’environnement de RFC 8570 et RFC 7471, est comparée au plafond. Une valeur trop élevée élimine le lien. Une valeur absente ne le fait pas échouer à cette règle.

Cela ne signifie pas que le lien respecte le seuil. Cela signifie seulement que la prémisse du rejet n’est pas disponible. L’afficher « conforme » serait aussi faux que l’afficher « élagué ». Les conteneurs applicatifs de RFC 9479 et RFC 9492 ajoutent une autre dimension : la présence d’un attribut ailleurs dans l’état de liens ne garantit pas qu’il soit celui que l’application sélectionnée peut consommer.

Un opérateur peut vouloir une politique plus stricte : refuser d’activer une FAD tant que chaque lien candidat ne publie pas bande passante et délai. C’est une décision locale légitime, mais il faut la nommer comme précondition d’admission. Elle ne doit pas être attribuée au comportement commun de la contrainte. C’est ici que la doctrine de docs/heng-lu-note.md devient pratique : le standard partage une règle minimale et déterministe ; l’exigence d’exploitation reste proche de l’opérateur et de son code.

Une fonction de capacité n’est pas une mesure de charge

RFC 9843 propose une méthode par bande passante de référence et une méthode par seuils. La première divise une référence par la capacité annoncée ; une granularité évite que de petites variations changent sans cesse la métrique. La seconde associe des tranches de capacité à des valeurs prédéfinies. Une FAD qui annonce simultanément les deux méthodes est ignorée, et une référence nulle invalide son sous-TLV.

Une Bandwidth Metric explicitement annoncée prévaut sur la dérivation. Le mode Interface Group traite les liens parallèles ensemble. Si tous publient une métrique explicite, chacune est utilisée. Si seulement certains la publient, ces valeurs partielles sont ignorées et le calcul automatique est appliqué à l’ensemble. Les modèles de membres de faisceau de RFC 8668 et RFC 9356 aident à comprendre pourquoi la capacité effective dépend des composants actifs et de l’appartenance au groupe.

Mais cette capacité n’est pas la charge instantanée. RFC 9843 précise que ses procédures ne mettent pas la métrique à jour selon le trafic réel et ne remplacent pas la vision dynamique d’un PCE de RFC 4655. Un coût dérivé d’un lien rapide ne prouve ni bande passante disponible, ni absence de congestion, ni aptitude d’un flux massif au moment présent.

Le reçu doit expliquer la règle qui a décidé

Les contextes Flex-Algorithm IS-IS et OSPF de RFC 8919 et RFC 8920 rappellent que l’identifiant de l’algorithme ne suffit pas. Il faut conserver la FAD gagnante, son origine, son type de calcul, son type de métrique et ses contraintes. Le vocabulaire normatif de RFC 2119 et RFC 8174 distingue les obligations des simples explications.

Pour chaque lien, un reçu sérieux contient l’état de présence de la métrique, de la bande passante et du délai ; la valeur brute, l’unité, l’âge et la publicité source ; le caractère explicite, dérivé ou indisponible ; les paramètres de référence ou de seuil ; l’appartenance au groupe d’interfaces ; les doublons et combinaisons invalides rencontrés ; la première règle d’élagage décisive ; puis, séparément, le résultat SPF, la FIB observée et les preuves de paquets ou de service revendiquées.

Les tests en découlent. Pousser la valeur au maximum sans chemin alternatif doit conserver le dernier recours. Retirer la métrique sélectionnée doit élaguer le lien. Demander une dérivation sans Link Bandwidth doit également l’élaguer. Retirer uniquement la mesure FAEMB ou FAEMD doit laisser passer cette règle sans produire un faux verdict de conformité. Une publicité partielle dans un groupe parallèle doit céder au calcul commun. Deux méthodes automatiques simultanées doivent invalider la FAD.

La réussite n’est pas que tous les écrans soient verts. Elle est que chaque participant puisse reproduire le même parcours depuis les mêmes octets jusqu’au même motif de décision.

Limites de ce rapport

Aucun routeur, logiciel, constructeur, numéro d’algorithme, seuil, lien, délai, domaine ou événement de maintenance n’a été testé. Aucun chemin installé, paquet, encombrement évité ou résultat SLA n’a été observé. Le statut Standards Track ne prouve ni adoption ni conformité. Une topologie calculée n’est pas une route utilisée.

La conclusion demeure utile : le maximum renchérit sans retirer ; l’absence de métrique requise peut retirer ; l’absence de preuve de seuil ne retire pas par cette règle. Sans la règle consommatrice, « donnée manquante » n’explique rien.

Sources