Résumé

  • Le plan RIPEstat du troisième trimestre 2026 annonce l’ajout prochain de descriptions des communautés BGP. L’API du Looking Glass fournit déjà un objet community_info et RIPEstat désigne le projet NLNOG Looking Glass comme source d’une partie de ces explications.
  • La capture unique de 193.0.20.0/23 contient 349 entrées de pairs réparties entre 23 groupes de collecteurs ; 71 entrées possèdent des informations de communauté non vides. C’est le portrait d’une requête, pas un taux global de couverture.
  • Pour une entrée, la valeur présente dans les données est 12859:4000, la description est « customer routes » et l’expression original vaut 12859:4xxx. Une règle avec joker a donc produit l’annotation.
  • Un reçu de description devrait conserver le type de communauté, la valeur observée, l’expression correspondante, la classe de correspondance, la source et sa version, les deux horloges — description et route — ainsi que la différence entre information et demande d’action.

Le numéro vient de la route, la phrase d’une autre chaîne

Le plan trimestriel de RIPEstat présente les descriptions de communautés BGP comme une prochaine amélioration du Looking Glass. L’utilité est immédiate : une suite comme 12859:4000 ne renseigne guère le lecteur qui ignore la convention publiée par le réseau concerné.

Il faut cependant regarder la jointure. La documentation de l’API Looking Glass explique que les routes proviennent des collecteurs RIPE RIS et que community_info apporte des informations supplémentaires sur les communautés ordinaires et larges. La page des sources RIPEstat indique que le projet NLNOG Looking Glass fournit certaines informations sur les communautés connues.

La valeur et son commentaire n’ont donc pas la même provenance. RIS observe un attribut dans une route reçue par un pair. La couche descriptive cherche une règle et associe un texte lisible à cet attribut. Les deux éléments se côtoient à l’écran, mais la proximité visuelle ne les transforme pas en une seule mesure.

Lors du lancement du nouveau Looking Glass en mai 2025, RIPE NCC le qualifiait de nouvelle version fondée sur RIS, capable d’analyser les communautés ordinaires, larges et étendues, accessible aussi par API, et encore ouverte aux améliorations. C’est précisément pendant cette phase que la jointure mérite d’être rendue durable.

Une capture suffit pour voir le mécanisme, pas pour mesurer le service

Le dossier de preuve conserve une réponse du Looking Glass pour 193.0.20.0/23. Le serveur a renvoyé ok, la version 2.1, un latest_time égal à 2026-09-14T20:20:43, 23 groupes RRC et 349 entrées de pairs. Parmi elles, 71 ont un objet community_info non vide.

Ces nombres n’autorisent aucune extrapolation sur la totalité de RIPEstat. Une seule ressource, un seul instant et une seule réponse ne disent ni quelle proportion des communautés mondiales est expliquée, ni combien de définitions sont actuelles, ni combien viennent directement d’un opérateur. La capture sert à inspecter la forme de la preuve.

Dans une entrée, la chaîne observée comprend 12859:4000. Sous community_info.regular, la même valeur devient la clé, la description est « customer routes », et le champ original porte 12859:4xxx. À côté, d’autres annotations conservent une égalité exacte, par exemple 2914:410 accompagné de « NTT and customer routes » et d’un original identique.

L’API préserve ainsi déjà un détail décisif. Une description peut provenir d’une définition exacte ou d’une famille. Écrire « 12859:4000 signifie customer routes » efface cette nuance. Écrire « 12859:4000 a correspondu à la règle 12859:4xxx, décrite comme customer routes » expose l’inférence et permet de la discuter.

Un joker n’est pas un défaut par nature. Un opérateur peut réserver une plage entière à une catégorie stable. Mais la résolution de la règle fait partie de la qualité du résultat. Une définition exacte, une plage et un motif ouvert n’emportent pas le même niveau de précision.

La syntaxe de correspondance est un élément documentaire

Le dépôt du NLNOG Looking Glass décrit deux circuits. Le premier récupère des fichiers structurés selon un modèle YANG depuis des URL déclarées. Le second, plus ancien, utilise un fichier texte par ASN : une expression de communauté, une virgule et une description par ligne valide.

Ce format accepte les valeurs exactes, les intervalles, les jokers portant sur un chiffre et des motifs remplaçant une suite numérique. Il peut réinjecter les valeurs capturées dans le commentaire. Le mécanisme évite de recopier des milliers d’entrées, ce qui est efficace, mais il fabrique bien une annotation à partir d’une règle.

