Résumé
- La RFC 8966, cosignée par Juliusz Chroboczek et David Schinazi, traite le calcul de la métrique Babel comme une politique locale. Elle exige seulement qu’un coût local infini donne une métrique infinie et que l’ajout d’un coût rende la métrique strictement plus grande.
- Cette propriété porte sur l’évitement des boucles. Elle ne permet pas de lire un chiffre comme une mesure mondiale de débit, de prix, de délai réel, de joignabilité ou de qualité de service. La RFC 9616 rappelle qu’un échantillon RTT peut être précis tout en restant trop bruité pour décider directement d’une route.
Une contrainte de sûreté, pas une note publique
Une table de routage donne facilement au lecteur l’impression que ses nombres décrivent le réseau tout entier. La valeur la plus petite paraît meilleure; une valeur stable paraît garantir quelque chose. Mais un protocole peut employer un nombre pour préserver une relation interne sans lui attribuer ce sens général.
Dans Babel, le voisin annonce une métrique et le nœud calcule son propre coût de lien. La RFC 8966 ne prescrit pas une formule universelle. Elle autorise des stratégies différentes entre nœuds d’un même réseau et entre types d’interfaces. La règle partagée est plus modeste : la fonction doit être strictement monotone. Une route ne peut pas traverser un lien supplémentaire tout en devenant, selon cette même logique, meilleure qu’elle ne l’était avant ce lien.
Cette discipline rend l’invariant vérifiable localement. Elle ne transforme pas la métrique en certificat sur un tunnel, un marché, une clientèle ou un service distant. Une valeur sélectionnée explique une décision sous des entrées et des hypothèses déclarées; elle ne remplace pas les preuves de l’effet observé.
Sans optimum global garanti
La RFC distingue soigneusement la monotonie stricte de la distributivité à gauche. La première est essentielle pour éviter les boucles persistantes. La seconde est recommandée, non essentielle à une convergence sans boucle. Sans elle, Babel peut converger sans que l’optimum global soit atteint — et un tel optimum peut même ne pas exister.
Cette limite protège contre une fausse extension de sens. Des politiques locales peuvent privilégier des caractéristiques différentes tout en restant compatibles avec la condition de sûreté. Une métrique est alors utile parce qu’elle est située, non parce qu’elle aurait découvert une vérité abstraite sur tous les chemins.
La sélection conserve d’autres frontières : une route infinie ou infaisable n’est pas sélectionnée, et un numéro de séquence plus récent ne doit pas, à lui seul, être préféré. La RFC avertit qu’une telle préférence peut provoquer oscillations et, avec certaines métriques, trous noirs persistants. Lorsque les métriques fluctuent, l’hystérésis recommandée ralentit le basculement. Elle stabilise une décision; elle ne certifie pas une performance.
Mesurer n’est pas encore décider
La RFC 9616, de Baptiste Jonglez et Juliusz Chroboczek, rend cette séparation concrète. Elle indique que Babel ne fixe aucun algorithme de métrique. Son extension RTT répond à certains mauvais choix dans des topologies de tunnels ou de VPN, mais elle refuse de confondre échantillon et règle. Les mesures RTT peuvent être exactes et pourtant bruyantes; injectées directement dans la sélection, elles peuvent créer un retour négatif et des oscillations. Le document définit donc une transformation et de l’hystérésis.
Il limite aussi l’emploi de l’extension aux situations où le délai symétrique prédit utilement le choix de lien. Cela exclut une conclusion sur tous les réseaux, toutes les applications ou tout ressenti d’utilisateur. La RFC 8965, écrite par Chroboczek, confirme l’esprit : les hypothèses faibles de Babel favorisent des métriques nouvelles ou fluctuantes, mais les mises à jour périodiques et l’hypothèse d’une table complète fixent également des limites.
Le profil IETF de Chroboczek relie publiquement les RFC 8965, 8966 et 9616 à son travail. Il ne lui attribue ni le contrôle d’un déploiement, ni une métrique obligatoire, ni l’autorité sur la décision de chaque opérateur.
Limites de preuve
Les sources ne prouvent aucun déploiement Babel actuel, aucun tunnel actif, aucune mesure RTT présente, aucun débit, aucune route livrant effectivement du trafic ni aucune qualité de service. Elles ne prouvent pas qu’une métrique locale est optimale partout. Le reçu approprié conserve plutôt la famille de métrique, la portée des entrées locales, la transformation, l’état de faisabilité, l’hystérésis et le contexte d’interface.
Sources
- RFC Editor record for RFC 8965
- RFC 8965 — Applicability of the Babel Routing Protocol
- RFC Editor record for RFC 8966
- RFC 8966 — The Babel Routing Protocol
- RFC Editor record for RFC 9616
- RFC 9616 — Delay-Based Metric Extension for Babel
- Profil IETF Datatracker de Juliusz Chroboczek
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running-Code Primacy
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
