Résumé

  • L'IETF Datatracker associe actuellement Rob Shakir à neuf RFC. Plusieurs portent sur les exigences de Segment Routing, ses cas d'usage de résilience, son architecture, son fonctionnement sur MPLS et ses extensions OSPF. Il s'agit d'un historique de coauteur, pas de la preuve qu'il aurait inventé seul ces mécanismes. [1] [2] [3] [4] [5] [6]
  • Les documents OpenConfig sur les instances réseau et la redistribution des routes abordent un autre problème : comment exprimer des tables, des services et des politiques sur des équipements dont l'organisation interne varie selon le fournisseur. La neutralité du modèle ne supprime pas ces différences ; elle donne un langage commun pour les exposer. [7] [8] [9]
  • Une règle de prudence relie les deux ensembles. OpenConfig indique qu'en l'absence d'une politique d'importation et d'une politique par défaut, aucune route ne devrait être redistribuée. RFC 8402 impose aussi des filtres aux limites d'un domaine Segment Routing. La description partagée sert donc autant à interdire un passage non autorisé qu'à activer une fonction. [4] [8]
  • Plusieurs brouillons liés aux premiers travaux de Shakir sont expirés. Un modèle YANG BGP actif en 2026 continue sous un autre groupe d'auteurs. Cette évolution ne permet pas d'affirmer que tout le texte ancien a survécu ; elle montre que le problème et son historique peuvent être repris par d'autres. [1] [9] [10] [11] [12]

Un vocabulaire commun pour des machines qui restent différentes

BGP est le protocole par lequel des réseaux autonomes échangent des informations de joignabilité. Un routeur apprend des chemins, applique la politique de son opérateur, puis décide lesquels il utilisera ou annoncera. Dans une grande infrastructure, cette activité ne se résume pas à une liste de destinations. Elle comprend des voisins BGP, des règles d'importation et d'exportation, plusieurs tables, des services séparés et un état opérationnel qui change en permanence.

Les fournisseurs n'organisent pas toujours ces éléments de la même façon. Un équipement peut maintenir une table par protocole ; un autre peut faire converger plusieurs protocoles dans une table commune. Une plateforme place un paramètre sous l'interface physique ; une autre l'attache à un contexte virtuel. Ces choix sont légitimes tant que les opérateurs les comprennent. Ils deviennent difficiles à gérer lorsqu'un même outil doit lire et modifier des centaines d'équipements hétérogènes.

YANG fournit un langage structuré pour décrire la configuration et l'état. Un modèle YANG organise les objets comme un arbre : une application peut demander une valeur à un chemin précis ou proposer une modification. « Indépendant du fournisseur » signifie ici que le modèle ne reproduit pas l'interface privée d'un seul constructeur comme norme universelle. Cela ne signifie pas que tous les matériels acquièrent les mêmes capacités.

Le document OpenConfig sur les cas d'usage des instances réseau rend cette limite visible. Il traite des commutateurs de niveau 2, des routeurs de bordure pour fournisseurs de services et des appareils hybrides. Il cherche une structure capable de représenter des contextes de commutation, de routage ou les deux. Lorsqu'une demande permise par le modèle dépasse les capacités de l'appareil, le texte recommande, dans le cas décrit, un refus explicite plutôt qu'une fausse apparence de conformité. [7]

Ce refus est une information utile. Un système peut l'enregistrer, arrêter un changement et avertir un opérateur. Une acceptation silencieuse suivie d'un comportement différent est plus dangereuse, car l'outil croit avoir établi un état qui n'existe pas. Le modèle vaut donc par sa capacité à rencontrer le système en fonctionnement, pas seulement par l'élégance de son schéma.

La page OpenConfig crédite « Rob Shakir & OpenConfig WG members ». Cette formule fixe une frontière d'attribution. Shakir est un contributeur documenté parmi des membres du groupe. Les implémentations appartiennent aux projets et fournisseurs qui les développent ; les politiques appartiennent aux réseaux qui les exploitent.

L'instance réseau organise une frontière de transfert

Le brouillon OpenConfig de novembre 2015, dont Shakir est l'auteur nommé, décrit une « network instance » générique. Une instance réseau peut contenir une table de routage de niveau 3, une table de commutation de niveau 2 ou une combinaison. Elle peut représenter la table globale d'un équipement ou un contexte isolé pour un client ou un service. [9]

