Résumé

  • draft-geng-grow-bmp-rr-sync-00 propose de resynchroniser une vue BMP précise par une séquence BoRR, messages Route Monitoring, puis EoRR, sans couper la session.
  • EoRR atteste que l’émetteur déclare la reprise terminée ; sans génération, nombre attendu ni condensat, il ne prouve pas que chaque route a été produite, transportée, ingérée et validée.

Le collecteur reçoit EoRR et supprime les routes encore marquées obsolètes. Ce geste peut restaurer fidèlement la vue du routeur. Il peut aussi effacer une route qui n’a jamais traversé une file saturée, alors même que tous les messages reçus sont valides et authentifiés. Le même marqueur final peut donc clore une copie complète ou une copie trouée.

Voilà l’enjeu du texte BMP Extension for Non-Disruptive RIB View Synchronization, déposé le 30 septembre 2026. La révision 00 est un Internet-Draft individuel actif, au stade I-D Exists. Son en-tête vise Standards Track, tandis que Datatracker ne renseigne aucun statut RFC prévu. Ce n’est ni un document adopté par GROW, ni un RFC, ni une allocation IANA, ni une preuve de déploiement.

Réparer une vue sans tout réinitialiser

BMP transmet les états de routage des routeurs vers des collecteurs. Une indisponibilité, un débordement de tampon ou un redémarrage interne peut laisser des routes périmées dans la base du collecteur. Réinitialiser toute la session BMP ou perturber un voisin BGP pour corriger un seul périmètre est coûteux.

La proposition ajoute un message BMP Route-Refresh. Pour un <Peer, AFI, SAFI>, l’émetteur envoie BoRR, diffuse l’ensemble courant des routes actives dans des messages Route Monitoring, puis envoie EoRR. À BoRR, le collecteur marque l’ancien ensemble comme stale ou historique. Chaque annonce reçue rafraîchit son entrée. À EoRR, les restes obsolètes sont purgés.

La méthode reprend le schéma d’Enhanced Route Refresh défini par le RFC 7313. Elle constitue une amélioration opérationnelle réelle : la correction reste ciblée. Mais un début et une fin ne forment pas un bordereau de contenu.

Une enveloppe sans inventaire

La révision 00 ne définit ni identifiant de reprise, ni total attendu, ni accusé par préfixe, ni condensat final, ni comparaison indépendante. Son exemple autorise zéro ou plusieurs messages Route Monitoring. Zéro est le bon résultat pour une RIB vide ; c’est aussi le résultat visible si toutes les routes de reprise sont perdues mais que l’EoRR arrive.

Le RFC 7854 emploie en outre les mêmes messages Route Monitoring pour l’instantané initial et les changements continus. L’ordre d’un dump n’est pas imposé et la compression d’état est admise : si un préfixe change plusieurs fois avant l’émission, le routeur peut ne transmettre que son état final. Il faut donc savoir si une annonce ou un retrait intercalé appartient à l’instantané, à la génération en direct suivante, ou aux deux.

Le nouveau texte n’ajoute pas de drapeau « reprise » à chaque message RM et ne fournit pas de séquence portable. L’émetteur peut connaître son intention ; le collecteur hétérogène doit la reconstruire grâce à l’ordre TCP et à ses conventions locales. Le cadre est standardisable, la preuve d’exhaustivité ne l’est pas encore.

L’identité d’une vue dépasse le triplet

<Peer, AFI, SAFI> ne suffit pas toujours. Le RFC 8671 distingue Adj-RIB-In et Adj-RIB-Out, avant et après politique. Le RFC 9069 ajoute l’instance Loc-RIB et indique si la vue exportée est filtrée. Un reçu fiable doit lier la reprise au type de peer, au distingueur, au BGP ID, à la direction, à l’étape de politique, à l’instance, au filtre et à la version de configuration.

Sans cette précision, une reprise parfaite d’Adj-RIB-In avant politique peut être interprétée à tort comme une Loc-RIB complète. Même une Loc-RIB complète ne prouve ni l’installation dans la FIB, ni le passage des paquets, ni le résultat du service.

La protection du canal ne compte pas les absents

Le projet avertit qu’un faux EoRR peut provoquer une purge prématurée et recommande IPsec, TLS ou des ACL strictes. Ces contrôles authentifient le canal. Ils ne prouvent pas qu’un émetteur autorisé a assemblé toute la population, que sa file interne n’a rien perdu ou que le collecteur a validé chaque message avant EoRR.

La chaîne de preuve doit conserver le déclencheur autorisé, l’identité complète de la vue, l’ID et la génération de reprise, le commit du marquage stale, le total ou le condensat côté routeur, les pertes et la pression de transport, l’ordre des changements concurrents, l’émission et la réception d’EoRR, les comptes de purge et de rejet, puis une comparaison finale ou une relecture ciblée.

La doctrine de spécification minimale de Heng Lu place bien la frontière : le protocole commun fournit le sens nécessaire à l’interopérabilité, pas une autorité magique sur les faits locaux. La primauté du code en production demande les observations, commits et comparaisons réellement exécutés.

Cette proposition réduit le rayon de la réparation. C’est un gain. Il ne faut pas le transformer en affirmation excessive : EoRR termine la reprise ; un reçu séparé établit qu’elle était entière.

Sources