Résumé

  • draft-ietf-idr-bgpls-inter-as-topology-ext-46 propose un NLRI BGP-LS de type 7 et trois descripteurs afin qu'un consommateur corrèle les annonces provenant des deux côtés d'une interconnexion.
  • Le lien complet n'est pas un fait transmis d'un seul bloc : il résulte des sources IGP ou locales, des politiques d'exportation, des identifiants, de la fraîcheur et de la règle d'appariement du contrôleur.
  • Une alliance qui s'en sert pour calculer des chemins doit conserver un reçu borné : deux entrées, leur provenance, la décision de jointure, les désaccords et, séparément, le résultat de transfert.

Le trait n'existe pas dans un seul message

Dans chaque domaine, BGP-LS sait déjà exposer des nœuds, des liens et des préfixes. La frontière reste un angle mort particulier : l'IGP ne s'exécute généralement pas sur la liaison Inter-AS. Le contrôleur peut donc connaître le domaine A et le domaine B sans disposer de la couture qui les relie.

La révision 46 de BGP-LS Extensions for Inter-AS Topology Retrieval définit cette couture sous forme de données. Elle introduit le type NLRI 7, un numéro d'AS distant et des identifiants d'ASBR distant IPv4 ou IPv6. L'information peut venir d'une annonce OSPF Inter-AS TE décrite par le RFC 5392, d'une annonce IS-IS du RFC 9346, puis être exportée selon le cadre BGP-LS du RFC 9552.

Le projet dit qu'une liaison est normalement représentée par des informations apprises de chaque côté. Le consommateur rapproche l'AS local de l'AS distant, les identifiants des routeurs de bord, l'identifiant d'instance BGP-LS et, lorsqu'ils existent, les identifiants d'interface. Une correspondance produit une arête. Un échec produit une liaison non appariée ou incomplète.

Il n'existe donc pas d'identifiant universel envoyé par la fibre elle-même. Le contrôleur formule une conclusion à partir de deux témoignages structurés.

Deux formes identiques peuvent avoir des provenances différentes

Dans le chemin principal, un ASBR publie l'information dans OSPF ou IS-IS. Un locuteur BGP-LS la reçoit, construit le NLRI, puis une politique l'autorise ou non à atteindre le consommateur. Chaque étape peut être correcte localement et néanmoins laisser une vue asymétrique.

Le projet prévoit aussi un autre cas : un ASBR peut créer le NLRI à partir d'une interface directement connectée ou d'une route statique, avec une origine Direct ou Static configuration. Le contrôleur rapproche alors les côtés avec le numéro d'AS et l'adresse.

Une moitié peut donc suivre le rythme d'un LSA, l'autre celui d'un changement de configuration. La première porte une histoire de diffusion IGP ; la seconde, une histoire de validation opérateur. Les traiter comme deux champs équivalents sans garder l'origine rend l'arête plus nette que la preuve.

Un reçu minimal devrait conserver, pour chaque côté, une référence stable à l'annonce, le protocole source, l'instance BGP-LS, les AS et ASBR locaux et distants, les identifiants complémentaires, l'heure d'arrivée, l'âge et l'état de retrait. Il devrait ajouter la règle exacte d'appariement et la version de politique qui a admis le résultat.

Ce reçu est une proposition éditoriale, pas une exigence de l'IETF. Il vise à rendre une inférence locale contestable, non à créer un registre central de toutes les liaisons.

La chaîne de preuve compte plus que la forme finale

Neuf étapes au moins séparent le câble du service : configuration de l'interconnexion ; description OSPF, IS-IS ou locale ; construction BGP-LS ; passage des politiques ; analyse par le consommateur ; corrélation ; admission dans un instantané ; calcul et programmation du chemin ; observation des paquets et du résultat applicatif.

Un résultat vert ne se propage pas automatiquement. Un code IANA commun permet d'écrire deux implémentations compatibles. Un NLRI valide prouve que la forme est comprise. Deux annonces cohérentes prouvent qu'elles satisfont la règle de rapprochement. Elles ne prouvent ni que le lien est actif, ni que sa capacité est actuelle, ni qu'un chemin a été installé.

La révision 46 est un Internet-Draft actif du groupe IDR, daté du 29 septembre 2026. Ce n'est pas un RFC. Le dossier ne contient ni déploiement public, ni test d'interopérabilité, ni mesure de transfert. Les allocations anticipées du registre IANA BGP-LS permettent le développement ; elles ne certifient pas la chaîne opérationnelle.

