Résumé

  • La révision 03 du projet GROW sur la terminologie des opérations de routage se présente explicitement comme un instantané descriptif et non comme une autorité de vocabulaire ; un terme peut apparaître dans plusieurs contextes avec des sens différents.
  • Network edge, Provider Edge, peer, cone, blackholing ou converged ne sont pas des types interchangeables. Une chaîne d’automatisation doit lier le mot à un sens, une version, des sujets, un point d’observation et une preuve avant d’agir.

Le fichier d’inventaire contenait une colonne edge. L’équipe d’interconnexion y avait rangé les derniers routeurs qu’elle contrôlait avant le passage vers d’autres réseaux. Le moteur de configuration, conçu par une autre équipe, interpréta la même valeur comme « Provider Edge » et poussa un modèle MPLS. Aucun parseur ne se trompa. La faute venait d’un mot qui avait traversé deux contextes sans son type.

La révision 03 de Currently Used Terminology in Global Routing Operations, déposée le 2 octobre 2026 par Tobias Fiebig et Wolfgang Tremmel, rend ce risque visible. Dans la partie consacrée aux relations entre voisins, Network edge désigne les derniers routeurs sous le contrôle d’un opérateur connectés à ceux d’autres réseaux. Dans la partie routage, le terme désigne plus brièvement les derniers routeurs sous ce contrôle. Provider Edge, lui, implique généralement un rôle au bord d’un réseau fournisseur utilisant MPLS et des connexions vers des routeurs P, PE ou CE.

Le document prend soin de ne pas prétendre imposer une définition universelle. Son résumé dit qu’il n’est pas une source faisant autorité sur la terminologie correcte. Sa section de portée le qualifie de descriptif : il collecte des usages observés à un moment donné et reconnaît qu’ils peuvent changer. Un même terme peut donc apparaître dans plusieurs sous-sections avec des descriptions différentes.

Datatracker le classe comme Internet-Draft actif du groupe GROW, dans le flux IETF. Il n’a ni Area Director responsable, ni shepherd, ni numéro RFC, ni date de téléconférence, ni issue achevée du processus de normalisation. Le statut visé est Informational et l’expiration est fixée au 5 avril 2027. Aucune action IANA n’est demandée. La section de sécurité explique que le document décrit des mots, ne formule pas de recommandation et n’a donc pas de considération de sécurité.

Cette phrase borne le projet lui-même. Elle ne garantit pas l’innocuité d’un logiciel qui transforme ses mots en sélecteurs de configuration. Un glossaire descriptif ne commande aucun routeur ; un consommateur qui réduit un contexte à une chaîne de caractères peut, lui, déplacer ce mot dans une couche d’autorité que le texte n’a jamais revendiquée.

Le bord n’est pas un endroit unique

Le mot edge paraît spatial. Il suggère une frontière nette entre l’intérieur et l’extérieur. Dans un réseau réel, plusieurs frontières se superposent : limite administrative, dernière interface contrôlée, bord d’un service, rôle MPLS, point d’interconnexion, limite de collecte télémétrique ou frontière de responsabilité contractuelle.

Un routeur peut être au bord administratif sans être un PE MPLS. Un PE peut fournir des VPN sans être le dernier équipement avant un autre AS pour tous les services. Un équipement peut changer de rôle selon la VRF, la famille d’adresses ou le service. Une étiquette d’actif unique ne capture pas ces dimensions.

Le bon modèle ne remplace pas edge par un mot plus long ; il sépare les prédicats. administrative-boundary-router, external-bgp-border, mpls-provider-edge, service-ingress et telemetry-vantage peuvent partager une présentation humaine, mais déclenchent des politiques différentes. Chaque assertion doit nommer l’opérateur, le service, les interfaces, la période et la preuve.

La direction compte également. « Dernier routeur sous contrôle » n’indique pas qui contrôle le voisin ni quelle relation lie les AS. Il ne dit pas si l'équipement est autorisé à recevoir un modèle de service particulier. L’inventaire doit conserver la différence entre localisation topologique, rôle fonctionnel et pouvoir d’administration.

La révision améliore la carte, pas son autorité

Le passage de la révision 02 à 03 apporte de vraies améliorations. La liste des acronymes s’enrichit. Des définitions et références sont ajoutées ou précisées. BFD n’est plus résumé comme un moyen de savoir si un voisin est « vivant », mais comme un protocole détectant sa joignabilité et signalant sa perte à des protocoles tels que BGP. Ce déplacement d’alive vers reachable évite déjà une conclusion excessive.

Les catégories d’attributs BGP sont reformulées autour de leur présence et de leur propagation. Un attribut optionnel transitif non compris doit être propagé selon sa définition ; un attribut optionnel non transitif non compris est éliminé. Les entrées BGP, EGP, IGP, EIGRP, IS-IS, OSPF ou RIR gagnent en précision.

