Résumé

  • Pour les types de segment I, J et K, RFC 9831 autorise une valeur SRv6 SID nulle lorsque le contrôleur veut indiquer un comportement de terminaison ou une structure sans fixer la SID elle-même.
  • Le drapeau S atteste la présence matérielle du champ, pas celle d’une valeur exécutable. Le headend doit encore résoudre le nœud ou l’adjacence dans son propre contexte SR et peut constater une absence ou une contradiction.
  • La preuve utile conserve donc séparément drapeaux, octets reçus, référence topologique, valeur résolue, raison de vérification, chemin actif, état programmé et observation des paquets.

Un zéro qui ne veut pas dire « rien reçu »

Les protocoles utilisent souvent zéro comme valeur par défaut. L’exploitation finit alors par ranger tous les zéros dans une même case : vide, absent, inconnu. RFC 9831 impose une lecture plus attentive.

Pour les types I, J et K, le drapeau S indique que le champ SRv6 SID de seize octets est présent. Ce champ peut contenir l’adresse IPv6 nulle si le contrôleur souhaite annoncer un comportement SRv6 ou une structure de SID sans choisir la SID concrète. Les octets ont donc une fonction positive : ils montrent que l’émetteur a retenu la forme « champ présent, résolution déléguée ».

Cette forme n’est pas équivalente à l’absence du champ. Quand le champ SID n’existe pas, le bloc décrivant comportement et structure ne peut pas être ajouté. Avec une SID nulle présente, ce bloc peut accompagner la référence. Une SID non nulle constitue encore un troisième état : l’émetteur fournit alors une valeur que le récepteur pourra comparer à son propre résultat.

Une base d’observation qui transforme les deux premiers cas en null efface la délégation. Une interface qui affiche seulement « champ SID : oui » transforme la délégation en affirmation. Le reçu minimal doit garder S, B, les 128 bits originaux, le type du segment et les adresses ou identifiants qui donnent leur contexte.

Le chemin est explicite, sa matérialisation peut rester locale

RFC 9831 appelle Segment List sub-TLV la représentation d’un chemin explicite vers le point terminal. Chaque Segment sub-TLV en décrit un élément. Le mot « explicite » porte sur l’ordre et sur la nature des étapes ; il n’oblige pas chaque étape à arriver sous la forme finale d’une étiquette ou d’une SID.

Les types C et D désignent des nœuds IPv4 ou IPv6 à résoudre en étiquette SR-MPLS. Les types E à H décrivent des adjacences au moyen d’adresses de nœuds, d’adresses de liens et d’identifiants d’interface. Les types I à K étendent cette logique aux nœuds et adjacences SRv6. RFC 9256 demande au headend de résoudre ces références vers une étiquette ou une SID.

Un contrôleur peut ainsi fixer « quel nœud » ou « quel lien » sans figer dans le message l’allocation locale du récepteur. L’indirection protège une part d’autonomie opérationnelle : une modification locale n’oblige pas nécessairement à réécrire toutes les intentions. Mais elle rend la connaissance du headend partie intégrante de l’exécution.

Deux headends recevant exactement le même segment peuvent produire deux résultats si leurs informations SR diffèrent. L’un trouve une SID actuelle ; l’autre ne reconnaît plus l’interface ou voit une autre correspondance. Archiver le message BGP seul prouve une réception identique, pas une résolution identique. Il faut aussi garder la provenance, la version et l’heure du contexte local.

A, S, B et V ne répondent pas à la même question

Le drapeau A indique que le champ SR Algorithm a un sens pour les types concernés. Quand A n’est pas positionné, l’émetteur doit écrire zéro et le récepteur doit ignorer cette case. Ce zéro ne délègue aucun choix ; il signifie qu’aucun algorithme n’est affirmé dans ce champ.

S annonce la présence d’un champ SID. Il ne dit ni si cette valeur est nulle, ni si elle existe dans les informations du headend, ni si elle correspond au nœud ou au lien décrit.

B annonce le bloc de comportement de terminaison et de structure SRv6 pour les types B, I, J et K. Ce bloc ne peut exister sans champ SID. Il peut pourtant accompagner une SID nulle, et donc préciser l’attente appliquée à une valeur que le headend devra encore résoudre.

V demande à SRPM d’effectuer la vérification de SID prévue par RFC 9256. Il ne certifie pas son succès. Traduire V=1 par « vérifié » revient à confondre un ordre avec son compte rendu.

Ces quatre bits répartissent quatre responsabilités : donner du sens à l’algorithme, matérialiser un emplacement, préciser un comportement, déclencher un contrôle. Un voyant unique intitulé « segment valide » ne peut pas les représenter sans perdre l’auteur de chaque décision.

