Résumé

  • La RFC 10005 définit le transport BGP d’une valeur flottante de quatre octets, exprimée en octets par seconde, mais ne définit ni son mode de calcul ni l’algorithme de répartition pondérée.
  • Zéro, absence, valeurs multiples, transitivité et changement de prochain saut ouvrent des choix de politique. Une communauté valide ne prouve donc ni la capacité disponible à l’instant présent, ni les poids installés, ni le débit obtenu.
  • Pradosh Mohapatra est l’un des six auteurs du texte. Leur contribution normalise un signal volontairement étroit ; l’exploitation doit relier sa provenance aux décisions du récepteur et aux mesures du plan de données.

Imaginons trois routes multipath. Deux annoncent une valeur positive ; la troisième annonce zéro parce qu’une maintenance vient de commencer. Un équipement retire la troisième de la répartition. Un autre, configuré pour revenir à l’équilibrage égal, continue de lui confier un tiers des flux. Un rapport qui conserve seulement les trois nombres ne peut expliquer la divergence.

Ce cas n’est pas une anomalie aux marges du standard. La RFC 10005 reconnaît zéro comme une valeur valide et laisse au récepteur le choix de son interprétation. Elle transforme ainsi une ambiguïté historique en surface de configuration visible. Encore faut-il que l’opérateur conserve la configuration avec la route.

Publiée en juin 2026 sur la voie Standards Track de l’IETF, la RFC 10005 est signée par Pradosh Mohapatra, Reshma Das, Satya Mohanty, Serge Krier, Rafal Jan Szarecki et Akshay Gattani. Elle définit la BGP Link Bandwidth Extended Community. Son mérite n’est pas de promettre une mesure universelle de capacité, mais d’établir précisément ce que BGP peut transporter et ce qui reste hors de son champ.

Le format est précis, la signification reste locale

La communauté existe sous une forme transitive de type 0x00 et une forme non transitive de type 0x40, avec le sous-type 0x04. Elle contient un Global Administrator de deux octets puis un Local Administrator de quatre octets. Ce dernier encode une valeur IEEE 754 en simple précision, exprimée en octets par seconde.

Cette unité interdit un raccourci fréquent. Afficher des bits par seconde suppose une multiplication par huit. Le dossier de preuve doit conserver les octets bruts, la valeur décodée, l’unité d’origine et la conversion d’affichage. Sinon, un chiffre arrondi dans une interface devient impossible à rapprocher de l’annonce qui l’a produit.

Le Global Administrator ne constitue pas davantage une identité complète. Il devrait contenir l’ASN du routeur qui attache la communauté, mais peut prendre n’importe quelle valeur sur deux octets. Un ASN sur quatre octets y apparaît sous la forme AS_TRANS. Le champ ne modifie ni l’usage ni la sémantique de la communauté. L’identifier comme « propriétaire de la capacité » serait donc une conclusion que le format ne porte pas.

La lacune la plus importante est volontaire : les quatre octets ne disent pas comment la valeur a été obtenue. Il peut s’agir du débit nominal d’une interface, d’un agrégat distant, d’une valeur configurée, d’un résultat de mesure ou d’un poids abstrait. La RFC laisse explicitement le calcul ou la détermination hors de son périmètre.

Deux annonces peuvent ainsi utiliser la même unité et désigner des objets différents. Sans une définition contrôlée, une date d’observation, une période de validité, une méthode et un responsable, leur addition n’a pas de sens opérationnel même si elle est arithmétiquement possible.

Le prochain saut est une frontière de responsabilité

Lorsqu’un locuteur BGP réannonce une route en changeant le prochain saut, la RFC 10005 lui permet de supprimer la communauté, de la conserver telle quelle ou de la régénérer. L’implémentation devrait rendre son choix par défaut visible et autoriser une dérogation par session. Si le prochain saut ne change pas, elle ne devrait pas modifier la communauté.

Supprimer, conserver et régénérer ne sont pas trois variantes décoratives. La suppression refuse de prolonger l’affirmation. La conservation transporte l’affirmation d’amont sans y ajouter de mesure locale. La régénération produit une nouvelle décision à partir d’entrées locales, même si la valeur finale ressemble à l’ancienne.

Or le champ final ne garde aucune trace de cette histoire. Il ne contient ni la valeur reçue, ni la fonction de limitation, ni le motif de la transformation. Il faut donc créer un reçu de frontière : voisin et prochain saut avant et après, action choisie, politique et version, entrées, résultat, heure et acteur responsable.

Le brouillon draft-ietf-bess-ebgp-dmz-10, daté d’avril 2026 et encore en cours de travail, illustre ce besoin. Une valeur distante de 70 Gbit/s peut parvenir à un routeur qui n’atteint le prochain saut que par un lien local de 50 Gbit/s. Une fonction locale peut limiter la contribution à 50. Le brouillon distingue aussi bande passante distante, lien local, agrégation et poids dérivé d’un nombre de serveurs. Ces exemples expliquent des politiques possibles ; ils ne deviennent pas des garanties normatives de la RFC.

Additionner exige de connaître les termes

Lorsque tous les chemins contributeurs portent une valeur non nulle, les valeurs ou leurs rapports peuvent servir de poids. Le détail de la répartition pondérée reste hors champ. La RFC précise en outre que la valeur ne devrait pas intervenir dans la sélection du meilleur chemin BGP.

