Résumé

  • L’IETF a publié le 19 août à 09 h 22 min 08 s UTC la version 38 de son projet sur la remontée de topologie inter-AS par BGP-LS. La seule modification de fond par rapport à la version 37 supprime le TLV 263, Multi-Topology Identifier, de la liste des descripteurs de lien inter-AS.
  • MT-ID ne disparaît pas de BGP-LS. La modification porte sur l’identité du nouvel objet proposé et doit être éprouvée par des retraits propres, l’absence de doublons et le maintien de topologies distinctes.

Dans un protocole qui transforme une carte de réseau en objets identifiables, supprimer un champ n’est pas une retouche éditoriale. C’est modifier la manière dont deux implémentations peuvent décider qu’elles parlent du même lien.

L’historique IETF horodate la mise à disposition de draft-ietf-idr-bgpls-inter-as-topology-ext-38 au 19 août à 09 h 22 min 08 s UTC. La comparaison des sources officielles des versions 38 et 37 ne révèle qu’un changement technique : la ligne qui citait Multi-Topology Identifier, ou MT-ID, dans les descripteurs supplémentaires a été retirée.

Le projet cherche à combler un angle mort. Le BGP-LS défini par le RFC 9552 permet à un producteur de transmettre l’état d’un domaine IGP à une application consommatrice. Lorsque le même opérateur exploite plusieurs AS et plusieurs domaines IGP, le contrôleur reçoit les cartes internes mais pas nécessairement les liens qui les relient. Le texte propose donc un nouvel NLRI de type 7, accompagné du numéro de l’AS distant et des identifiants IPv4 ou IPv6 du routeur frontière distant.

Chaque extrémité publie une représentation unidirectionnelle, un demi-lien. Le contrôleur doit rapprocher les deux moitiés avant d’utiliser l’ensemble pour calculer un chemin de bout en bout. C’est précisément là que le choix des descripteurs devient opératoire : trop de différences peuvent créer deux objets pour un même lien ; une fusion trop large peut confondre des liens qui devraient rester séparés.

Dans la version 37, la liste comprenait les identifiants local et distant du lien, les adresses d’interface et de voisin IPv4, les équivalents IPv6, puis MT-ID. La version 38 s’arrête à l’adresse du voisin IPv6. La phrase suivante n’a pas changé : l’emploi d’autres TLV comme descripteurs peut compliquer la corrélation des deux demi-liens lorsque les producteurs ne se comportent pas de la même façon.

Il serait toutefois erroné d’annoncer la suppression générale de MT-ID. Le RFC 9552 continue d’attribuer le type 263 à cet identifiant. Pour son NLRI de lien ordinaire, il impose MT-ID lorsque le lien IGP appartient à une topologie autre que celle par défaut et demande un NLRI distinct pour chaque topologie. La section de sécurité de la version 38 mentionne encore MT-ID parmi les informations de topologie critiques.

Le changement concerne donc le contrat proposé pour le nouvel NLRI inter-AS. Un producteur construit selon la version 37 peut inclure le TLV 263 dans sa clé ; un autre suivant la version 38 peut l’omettre. Le comportement correct ne se déduit pas d’un numéro de version : il se vérifie dans la succession des annonces et dans l’état final du consommateur.

Le RFC 9552 fixe déjà une règle importante. Lorsqu’un producteur ajoute, retire ou modifie un TLV dans un NLRI Link-State, il doit retirer l’ancien NLRI. Faute de quoi, prévient le RFC, des objets incohérents ou dupliqués peuvent rester dans la table BGP-LS. Cette règle fournit un scénario d’essai pour la version 38 ; les documents officiels consultés le 19 août ne signalent aucun incident réel de ce type.

Un deuxième décalage reste visible dans le registre IANA. Consulté le 19 août, le registre indiquait une dernière mise à jour au 7 août ; le type 7 y portait encore le nom Stub Link NLRI et renvoyait à la version 17, alors que la version 38 parle d’Inter-AS Link NLRI. Les TLV 270 à 272 ont les noms actuels — numéro d’AS distant et identifiants du routeur frontière — mais leur référence reste également la version 17.

La fiche Datatracker met ce travail en cours en contexte. Le document vise le statut Proposed Standard, a été transmis à l’IESG et se trouve à l’étape AD Followup. L’examen IANA indique Version Changed - Review Needed, tandis que l’examen des experts est marqué comme terminé. Ce n’est ni un RFC ni une preuve d’interopérabilité.

La confidentialité fait partie du même dossier. Le projet limite son scénario à plusieurs AS exploités par une seule entité et qualifie de critiques les identifiants de liens, adresses, numéros d’AS et identifiants de topologie. Il recommande de conserver ces données dans ce domaine fermé ou de les filtrer avant qu’elles n’en sortent. Une carte plus complète aide l’automatisation, mais augmente aussi la précision de l’information qu’il faut protéger.

La version 38 apporte ainsi un signal précis : la clé proposée devient plus étroite. Avant d’en faire un contrat d’exploitation, il faut voir un producteur retirer l’ancienne identité, un consommateur n’en garder qu’une, les deux demi-liens se rejoindre correctement et les topologies non par défaut rester distinctes.

Sources