Résumé

  • RFC 5311 transforme une contrainte de stockage — 256 numéros LSP par jeu — en plusieurs jeux rattachés à un seul système physique. Un Virtual IS possède un identifiant dans la base, mais ni châssis, ni panne, ni autorité propres.
  • La preuve exploitable est une chaîne : Extended LSP zéro vivant, TLV 24 d’alias, adresses de zone compatibles, deux arêtes synthétiques asymétriques, restrictions de contenu, état OL du parent et règles de priorité. Un fragment isolé n’atteste pas cette chaîne.

Une deuxième identité n’est pas un deuxième équipement

La télémétrie signale soudain deux origines. L’inventaire n’a pourtant enregistré aucune installation, aucun numéro de série et aucune nouvelle alimentation. Ce décalage n’est pas une anomalie : il est précisément l’outil de capacité défini par RFC 5311.

Dans IS-IS, un jeu LSP dispose de 256 numéros. Le RFC cite une valeur maximale de 1492 octets pour un LSP. Les informations d’ingénierie de trafic, de topologies multiples, de capacités et de joignabilité peuvent remplir cet espace. L’Originating System peut alors employer un Additional System ID unique pour émettre un jeu Extended LSP supplémentaire. La base reçoit une nouvelle identité syntaxique ; le réseau physique reste gouverné par la même machine.

Cette différence doit survivre aux collecteurs, graphes, moteurs de conformité et systèmes d’incident. Si le Virtual IS devient un objet autonome, les outils inventent un domaine de panne et une responsabilité qui n’existent pas. La capacité de publication, l’identité physique, la position topologique et la joignabilité actuelle sont quatre dimensions distinctes.

Le fragment zéro autorise tous les autres

Les Extended LSP sont générés, diffusés, vieillis et purgés selon les mécanismes habituels. Leur admission comporte toutefois une règle décisive : si le LSP numéro zéro de l’Additional System ID est absent, ou si sa durée de vie restante vaut zéro, aucun autre fragment de ce jeu ne doit être traité.

Ainsi, conserver les fragments 1 à 255 après la disparition du zéro produit une archive fidèle de données devenues inutilisables. Un tableau de bord peut les afficher comme « présentes » tout en contredisant le comportement requis des routeurs. L’état de chaque fragment doit donc être joint à l’état vivant du zéro, pas seulement à une clé d’origine.

Ce LSP zéro doit contenir l’IS Alias ID TLV 24, qui désigne le system ID normal du système d’origine. Il doit aussi publier des Area Addresses formant un sous-ensemble de celles du LSP zéro normal ; une identité syntaxique est préférable. Le modèle correct est donc une relation identifiant additionnel → zéro vivant → alias → origine normale → zone et niveau, assortie des séquences, durées de vie et purges.

L’unicité est contextuelle : l’Additional System ID doit être unique dans toute la zone de niveau 1 lorsqu’il sert au niveau 1, et dans tout le domaine lorsqu’il sert au niveau 2. Une validation limitée à un seul châssis peut accepter deux revendications valides localement mais incompatibles globalement.

Deux arêtes, deux fonctions et deux coûts

Le jeu LSP original annonce chaque Virtual IS associé comme voisin avec une métrique nulle. Cette direction satisfait la vérification de connectivité bidirectionnelle et fait coïncider le coût d’accès au Virtual IS avec celui du système physique.

Le jeu Extended annonce en retour l’Originating System avec une métrique non nulle, de préférence MaxLinkMetric-1. En environnement multi-topologie, les annonces correspondantes doivent exister des deux côtés pour chaque topologie représentée dans le jeu étendu.

Ces arêtes ne décrivent pas un câble. Elles forment un échafaudage de compatibilité. L’aller nul attache l’espace supplémentaire à son propriétaire ; le retour très coûteux empêche l’identité virtuelle de devenir un raccourci de transit. Fusionner ces directions en une simple adjacence non orientée détruit l’intention de sûreté.

RFC 5311 remplace RFC 3786 en limitant le contenu étendu de façon à ne pas modifier la construction SPF. Un routeur ancien voit le Virtual IS uniquement derrière l’origine réelle et ne voit aucun autre système accessible à travers lui. Il calcule donc un arbre compatible sans mode spécial ni fusion logique pendant SPF.

L’espace supplémentaire reste soumis à une discipline stricte

Les TLV 3, 4 et 5 — ES Neighbors, Partition Designated Level 2 IS et Prefix Neighbors — sont interdits dans les Extended LSP. Un récepteur capable les ignore, devrait signaler l’erreur et poursuit néanmoins le traitement des données permises. Une valeur invalide ne transforme pas nécessairement tout le jeu en déchet.

