Résumé

  • Les LSA étendues de RFC 8362 portent le bit U afin qu'un routeur qui n'en connaît pas la fonction puisse les stocker et les diffuser dans la portée indiquée. Leur présence dans la LSDB établit une chaîne de garde, pas une capacité fonctionnelle.
  • Une information inconnue mais correctement formée n'a pas le même statut qu'une LSA mal encodée. La première peut circuler; la seconde ne doit être ni installée, ni acquittée, ni diffusée. Elle devrait être comptée et journalisée.

Le relais qui ne prétend pas comprendre

Dans OSPFv3, le champ LS Type ne désigne pas seulement une fonction. Il contient aussi un bit U et des bits de portée. RFC 5340 précise la conduite à tenir lorsqu'un routeur ne reconnaît pas la fonction: avec U=0, il traite l'annonce comme ayant une portée locale au lien; avec U=1, il la stocke et la diffuse selon la portée inscrite dans le type.

RFC 8362 crée les versions étendues des principales LSA OSPFv3 en ajoutant 32 en décimal, soit 0x20, aux codes de fonction correspondants. Elle exige que le bit U soit positionné. Un routeur plus ancien peut donc servir de passage entre deux équipements capables de comprendre l'extension. Il participe réellement à la fiabilité de la diffusion, sans pour autant participer au sens de l'annonce.

Cette architecture sépare au moins quatre preuves. L'entrée LSDB prouve qu'une annonce recevable est arrivée. Le décodeur prouve que la version logicielle reconnaît sa grammaire. La configuration prouve qu'une fonction est autorisée à s'en servir. Enfin, la sortie SPF, la RIB, la FIB et les paquets renseignent sur la décision et son effet. Aucun voyant unique ne devrait fondre ces niveaux.

Le constat est particulièrement important lors d'un inventaire. Lire une Extended Router-LSA sur un nœud intermédiaire ne permet pas d'affirmer que ce nœud prend en charge tous ses TLV, que la fonction correspondante est active, ni qu'un chemin a changé. La formule exacte est plus modeste: ce nœud a reçu et gardé une instance identifiée de l'annonce dans les règles de portée du protocole.

Une enveloppe extensible, des sens distribués

Les LSA historiques ont des formats fixes. RFC 8362 introduit des enveloppes dont l'information variable est organisée en TLV, puis parfois en sous-TLV. L'enveloppe nouvelle peut être reconnue indépendamment de chacune des significations qu'elle contiendra à l'avenir. C'est ce qui permet à OSPFv3 d'évoluer sans imposer une mise à niveau simultanée de tous les routeurs.

Le bénéfice n'est pas une garantie magique de déploiement partiel. RFC 8362 demande à chaque nouvelle spécification de TLV ou de sous-TLV de définir son propre comportement lorsque seuls certains équipements la comprennent. Une fonction peut tolérer un îlot de nœuds anciens, nécessiter des extrémités capables, ou exiger une continuité plus stricte. Le mécanisme de diffusion ne décide pas à la place de l'extension.

À l'intérieur d'une LSA étendue connue, les TLV et sous-TLV inconnus sont ignorés pendant l'analyse et le traitement. «Ignoré» ne signifie ni supprimé, ni pris en charge. Le routeur peut conserver l'annonce globale pour la diffusion, tout en refusant de prêter un sens à un élément. RFC 9492, consacré aux attributs de lien propres à une application, confirme l'utilité de cette retenue: annoncer un attribut pour une application et activer cette application sur un lien sont deux actes distincts.

La nouveauté valide et l'encodage défectueux

La compatibilité future suppose d'accepter des significations nouvelles, à condition que leur structure soit valide. Elle ne demande pas de faire circuler n'importe quelle suite d'octets. RFC 8362 prévoit qu'une LSA étendue dont les longueurs sont incohérentes ou l'encodage erroné ne soit pas installée dans la LSDB, ne soit pas acquittée et ne soit pas diffusée. L'implémentation devrait compter et journaliser l'erreur.

Trois files d'observation sont donc nécessaires:

  1. les éléments connus et valides, décodés et éventuellement utilisés selon la configuration;
  2. les éléments inconnus mais valides, gardés comme information opaque et relayés lorsque les règles du bit U l'ordonnent;
  3. les éléments mal formés, arrêtés avant la base et exposés par des compteurs de rejet.

