Résumé

  • RFC 10005 encode la bande passante dans un flottant IEEE 754 de 32 bits, en octets par seconde, sous deux formes : transitive (0x00) et non transitive (0x40), toutes deux de sous-type 0x04.
  • La transitivité règle une possibilité de propagation, pas une autorisation commerciale ni une preuve de mesure. L’opérateur doit fixer le périmètre, conserver la provenance du chiffre et vérifier l’effet réel sur le multipath et la FIB.

Le chiffre était utile à l’intérieur du réseau. Il représentait une capacité agrégée derrière deux sorties et permettait de répartir les flux avec un ratio plus réaliste qu’un ECMP égal. Puis une politique d’export l’a laissé franchir une frontière administrative. Le voisin suivant n’a pas reçu la méthode de calcul, la fraîcheur, les exclusions ou la clause de confidentialité. Il a reçu un nombre dans une communauté transitive.

Ce glissement paraît minuscule dans une configuration BGP. Il change pourtant la nature de l’acte. À l’intérieur, la valeur était une entrée de politique connue. À l’extérieur, elle devient une information de capacité qui peut révéler la structure d’un réseau ou orienter le trafic d’un tiers. La syntaxe est restée valide ; l’autorité de divulguer n’a pas voyagé dans le paquet.

RFC 10005, publié en juin 2026 comme Proposed Standard, reconnaît explicitement cette sensibilité. Il recommande de filtrer la communauté lorsqu’une route est propagée vers un réseau non fiable ou hors du domaine administratif. Cette phrase doit être lue comme une limite opérationnelle, non comme une note de bas de page.

Deux types, un même chiffre, des portées différentes

La forme transitive utilise le Type 0x00 ; la forme non transitive, 0x40. Le sous-type 0x04 identifie Link Bandwidth dans les deux registres IANA. Un récepteur conforme doit savoir traiter les deux. Il ne doit ni faire flap la route ni la déclarer malformée à cause de la combinaison entre type de communauté et session iBGP ou eBGP.

Pendant une migration, un émetteur peut attacher les deux formes à la même route. Leurs valeurs devraient être identiques. Cette coexistence aide les réseaux contenant des logiciels anciens qui ne comprennent qu’une forme, mais elle crée aussi un risque : un routeur modifie une communauté et oublie l’autre. Deux récepteurs en aval peuvent alors calculer des poids différents à partir d’une route apparemment commune.

La correction n’est pas « mettre à jour seulement le route reflector ». L’annexe du RFC exclut précisément cet objectif. Les locuteurs qui émettent ou reçoivent doivent implémenter les procédures pertinentes ; à défaut, l’opérateur filtre la forme non comprise au bon endroit. La matrice de versions est donc un élément du périmètre de confiance.

L’identifiant global n’authentifie personne

Le champ Global Administrator contient deux octets. Il devrait prendre l’ASN du routeur qui attache la communauté, mais peut contenir n’importe quelle valeur sur deux octets. Pour un ASN trop grand, le RFC recommande AS_TRANS; l’ASN complet sur quatre octets ne tient pas dans cet encodage. Surtout, le texte précise que ce champ ne change ni l’usage ni la sémantique de la communauté.

Un journal ne doit donc pas traduire ce nombre par « capacité certifiée par cet AS ». Le champ ne signe pas la mesure, n’identifie pas juridiquement son auteur et ne prouve pas que le chiffre vient d’une interface. L’attribution exige la session, la politique, la configuration et l’état effectif du locuteur.

Le champ Local Administrator porte un flottant 32 bits exprimé en octets, non en bits, par seconde. Cette précision permet le décodage commun. Elle ne définit pas l’objet mesuré. Le RFC laisse le calcul hors périmètre. Le projet de cas d’usage en cours emploie tour à tour une liaison directement connectée, une somme de chemins, une capacité de serveurs et de simples poids proportionnels.

Ainsi, deux opérateurs peuvent encoder le même nombre et parler de choses différentes. La frontière de confiance doit transporter une convention hors bande : source, unité économique ou technique, horizon temporel, méthode d’agrégation et destinataires autorisés.

La réécriture déplace l’autorité

RFC 10005 permet d’attacher ou d’actualiser la communauté dans Adj-RIB-In et dans Adj-RIB-Out. Lorsqu’un locuteur change le next hop, son comportement par défaut peut être de supprimer la valeur, de la conserver ou de la régénérer. L’implémentation devrait exposer ce défaut et offrir un réglage par session. Si le next hop reste inchangé, notamment lors d’une réflexion de route, la communauté ne devrait pas être modifiée.

Chaque choix emporte une responsabilité. Conserver une valeur après changement de next hop affirme que l’ancienne description reste pertinente pour un chemin transformé. La régénérer affirme qu’un nouveau calcul représente mieux ce chemin. La supprimer refuse de transmettre un sens devenu incertain. Aucun de ces choix n’est universellement correct ; chacun doit être justifié par le modèle local.

Les documentations de Juniper, Cisco et Arista montrent des contrôles concrets : valeur explicite, détection de vitesse, transitivité, agrégation ou régénération par voisin. Elles prouvent que ces décisions existent dans du code déployable. Elles ne prouvent pas le défaut d’une version donnée ni l’état d’un réseau réel.

Le destinataire garde le dernier mot

Même correctement reçue, la valeur ne commande pas directement la livraison. Quand tous les chemins contribuant au multipath portent des valeurs non nulles, leur nombre ou leur ratio peut servir de poids. En présence de zéros mélangés, de zéros partout ou d’une valeur absente, la politique locale décide ou revient par défaut à un partage égal selon le cas. La bande passante ne devrait pas participer à la sélection du best path BGP.

La valeur zéro est valide. L’émetteur peut vouloir drainer un chemin pendant une maintenance ; le récepteur peut l’exclure, choisir un partage égal ou appliquer une autre politique configurée. Plusieurs communautés entraînent par défaut le choix de la valeur la plus basse, zéro compris, sans considération de transitivité. Une valeur négative est ignorée.

Autrement dit, la portée de la communauté et son effet sont deux décisions séparées. Un réseau peut bien filtrer la divulgation et mal programmer les poids ; il peut aussi calculer correctement ses poids tout en laissant fuiter une cartographie de capacité.

Un registre de divulgation et d’effet

Pour chaque préfixe concerné, conserver la route avant et après politique, le voisin, le next hop, le type, le Global Administrator, les octets bruts et la valeur décodée. Ajouter l’origine sémantique : vitesse configurée, vitesse découverte, agrégat distant, nombre de serveurs ou ratio volontaire. Identifier la frontière administrative et la règle qui autorise ou bloque l’export.

Du côté récepteur, enregistrer l’ensemble multipath, le traitement des valeurs nulles, absentes ou multiples, la fonction local/distant, puis les membres et poids effectivement inscrits dans la FIB. Les compteurs de flux, files, pertes, latence et résultat applicatif ferment la chaîne.

La primauté du code en fonctionnement de Heng Lu interdit de confondre publication, intention et résultat. Sa doctrine de spécification initiale minimale place dans le socle commun l’encodage et l’interopérabilité ; le périmètre de confiance, l’objectif de trafic et l’acceptation du risque restent chez l’opérateur.

Une valeur peut franchir une session. L’autorisation de la croire, de la divulguer ou d’en faire un poids ne franchit rien sans une décision traçable.