Résumé

  • RFC 9992 normalise la structure des KV TIE de RIFT ; il n’élève pas n’importe quelle paire clé-valeur au rang d’information de topologie pour les calculs distribués de RIFT.
  • Relayer, viser un groupe de nœuds, choisir une valeur concurrente et programmer le forwarding sont des actes distincts, avec des preuves différentes.
  • Une clé enregistrée ou gagnante ne devient sûre qu’après une sémantique documentée, une origine autorisée, une admission locale et une vérification du système réellement exécuté.

RFC 9992 autorise des valeurs KV pour des usages très variés. C’est précisément pourquoi il encadre le nom de la clé et avertit de ne pas employer ce canal pour les informations de topologie dont RIFT a besoin pour ses propres calculs distribués. Course de convergence, oscillation et comportement sous-optimal ne sont pas des défauts de grammaire ; ce sont les effets d’une responsabilité déplacée.

La structure comprend un Key Type, un Key Identifier et des valeurs. Les zéros interdits doivent être rejetés et journalisés. Les espaces Experimental, Well-Known et OUI permettent d’organiser l’extension ; les sous-types évitent de faire coïncider des sens différents. Un format correct établit donc une compatibilité de représentation. Il ne prouve ni la finalité de la charge, ni l’autorité de son origine, ni la décision locale qui pourrait en découler.

Le protocole de base RFC 9692 permet qu’un nœud incompétent pour une KV TIE inconnue la relaie normalement. Cette propriété protège le déploiement progressif. Elle interdit aussi de lire une trace de diffusion comme un registre d’adhésion : l’équipement a peut-être transmis des octets sans les comprendre ; un suivant les a peut-être compris sans les accepter ; un troisième a pu les accepter sans toucher à une route.

Key Target ne ferme pas ce fossé. C’est une indication optionnelle, seulement southbound, de l’audience voulue. Les nœuds qui ne savent pas l’interpréter continuent la diffusion appropriée. Le groupe visé n’est donc ni une preuve de capacité ni un mandat d’exécution.

La frontière devient concrète lorsque deux voisins northbound offrent la même clé avec des valeurs différentes. Une sélection par System ID supérieur peut donner une réponse déterministe. RFC 9992 recommande que les valeurs soient déterminées de façon cohérente, car une situation de split brain peut sinon produire un effet inattendu. Le vainqueur rend le keystore utilisable ; il ne prouve pas que la valeur est récente, vraie ou appropriée. Le rapport d’incident doit conserver le perdant, les identifiants, les durées de vie, la cible et le hash des valeurs.

L’IANA gère un registre de sous-types Well-Known et RFC 9992 impose l’Expert Review. Le relecteur exige une sémantique et, si nécessaire, un modèle Thrift normatif. Cette discipline empêche une collision de noms. Elle ne délègue pas au registre la politique d’un opérateur, le changement d’un contrôleur ou l’acceptation d’un risque local.

RFC 9719 aide à gérer RIFT, mais une configuration voulue, une TIE observée, une valeur retenue, une RIB, une FIB et un paquet reçu restent six observations. Selon Heng Lu, c’est une séparation de couches de réalité : la spécification commune doit rester minimale, et la décision future doit rester près de l’acteur qui peut la vérifier et l’assumer.