Classer les deux derniers ensemble détruit le diagnostic. Rejeter toute nouveauté coupe le passage aux routeurs plus récents. Diffuser toute anomalie sous prétexte qu'elle est inconnue étend la portée d'un défaut. Il faut un analyseur capable de dire «je ne connais pas ce type, mais sa forme est recevable» et une télémétrie qui conserve cette nuance.

Suivre l'annonce sans inventer une identité immuable

RFC 5340 identifie une LSA par le LS Type, le Link State ID et l'Advertising Router. Le numéro de séquence, la somme de contrôle et l'âge servent à départager les instances. La somme de contrôle exclut l'âge, qui évolue pendant la conservation et la diffusion. Parler d'un objet strictement identique octet pour octet sur tous les sauts serait donc excessif.

Un reçu de transport plus solide associe le type et sa portée, le routeur annonceur, l'identifiant d'état de liens, la séquence, la somme de contrôle, l'aire ou l'interface d'observation et l'heure de collecte. Il permet de rapprocher les observations sans transformer l'âge en contenu immuable. Pour démontrer la compréhension, il faut encore ajouter la version du logiciel et les types reconnus; pour démontrer l'usage, la configuration et la sortie du calcul; pour démontrer l'effet, la RIB, la FIB et le trafic.

Deux chemins de migration

RFC 8362 décrit d'abord une migration complète à l'aide de deux instances OSPFv3. L'instance étendue reçoit au départ une préférence moindre. L'opérateur compare les RIB, change la distance administrative lorsque les différences sont expliquées, compare de nouveau, puis retire l'instance historique. La présence des LSA étendues n'est pas le jalon décisif: c'est la comparaison des résultats de routage.

Le mode clairsemé conserve les LSA historiques pour le calcul SPF ordinaire et utilise les LSA étendues seulement pour les fonctions nouvelles. Il évite deux instances complètes, mais rend la carte des capacités plus importante. Quelques annonces visibles ne disent pas si toutes les extrémités nécessaires sont compatibles ni si les TLV requis sont complets.

RFC 9587 apporte une pièce de gestion utile. Son modèle YANG OSPF prévoit un indicateur de prise en charge des LSA étendues, désactivé par défaut, ainsi qu'une représentation des TLV inconnus avec type, longueur et valeur hexadécimale. Ce modèle donne à l'opacité une place observable; il ne la transforme pas en compréhension. L'heure, le routeur source et le chemin de modèle doivent rester liés à la collecte.

La place exacte d'Acee Lindem

RFC 8362 a été publiée en avril 2018 par Acee Lindem, Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem et Fred Baker. Elle met à jour RFC 5340 et RFC 5838. La page actuelle du groupe de travail Link State Routing cite Lindem parmi ses présidents; ce rôle daté n'est ni la propriété de la norme ni le contrôle des déploiements.

Les sources autorisent une attribution précise: Lindem a contribué à un travail collectif qui sépare le transport d'un état OSPFv3 extensible de l'interprétation de cet état, puis a aussi cosigné le modèle opérationnel de RFC 9587. Elles ne font pas de lui l'inventeur unique des Extended LSA, l'auteur de chaque extension ultérieure ou le garant d'une implémentation.

Cette limite reflète le protocole lui-même. L'origine contrôle l'annonce. OSPFv3 règle la diffusion d'une enveloppe valide. Le logiciel décide ce qu'il sait décoder. La configuration autorise une fonction. Les plans de routage et de transfert produisent un effet. L'opérateur choisit la preuve conservée. Une ligne de LSDB n'absorbe aucune de ces responsabilités.

Le registre probant d'un déploiement

Un dossier exploitable relie sept pièces sans les confondre: identité et portée de la LSA; capacités exactes de chaque version; état d'activation de la fonction; résultat SPF ou applicatif; changement de RIB et de FIB; observation bornée du trafic; enfin, compteurs et journaux des annonces mal formées rejetées.

Le transport n'est pas une version incomplète de l'effet. C'est un fait autonome. La sagesse de RFC 8362 est d'autoriser un routeur à rendre le service le plus juste lorsqu'il ne comprend pas une information: la porter fidèlement jusqu'à celui qui la comprend. Il faut reconnaître cette garde, sans lui attribuer un sens qu'elle n'a jamais revendiqué.

Sources