L'asymétrie doit devenir un état visible

Le déploiement peut être progressif. Seuls les producteurs concernés, les locuteurs BGP-LS et les consommateurs doivent comprendre le nouveau NLRI. C'est un avantage, mais aussi une source d'incomplétude crédible.

Un côté peut omettre un identifiant. Un filtre peut supprimer une seule annonce. Une session peut être en retard. Un retrait peut arriver après son homologue. Deux ASBR peuvent désigner la même interconnexion avec des informations que la règle ne sait pas réconcilier.

Le projet recommande précisément d'examiner les deux ASBR, les annonces OSPF ou IS-IS, la réception par les locuteurs BGP-LS, l'exportation, la cohérence des identifiants et les politiques. Il encourage l'affichage du résultat de corrélation.

Ce résultat mérite plusieurs états : apparié, isolé, contradictoire, périmé, en retrait ou non pris en charge. Réduire tout cela à « présent/absent » efface le diagnostic au moment où l'automatisation en a besoin.

Une jointure temporelle peut inventer un monde

Imaginons que le côté A soit reçu à 09 h 00 et le côté B à 09 h 04. À 09 h 02, A change d'identifiant et retire l'ancienne annonce, mais le retrait est retardé. À 09 h 04, le contrôleur peut posséder deux enregistrements compatibles qui n'ont jamais été vrais au même instant.

Le projet ne fixe pas une politique universelle de fraîcheur ou de retrait. C'est raisonnable : les opérateurs ont des contraintes différentes. Mais la responsabilité passe au consommateur. Son reçu doit déclarer la fenêtre temporelle acceptée, le traitement des retraits et l'identifiant de l'instantané utilisé.

Sans cette frontière, « les deux côtés concordaient » peut désigner seulement une concordance dans la base, pas dans le réseau.

Protéger la carte sans perdre la raison de la décision

Le scénario vise surtout plusieurs AS sous une administration commune. Le projet avertit que les identifiants et adresses d'interconnexion sont des informations critiques, à maintenir dans le domaine contrôlé ou à filtrer.

L'audit ne commande pas une publication générale. Les entrées du reçu peuvent être des références internes ou des condensats, protégés par rôle et limités dans le temps. Le besoin commun est plus petit : permettre à un examinateur autorisé de reconstruire pourquoi une arête a été admise.

Même parfaitement protégé, ce reçu reste celui d'une carte. Le calcul de chemin multi-domaine du RFC 8735, la programmation, la convergence et la livraison exigent chacun une preuve distincte.

Un essai qui peut démentir le dessin

Running Code Primary fournit un test concret. Deux implémentations indépendantes reçoivent successivement une paire cohérente, des ASBR distants incompatibles, un filtrage unilatéral, des mises à jour réordonnées, un retrait tardif et une moitié statique face à une moitié IGP. On compare les arêtes créées, dégradées et supprimées, mais aussi la raison enregistrée.

Si deux contrôleurs dessinent le même trait pour des motifs différents, l'interopérabilité apparente se brisera au premier retrait. Minimum Initial Specification invite alors à normaliser le strict nécessaire : références des deux entrées, règle de corrélation, frontière temporelle et état final. Le stockage, la réparation et la politique de chemin peuvent rester locaux.

La formulation honnête devient plus longue : le contrôleur a reçu ces deux annonces, de ces sources, dans cette fenêtre ; il a appliqué cette règle ; aucun conflit non résolu n'a subsisté ; l'arête a été admise dans tel instantané. Le résultat de transfert vient après.

Un trait de carte est plus élégant. Un reçu de corrélation est plus gouvernable.

Sources

  1. BGP-LS Inter-AS Topology Retrieval, révision 46
  2. Historique du projet
  3. RFC 9552
  4. RFC 5392
  5. RFC 9346
  6. Registre IANA BGP-LS
  7. Lu Heng — Minimum Initial Specification
  8. Lu Heng — On Reality Layers
  9. Lu Heng — Running Code Primary
  10. Révision 46 en HTML
  11. Révision 46 en texte brut
  12. Diff officiel des révisions 45 et 46
  13. RFC 7426 — terminologie SDN
  14. RFC 9086 — BGP-LS Egress Peer Engineering