Résumé

  • Le tag de route externe OSPF décrit par RFC 1403 indiquait son mode de génération, la complétude de l’information et une classe de longueur de chemin ; il ne contenait pas le chemin complet.
  • Un tag manuel restait une valeur locale opaque. Même un tag automatique ne distinguait que zéro, un ou plusieurs éléments de chemin.
  • Pour les chemins tronqués ou conservés dans un enregistrement BGP séparé, la perte de détail retirait le droit de réexporter depuis OSPF.

La frontière avait une mémoire plus petite que son pouvoir

À la limite d’un système autonome, BGP et OSPF ne regardaient pas la route de la même manière. Le premier transportait une histoire interdomaines ; le second projetait la joignabilité dans un calcul intérieur. Un ASBR pouvait traduire l’une vers l’autre, puis un autre ASBR pouvait être tenté de refaire une annonce extérieure à partir de la projection.

RFC 1403 donna au tag externe OSPF une grammaire compacte. Un bit disait si le tag avait été produit automatiquement, un autre si l’information de chemin était complète, deux autres classaient sa longueur. Douze bits restaient arbitraires et seize pouvaient porter un numéro d’AS.

Le tag ne devenait pas un petit AS_PATH. Il décrivait l’état de la preuve disponible.

Lorsque le bit Automatic valait zéro, les trente et un bits restants appartenaient à la configuration locale. Pour préserver la compatibilité avec les déploiements OSPF, c’était même la valeur par défaut. Le RFC interdisait alors de déduire les caractéristiques de la route à partir du motif binaire. Une donnée ne recevait donc pas une sémantique commune par simple ressemblance ; sa provenance de génération devait d’abord être connue.

Automatic ne signifiait pas « authentique ». Le document ne traitait pas la sécurité. Le bit ne certifiait ni l’équipement ni son entrée ; il indiquait seulement quelle convention de lecture s’appliquait.

Deux absences, deux conduites

Pour un chemin nul ou limité à un AS voisin, la combinaison de la classe de longueur et du numéro d’AS pouvait suffire à construire une assertion bornée. Un chemin plus long dépassait la capacité du champ.

Dans un premier cas, le chemin avait été tronqué avant ou pendant l’importation. Le tag pouvait dire « incomplet et long », mais ne connaissait plus la séquence. RFC 1403 imposait alors de ne jamais réexporter la route vers BGP depuis un autre ASBR.

Dans le second cas, le chemin complet existait encore, mais ailleurs. OSPF portait la projection de joignabilité ; BGP devait transporter l’histoire complète entre routeurs de bord du même AS. L’ASBR qui voyait la route OSPF devait attendre la mise à jour BGP intérieure avant d’annoncer à l’extérieur.

Le tableau du RFC qualifiait cette seconde transmission de « out of band ». Il ne s’agissait pas d’un canal de données secret, mais d’un autre enregistrement protocolaire. La première absence signifiait que la preuve était perdue ; la seconde, que la preuve faisait autorité ailleurs. Aucune n’autorisait le résumé à l’inventer.

Une route apprise n’était pas encore publiable

Les valeurs par défaut renforçaient la séparation. Aucun export OSPF vers BGP sans décision explicite ; aucun import BGP vers OSPF sans sélection ; aucune route par défaut intérieure produite spontanément. Voir, importer et annoncer restaient trois actes différents.

La métrique révélait le même refus de l’équivalence facile. Le coût OSPF et la métrique inter-AS de BGP-3 n’avaient ni la même largeur ni la même fonction. Dans la republication corrigée, la métrique BGP optionnelle restait absente par défaut. Une formule ne suffisait pas à transférer la signification d’un système de décision à l’autre.

L’identité reliait ensuite les dossiers. RFC 1403 exigeait que le BGP Identifier et l’OSPF router ID d’un équipement correspondent. Si deux ASBR importaient le même réseau extérieur, un troisième devait identifier celui qu’utilisait réellement sa route OSPF, puis reprendre le chemin BGP associé à cet ASBR.

RFC 1745 adapta en 1994 cette architecture à BGP-4 et IDRP : préfixes variables, ensembles de chemins, MULTI_EXIT_DISC, LOCAL_PREF. Les objets changèrent ; la limite demeura. Un chemin tronqué ne devait jamais ressortir. Un chemin complet mais trop long pour le tag devait arriver par BGP/IDRP avant toute nouvelle annonce.

Même le rapprochement entre Forwarding Address OSPF et NEXT_HOP BGP ne prouvait qu’une construction de prochain saut. Il ne prouvait pas le forwarding observé, la réponse distante ni le résultat applicatif.

RFC 1403 et RFC 1745 sont aujourd’hui Historic. Ils n’attestent ni pratique actuelle, ni déploiement, ni incident. Leur leçon historique tient dans une contrainte plus robuste : déclarer une information incomplète n’a de valeur que si cette déclaration retire les décisions qui exigent l’information absente.

Sources

Ces sources établissent le statut des textes, la sémantique des champs et les obligations spécifiées, non une adoption présente, une authentification, un succès de forwarding ou un résultat utilisateur.