Si plusieurs communautés Link Bandwidth accompagnent une même route, le comportement par défaut consiste à choisir la plus faible, zéro compris, quand la route sert à la répartition pondérée. Une configuration peut modifier cette préférence. Si un chemin multipath n’a aucune communauté valide, le défaut est l’équilibrage égal, là encore sauf configuration contraire. Une valeur négative ne devrait pas être émise et doit être ignorée à la réception.

Ces règles montrent pourquoi « manquant », « zéro », « négatif ignoré » et « périmé » ne peuvent occuper la même case. Un zéro peut être une consigne de maintenance. Une absence peut signaler un voisin non compatible. Une valeur invalide peut venir d’un émetteur défectueux. Une valeur périmée peut résulter d’un mécanisme de réduction du churn. Les remèdes ne sont pas interchangeables.

La transition entre formes transitive et non transitive ajoute un risque. Une ancienne implémentation peut ne comprendre qu’une forme ; une copie est actualisée tandis que l’autre reste ancienne. Plus loin, un routeur voit deux valeurs reconnaissables et calcule pourtant des poids inadaptés. L’alerte doit comparer type, valeur brute et âge, pas seulement choisir silencieusement un nombre à afficher.

Le calcul du récepteur n’est pas la FIB

Supposons que le récepteur transforme 40 et 80 en rapport un pour deux. Ce rapport est une intention logicielle. La plate-forme peut devoir l’approximer dans un nombre limité de compartiments ECMP, respecter des contraintes de hachage résilient ou conserver les flux existants sur leur chemin. L’accusé de programmation matérielle constitue un reçu distinct.

Le trafic observé en constitue un autre. Des flux très inégaux et des collisions de hachage peuvent produire une distribution éloignée de la proportion théorique. Les compteurs peuvent suivre le rapport tandis que perte, latence et files d’attente montrent que les deux chemins manquent de marge. Une répartition réussie n’est pas, à elle seule, une preuve de capacité disponible.

Il faut donc suivre au moins quatre états : valeurs acceptées, poids calculés par la politique du récepteur, poids réellement installés dans la FIB et trafic mesuré par chemin. Aucun écran vert situé en amont ne doit parler au nom de l’étape suivante.

Cette séparation respecte la primauté du code en fonctionnement. Un document de configuration dit ce qui devrait arriver. Un état de contrôle montre ce que le logiciel a retenu. Une lecture matérielle montre ce qui a été programmé. Les octets, paquets, pertes, délais et files montrent enfin ce qui s’est passé.

La fraîcheur a plusieurs horloges

Des changements trop rapides de valeur peuvent perturber la stabilité du protocole et les opérations. La RFC recommande des mécanismes pour limiter ce churn. Seuils, temporisations et cadencement peuvent protéger BGP, mais ils créent un décalage entre la source et l’annonce.

La source peut mesurer à 14 h 00, la politique retenir la mise à jour jusqu’à 14 h 04, BGP la transmettre à 14 h 05 et la FIB l’appliquer à 14 h 06. Enregistrer seulement l’heure de réception transforme une preuve vieille de six minutes en information apparemment fraîche. Les changements supprimés par le filtre doivent rester dans le journal de provenance.

La confidentialité forme une autre limite. Une valeur de bande passante peut révéler une capacité sensible. La RFC recommande le filtrage lorsque les routes quittent un domaine administratif ou vont vers un réseau non fiable. L’organisation doit nommer la frontière qui retire ou transforme le signal, les exceptions autorisées et la preuve que la politique a été exécutée.

Le nom de Pradosh Mohapatra situe une contribution collective

La RFC 10005 rattache Pradosh Mohapatra à Google LLC et le cite avec cinq coauteurs. Lors de la capture du 1er septembre 2026, la fiche officielle du Datatracker associée au document recensait onze RFC mais utilisait l’ancienne graphie « Prodosh Mohapatra ». La RFC et la page publique d’auteur d’ipSpace emploient « Pradosh Mohapatra » ; cette graphie sert ici d’identité canonique.

La biographie d’ipSpace donne un contexte daté sur des fonctions antérieures dans les logiciels de routage chez Cumulus Networks et Cisco. Elle ne prouve pas une fonction actuelle au-delà de l’affiliation inscrite dans la RFC, ni la maîtrise du consensus de l’IETF, ni la responsabilité d’une politique déployée.

Le portrait d’une personne ne doit pas convertir un travail à six en récit de héros. L’intérêt analytique de Mohapatra tient à une frontière qu’il a contribué à normaliser : le protocole peut transporter un nombre avec exactitude tout en refusant d’inventer sa provenance et son effet.

Construire le reçu avant de croire la capacité

Pour chaque route, conserver famille d’adresses, voisin, domaine administratif, type de transitivité, octets exacts, Global Administrator, valeur décodée et conversion d’affichage. Relier ensuite la définition sémantique, la méthode, l’heure d’observation, la durée de validité et le responsable.

À chaque changement de prochain saut, inscrire supprimer, conserver ou régénérer, avec l’entrée, la sortie et la version de politique. Pour un agrégat, préserver les chemins constitutifs, le traitement de zéro, de l’absence et de l’invalide, ainsi que la formule. Pour l’exécution, ajouter poids calculés, FIB, accusé matériel et mesures par chemin.

Ce dossier doit se terminer par les conséquences : octets, perte, latence, files, congestion, alarme, décision, retour arrière et nettoyage d’une valeur périmée. La communauté reste alors ce qu’elle fait bien : un signal compact pour le routage. La capacité disponible devient une affirmation séparée, soutenue par les faits que quatre octets ne pouvaient pas contenir.

Sources