Résumé

  • Le RFC 1863 classait les serveurs selon le nombre de clients qu’ils informaient et donnait le délai le plus court au moins chargé ; il parlait du gagnant le plus probable, pas d’une élection certaine.
  • Une entrée dans une liste de clients « informés » attestait la responsabilité déclarée par un serveur, jamais la réception, la sélection, l’installation de route ou la connectivité utile côté client.
  • Le remplacement des doublons et un budget de Hold Time contenaient encore la course et le basculement. En 2005, le RFC 4223 constata qu’aucune implémentation de ce dispositif précis n’existait.

L’attente qui n’élisait personne

Le RFC 1863 proposait en 1995 des serveurs BGP/IDRP pour réduire le nombre de sessions d’un maillage complet. Un client ouvrait des sessions vers tous les serveurs de sa grappe afin de conserver de la redondance, tandis qu’un seul devait normalement lui transmettre les mises à jour.

Chaque serveur conservait une liste pour chacun de ses pairs et une pour lui-même. Ces listes indiquaient les clients auxquels le serveur disait fournir l’information de routage. Elles étaient ordonnées par taille, puis par adresse du serveur en cas d’égalité. Lorsqu’un nouveau client n’apparaissait nulle part, le serveur de rang N lançait un délai égal à (N-1) × DelayGranularity.

Le mécanisme donnait l’avantage au serveur le moins chargé. À l’expiration, celui-ci relisait toutes les listes. Une annonce récente d’un pair suffisait à le faire renoncer ; sinon il inscrivait le client chez lui, annonçait la nouvelle liste et commençait les mises à jour. Ce second contrôle réduisait l’intervalle d’incertitude. Il ne transformait pas des copies distribuées et retardées en registre atomique.

Le texte le reconnaissait : la conciliation n’éliminait pas entièrement les courses. Plusieurs serveurs pouvaient envoyer. Le vocabulaire de la probabilité était exact, et il faut le conserver.

Le relais ne décidait pas du meilleur chemin

Le serveur recevait les routes externes et les redistribuait avec leurs attributs. Le client appliquait ensuite ses critères et sa politique locale comme s’il avait reçu l’information d’un pair direct. Le document appelait cela un peering virtuel.

La réduction portait sur les connexions, pas sur le volume des routes à conserver. Elle ne permet donc pas de conclure qu’un serveur central avait choisi, installé ou validé un chemin. Une mise à jour relayée est un candidat livré. Il reste au client à la comparer, à la sélectionner et à l’installer ; il reste au plan de données à rendre la destination effectivement joignable.

L’attribut optionnel ADVERTISER conservait l’adresse du routeur frontière qui avait soumis la route. Il redonnait au client un contexte nécessaire à sa décision. Il ne constituait pas une signature. Le RFC disait explicitement que les questions de sécurité n’étaient pas discutées. Une adresse déclarée restait une identité de protocole, non la preuve d’un droit à annoncer.

Une liste d’intention, pas un reçu du client

Le terme informed client peut tromper. L’entrée provenait du serveur chargé d’envoyer, pas du client censé recevoir. Elle ne signifiait pas « j’ai reçu cette UPDATE », encore moins « je l’ai choisie » ou « le trafic fonctionne ».

Cette différence apparaissait dès l’initialisation. Un serveur en état Initiation pouvait accepter les connexions et traiter les mises à jour entrantes, mais n’en envoyait aucune. Il attendait le temporisateur initial suggéré de cinq minutes, ou bien toutes les sessions internes configurées et leurs listes. Une connexion vivante n’était donc pas encore une autorisation suffisante pour se déclarer diffuseur.

Quand deux serveurs gagnaient malgré le délai, le client fournissait la dernière barrière. S’il recevait d’un autre serveur une route aux attributs complètement identiques, il devait remplacer l’ancienne copie sans déclencher de publicité supplémentaire. La condition complètement identiques empêchait d’aplatir des chemins seulement ressemblants. Le geste limitait le stockage en double et les battements ; il ne jugeait ni la vérité ni la fraîcheur de la route.

Le basculement devait tenir dans le temps restant

Après la perte d’une session entre serveurs, un survivant examinait les clients de la liste du pair disparu. Il ne pouvait envisager la reprise que s’il possédait encore une session vers le client et si aucune liste active ne revendiquait déjà celui-ci. Le client admissible repassait ensuite par le même délai et la même seconde lecture.

Le transfert n’était donc pas un jeton reçu du serveur défaillant. Il était reconstruit à partir des sessions et listes survivantes. L’ancienne liste n’était supprimée qu’après conciliation.

Le RFC liait cette séquence au Hold Time. Le délai maximal ajouté au Hold Time inter-serveurs devait rester inférieur aux deux tiers du plus petit Hold Time côté client. Dans l’exemple à trois serveurs, 90 secondes côté client permettaient 30 secondes entre serveurs et une granularité de 15 secondes.

Respecter cette inégalité donnait au système une chance de reprendre l’envoi avant expiration. Cela ne prouvait pas que la table du survivant était actuelle ni que le trafic avait continué. Le temps était une enveloppe de travail, pas un résultat.

Le chemin interne n’était pas une provenance universelle

Dans une hiérarchie de grappes, RCID_PATH conservait les identifiants traversés. Si la grappe destinataire apparaissait déjà, le serveur n’annonçait pas la route et journalisait la boucle ; sinon il ajoutait son propre identifiant. Mais l’attribut disparaissait avant l’envoi aux routeurs frontières ordinaires.

Il s’agissait d’un état de prévention de boucle entre serveurs, non d’un certificat de provenance de bout en bout. L’attribut ADVERTISER répondait à une autre question, et aucun des deux ne remplaçait l’authentification absente.

Une fermeture historique sans déploiement

La fiche du RFC Editor classe aujourd’hui le texte comme Historic. Le RFC 4223 expliqua pourquoi : aucune implémentation du serveur défini par le RFC 1863 n’existait et cette technique n’était pas utilisée contre le maillage complet.

Cette phrase ne vise pas tous les systèmes appelés route servers. Le RFC 4223 les excluait expressément de son périmètre. Il citait la réflexion de routes, les confédérations BGP et les numéros d’AS privés parmi les alternatives courantes. Le RFC 2796, puis le RFC 4456, donnent au réflecteur une sélection de meilleur chemin et d’autres attributs de boucle. Le RFC 3065 décrit les confédérations. Aucun n’est une implémentation cachée du protocole de listes du RFC 1863.

L’absence de code ne démontre pas que chaque idée était mauvaise. Elle retire en revanche toute prétention à une validation par l’exploitation. Les délais, partitions et reprises sont restés des comportements spécifiés, jamais des faits observés dans ce système précis.

La portée honnête de chaque trace

Une session prouvait une relation active. Une liste prouvait la revendication actuelle d’un serveur. Un délai court augmentait une probabilité. La seconde lecture réduisait une décision périmée. Le remplacement identique absorbait un doublon. Le Hold Time réservait un intervalle pour la reprise.

Aucune trace ne prouvait seule la continuité. La leçon durable du RFC 1863 est cette modestie : la redondance ne devient réelle que lorsque l’ambiguïté entre responsables est bornée, que le client survit à la borne, puis qu’un observateur distinct constate le service.

Sources