Résumé

  • La RFC 9104 attribue le type 1173 au TLV d’attribut de lien qui transporte l’Extended Administrative Group. Une longueur valide et un masque intact attestent le transport, pas l’interprétation locale ni le choix d’un chemin.
  • La preuve exploitable doit séparer l’état IGP source, la projection BGP-LS, la cohérence AG/EAG, le dictionnaire du consommateur, la version de politique, le calcul, l’installation et l’observation des paquets.

Un champ valide, une machine encore indécise

Prenons un cas hypothétique. Un consommateur reçoit un Link NLRI accompagné d’un attribut contenant le TLV 1173. Sa valeur occupe huit octets, donc deux mots de 32 bits. La session fonctionne, l’encodage est accepté et aucun traitement « malformed » n’est déclenché.

Dire alors « le contrôleur connaît les couleurs du lien » raccourcit abusivement la chaîne. Le producteur a transporté un masque. Le consommateur a accepté une structure. Un catalogue local peut attribuer un sens aux bits. Une politique peut exploiter ce sens. Un moteur peut calculer des chemins, un système southbound peut en installer un et les paquets peuvent finalement l’emprunter. Chacun de ces verbes demande sa propre preuve.

Publiée en août 2021 sur la voie Standards Track, la RFC 9104 définit la représentation BGP Link-State de l’Extended Administrative Group, ou EAG, attaché à un lien. Le TLV 1173 contient un ou plusieurs masques de 32 bits. Son champ Length compte les octets de la valeur et doit être divisible par quatre.

Ce format est suffisant pour transporter les bits. Il n’embarque ni vocabulaire métier, ni priorité de politique, ni résultat de calcul, ni accusé d’installation.

Étendre le masque ne rend pas sa signification universelle

L’Administrative Group historique est limité à 32 bits. Les opérateurs parlent couramment de « couleurs », mais le terme désigne seulement des bits. Une même position peut signifier faible latence dans un réseau, maintenance dans un autre, ou ne rien signifier du tout.

La RFC 7308 a créé l’EAG pour dépasser cette limite. Il reste composé de mots de 32 bits et sa taille praticable dépend du protocole qui le transporte. La RFC 9104 lui offre ensuite une projection normalisée dans BGP-LS.

Le nouveau champ ne remplace pas l’ancien. Les TLV 1088 (Administrative Group) et 1173 (EAG) peuvent coexister. Lorsque les deux décrivent le même lien, la RFC 7308 exige que les 32 premiers bits de l’EAG soient identiques à l’AG. Le récepteur emploie l’AG pour les bits 0 à 31 et l’EAG à partir du bit 32 ; une divergence devrait être signalée à l’opérateur.

Cette règle vérifie une cohérence de représentation. Elle ne vérifie pas le dictionnaire qui transforme les positions en intentions opérationnelles.

La syntaxe s’arrête là où commence la responsabilité du consommateur

La RFC 9104 fixe une conséquence nette pour la syntaxe : si la longueur du TLV 1173 n’est pas un multiple de quatre, le TLV est malformé et l’attribut BGP-LS concerné est rejeté selon les règles applicables. Un parseur peut donc conclure sur la forme.

Le contrôle sémantique et le contrôle de contenu appartiennent au consommateur. C’est aussi lui qui vérifie l’association avec le bon type de NLRI ou d’attribut et décide du traitement applicatif. Le comportement du consommateur est explicitement hors du périmètre de la RFC 9104.

Le succès du parseur ne prouve donc pas que le bit 42 conserve la signification attendue, qu’une politique active le consulte, ni que les bits inconnus sont traités de manière prudente. Il prouve que les bits sont arrivés dans une enveloppe acceptable.

La RFC 9552, qui a remplacé en 2023 la spécification de base RFC 7752, décrit aujourd’hui BGP-LS comme un mécanisme qui extrait des informations de topologie et d’ingénierie du trafic d’une LSDB ou d’une TED pour les distribuer à des consommateurs externes. Ce texte éclaire l’architecture actuelle ; il ne constitue pas une preuve rétroactive du comportement d’un contrôleur donné en 2021.