Le dépôt invite la communauté à proposer des ajouts et des corrections. Il demande, « si possible », d’indiquer la source dans un commentaire en première ligne. Cette formule ne promet pas que chaque entrée historique possède une citation contrôlée par l’opérateur, une date de validité et un identifiant de version.

Le fichier figé community_urls.yml contenait deux sources structurées, pour AS25152 et AS197000. Il ne se présentait pas comme la liste exhaustive de toutes les descriptions visibles dans la réponse RIPEstat. L’absence de 12859 dans ce petit fichier ne prouve pas que la règle est fausse ; elle montre seulement que cette voie structurée ne documente pas, à elle seule, la lignée de l’annotation examinée.

La route et le commentaire n’ont pas la même heure

Le champ latest_time situe les données de routage. Il ne date pas le texte « customer routes ». Cette description peut avoir été récupérée avant la route, copiée d’une page d’opérateur, ajoutée par une contribution ou importée depuis un flux formel. Elle peut ensuite être corrigée sans que la route change ; la route peut changer sans que le fichier descriptif soit relu.

RFC 1997 définit les communautés ordinaires comme un attribut BGP optionnel et transitif. Hors valeurs réservées, un système autonome peut définir le sens de la partie qu’il administre. RFC 8092 structure les grandes communautés en un administrateur global et deux champs locaux, utilisés pour des propriétés ou des actions de politique.

La structure numérique aide à retrouver le domaine d’administration. Elle ne signe pas la phrase affichée et ne garantit pas que tous les réseaux appliquent le même traitement. Une communauté peut être ajoutée, retirée, modifiée, ignorée ou utilisée selon des politiques locales. Ce que voit un collecteur RIS ne reconstitue pas toutes les décisions prises avant et après lui.

« Informe » et « demande » ne sont pas des verbes interchangeables

RFC 8195 sépare les communautés informationnelles des communautés d’action. Les premières décrivent, par exemple, un lieu ou la manière dont une route a été apprise. Les secondes demandent à un réseau d’effectuer une opération. Le document encourage les opérateurs à publier et maintenir leur documentation.

Une demande d’action peut aussi informer : sa présence prouve qu’un tag a été observé. Elle ne prouve pas que l’action a été acceptée, que la politique correspondante s’est déclenchée, que le résultat s’est propagé ou qu’il persiste. Une interface devrait donc dire « demande » plutôt que « provoque », puis réserver un champ différent à l’effet effectivement observé.

Dans l’exemple présent, « customer routes » est une classification, pas une instruction. Même là, les mots n’établissent pas l’existence d’un contrat, une propriété, une relation commerciale actuelle ou le statut juridique de chaque préfixe portant la valeur. Ils rendent compte de la catégorie documentée par la source.

Le reçu minimal

La ligne principale peut rester légère : valeur observée, description claire. Un panneau de provenance devrait permettre d’inspecter :

  • le type ordinaire, large ou étendu ;
  • la valeur réellement observée ;
  • l’expression qui a correspondu et son type — exacte, intervalle ou motif ;
  • la source de la description, sa classe d’autorité et son URL ;
  • une révision, un commit ou une empreinte de contenu ;
  • le moment de récupération et, s’il existe, le moment de validité déclaré ;
  • le caractère informationnel ou opérationnel du sens ;
  • le temps d’observation de la route, le collecteur et le pair ;
  • les conflits, corrections et remplacements.

Ce reçu ne certifie pas que le texte est vrai. Il rend l’interprétation reproductible. Un lecteur peut accepter une contribution communautaire pour l’exploration, demander une source d’opérateur pour un rapport d’incident, ou exclure une annotation non versionnée d’une automatisation.

Les absences doivent aussi avoir un statut. « Aucune description trouvée », « source indisponible », « règles en conflit », « définition expirée » et « type non pris en charge » ne sont pas le même vide.

Ce que permet de conclure l’exemple

La capture prouve que RIPEstat peut exposer ensemble une valeur de communauté observée, une description humaine et l’expression plus large qui a fourni cette description. C’est déjà une transparence utile.

Elle ne prouve pas que le texte est erroné, qu’une route est dangereuse, qu’une relation client existe ou qu’une action BGP a réussi. Elle ne mesure pas la qualité globale du catalogue NLNOG et n’établit aucun manquement de RIPE NCC, de NLNOG ou d’un réseau présent dans le chemin.

Le prochain progrès n’est donc pas un avertissement spectaculaire. C’est un reçu attaché à une explication utile. RIPEstat veut rendre les communautés plus lisibles ; conserver le joker et sa source les rendra aussi plus vérifiables.

Sources