Résumé

  • Le RFC 9815 fait de la joignabilité d’un nœud et de son aptitude à servir au transit deux faits distincts. Un statut 2 conserve l’accès au nœud et à ses préfixes, mais empêche l’expansion de ses liens sortants pendant le calcul SPF ; son omission ultérieure retire implicitement cette contrainte et rétablit l’éligibilité au transit.
  • Un contrôle de reprise qui se limite à constater qu’un service répond ne démontre donc pas le rétablissement de l’intention non-transit. La validation doit examiner séparément l’état annoncé, le résultat du calcul et de l’installation, puis des flux précisément définis, en gardant à l’esprit qu’un test négatif ne vaut que pour ces flux et à cet instant.

Un voyant vert ne rétablit pas une contrainte négative

Prenons un passage de relais explicitement hypothétique. Un serveur ou un hôte de contrôle redémarre. Son test de service réussit. Les préfixes qui lui appartiennent restent atteignables. Dans le même temps, la nouvelle annonce de nœud ne contient plus le TLV d’état SPF dont la valeur était 2 avant le redémarrage.

Le RFC 9815, document de la filière de normalisation, fixe une règle importante : chaque routeur du domaine BGP SPF annonce sans condition sa NLRI de nœud. Son article 5.2.1.1 définit en outre le TLV facultatif d’état SPF, de type 1184. Pour une NLRI de nœud, l’absence de ce TLV signifie que le nœud est considéré comme actif et disponible pour le trafic de transit. Si une valeur avait été reçue auparavant puis disparaît d’une annonce ultérieure, l’information d’état précédente est considérée comme implicitement retirée.

Ce mécanisme rend l’omission sémantiquement active. Elle ne signifie pas « conserver le dernier état connu ». Elle revient, pour le calcul BGP SPF, à supprimer la restriction précédente et à revenir au comportement par défaut. Dans notre scénario, le statut 2 ne survit donc pas simplement parce que le service revient.

L’inférence opérationnelle doit néanmoins rester bornée : le retrait de la restriction rétablit une possibilité, pas un trajet réel. Dire que le nœud redevient « disponible pour le transit » au sens du protocole ne permet pas d’affirmer qu’un paquet donné le traversera. Il faut encore que la topologie et les métriques rendent ce passage pertinent, que SPF sélectionne les chemins correspondants, que l’état résultant soit installé, puis que les flux observés rencontrent effectivement cette décision.

C’est pourquoi le feu vert du service et le retour du statut 2 sont deux critères d’acceptation indépendants. Le premier répond à une question positive : « puis-je atteindre la fonction attendue ? » Le second protège une propriété négative : « ce nœud reste-t-il exclu de l’expansion de transit ? » Confondre les deux transforme une vérification de disponibilité en preuve d’une contrainte qu’elle n’a jamais mesurée.

Ce que fait réellement la valeur 2 dans SPF

Le cœur du mécanisme se lit dans la section 6.3 du RFC 9815. L’étape 3 écarte un nœud dont le statut vaut 1 : il est alors injoignable pour BGP SPF. L’étape 4, elle, considère les préfixes du nœud courant qui est joignable. Puis l’étape 5 examine ses liens ; si le nœud courant porte le statut 2, ses liens sortants ne sont pas développés pour poursuivre le transit.

La distinction est fine mais décisive. La valeur 1 retire le nœud du calcul en tant que nœud joignable. La valeur 2 ne fait pas cela. Elle laisse ses préfixes accessibles dans la logique SPF, tout en empêchant que le calcul se prolonge au-delà de lui par ses liens sortants. C’est exactement ce qui permet au nœud d’être une destination sans devenir un passage.

Le RFC 9816, compagnon consacré à l’usage et à l’applicabilité, reste lui aussi étroit sur ce point. Sa section 7 donne deux applications non-transit : un serveur qui doit rendre des services applicatifs accessibles sans agir comme routeur, et un contrôleur hébergé sur un serveur qui doit être directement joignable sans transporter de transit. Le texte ne démontre pas qu’un réseau donné emploie ces cas. Il ne transforme pas non plus la valeur 2 en indicateur générique de maintenance ou de surcharge.

Cette retenue importe pour l’exploitation. Une équipe peut avoir ses propres raisons d’appliquer le statut 2, mais ces raisons ne doivent pas être réinjectées dans le sens normatif de la valeur. Le protocole dit ce que SPF doit faire de l’état ; il ne fournit pas à lui seul la cause organisationnelle ayant conduit à l’annoncer.