Résoudre, trouver et faire correspondre sont trois opérations

RFC 9256 présente la SR-DB comme un ensemble conceptuel d’informations utiles au calcul et à la validation. Une mise en œuvre n’est pas tenue de créer une base littérale portant ce nom. En revanche, le headend a besoin d’éléments locaux permettant de rattacher un préfixe, un nœud, une interface ou une paire d’adresses à une SID actuelle.

La vérification échoue si le headend ne trouve pas une SID fournie dans ses informations SR. Elle échoue aussi lorsque le contexte d’un type C à K conduit à une autre SID que celle fournie. Enfin, un segment non initial peut être impossible à résoudre en étiquette ou SID. Ces causes ont des conséquences différentes : donnée locale manquante, divergence entre émetteur et récepteur, ou trou au milieu du chemin ordonné.

Dans un environnement multidomaine, la limite est explicite. Le headend peut ne pas savoir vérifier l’accessibilité de SID éloignées. RFC 9256 demande alors d’utiliser les types A ou B, qui portent directement les SID concernées, tout en exigeant que la première SID reste toujours accessible. L’indirection contextuelle s’arrête là où la connaissance vérifiable s’arrête.

Le récepteur n’est donc pas un simple décodeur. Il choisit les champs applicables, consulte son état, complète éventuellement la valeur, compare les deux versions et juge la liste. Protéger la session BGP peut authentifier le pair ; cela ne rend pas exactes ses adresses de nœuds, ses interfaces, son comportement souhaité ou sa vision de la topologie.

Une structure correcte peut former une liste invalide

Les longueurs définies par RFC 9831 varient selon la présence de la SID et du bloc comportement/structure. Les vérifier empêche de lire les octets suivants sous la mauvaise étiquette. C’est une condition de sûreté syntaxique, pas une preuve d’exécution.

Le type indique si les octets représentent un nœud, une adjacence, une étiquette ou une SID. Les drapeaux indiquent quels champs comptent. SRPM doit encore valider la liste dans son ensemble. RFC 9256 rend invalide une liste qui mélange des segments SR-MPLS et SRv6, même si chaque sub-TLV, pris séparément, possède une longueur parfaite.

RFC 9830 place déjà la validation sémantique du chemin explicite hors de BGP. RFC 9831 précise que ses nouveaux types ne modifient ni les opérations SR Policy ni la gestion des fautes. L’article précédent sur RFC 9830 séparait le transport BGP de l’autorité d’installer. Ici, la frontière est antérieure : avant même de comparer les candidats, un champ reçu peut être une demande de résolution et non une instruction terminée.

Le registre public ne remplace pas le routeur

IANA attribue les valeurs des sub-TLV pour les types C à H et I à K, ainsi que les bits A et S. Cette coordination empêche deux produits de donner des structures incompatibles au même code. Elle ne crée ni la topologie, ni la SID locale, ni la capacité d’installation.

La présence d’un code enregistré ne prouve pas qu’un routeur prend en charge chaque type, que ses données SR sont fraîches, qu’un identifiant d’interface désigne encore le bon lien, ou que la valeur résolue a atteint le plan de transfert. Le statut Experimental de RFC 9831 décrit de même une spécification ouverte à l’implémentation et à l’évaluation, pas un inventaire du terrain.

Il faut donc définir les mots des écrans d’exploitation. « Pris en charge » peut signifier que le parseur reconnaît Type J. « Résolu » signifie qu’un contexte local a produit une SID. « Vérifié » signifie que les éléments attendus concordent. « Actif » concerne le choix du candidat. « Installé » concerne le plan de transfert. « Observé » exige un paquet contrôlé. Aucun registre ne fusionne ces reçus.

Conserver les deux côtés de la décision

Le reçu du contrôleur doit contenir l’intention, l’ordre des segments, le type, les références de nœud ou de lien, A/S/B/V, les longueurs, les valeurs brutes, la version de configuration et l’heure. Il doit nommer le cas : SID non nulle fournie, SID nulle utilisée pour déléguer, ou champ omis.

Le reçu de résolution ajoute les sources et la version des informations SR, la valeur trouvée, l’éventuelle ambiguïté et l’heure. Le reçu de vérification garde la concordance, l’échec de recherche, le mélange technologique et le motif de rejet. Viennent ensuite, sans raccourci, validité du candidat, sélection active, programmation, paquet et résultat de service.

Cette séparation permet d’envoyer l’incident au bon propriétaire. Une référence déléguée sans correspondance locale n’est pas une « mauvaise SID envoyée ». Une SID non nulle qui contredit le contexte n’est pas un simple chemin indisponible. Une programmation refusée après résolution correcte n’est pas la faute du résolveur.

Sources