Résumé

  • RFC 9736 sépare les espaces TLV de Peer Up et d’Initiation et exige de conserver l’ordre des String TLV répétées. Il règle la propriété des codes, pas la conformité d’une chaîne déployée.
  • Toute conclusion opérationnelle doit relier le registre, la version de l’émetteur, les octets reçus, les décisions du parseur et l’enregistrement persistant aux preuves de session, de route, de transfert et de résultat.

Deux messages, un registre de trop

Dans BMP, Initiation décrit le système surveillé tandis que Peer Up décrit une session BGP. RFC 7854 leur faisait pourtant partager l’espace des Information TLV. Ce raccourci devenait coûteux à mesure que le protocole s’étendait : un numéro n’avait plus de propriétaire évident sans connaître le type de message qui l’enveloppait.

RFC 9736 apporte une réparation ciblée. L’ancien registre devient BMP Initiation Information TLVs; un registre BMP Peer Up Message TLVs est créé. Initiation garde String en Type 0, sysDescr en Type 1 et sysName en Type 2. Peer Up utilise String en Type 0, VRF/Table Name en Type 3 et Admin Label en Type 4. Les numéros 1 et 2 sont réservés côté Peer Up, les numéros 3 et 4 côté Initiation.

Le texte précise également le contrat binaire. Une String TLV est une séquence UTF-8 dont la longueur est donnée en octets, sans terminaison nulle. Le champ Information de Peer Up est facultatif ; Message Length indique s’il existe. String peut être répétée et l’ordre doit être conservé lors du compte rendu. Une base qui transforme cette suite en ensemble a donc perdu une propriété exigée, même si son écran paraît cohérent.

La compatibilité normative n’est pas un inventaire de production

Le RFC indique que les implémentations conformes aux RFC 7854, 8671 et 9069 sont aussi conformes à RFC 9736. Cette phrase protège la continuité des affectations existantes. Elle ne nomme aucun logiciel, aucune version ni aucun schéma de stockage.

Un collecteur peut garder seulement la dernière String répétée. Il peut reconnaître Type 3 mais associer le nom de table au mauvais peer Loc-RIB émulé. Il peut ignorer silencieusement un type futur. Dans chaque cas, le registre IANA est correct et la trace opérationnelle est incomplète.

La vérification doit donc commencer avant le décodage. Il faut conserver les octets Peer Up, l’identité de la session BMP, la version et la configuration de l’émetteur, Message Length et la séquence TLV. Cette capture doit être liée au build du collecteur, à sa table de parsing et à sa politique pour les types inconnus. Le reçu d’ingestion brute doit ensuite être comparé au document décodé et à l’enregistrement stocké. Une ligne normalisée seule ne permet pas de savoir si la donnée manquait sur le fil ou a disparu après réception.

Ce que Peer Up ne clôt pas

RFC 7854 définit Peer Up comme le signalement du passage d’une session BGP à Established, avec les messages OPEN et des informations TCP. Mais au démarrage d’une session BMP, un Peer Up est aussi envoyé pour chaque peer déjà Established. L’heure d’arrivée chez le collecteur n’est donc pas nécessairement l’heure de naissance de la session BGP.

RFC 8671 ajoute une frontière décisive : l’état Peer Up/Down est indépendant de l’envoi de Route Monitoring ou Route Mirroring pour Adj-RIB-In ou Adj-RIB-Out. Initiation, Peer Up, le dump initial, End-of-RIB et les mises à jour incrémentales sont des reçus distincts. Un Peer Up valide ne prouve pas que le flux de routes est complet.

Avec Loc-RIB, RFC 9069 emploie des peers émulés, parfois plusieurs pour une même table selon les familles d’adresses. VRF/Table Name aide l’opérateur, mais global n’est pas une identité universelle. Le distingueur de peer, le BGP ID et les capacités OPEN restent nécessaires.

Une chaîne de preuve qui peut s’arrêter honnêtement

Le dossier d’exploitation doit répondre successivement : quel instantané de registre ; quel build d’émetteur ; quelle session BMP et quelle époque du peer ; quels octets ; quel parseur ; quel traitement des inconnus ; quels reçus brut et décodé ; quelle corroboration BGP ; quelle couverture du flux de routes ; quelle observation RIB, FIB ou active ; quelle action autorisée ; quel résultat indépendant.

La réponse peut être « inconnu » après n’importe quel maillon. Peer Up peut établir un événement de session sans établir l’acceptation d’une route. Un flux complet peut laisser le transfert matériel inconnu. Le transfert peut laisser l’effet métier indéterminé. RFC 9736 rend le premier contrat plus net ; il ne remplit pas les reçus suivants.