Résumé

  • Le rôle documenté de Ketan Talaulikar dans les travaux collaboratifs de l'IETF fournit une voie d'accès au niveau personnel vers trois sujets opérationnels interconnectés: l'identité et les règles de chemin candidat d'une politique SR dans la RFC 9256, les descripteurs et les limites d'erreur des enregistrements topologiques BGP-LS dans la RFC 9552, et la visibilité OSPFv3 des localisateurs et capacités SRv6 dans la RFC 9513.
  • Les spécifications définissent différents types de preuves. Un tuple de politique identifie une politique prévue au niveau d'une tête de réseau; l'état du chemin candidat enregistre les alternatives utilisables; BGP-LS décrit des objets topologiques pour les consommateurs; et OSPFv3 expose des informations de routage sur SRv6. Aucun de ces enregistrements ne prouve à lui seul le chemin de paquet qu'une implémentation en cours a produit.
  • Le contrat opérationnel est donc stratifié: les normes définissent la sémantique, les implémentations les réalisent, les opérateurs choisissent la politique, le plan de contrôle publie les enregistrements actuels, et les observations de transfert montrent les résultats. Une automatisation fiable maintient le lien entre ces couches sans prétendre qu'une seule d'entre elles représente l'ensemble du réseau.

Un enregistrement au niveau personnel organisé autour de la signification opérationnelle

Le profil Datatracker IETF de Ketan Talaulikar documente son leadership dans le domaine du routage et son travail soutenu sur les protocoles de routage. Les trois normes examinées ici le mentionnent dans des rôles éditoriaux, établissant un lien clair au niveau personnel avec leurs sujets techniques. La RFC 9256 définit l'architecture de la politique de routage segmenté (Segment Routing Policy). La RFC 9552 définit comment BGP-LS distribue les informations d'état de lien et d'ingénierie de trafic.

La RFC 9513 définit les extensions OSPFv3 qui rendent visibles les informations sur les localisateurs et les capacités SRv6 dans le système de routage.

Cette attribution nécessite des limites précises. Chaque RFC est un travail collaboratif de l'IETF façonné par plusieurs auteurs ou éditeurs, les discussions en groupe de travail, l'examen, l'expérience de mise en œuvre et le processus de normalisation. Le document atteste de la participation documentée de Talaulikar. Il ne permet pas d'affirmer qu'il a inventé les mécanismes à lui seul, choisi la politique d'un opérateur, écrit une implémentation particulière ou contrôlé un déploiement. Il ne fournit pas non plus de base pour des affirmations concernant des clients, des incidents, des résultats commerciaux ou des améliorations mesurées.

Il s'agit d'un récit opérationnel, pas d'une biographie héroïque. L'automatisation ne peut agir de manière sûre que si elle est capable de déterminer sur quel objet elle agit, quel enregistrement est actuel, quelles alternatives sont valides et ce qui s'est passé lorsque l'entrée n'a pas pu être utilisée. Le bilan normatif attribué à Talaulikar est significatif ici car il relie la politique, la topologie et la capacité aux points où l'intention abstraite doit devenir un état de protocole.

Cinq couches qui ne doivent pas être confondues

La première couche est la norme. Une norme définit une sémantique partagée: comment une politique SR est identifiée, comment les chemins candidats s'y rapportent, comment les enregistrements BGP-LS décrivent la topologie ou comment OSPFv3 transporte les informations SRv6. Elle fournit un contrat entre des implémentations indépendantes. Elle n'instancie pas une politique dans un réseau particulier, ne choisit pas un objectif commercial et n'indique pas si un paquet est arrivé.

La deuxième couche est l'implémentation. Le logiciel traduit la spécification en analyseurs syntaxiques, structures de données, logique de sélection, interfaces de programmation et sortie opérationnelle. Une implémentation peut être conforme à une norme tout en différant sur les options prises en charge, la capacité, les diagnostics, le comportement des versions et les défauts. L'existence d'une RFC ne peut pas prouver qu'une version logicielle donnée prend en charge tous les mécanismes ou gère correctement toutes les limites.