L’omission, le retrait implicite et les valeurs qui ne veulent pas dire la même chose

Le TLV d’état SPF utilise le type 1184. La section 8.2 du RFC 9815 l’enregistre sous l’intitulé d’état SPF, et le registre IANA des paramètres BGP-LS montre le même point de code. Les valeurs propres au nœud relèvent d’un autre registre : la section 8.3 du RFC 9815 et le registre IANA BGP SPF indiquent 0 réservé, 1 injoignable, 2 non-transit, 3 à 254 non attribués et 255 réservé.

Cette séparation des registres n’est pas décorative. Le point de code du TLV appartient au registre BGP-LS approprié ; les valeurs du statut de nœud appartiennent au registre BGP SPF. Les attribuer à une page IANA générale des paramètres BGP ferait perdre la précision qui permet de vérifier la sémantique exacte.

Les valeurs 3 à 254 demandent une autre discipline. Elles sont non attribuées. Le RFC prévoit qu’une valeur inconnue est propagée mais ignorée par le calcul SPF ; une mise en œuvre peut la journaliser pour analyse. Il serait donc incorrect d’inventer localement un sens de transit, de maintenance ou de priorité à partir de ces nombres et d’attendre que les autres participants au domaine SPF l’appliquent.

Les valeurs réservées 0 et 255 suivent un chemin différent. Pour le TLV d’état SPF du nœud, elles rendent le TLV mal formé ; la section 7.1 du RFC 9815 impose alors le traitement « comme retiré » pour la NLRI correspondante. Une valeur inconnue et une valeur réservée ne sont donc pas deux versions d’un même cas d’erreur. L’une est transmise puis ignorée par SPF ; l’autre déclenche le traitement d’une annonce mal formée.

L’éligibilité n’est pas la preuve d’un chemin

Le redémarrage hypothétique révèle surtout un piège de langage. « Le statut 2 a disparu, donc le nœud transporte du transit » est une conclusion trop forte. La formulation exacte est : la disparition du TLV retire implicitement l’ancien état et le nœud retrouve le statut par défaut qui l’autorise à participer au transit.

Entre autorisation et usage effectif s’interposent plusieurs décisions. La topologie détermine quels chemins existent. Les métriques influencent leur coût. Le calcul SPF détermine quels résultats sont retenus. L’état de transfert installé traduit ces résultats dans la fonction de commutation. Enfin, un test de trafic n’observe qu’un ensemble de flux choisi.

Cette dernière limite est particulièrement importante. La section 5.5.2 du RFC 9816, et non le RFC 9815, distingue la visibilité de la topologie obtenue à partir des annonces BGP-LS-SPF d’une vérification possible du chemin de données par un outil de gestion. Le texte laisse les algorithmes et les heuristiques de cette vérification hors de son périmètre.

Conséquence de méthode : un test négatif — aucun des flux définis n’a traversé le nœud — ne démontre pas une absence universelle de transit. Il établit seulement ce qui a été observé pour ces flux, pendant cette fenêtre et avec l’état alors en place. Pour vérifier l’intention non-transit, le signal le plus direct reste donc la présence correcte du statut 2, complétée, selon le besoin, par l’inspection du résultat SPF, de l’état installé et de tests ciblés.

Le vrai passage de relais est un passage de responsabilité

Le risque vient de l’usage que l’on fait d’un contrôle simple. Si la reprise s’arrête à « le service répond », personne n’a nécessairement vérifié que la contrainte négative a été régénérée. La responsabilité doit donc être nommée là où l’intention peut être préservée : lorsque le statut 2 est attendu, l’état annoncé après redémarrage doit être vérifié séparément. Une validation de chemin, si elle est ajoutée, confirme un comportement observable ; elle ne remplace pas la vérification du statut.

Ce découpage suit une discipline éditoriale utile proposée par Heng Lu : lire d’abord ce que le système exécute réellement plutôt que de confondre l’intention écrite avec son effet. Son texte sur la primauté du code effectivement exécuté n’est pas une autorité sur BGP SPF ; il sert ici de grille de lecture. Le même statut doit être accordé à son idée d’une spécification initiale minimale et vérifiable localement : une inspiration pour réduire les ambiguïtés de contrôle, pas une extension du RFC.

Dans ce cadre, la question d’exploitation devient nette : après chaque transition susceptible de reconstruire l’état annoncé, qui atteste le retour de la joignabilité, et qui atteste séparément la restauration de la contrainte non-transit ? Tant que ces deux réponses n’ont pas de propriétaire explicite, un contrôle positif peut finir par valider le mauvais fait.