Le dictionnaire des couleurs ne figure pas dans le TLV

La structure permet une inférence simple et importante. Le TLV 1173 transporte une longueur et des masques. Il ne transporte pas l’étiquette locale d’un bit, la version du dictionnaire, l’ordre de priorité des règles, l’identité d’un approbateur, les chemins candidats, le chemin retenu ou l’état FIB.

Un producteur peut ainsi diffuser le bon EAG à un consommateur muni d’un ancien dictionnaire. Deux consommateurs peuvent recevoir exactement la même valeur et choisir différemment à cause de règles distinctes sur les bits inconnus. Une migration peut activer un nouveau bit avant que tous les moteurs aient reçu le catalogue correspondant.

La RFC 7308 traite généralement comme nuls les bits qui ne sont pas annoncés, tout en laissant la place à une stratégie locale. Il faut donc consigner cette stratégie. On ne peut pas la déduire du seul paquet BGP-LS.

Sept reçus au lieu d’un voyant vert

Le reçu source identifie l’instance IGP, le protocole, le lien, le LSA ou LSP d’origine, l’EAG et l’instant d’observation. Le reçu de projection conserve le producteur BGP-LS, les descripteurs du Link NLRI, le Protocol-ID, la session, la longueur et la valeur du TLV 1173, ainsi que la comparaison avec le TLV 1088 le cas échéant.

Le reçu consommateur enregistre le résultat du parsing, la validation sémantique, l’association au lien, la version du dictionnaire et la règle sur les bits inconnus. Le reçu de politique nomme les bits inclus ou exclus, les priorités, les conflits, l’approbation et l’autorité de retour arrière.

Le reçu de calcul relie une époque de topologie et une version de politique aux candidats, exclusions et chemin retenu. Le reçu d’exécution décrit la transaction southbound et l’état RIB, FIB ou labels obtenu. Enfin, le reçu de service observe le chemin des paquets et le résultat pertinent.

« Reçu » ne veut pas dire « compris » ; « compris » ne veut pas dire « utilisé » ; « calculé » ne veut pas dire « installé » ; « installé » ne veut pas dire « livré ». Cette discipline rend les pannes localisables au lieu de transformer un indicateur de session en certificat universel.

Ni authentification, ni fraîcheur, ni résultat garanti

La RFC 9104 ne modifie pas le modèle de sécurité de BGP. Elle suppose que les instances IGP à l’origine des attributs appliquent les protections OSPF ou IS-IS nécessaires. La présence du TLV 1173 n’authentifie donc pas à elle seule la source, n’autorise pas le consommateur et ne garantit pas une route sûre.

Elle ne garantit pas non plus la fraîcheur au moment du calcul. Une valeur exacte à l’export peut être combinée plus tard avec une autre époque de topologie. Une bonne politique appliquée à des entrées périmées peut donner un résultat inattendu.

Il faut également préserver la frontière avec les normes voisines. La RFC 9917 concerne des contraintes Administrative Group inverses dans Flex-Algorithm ; la RFC 9825 concerne des listes ordonnées d’étiquettes administratives OSPF et leur éventuelle troncature. L’EAG de la RFC 9104 est un masque projeté dans BGP-LS, avec une chaîne de preuve différente.

Une affirmation étroite reste une affirmation utile

Un code point stable, un encodage reproductible et une règle claire pour les attributs malformés apportent une vraie valeur d’interopérabilité. La prudence consiste seulement à ne pas étendre cette valeur au-delà de ce que le champ prouve.

Les textes de Lu Heng sur la primauté du code en fonctionnement et sur la spécification initiale minimale offrent ici un éclairage éditorial déclaré : un artefact de coordination n’est pas encore un résultat implémenté, validé et utilisé ; une couche commune minimale peut préserver l’interopérabilité tout en laissant les décisions futures au niveau local. Ils ne prouvent ni l’intention des auteurs de la RFC ni une réalité de déploiement.

La formulation opérationnelle peut donc rester exacte : « l’EAG de ce lien est arrivé intact dans un TLV 1173 valide ». Toute phrase sur la politique choisie ou le trafic obtenu doit commencer après ce point, avec de nouvelles preuves.

Sources