La troisième couche est la politique de l'opérateur. Les opérateurs décident quelles couleurs ont une signification dans leur environnement, quels points d'extrémité importent, quels chemins candidats doivent exister, quelles préférences s'appliquent, quels consommateurs de topologie peuvent agir et comment les défaillances doivent être contenues. Ces décisions ne sont pas fournies par la norme. Ce sont des choix de gouvernance locaux exprimés par la configuration et l'automatisation.

La quatrième couche est l'état actuel du plan de contrôle. Cela inclut la politique SR et les chemins candidats actuellement connus au niveau d'une tête de réseau, les enregistrements BGP-LS actuellement disponibles pour un consommateur et les annonces OSPFv3 actuellement installées dans la base de données d'état de lien. Ces enregistrements sont sensibles au temps. Un identifiant correctement défini associé à un état obsolète peut encore orienter l'automatisation dans la mauvaise direction.

La cinquième couche est le transfert observé. C'est la preuve de ce que le système en cours a fait: quels prochains sauts et instructions de segment ont été programmés, quels paquets ont suivi quel chemin, et comment le comportement a changé après une mise à jour ou une erreur. L'observation du transfert ne remplace pas les normes ou les enregistrements; elle vérifie si la chaîne prévue a atteint l'exécution. Un système fiable préserve la distinction entre les cinq couches tout en conservant une corrélation suffisante pour passer de l'une à l'autre.

La RFC 9256 commence par une identité de politique en trois parties

La RFC 9256 identifie une politique SR au moyen d'un tuple composé de la tête de réseau, de la couleur et du point d'extrémité. La compacité de ce tuple est importante. Elle transforme une expression telle que « utiliser le chemin à faible latence » en un objet dont la portée peut être déterminée. La politique n'est pas simplement une propriété souhaitée. C'est une politique au niveau d'une tête de réseau particulière, associée à une couleur particulière, vers un point d'extrémité particulier.

Chaque composant empêche un type différent d'ambiguïté. La tête de réseau identifie où la politique est instanciée et où le pilotage vers celle-ci se produit. La couleur fournit une association entre le trafic ou les informations de routage et un objectif de politique dans un contexte convenu. Le point d'extrémité ancre la politique à la destination vers laquelle la liste de segments est destinée à acheminer le trafic. Supprimer un composant risque de fusionner des objets qui peuvent avoir des propriétaires, des entrées ou des effets opérationnels différents.

Le tuple est une identité, pas une description complète du comportement. Il ne révèle pas quel chemin candidat est actif, quelle liste de segments a été programmée, si la topologie utilisée pour le calcul est à jour ou si le transfert correspond au chemin choisi. Ce sont des enregistrements connexes. Traiter le tuple comme une preuve du système entier confondrait l'identité avec l'état et l'état avec le résultat.

L'unicité limitée est importante ici. L'automatisation ne doit pas créer deux objets de politique impossibles à distinguer au même niveau et se fier ensuite à un départage non documenté. Elle doit également éviter de supposer qu'une couleur a une signification identique dans chaque tête de réseau ou dans chaque environnement administratif. L'identité est utile parce que ses parties sont explicites et que leur portée peut être enregistrée.

La RFC 9256 fournit l'architecture partagée; les implémentations et les opérateurs doivent encore préserver cette identité avec précision au travers de la configuration, de la distribution, de la sélection et de l'observation.

La tête de réseau transforme l'identité en responsabilité locale

La tête de réseau est plus qu'une étiquette dans la clé de politique. Elle marque le point auquel une politique SR devient un objet local actionnable. Ce nœud maintient la politique, résout les chemins candidats en fonction des informations dont il dispose, installe les listes de segments utilisables et dirige le trafic éligible. D'autres nœuds peuvent transmettre les instructions résultantes, mais ils n'ont pas pour autant la même décision de politique.

Cette responsabilité locale empêche que l'expression « le réseau a une politique » ne devienne trop vague pour être auditée. Deux têtes de réseau peuvent utiliser la même couleur et le même point d'extrémité tout en ayant des vues topologiques différentes, en recevant des chemins candidats différents, en prenant en charge des limites de liste de segments différentes ou en appliquant des contrôles opérateur différents. Leurs identités de politique restent distinctes car la tête de réseau fait partie du tuple. Un système d'automatisation doit donc demander non seulement quelle politique est prévue, mais où elle est censée exister.