La joignabilité vers un IS est encore plus encadrée : dans un Extended LSP, elle ne peut viser que l’Originating System. Les voisinages ordinaires restent dans le jeu original. Les TLV 23 et 223 peuvent déplacer des attributs de voisin, mais ils ne créent jamais l’adjacence. Sans TLV 22 ou 222 correspondant dans le jeu d’origine, ces attributs ne prouvent aucun voisin.

Les bits OL, ATT et P doivent être nuls dans les Extended LSP. La règle ATT révèle le danger : un système ancien pourrait prendre le Virtual IS pour une sortie par défaut vers une autre zone, alors que le propriétaire physique ne possède pas cette autorité. Une identité artificielle ne doit pas acquérir des pouvoirs de routage absents chez son parent.

Quand les feuilles migrent, l’espace devient action de forwarding

RFC 5311 autorise dans les jeux étendus plusieurs formes de joignabilité feuille : IP interne et externe, Extended IP, multi-topologie IP, IPv6 et multi-topologie IPv6. Lorsque plusieurs topologies sont présentes, le MT TLV 229 doit énumérer toutes celles représentées par ces annonces.

À cet instant, le mécanisme n’est plus une simple extension documentaire. Les préfixes présents dans un Extended LSP peuvent déclencher des mises à jour RIB puis FIB. Le RFC avertit d’une fréquence accrue de changements de forwarding et recommande de conserver les informations feuille dans le jeu normal lorsque c’est possible.

La preuve opérationnelle doit relier préfixe, fragment, Additional System ID, zéro d’admission, topologie, état OL du parent et générations RIB/FIB. Compter les fragments étendus ne distingue pas une capacité descriptive d’une entrée qui vient de modifier le chemin des paquets.

Le bit overload du parent gouverne les enfants

Les Extended LSP imposent eux-mêmes OL à zéro. Leur utilité dépend pourtant du bit OL publié par une autre identité, celle du système normal. Tant que le parent n’est pas en overload, la joignabilité vers ses Virtual IS demeure cohérente avec sa propre joignabilité. Lorsqu’il passe en overload, les routeurs anciens considèrent les identités associées comme inaccessibles ; les routeurs compatibles doivent arriver au même résultat.

Cette convergence prévient des boucles lorsque des informations feuille résident dans l’espace étendu. Elle crée aussi un piège d’observabilité : une requête limitée à l’enregistrement virtuel voit un LSP dont OL vaut zéro, au moment exact où le parent vient de rendre tout le jeu impropre à l’usage.

Il faut donc agréger origine physique, niveau, zone, alias, zéro vivant, état OL et génération. La santé d’un enfant virtuel ne se mesure jamais dans sa seule ligne de base de données.

La priorité explique la valeur finale

Une migration peut laisser coexister des attributs de voisin dans les jeux normal et étendu. Les valeurs non contradictoires s’additionnent. En cas de conflit, le jeu original l’emporte. S’il ne fournit aucune valeur, le jeu Extended portant le system ID additionnel le plus faible gagne. À l’intérieur d’un contexte, TLV 22 prévaut sur TLV 23 et TLV 222 sur TLV 223 pour le même MTID.

Ne conserver que le gagnant efface la provenance de la décision. Un reçu digne d’un incident garde chaque candidat, le LSP source, le type de TLV, le MTID, la séquence, la durée de vie et la règle appliquée. Sinon, le changement de gagnant ressemble à une oscillation inexpliquée ou à une corruption.

Le registre IANA peut autoriser de nouveaux TLV et une extension future peut les placer dans l’espace Extended. Cela ne démontre pas que les équipements anciens savent les consommer. Reconnaissance d’un numéro, interprétation du champ et déploiement dans la flotte restent des preuves séparées.

Le reçu doit rester centré sur le propriétaire physique

Un reçu non secret utile associe : système d’origine et system ID normal ; niveau et zone ; tous les Additional System IDs et leur portée d’unicité ; identité, séquence, durée de vie et purge du LSP zéro ; TLV 24 ; sous-ensemble d’adresses ; arête nulle originale-vers-virtuelle ; arête non nulle virtuelle-vers-originale ; topologies ; contrôles TLV et bits ; contenus feuille ; candidats en conflit ; OL du parent ; générations RIB/FIB ; observations paquet ; et décision de retour arrière.

La base a créé plusieurs symboles afin de transporter davantage d’information. Elle n’a pas réparti la responsabilité. Le propriétaire physique demeure le point d’autorité et de défaillance de tous les jeux.

Sources