Pour un lecteur non spécialiste, on peut imaginer plusieurs pièces dans un même bâtiment. Chaque pièce dispose de son propre répertoire de destinations et de règles sur les portes qui y conduisent. Une interface physique peut être associée à une pièce ; une sous-interface peut mener à une autre. Le modèle doit nommer ces relations sans supposer que chaque constructeur a bâti les murs au même endroit.

Le brouillon reconnaît qu'il est orienté vers les équipements de fournisseurs de services et qu'il résulte de discussions au sein d'OpenConfig. [9] Cette précision empêche de présenter le modèle comme une vérité sans contexte. Il est générique par rapport à plusieurs architectures visées, non par rapport à toute machine possible.

Cette structure devient sensible lorsque des routes doivent passer d'une table à une autre. La redistribution de routes permet, par exemple, de prendre une route statique et de l'annoncer par BGP, ou de rendre certaines routes d'un protocole visibles dans un autre. Une mauvaise redistribution peut provoquer une boucle, propager une destination trop largement ou injecter une grande table Internet dans un protocole interne qui ne devrait pas la recevoir.

Le guide OpenConfig part du constat que les fournisseurs modélisent leurs bases d'informations de routage différemment. Il propose une connexion explicite entre la table source et la table de destination, accompagnée d'une politique. La phrase décisive indique que, si aucune politique d'importation ni politique par défaut n'est présente, aucune route ne doit être redistribuée. [8]

Ce choix place l'autorité au bon niveau. Le modèle n'ordonne pas à tous les réseaux d'accepter les mêmes routes. Il oblige l'opérateur local à exprimer une permission. Le document enregistre la décision ; l'organisation qui exploite le réseau reste responsable de son contenu.

Les interfaces de gestion ne remplacent pas les preuves d'exécution

Un modèle décrit les données. Une interface de gestion décrit comment un client demande ces données ou envoie un changement. Un brouillon gNMI de mars 2017 liste Shakir avec Anees Shaikh, Paul Borman, Marcus Hines et Carl Lebsack. Il documente une première interface fondée sur gRPC et des chemins structurés. [10]

Ce brouillon est expiré et ne doit pas être traité comme la spécification actuelle. Sa valeur dans cette chronologie est plus modeste : il montre que les contributeurs travaillaient aussi sur le passage entre le modèle et les logiciels qui l'utilisent. Un système complet exige encore une authentification, des autorisations, une implémentation, des contrôles avant changement et une possibilité de retour arrière.

L'automatisation est parfois décrite comme un moyen d'accélérer les opérations. Elle peut surtout accélérer une erreur si le modèle ne correspond pas au comportement réel. Une réponse structurée, un état observé et un rejet explicite créent des points de contrôle. Ils ne prouvent pas que l'appareil a bien fait circuler le trafic. Cette preuve demande une comparaison avec les tables, les mesures et le résultat en production.

Segment Routing exprime des chemins, avec une limite de confiance

La liste de RFC associée à Shakir déplace la question de la gestion vers l'expression des chemins. RFC 7855 formule des problèmes et exigences pour SPRING. RFC 8355 traite de cas de résilience. RFC 8402 définit l'architecture Segment Routing. RFC 8660 précise son utilisation sur le plan de données MPLS, et RFC 8665 définit les extensions OSPF nécessaires à la publicité d'informations de segments. [2] [3] [4] [5] [6]

Dans une explication simplifiée, Segment Routing permet à un nœud d'entrée d'associer au paquet une suite d'instructions appelées segments. Avec MPLS, ces instructions prennent la forme d'une pile d'étiquettes. L'idée ne supprime ni les protocoles de routage ni la politique. Elle change la manière dont une intention de chemin peut être encodée et appliquée.

RFC 8402 compte six auteurs, dont Shakir, et nomme d'autres contributeurs. [4] Une description fidèle doit préserver ce collectif. Elle doit aussi conserver les limites de sécurité du texte. Le RFC impose aux routeurs de bordure de filtrer le trafic externe visant des étiquettes internes au domaine de confiance. Il indique que les informations de routage explicite ne doivent pas fuir hors du domaine administré par défaut. [4]

La ressemblance avec la redistribution est nette. L'existence d'un mécanisme de passage ne vaut pas autorisation. Une politique ouvre une connexion entre tables ; une limite de domaine contrôle l'usage d'instructions internes. Dans les deux cas, le standard ou le modèle décrit la porte, tandis que l'opérateur décide et vérifie comment elle fonctionne.