La distinction se prolonge jusqu'aux preuves de transfert. Un contrôleur peut signaler qu'une politique a été livrée. La tête de réseau peut signaler qu'un candidat est devenu actif. Le plan de transfert peut montrer une liste de segments programmée. L'observation du trafic peut montrer si les paquets l'ont effectivement suivie. Ce sont des éléments de preuve successifs, pas des confirmations interchangeables. En mettant la tête de réseau dans l'identité, la RFC 9256 donne aux opérateurs un point stable autour duquel les corréler sans attribuer une autorité globale à un seul enregistrement.

La couleur crée une association, pas une instruction universelle

La couleur est souvent la partie la plus tentante à surinterpréter du tuple. Elle peut associer une route ou une classe de trafic à une caractéristique de politique souhaitée, mais la valeur numérique ne porte pas en elle-même une signification universelle en langage naturel. Sa signification opérationnelle découle du contexte de politique et d'administration dans lequel elle est utilisée. L'interprétation d'un environnement ne peut pas être importée en toute sécurité dans un autre simplement parce que le numéro correspond.

Cela fait de la couleur une surface de gouvernance. Les opérateurs ont besoin d'un enregistrement des valeurs en cours d'utilisation, de leur signification, des politiques qu'elles sélectionnent, des personnes autorisées à modifier la correspondance et de la manière dont une correspondance modifiée est propagée. L'enregistrement doit rendre visibles les collisions et les associations obsolètes. Une valeur unique mais incorrectement mappée n'est pas sûre; une valeur exacte mais à portée ambiguë n'est pas suffisante.

L'automatisation doit donc traiter la couleur comme une entrée parmi d'autres dans une décision, et non comme un ordre qui prévaut sur toutes les autres preuves. Si la politique est absente, inactive ou incompatible avec l'état actuel, un système responsable doit avoir une réponse limitée: refuser l'action de pilotage, utiliser une alternative délibérément définie ou lever une exception visible. Interpréter silencieusement la couleur comme « faire quelque chose d'assez proche » détruirait l'association précise que le tuple a été conçu pour fournir.

Le point d'extrémité ancre l'intention à une destination de transfert

Le composant de point d'extrémité donne à la politique SR un contexte de destination. Une couleur sans point d'extrémité peut exprimer un objectif large, mais elle n'identifie pas la destination vers laquelle une tête de réseau doit construire ou sélectionner la politique. Le point d'extrémité comble cette lacune. Ensemble, la tête de réseau, la couleur et le point d'extrémité identifient où la politique commence, quelle association elle représente et vers où elle est dirigée.

Un point d'extrémité reste une valeur du plan de contrôle, pas une preuve d'accessibilité. La topologie pertinente peut changer. Un chemin candidat peut devenir invalide. Une liste de segments peut ne plus se résoudre comme prévu. Une implémentation peut être incapable de programmer les instructions sélectionnées. Le point d'extrémité reste une partie de l'identité de la politique à travers ces conditions, tandis que l'état opérationnel de la politique change autour d'elle.

Cette persistance est utile pour une sémantique de changement enregistrée. Un opérateur peut distinguer « la même politique est devenue inactive » de « une politique différente l'a remplacée ». L'automatisation peut conserver un historique des événements indexé sur le tuple: création, ajout de candidat, changement de préférence, transition de chemin actif, retrait et récupération. Sans identité stable, ces événements peuvent être confondus avec des instantanés sans rapport, rendant la continuité plus difficile à établir.

Les chemins candidats rendent les alternatives explicites

Une politique SR peut avoir plusieurs chemins candidats. Cette conception transforme les alternatives en objets de plan de contrôle nommés, plutôt que de les enfouir dans un calcul opaque. Au sein de l'architecture, un chemin candidat porte sa propre identité par l'origine du protocole, l'émetteur et le discriminateur. Ces éléments conservent la provenance du candidat et le distinguent des autres candidats associés à la même politique.