Ces corrections rendent l’instantané plus utile. Elles ne créent ni profil de conformité ni registre normatif. Un outil qui importe la révision 03 doit conserver son origine et son numéro, car une décision ancienne a pu employer la révision 02 ou un usage local encore différent. Réécrire rétroactivement tous les tickets avec la dernière définition fabrique une cohérence qui n’existait pas au moment de l’action.

Une migration sémantique devrait donc produire une correspondance versionnée et réversible. Elle peut dire qu’un ancien champ edge est probablement compatible avec un nouveau sens, citer les indices, préserver l’incertitude et demander validation. Elle ne devrait pas remplir silencieusement un type précis pour satisfaire un schéma moderne.

Le cas de peer confirme le problème

Dans la partie consacrée aux relations, un peer est constitué de deux AS directement connectés qui ne s’annoncent mutuellement que leurs routes propres et celles de leurs downstreams. Dans la partie routage, peer peut être un simple voisin BGP : deux locuteurs échangeant des NLRI.

La première proposition décrit une politique de relation. La seconde décrit un état ou un rôle protocolaire. Une session peut être établie sans que la relation soit du peering ; un fournisseur et son client sont aussi des voisins BGP. Inversement, une relation de peering peut subsister pendant une maintenance où la session tombe.

RFC 9234 rend les rôles BGP explicites dans OPEN pour prévenir des fuites. C’est une preuve plus ciblée qu’une inférence par le nom, mais elle reste liée à une configuration et à une négociation. Un contrat, une déclaration d’opérateur, un rôle annoncé, le filtre installé et les routes réellement exportées sont cinq reçus différents.

RFC 4271 décrit un processus de décision local. La sélection d’une route par un locuteur ne démontre pas la politique du voisin ni le chemin des paquets. Si l’inventaire déduit la relation de la seule existence d’une session, il donne à un fait de contrôle un poids institutionnel qu’il n’a pas.

Un type d’ensemble n’en remplace pas un autre

Le cone illustre une erreur encore plus mécanique. Le projet le décrit comme l’ensemble des AS downstream directs ou récursifs et ajoute que, selon le contexte, il peut aussi inclure l’ensemble conjoint des préfixes qu’ils origent. Un ensemble d’ASN et un ensemble de préfixes n’acceptent pas les mêmes opérations.

Une requête « cette ressource appartient-elle au cone ? » n’a aucun sens sans savoir si la ressource est un AS, un préfixe ou une observation datée qui relie les deux. La composition d’un cone change avec les relations et les annonces. Une valeur calculée depuis un collecteur n’est pas nécessairement une vérité contractuelle.

Le schéma doit imposer le type des membres, la méthode de construction, le point d’observation, l’instant et le traitement des inconnus. Un moteur qui accepte indistinctement ASN et préfixes peut produire une liste syntaxiquement valide et une frontière totalement fausse.

Cette distinction touche directement les politiques de filtrage, de mesure et de responsabilité. Compter des AS, couvrir des préfixes et attribuer un trafic sont trois opérations. Le mot commun sert à expliquer leur parenté, pas à prouver leur équivalence.

Symptôme et action partagent parfois un nom

Blackholing a un sens général de paquets silencieusement abandonnés, sans notification ICMP. Dans la section sécurité, il désigne l’annonce de préfixes avec une communauté particulière afin que les voisins jettent le trafic vers la destination. Le premier peut être un symptôme observé ; le second est une action volontaire de mitigation.

Un système d’incident qui convertit automatiquement une alerte « blackhole » en annonce de blackholing prend le mot pour une autorisation. Il faut d’abord distinguer perte observée, cause supposée, demande de mitigation, principal autorisé, configuration appliquée et résultat. L’action défensive peut aggraver une panne si le diagnostic initial décrivait seulement un trou de visibilité.

Le terme depeering marque lui aussi une action limitée : retirer des sessions avec un AS voisin. Le reçu de suppression de session ne prouve pas que tout trafic vers ou via cet AS a cessé. Un autre point d’interconnexion, un transit, une route par défaut ou un état de forwarding encore installé peut continuer à transporter les paquets.

La clôture d’un incident doit donc reposer sur des observations du plan de données, pas seulement sur le succès d’une commande de configuration. Le système doit pouvoir dire « sessions supprimées, effet de trafic inconnu » plutôt que « relation et trafic terminés ».

« Complet » et « convergé » ont besoin de coordonnées

Le projet définit une Full Table comme une table contenant une route vers tous les préfixes de la Global Routing Table, sans route par défaut. Le mot « tous » dépend pourtant d’une famille d’adresses, d’un locuteur, d’une politique d’import, d’un instant et d’une conception de la GRT. Deux points de vue peuvent diverger sans corruption.

La complétude du plan de contrôle ne prouve pas davantage l’installation dans la FIB. Des limites de ressources, une récursion impossible, un filtre ou un délai de programmation peuvent empêcher une route sélectionnée de devenir un comportement de forwarding. « Table complète reçue » n’est pas un reçu de livraison.

