Résumé

  • Quand 255 octets ne suffisent plus, la RFC 9885 permet de représenter un objet IS-IS par plusieurs TLV de même type et de même clé, à condition que chaque partie reste décodable seule.
  • Le sous-TLV de capacité de type 30 est une information d’exploitation : il ne doit modifier ni l’émission ni le traitement du protocole et ne décrit pas les codepoints un par un.
  • La décision d’activer l’émission repose donc sur une preuve externe couvrant chaque récepteur, chaque version et le codepoint concerné.

Le piège apparaît souvent dans une réunion de changement. La colonne « capacité MP-TLV » est verte pour tous les routeurs. La proposition semble prudente : activer une fonction standard afin qu’un objet de trafic ingénierie puisse dépasser la taille d’un TLV. Pourtant, la colonne ne dit pas si le vieux routeur placé au bord d’une zone comprend les deux parties du codepoint que l’on veut précisément utiliser.

La RFC 9885 part d’une limite ancienne. Dans un tuple Type-Length-Value d’IS-IS, Type et Length occupent chacun un octet. La valeur ne peut donc dépasser 255 octets. À mesure que les réseaux grandissent et que les technologies ajoutent des attributs, cette limite cesse d’être théorique. Le texte codifie l’occurrence multiple d’un TLV comme mécanisme normal d’extension lorsque la spécification du codepoint n’a pas déjà défini une autre méthode.

Il ne s’agit toutefois pas de découper un flux d’octets n’importe où. Plusieurs occurrences constituent un MP-TLV si elles portent le même type et la même clé d’objet, lorsqu’une telle clé existe. Chaque partie doit pouvoir être analysée indépendamment. Couper un sous-TLV ou une autre unité de données entre deux occurrences produit un encodage invalide.

L’ordre disparaît, l’identité demeure

Un récepteur compatible doit accepter toutes les informations de toutes les parties. Leur ordre d’arrivée ne compte pas, pas plus que leur position dans un ou plusieurs fragments de LSP. Dans un IIH, leur emplacement est également sans effet. Le récepteur traite le contenu comme une concaténation logique, en reconnaissant que la clé répétée désigne toujours le même objet.

Cette règle ne gomme pas les contradictions. Une métrique fixe peut être répétée sans appartenir à la clé. Si deux parties donnent des valeurs incompatibles, il y a erreur. Il en va de même d’un sous-TLV censé être unique mais présent avec plusieurs valeurs. À défaut de règle plus spécifique, la première occurrence du LSP au numéro le plus faible prévaut ; dans un IIH, la première occurrence est retenue.

Le texte distingue aussi ce que le récepteur doit tolérer de ce que l’émetteur devrait produire. Deux parties de cent octets ne peuvent être rejetées au seul motif qu’elles auraient tenu ensemble. En revanche, l’émetteur ne devrait créer plusieurs TLV que si le mécanisme s’applique au codepoint et si l’information dépasse réellement la capacité d’un TLV. Si le TLV peut encore grandir mais que le LSP courant manque de place, il vaut mieux déplacer le TLV entier vers un autre LSP.

Cette asymétrie est une discipline de compatibilité. Le récepteur reste robuste devant une forme valide mais peu élégante ; l’émetteur évite d’élargir inutilement la surface d’interopérabilité.

Un avertissement dans Router CAPABILITY

Sans prise en charge MP-TLV, un routeur peut choisir une occurrence et ignorer les autres. Si la partie abandonnée contient des attributs utilisés pour un calcul de chemin contraint, les routeurs ne travaillent plus à partir de la même réalité. La RFC évoque des calculs inattendus, des boucles et des pertes de trafic, précisément le type d’incident où chaque équipement semble localement sain.

Pour rendre cette transition plus visible, la RFC crée le sous-TLV de type 30, de longueur nulle, dans Router CAPABILITY. Il signale la prise en charge des codepoints dont les anciens textes rendaient le comportement multi-parties implicite. La portée du TLV porteur est limitée au niveau IS-IS concerné.

Mais le signal est explicitement informatif. Une implémentation ne doit pas changer ce qu’elle envoie ni la manière dont elle traite ce qu’elle reçoit en fonction de l’annonce. Ce n’est ni une négociation, ni une permission, ni un verrou automatique de déploiement.

La granularité explique cette prudence. Le type 30 ne possède aucun champ permettant d’énumérer les codepoints pris en charge. Le texte suppose une couverture générale tout en reconnaissant qu’un produit réel peut n’avoir implémenté le mécanisme que pour certains TLV. L’annonce répond donc à « ce routeur déclare une capacité générale », pas à « cette version traite correctement le codepoint 22 dans toutes les positions ».

Les colonnes MP ajoutées aux registres IANA répondent encore à une autre question. Elles indiquent si la procédure est applicable à un codepoint. Elles ne mesurent ni le logiciel installé, ni la configuration, ni la cohérence d’une flotte.

La preuve d’autorisation appartient à l’exploitant

La RFC recommande des contrôles d’émission activables par codepoint. Si l’émission est désactivée, l’implémentation doit journaliser la réception d’un MP-TLV et le moment où la génération locale en aurait besoin. Enfin, l’exploitant ne devrait pas activer la fonction avant de s’être assuré que toutes les implémentations destinataires savent interpréter correctement les parties.

Ce contrôle réclame un registre extérieur au protocole : rôle du routeur, niveau, plateforme, image logicielle, codepoint testé, résultat de décodage, calcul de chemin et plan de retour arrière. L’authentification IS-IS peut prouver l’intégrité ou l’origine selon son propre contrat ; elle ne prouve pas qu’un récepteur comprend toute la sémantique authentifiée.

La primauté du code en fonctionnement prend ici une forme très concrète. L’étiquette du registre et le bit annoncé sont des indices. Le comportement du binaire exact qui calcule puis installe la route est la réalité décisive.

Sources