La provenance est importante car les alternatives peuvent arriver par différents mécanismes ou décideurs. Un candidat configuré localement et un candidat fourni par un autre composant de contrôle peuvent décrire des chemins vers le même point d'extrémité, mais ils ne sont pas opérationnellement identiques. Ils peuvent avoir une autorité, un calendrier de mise à jour, des contraintes et un comportement de retour en arrière différents. Si l'automatisation supprime leur origine et ne conserve que la liste de segments résultante, elle perd les preuves nécessaires pour expliquer une sélection ou un retrait ultérieur.

Un chemin candidat peut conduire à une ou plusieurs listes de segments qui expriment des instructions de transfert utilisables. L'architecture sépare le candidat du résultat actif car un candidat peut exister sans être utilisable à un moment donné. La résolution peut dépendre des informations actuelles et du comportement pris en charge. Les listes de segments peuvent également avoir une pondération au sein du traitement de transfert du candidat, mais une pondération configurée ou annoncée reste une instruction pour une implémentation, pas une mesure de la distribution réelle du trafic qui s'est produite.

Les règles de sélection transforment les alternatives en état actif

Les chemins candidats ont besoin d'une relation déterministe avec l'état actif de la politique. La RFC 9256 utilise la préférence et la validité pour structurer cette relation: un candidat éligible doit être utilisable, et la préférence détermine quelle alternative valide est sélectionnée. Le point opérationnel crucial n'est pas l'existence d'un numéro de préférence à lui seul. C'est la chaîne enregistrée allant de l'identité du candidat, à travers la validité, jusqu'au chemin que la tête de réseau a effectivement rendu actif.

La validité dépend du temps. Un candidat qui s'est résolu hier peut échouer aujourd'hui parce que ses entrées ont changé. Une liste de segments peut devenir indisponible, une capacité requise peut ne plus être visible, ou la topologie utilisée pour dériver le chemin peut être remplacée. Le tuple de politique peut rester constant tandis que le candidat sélectionné change. L'automatisation doit préserver à la fois l'identité stable et la transition d'état, y compris la raison pour laquelle l'ancien candidat actif a cessé de se qualifier.

La préférence ne doit pas être confondue avec la qualité observée. Un candidat à préférence plus élevée représente un ordonnancement configuré ou signalé. Il ne prouve pas un délai plus faible, une capacité plus grande, une sécurité améliorée ou tout autre résultat mesuré. Ces propriétés nécessitent des preuves distinctes et, le cas échéant, une observation actuelle. Le mécanisme de sélection répond à « quel candidat valide doit être actif selon ces règles », et non à « quel chemin est objectivement le meilleur dans toutes les dimensions ».

Le cas d'absence de candidat valide est particulièrement important. Une implémentation ne doit pas le masquer derrière l'existence continue de l'objet de politique. Une politique peut être connue mais inactive. Cet état doit être visible pour la logique de pilotage, la surveillance et le contrôle des modifications. Un repli limité peut être délibérément défini par l'opérateur, mais il ne doit pas être inventé implicitement par une couche d'automatisation. L'inactivité explicite est plus sûre qu'une équivalence devinée, car elle préserve la différence entre un chemin prévu et un chemin disponible.

Le pilotage reste une décision opérationnelle distincte

La sélection de la politique et le pilotage du trafic sont liés mais distincts. La logique de chemin candidat détermine le traitement de transfert actif pour une politique SR identifiée. Le pilotage détermine quel trafic est placé dans cette politique. Une politique active valide peut exister sans recevoir un flux de trafic particulier, et une association de pilotage peut exister alors que sa politique prévue est inactive. Combiner les deux en un seul indicateur vert dissimule des états de défaillance importants.

Le pilotage relève également de la politique de l'opérateur plutôt que de la norme seule. La RFC 9256 fournit des mécanismes architecturaux et des règles, mais un opérateur décide quel trafic doit utiliser quelle politique et ce qui doit se passer si la politique est indisponible. Un repli vers un transfert de destination ordinaire, une attente ou un autre chemin limité peut être approprié selon les contextes. L'exigence importante est que le choix soit délibéré et observable.