Converging décrit le travail d’un locuteur BGP qui apprend, évalue et choisit les routes préférées. Un routeur peut finir alors que des mises à jour circulent encore ailleurs, que des entrées de forwarding changent ou que la connectivité applicative reste instable. Un état converged=true doit nommer son périmètre et son critère d’arrêt.

BFD fournit une autre preuve étroite. RFC 5880 permet une détection rapide de défaillance du chemin entre systèmes configurés. Un état Up ne prouve pas le service applicatif ; un état Down ne prouve pas la cause. Joignabilité, session BGP, sélection, forwarding et résultat utilisateur doivent rester séparés.

Une catégorie d’incident n’établit pas l’intention

Le projet décrit un route hijack comme l’annonce par un AS d’une route qu’il n’est pas autorisé à annoncer, et précise qu’il peut résulter d’une mauvaise configuration accidentelle ou d’une action malveillante. Le label technique ne tranche donc pas l’intention.

RFC 7908 définit les fuites par propagation au-delà de la portée prévue, en violation des politiques attendues. Pour connaître cette portée, l’enquêteur a besoin de preuves de relation et de configuration. L’AS_PATH observé montre un événement ; il ne reconstitue pas à lui seul la chaîne d’approbation.

RPKI apporte des déclarations plus ciblées. RFC 6480 décrit l’architecture de certification des ressources et RFC 9582 les ROA autorisant un AS à originer des préfixes dans un périmètre. Un origin valide ne prouve ni la conformité du chemin à la relation, ni la joignabilité, ni la livraison. L’étiquette valid ne doit pas devenir « route sûre ».

Dans l’autre sens, l’état d’un validateur est une entrée d’une politique locale, non un verdict universel auto-exécutable. Il faut conserver la vue du validateur, la session RTR, l’instant, la politique du routeur, la décision et l’effet. Le vocabulaire nomme ces éléments ; l’exploitation doit les relier.

Une enveloppe sémantique minimale

Avant qu’un terme descriptif ne pilote une action, le consommateur devrait exiger : le mot exact ; le vocabulaire et sa version ; un identifiant de sens stable ; le contexte ; les sujets et la direction ; le point d’observation et l’instant ; la source ou la preuve ; l’action demandée et son principal autorisé ; enfin l’incertitude ou les interprétations concurrentes.

Cette enveloppe n’est pas une ontologie universelle. Elle évite une erreur de type. L’interface peut continuer à montrer edge, peer ou cone. L’API doit refuser un modèle PE si elle ne possède qu’une assertion de frontière administrative, une politique de relation si elle ne possède qu’une session, ou une opération de préfixes si elle reçoit un ensemble d’ASN.

Les anciens champs nus doivent rester ambigus jusqu’à résolution. Une migration peut proposer un sens et documenter ses indices. Elle ne doit pas créer de certitude simplement parce qu’un nouveau schéma rend le champ obligatoire.

Il faut surveiller le nombre de mots sans sens typé, les conversions entre contextes, les actions déclenchées par une définition descriptive, les désaccords entre relation et session, les tables dites complètes sans coordonnées, les convergences locales sans preuve de forwarding et les labels d’incident transformés en jugements d’intention.

La valeur du projet tient à sa modestie

La révision 03 mérite d’être utilisée précisément parce qu’elle ne se présente pas comme arbitre absolu. Elle expose les habitudes, rappelle leurs contextes et améliore la langue commune. Elle aide les opérateurs à découvrir des hypothèses devenues invisibles.

Chaque système consommateur doit ensuite prendre sa responsabilité. L’inventaire définit des types. Le moteur de politique exige des prédicats. L’agent autonome reçoit une capacité bornée. La gestion d’incident sépare observation, cause et intention. Aucun ne doit déléguer sa décision au glossaire.

C’est l’application des couches de réalité de Heng Lu. Le mot est une donnée symbolique. Le rôle et la relation sont des objets institutionnels. La configuration et la session sont des états exécutables. Le forwarding et la livraison sont des réalités observées. Le passage entre les couches demande une jonction de preuves.

Minimum Initial Specification conduit à l’enveloppe typée étroite plutôt qu’à une taxonomie totale. Running-Code Primacy exige des essais d’incompatibilité : présenter un edge administratif à un modèle PE et vérifier le refus ; supprimer les sessions et observer le trafic ; déclarer un routeur convergé pendant que le réseau bouge encore.

Dans l’incident initial, le champ edge n’était pas faux. Il était sous-spécifié pour l’action qu’on lui demandait d’autoriser. Le bon correctif ne consiste pas à imposer un sens à tous. Il consiste à préserver le contexte jusqu’à ce que le système sache quelle proposition il détient, quelle preuve l’appuie et quelle action elle permet réellement.

Sources