Résumé

  • draft-geng-grow-bmp-monitor-options-00 propose des notifications Enable et Disable pour déclarer l’état de supervision des vues RIB et des statistiques BMP. La révision 00 est un brouillon individuel, et le type de message TBD2 n’est pas attribué.
  • Pour une vue RIB désactivée, le collecteur doit purger immédiatement les entrées du triplet <Peer, AFI, SAFI>. Le canal authentifié ne suffit donc pas : il faut une autorisation précise, un reçu de suppression et un critère indépendant de reconstruction complète.

Un collecteur n’a reçu aucun changement depuis une heure. Pour l’analyste, deux réalités incompatibles se ressemblent : le pair n’a rien modifié, ou le routeur a cessé d’exporter une famille d’adresses. La session BMP peut rester établie dans les deux cas. Sans signal explicite, une table ancienne continue alors de porter l’apparence du présent.

Le brouillon BMP Extension for Monitoring Options (MO) Notification, daté du 30 septembre 2026, propose ce signal. Il s’agit d’un Internet-Draft individuel à statut Standards Track envisagé, valable jusqu’au 3 avril 2027. Ce n’est ni un RFC ni un consensus de groupe de travail. TBD2 désigne une valeur à attribuer, pas un numéro déjà enregistré par l’IANA.

Nommer la cause du silence

RFC 7854 a remplacé une partie du « screen scraping » par un flux structuré d’états de pairs, de routes et de statistiques BGP. RFC 8671 et RFC 9069 ont ajouté l’observation d’Adj-RIB-Out et de la Local RIB. Il manquait pourtant une information : le changement administratif de ce que l’émetteur choisit de superviser.

Le message MO rend cette déclaration visible. Le PDU RIB distingue Adj-RIB-In, Adj-RIB-Out et Loc-RIB, puis les états Pre-Policy et Post-Policy. Un bit indique Enable ou Disable, et une liste précise les couples AFI/SAFI. Le Common Header peut être suivi d’un Per-Peer Header. Un autre format couvre les types de statistiques.

Cette granularité constitue la frontière de l’opération. Un journal qui dirait seulement « BMP désactivé » perdrait les dimensions décisives : émetteur, pair, surface RIB, étape de politique, AFI, SAFI et heure.

Une déclaration qui modifie la base

Le déroulé normatif est net. Lorsqu’un opérateur désactive la supervision d’une famille, l’émetteur doit transmettre immédiatement MO Disable. À sa réception, le collecteur doit purger immédiatement toutes les entrées RIB associées à la vue <Peer, AFI, SAFI> concernée.

La purge empêche une vue non observée de rester présentée comme actuelle. C’est le gain. Mais elle transforme une notification de configuration en commande destructive. Les cartes de topologie, contrôles de politique, détecteurs de fuite et recherches forensiques qui consomment cette base peuvent être assainis par une purge correcte ou aveuglés par une purge excessive, sans que l’état vert de la session BMP disparaisse.

Le brouillon reconnaît le risque : de faux messages Disable non autorisés pourraient amener un collecteur à purger toute sa base supervisée. Il impose donc l’authentification mutuelle et une protection de transport telle que TLS.

TLS répond à la question de l’identité du pair de session et de l’intégrité du transport. Il ne démontre ni l’approbation humaine, ni la justesse de l’AFI/SAFI, ni la conformité de l’étendue à une politique interne. Un routeur compromis peut rester correctement authentifié. Authentifier le messager ne revient pas à autoriser toute suppression qu’il sait formuler.

Purger le présent sans détruire la preuve

« Purger immédiatement » vise la vue RIB stockée et active. La révision 00 ne décrit pas un régime complet d’archivage et n’interdit pas une trace historique immuable séparée.

Il est donc possible de retirer aussitôt les routes de la vue courante tout en conservant, selon une politique locale, un condensat antérieur, une liste historique ou le détail du changement. Cette copie doit être marquée comme historique et ne jamais alimenter silencieusement les décisions en temps réel. À l’inverse, une ligne « suppression réussie » ne prouve presque rien si elle ne nomme pas la vue ni le nombre d’entrées touchées.

Un reçu robuste relie la demande approuvée, l’identité de session, les champs exacts du message et la mutation réellement exécutée. Il énumère l’étendue purgée et celle laissée intacte. Le collecteur doit aussi pouvoir refuser, avant mutation, une demande mal formée ou plus large que le rôle accordé à cet émetteur.

Enable n’est pas synonyme de vue complète

Lors d’une réactivation, le brouillon prévoit un message Enable suivi de nouveaux messages Route Monitoring. La vue se reconstitue à mesure de leur arrivée. Pourtant, il ne définit ni marqueur de début d’instantané, ni volume attendu, ni marqueur de fin, ni test de complétude.

La première route reçue prouve que l’ingestion a repris, pas que la table actuelle est entière. Une vue partiellement reconstruite est même dangereuse : elle paraît fraîche tout en omettant des routes. Les consommateurs devraient voir trois états distincts — disabled, rebuilding, current — et ne quitter le second qu’avec une preuve déclarée.

Le brouillon séparé draft-geng-grow-bmp-rr-sync-00 propose, lui, des marqueurs BoRR et EoRR autour d’une resynchronisation ciblée. Il montre que le bornage d’un instantané constitue un autre problème de protocole. Il ne fait pas partie de MO et demeure lui aussi une proposition individuelle en révision 00.

La preuve doit suivre toute la transition

Une chaîne défendable conserve successivement : la version exacte de la spécification ; les identités mutuellement authentifiées ; la demande opérateur ; le pair, le type et sous-type RIB, l’AFI/SAFI ; l’autorisation de cette étendue ; les lignes supprimées et préservées ; la preuve historique ; le Enable correspondant ; l’époque de reconstruction ; puis la décision de rendre la vue de nouveau fiable pour l’aval.

Aucun maillon ne remplace le suivant. Un certificat valide ne prouve pas le bon périmètre. Un Disable conforme ne prouve pas l’approbation. Une purge réussie ne garantit pas la conservation de la preuve. Un Enable ne certifie pas la complétude.

La doctrine de Lu Heng aide à placer la frontière. La spécification commune minimale peut définir les champs déterministes nécessaires à l’interopérabilité. La conservation, l’autorisation, la limitation du rayon d’action et le seuil de confiance futur restent des décisions locales. L’adoption n’existe que dans le code en fonctionnement et ses reçus, pas dans la seule publication d’un brouillon.

Dès qu’un message de télémétrie peut effacer ce que l’on observe, il appartient au plan de contrôle de la preuve.

Sources