C'est là que les slogans sur le « réseau axé sur l'intention » peuvent dépasser les preuves. L'intention ne devient opérationnelle qu'à travers des objets identifiés, un état candidat actuel, un pilotage explicite, la prise en charge de l'implémentation et le transfert observé. Le travail attribué à Talaulikar sur l'architecture de la politique est utile précisément parce qu'il expose ces contrats intermédiaires. Il ne promet pas que les contrats soient toujours satisfaits; il donne aux systèmes indépendants un moyen commun de les représenter et de les inspecter.

La RFC 9552 rend la topologie consommable sous forme d'enregistrements

La RFC 9552 aborde un problème différent mais connexe: la distribution d'informations d'état de lien et d'ingénierie de trafic via BGP-LS afin que des applications externes puissent consommer une vue topologique. BGP-LS ne remplace pas le protocole d'état de lien sous-jacent, ne choisit pas une politique SR et ne transfère pas les paquets. Il transporte des enregistrements dérivés des informations de routage à travers une interface définie.

Cette distinction est importante pour l'automatisation. Un composant de calcul de chemin peut avoir besoin d'une vue des nœuds, des liaisons et des préfixes au-delà d'un seul dispositif. BGP-LS fournit une représentation normalisée par le biais d'informations d'accessibilité de couche réseau et d'attributs associés. La représentation permet à une application de distinguer les objets topologiques et d'interpréter leurs propriétés sans analyser des sorties de dispositif non structurées ou supposer un format propriétaire d'un fournisseur.

La base de données résultante est une vue dérivée. Elle dépend des informations collectées par le système d'origine, du codage de ces informations, de la distribution BGP, du comportement de sélection et du traitement du consommateur. Un enregistrement BGP-LS peut être correctement codé mais obsolète par rapport à un événement topologique récent. Il peut être actuel mais incomplet pour les contraintes d'une application. Il peut décrire une connaissance du plan de contrôle sans prouver que les tables de transfert y correspondent.

Les descripteurs donnent aux objets topologiques des identités stables

Une application topologique ne peut pas raisonner en toute sécurité sur « une liaison » ou « un nœud » dans l'abstrait. Elle a besoin de suffisamment de descripteurs pour identifier l'objet spécifique dans le contexte de routage pertinent. La RFC 9552 organise les enregistrements BGP-LS autour de ce besoin. Les descripteurs de nœud identifient un nœud dans son contexte de protocole et de domaine. Les enregistrements de liaison relient les descriptions de nœuds locaux et distants avec des descripteurs spécifiques à la liaison. Les enregistrements de préfixe attachent des informations d'accessibilité au contexte d'origine approprié.

Les descripteurs font plus que rendre un enregistrement lisible. Ils déterminent si deux annonces se réfèrent au même objet topologique ou à des objets différents. Si une implémentation omet une partie requise de l'identité, les enregistrements peuvent entrer en collision. Si elle ajoute une valeur instable à l'identité, un même objet peut apparaître comme un flux d'objets sans rapport. L'un ou l'autre échec peut induire un consommateur en erreur avant même que tout calcul de chemin ne commence.

L'étendue des identifiants est centrale. Un numéro de système autonome, un identifiant de protocole, un identifiant de domaine de routage, un identifiant de nœud, une adresse d'interface ou un préfixe a une signification dans des limites particulières. Aucun champ unique n'identifie nécessairement l'objet entier de manière globale. La description composite fournit le contexte nécessaire. L'automatisation doit conserver ce contexte plutôt que d'aplatir chaque nœud ou liaison en une étiquette pratique qui peut ne pas être unique.

Des enregistrements précis nécessitent également une sémantique de changement. Une liaison retirée n'est pas la même chose qu'une liaison dont les attributs ont changé. Un nœud vu à travers un contexte de routage différent n'est pas automatiquement un doublon. Une mise à jour de préfixe doit rester attachée à ses descripteurs d'origine. Les consommateurs doivent pouvoir expliquer si un objet a été ajouté, modifié, remplacé ou supprimé. Une identité stable associée à des transitions enregistrées transforme un flux topologique en une entrée vérifiable plutôt qu'en une séquence d'instantanés déconnectés.

