Résumé

  • La version du 28 octobre d'un projet individuel sur le routage sensible à la bande passante change le mécanisme de retour après un détour : l'une des nouvelles conditions suppose que tous les flux ont déjà repris le chemin principal.
  • Le texte définit pourtant ce retour comme le déplacement des flux depuis les chemins de remplacement. Il ne dit pas quelle mesure, avant ce déplacement, autorise le premier pas.

Le détour fonctionne sur le papier. Le retour attend son propre résultat.

Une liaison peut perdre une partie de sa capacité sans disparaître de la topologie. Le plus court chemin reste alors le même, alors que sa capacité réelle ne suffit plus. Le projet révisé propose une réponse proche du terrain : un nœud surveille l'utilisation de ses liaisons, détecte le franchissement d'un seuil de congestion et répartit certains flux entre le trajet principal et des trajets de remplacement. Des chemins stricts de Segment Routing portent les détours ; des poids UCMP tiennent compte de la bande passante disponible. Le contrôleur peut préparer une optimisation globale pendant que le nœud agit localement.

Il faut aussi savoir quitter le mode d'urgence. Le §4.4 appelle traffic fallback le mouvement qui ramène les flux détournés sur le chemin principal. Sa première condition dit qu'une fois tout le trafic revenu, l'utilisation du chemin principal doit rester sous le « Post-restore Threshold ». La seconde impose que la première tienne pendant une « Restore Period » configurable. Ce sont des vérifications formulées après l'arrivée, présentées comme les conditions du départ.

La différence avec la version de juillet est nette. Celle-ci proposait soit de constater que l'utilisation de la liaison congestionnée était tombée sous un seuil de restauration, soit de juger dynamiquement que la liaison locale pouvait reprendre tous les flux sans congestion. Dans les deux cas, la condition devait durer pendant une période configurable. La révision d'octobre retire ces deux méthodes et installe la condition fondée sur un état entièrement restauré.

Un calcul de charge future pourrait rendre cette idée praticable. Un retour progressif, accompagné d'une marche arrière, pourrait aussi le faire. Le texte actuel ne prescrit ni estimation préalable, ni essai, ni ordre de réintroduction des flux. Mesurer la liaison principale pendant qu'une partie du trafic emprunte encore le détour ne donne pas, à lui seul, sa charge après le retour de tous les flux. Il manque une règle pour autoriser le premier flux à revenir ; une prochaine rédaction qui la précise changerait le diagnostic.

Le Datatracker classe ce document comme projet Internet individuel. La question porte donc sur la proposition publiée, pas sur une panne constatée. Elle touche néanmoins son argument central : si la décision est rapprochée du nœud, ce nœud doit disposer d'un critère applicable au moment où il décide. Une consigne qui décrit l'état final sans décrire la première décision laisse chaque implémentation écrire sa propre fin.

Sources