La résilience reste une hypothèse à tester

RFC 8355 distingue notamment la protection de chemin, des protections locales gérées ou sans contournement préconfiguré, l'évitement de boucles et la coexistence de plusieurs techniques. [3] Ce vocabulaire décrit des options de conception. Il ne prouve pas qu'un réseau précis a évité une panne.

Une réparation locale peut détourner rapidement le trafic d'un lien défaillant. Elle peut aussi déplacer la charge vers un chemin saturé ou partager une infrastructure physique avec le chemin principal. Un modèle de contrôle ne montre pas à lui seul les conduits, l'alimentation électrique ou les dépendances communes. Les équipes doivent tester la topologie réelle et observer les résultats.

Le rôle attribuable à Shakir et aux autres auteurs est donc celui de la documentation de cas et de contraintes. Les fournisseurs implémentent. Les opérateurs déploient, surveillent et définissent leurs seuils. Les résultats appartiennent à cette chaîne entière.

L'expiration d'un brouillon n'efface pas le transfert

Le Datatracker ne liste actuellement aucun Internet-Draft actif pour Shakir, mais conserve de nombreux brouillons expirés liés à OpenConfig, gNMI, l'état opérationnel et les erreurs BGP. [1] Le brouillon d'instance réseau de 2015 et celui de gNMI de 2017 font partie de cette archive. [9] [10]

Pendant ce temps, OpenConfig maintient ses pages de cas d'usage, et un modèle YANG BGP actif de l'IETF continue en 2026 sous un autre groupe d'auteurs. Ce document vise une représentation indépendante des fournisseurs pour la configuration, la politique et l'état BGP dans des environnements hétérogènes. [11] Son historique contient des traces d'une participation antérieure de Shakir, mais son auteur actuel n'est pas Shakir. [12]

Cette distinction évite deux erreurs. Il serait faux de lui attribuer le brouillon actuel. Il serait également trompeur d'ignorer la lignée antérieure. Le passage à d'autres auteurs montre qu'un problème d'infrastructure peut sortir du contexte de ses premiers rédacteurs. Il ne prouve pas que chaque phrase ou choix initial a été conservé.

Le document actuel reste un brouillon et peut encore changer. [11] Cette incertitude n'annule pas le travail ; elle rappelle qu'une description partagée doit rester révisable lorsque les implémentations et les besoins évoluent.

Ce que le modèle ne peut pas promettre

Une arborescence commune ne rend pas les composants identiques. Un matériel peut manquer d'une fonction. Un fournisseur peut exposer un état avec retard. Deux appareils peuvent accepter la même demande et utiliser des mécanismes internes différents. La gestion doit vérifier le résultat au lieu de prendre l'accusé de réception comme preuve finale.

Segment Routing présente une limite comparable. Une architecture commune n'établit pas la politique locale et ne sécurise pas une frontière à la place de l'opérateur. Les filtres, les domaines de confiance et les procédures d'incident restent des décisions du réseau concerné.

Le résultat durable du dossier de Shakir est donc un ensemble de traces publiques que d'autres peuvent examiner. Les listes d'auteurs distribuent le crédit. Les versions montrent les changements. Les règles de refus et de filtrage rendent visibles les limites. Les modèles peuvent être comparés au système en fonctionnement.

La question non résolue n'est pas de savoir si un modèle abolira les différences entre fournisseurs. Elle est de savoir si les opérateurs, les projets et les constructeurs maintiendront la description assez proche de l'exécution pour qu'un écart devienne une alerte plutôt qu'une surprise. Les documents associés à Shakir ne garantissent pas cette discipline. Ils montrent pourquoi elle est nécessaire.

Sources

  1. IETF Datatracker, profil de Rob Shakir.
  2. RFC Editor, RFC 7855.
  3. RFC Editor, RFC 8355.
  4. RFC Editor, RFC 8402.
  5. RFC Editor, RFC 8660.
  6. RFC Editor, RFC 8665.
  7. OpenConfig, cas d'usage des instances réseau.
  8. OpenConfig, redistribution des routes dans les instances réseau.
  9. IETF Datatracker, draft-openconfig-rtgwg-network-instance-01.
  10. IETF Datatracker, draft-openconfig-rtgwg-gnmi-spec-00.
  11. IETF Datatracker, modèle YANG BGP actuel.
  12. IETF Datatracker, historique du brouillon BGP.