L'ordre est une règle d'interopérabilité, pas une mise en forme cosmétique

La RFC 9552 fait de l'ordre une partie du contrat d'enregistrement. Les éléments de descripteur ont un agencement défini, et l'ordre canonique empêche que des informations équivalentes soient sérialisées en objets apparemment différents simplement parce que les champs sont arrivés dans une séquence différente. Ceci est particulièrement important lorsque les informations d'accessibilité de couche réseau codées participent à l'identité et à la comparaison des routes.

Sans ordre canonique, deux locuteurs pourraient décrire le même nœud, la même liaison ou le même préfixe avec les mêmes valeurs de descripteur, mais produire des séquences d'octets différentes. Un système récepteur pourrait les conserver toutes les deux en tant que routes distinctes, alterner entre elles ou forcer un consommateur à deviner s'il s'agit de doublons. La topologie sous-jacente n'aurait pas changé, mais la représentation pourrait générer du bruit. L'ordre supprime un degré de liberté qui n'a aucune valeur opérationnelle.

La règle ne garantit toujours pas l'exactitude sémantique. Un enregistrement parfaitement ordonné peut contenir le mauvais identifiant ou des informations topologiques obsolètes. Inversement, un analyseur qui détecte une entrée non canonique doit la traiter dans les limites de compatibilité et d'erreur de la norme, plutôt que d'accepter silencieusement toutes les permutations. L'ordre fournit une syntaxe déterministe. L'exactitude dépend de la source et de l'état actuel du plan de contrôle, tandis que l'utilité dépend de l'interprétation du consommateur et des preuves de transfert par rapport auxquelles ses décisions sont vérifiées.

La compatibilité doit être utile et limitée

Les normes de routage évoluent dans des réseaux où les implémentations ne changent pas toutes en même temps. La RFC 9552 doit donc traiter de la compatibilité avec le comportement antérieur de BGP-LS tout en resserrant le contrat d'enregistrement actuel. La compatibilité est précieuse lorsqu'elle permet une transition contrôlée entre des représentations connues. Elle devient dangereuse lorsqu'elle est interprétée comme une autorisation d'accepter tout codage ambigu et de deviner l'objet topologique prévu.

Une approche limitée commence par séparer les variations historiques reconnues des données malformées ou sémantiquement conflictuelles. Un récepteur peut documenter les formes qu'il accepte, comment il les normalise et quelles informations peuvent être perdues. Il doit conserver l'origine de l'enregistrement et indiquer quand la gestion de la compatibilité a été invoquée. Un consommateur ne doit pas voir un objet normalisé comme s'il était arrivé dans la forme canonique actuelle alors que cette différence pourrait affecter la confiance.

Tout cela ne signifie pas qu'une RFC dicte le plan de mise à niveau d'un produit particulier. La norme définit un comportement interopérable et des limites. Les implémentations choisissent des diagnostics concrets et une prise en charge des versions. Les opérateurs décident de la séquence de déploiement et de la tolérance au risque. Les enregistrements BGP-LS actuels montrent ce qui a été reçu, et le comportement en aval montre comment les consommateurs ont agi. Garder ces couches séparées permet à la compatibilité de préserver la continuité sans laisser l'ambiguïté d'hier devenir la source permanente d'erreurs topologiques de demain.

La gestion des erreurs convertit les entrées incorrectes en état observable

L'automatisation de la topologie est exposée à des entrées qui peuvent être incomplètes, malformées, incohérentes, non prises en charge ou obsolètes. Les limites de gestion des erreurs de la RFC 9552 sont importantes car un consommateur de topologie ne doit pas transformer silencieusement des entrées inutilisables en état faisant autorité. Une longueur de descripteur malformée, un contexte d'identité manquant, une description conflictuelle ou un élément non pris en charge ne sont pas équivalents à un enregistrement topologique sain et actuel.

La réponse précise du protocole dépend de la classe d'erreur et des procédures BGP applicables, tandis que la réponse opérationnelle visible dépend également de l'implémentation. C'est une autre raison de ne pas réduire une norme à une revendication de produit. La norme peut définir quand une information ne peut pas être traitée en toute sécurité. Une implémentation doit appliquer cette règle et exposer des diagnostics utiles. Un opérateur doit décider si la perte d'un enregistrement invalide un calcul ou déclenche une alternative limitée.

L'observabilité doit conserver plusieurs faits: quel pair ou source a fourni l'enregistrement, quel objet topologique a été affecté, si la route a été rejetée ou retirée, si seul un attribut était inutilisable, quand l'événement s'est produit et quelles applications ont consommé la version précédente. Un compteur générique « erreur BGP-LS » est rarement suffisant pour déterminer l'impact. L'identité de l'objet et la transition d'état font partie des preuves.

La RFC 9513 expose les localisateurs et les capacités SRv6 via OSPFv3

La RFC 9513 ramène l'analyse au domaine de routage d'origine. Elle définit les extensions OSPFv3 pour SRv6, y compris l'annonce d'informations sur les capacités et les localisateurs SRv6. Le but est la visibilité: les systèmes de routage ont besoin d'enregistrements de protocole qui indiquent quelles fonctions SRv6 ou informations de localisateur pertinentes un nœud rend disponibles dans le contexte OSPFv3.

Un localisateur fournit une structure de routage pour les identifiants SRv6. L'annonce des informations de localisateur permet à d'autres composants de routage de construire une vue actuelle de l'endroit où cette structure est accessible et comment elle se rapporte au système annonceur. Les informations de capacité indiquent aux pairs et aux consommateurs qu'un comportement particulier lié à SRv6 est représenté comme pris en charge. Ensemble, ces enregistrements peuvent devenir des entrées pour le calcul, la validation et la résolution de politique.

Les annonces restent des informations d'état de lien limitées. Elles sont générées, diffusées, installées, mises à jour et retirées selon les mécanismes et les limites du protocole de routage. L'automatisation doit savoir quel routeur annonceur et quel contexte de zone ont fourni un enregistrement, quand il est entré dans la base de données et si une instance plus récente l'a remplacé. Un inventaire copié détaché de ce contexte est une preuve plus faible que l'enregistrement d'état de lien actuel.

La visibilité du localisateur est nécessaire mais ne constitue pas une preuve de transfert

Une annonce de localisateur SRv6 peut indiquer à un système de routage qu'un localisateur est présent dans la vue actuelle du protocole. Elle ne peut pas à elle seule prouver que chaque comportement associé est programmé, qu'un paquet peut traverser le chemin complet prévu ou qu'une politique SR utilisant les informations est active. La visibilité est une condition préalable à un contrôle informé, pas un substitut aux preuves d'exécution.

La même prudence s'applique aux capacités. Une annonce de capacité représente un état de protocole fourni par un nœud. Elle ne mesure pas la capacité, ne valide pas chaque option et ne certifie pas toutes les combinaisons avec les implémentations voisines. Les opérateurs doivent comparer la capacité annoncée avec l'intention configurée, la prise en charge de l'implémentation, la programmation de transfert et l'observation contrôlée. Les divergences doivent être visibles plutôt que résolues par des suppositions optimistes.

L'obsolescence est une limite importante. Si un localisateur ou une capacité est retiré ou remplacé, un calcul de politique basé sur l'ancien enregistrement peut ne plus être sûr. Les consommateurs ont besoin d'une gestion des mises à jour et des retraits qui atteigne les calculs mis en cache et la validité des chemins candidats. Il ne suffit pas de mettre à jour la base de données topologique tout en laissant les chemins précédemment dérivés intacts sans révision.

Sources

Profil Datatracker IETF de Ketan Talaulikar

RFC 9256: Architecture de la politique de routage segmenté

RFC 9552: Distribution d'informations d'état de lien et d'ingénierie de trafic via BGP

RFC 9513: Extensions OSPFv3 pour le routage segmenté sur IPv6