Résumé

  • RFC 5291 permet au récepteur BGP de fournir au pair des Outbound Route Filters typés. Le pair peut les ajouter à ses filtres d’export locaux pour ne pas produire les updates que le récepteur éliminerait ensuite.
  • ADD, REMOVE et REMOVE-ALL modifient un état fourni par le pair et limité à la session ; PERMIT et DENY expriment une préférence. Aucun de ces actes ne supprime les règles locales de l’émetteur, qui peut ne pas honorer la demande.
  • IMMEDIATE applique la mutation et déclenche la réannonce ; DEFER stocke la mutation en attendant un commit. Une preuve complète suit la liste source, l’encodage, l’état reçu, l’export local, Adj-RIB-Out, le fil et le RIB final, puis recommence à chaque nouvelle session.

Une capture « avant/après » sur le routeur du client semble décisive : la table reçue passe d’environ un million de routes à une vue étroite, la mémoire baisse et le filtre d’import compte des rejets. L’équipe conclut que le fournisseur envoie désormais un flux réduit.

Le même résultat apparaît si le fournisseur continue d’expédier la table entière. Le client a prouvé son refus, pas l’économie de calcul chez le voisin. ORF ne rend cette économie démontrable que si l’on observe aussi la capacité négociée, les entrées reçues et la sortie réelle de l’émetteur.

La préférence remonte le sens des annonces

Dans le modèle ordinaire, l’émetteur construit pour chaque pair un Adj-RIB-Out à partir de sa Loc-RIB et de sa politique locale. Le récepteur applique ensuite sa politique d’import. Deux domaines autonomes se touchent, sans se confondre.

ORF ajoute un signal inverse, volontaire et borné. Le récepteur décrit ce qu’il souhaite ne pas recevoir ; le pair peut intégrer cette information à son filtre de sortie destiné à ce seul récepteur. Les routes descendent toujours de l’émetteur vers le client, mais la préférence remonte du client vers l’émetteur.

RFC 5291 impose une composition, non un remplacement. Les ORF reçus s’ajoutent aux filtres d’export configurés localement. Un client peut demander moins de routes ; il ne peut pas retirer une règle commerciale, un garde-fou de sécurité ou une restriction de divulgation du fournisseur. REMOVE-ALL efface les entrées du seul ORF reçu concerné, jamais toute la politique de sortie.

Le texte normatif qualifie ces entrées de préférence locale que le pair peut décider d’honorer ou non. La capability ouvre un protocole d’expression ; elle ne crée pas un droit à l’exécution distante. Le client conserve donc un filtre d’import indépendant et vérifie le flux observé.

La capability est une intersection directionnelle et typée

Le code de capability 3 est échangé dans OPEN. Son sens ne se résume pas à « ORF supporté ». Chaque déclaration précise un AFI/SAFI, un type d’ORF et une direction : recevoir, envoyer, ou les deux.

La relation valable est l’intersection exacte. Si le client veut envoyer un Address Prefix ORF pour IPv4 unicast mais que le fournisseur n’accepte ce type qu’en IPv6, rien n’est négocié pour IPv4. Savoir envoyer ne prouve pas savoir recevoir ; un résultat dans une famille ne vaut pas pour l’autre.

Cette intersection influence le premier flux. Lorsqu’elle n’est pas vide pour une famille, RFC 5291 recommande à l’émetteur d’attendre un Route Refresh qualifiant avant d’annoncer les routes : soit un refresh simple, soit un message contenant des entrées avec IMMEDIATE. Le récepteur peut ainsi poser sa demande avant la table initiale.

Si l’intersection est vide, BGP suit son fonctionnement normal. Une même session Established peut donc attendre en IPv4 et annoncer immédiatement en IPv6. L’état de session seul masque le type, la direction et le premier commit.

Les preuves doivent être indexées par l’epoch de session. La configuration indique l’intention ; les OPEN réellement échangés, la famille active et le type accepté définissent l’interface en cours d’exécution.

Une liste locale et l’état distant ne sont pas le même objet

Une entrée ORF réunit AFI/SAFI, type, action, match et valeur spécifique. ADD l’installe ; REMOVE supprime l’entrée correspondante ; REMOVE-ALL vide l’ORF désigné. PERMIT demande le passage des routes correspondantes ; DENY demande leur exclusion.

RFC 5292 définit Address Prefix ORF avec séquence, préfixe, longueur, Minlen et Maxlen. Il sait exprimer l’égalité, les more-specifics d’une plage et les limites de longueur. La séquence règle l’ordre de décision.

Le prefix-list édité, sa compilation, son encodage Route Refresh et l’ORF décodé par le pair sont quatre identités. Un générateur peut inverser deux séquences, oublier un deny, encoder le mauvais AFI ou conserver une ancienne version. Le hash du fichier source ne couvre aucune de ces transformations.

Un canari doit tester le positif et le négatif : un préfixe exact, un more-specific dans la plage, un préfixe juste au-delà de Maxlen, un deny explicite et une route que l’export local bloque quoi que demande le client.

Plusieurs ORF de types différents peuvent coexister. Chaque route les traverse tous ; PERMIT combiné à DENY produit DENY. Un écran ne montrant que le prefix ORF peut donc surestimer le flux effectif.

DEFER prépare, IMMEDIATE rend visible

Les entrées empruntent l’enveloppe Route Refresh avec un choix transactionnel. IMMEDIATE traite la mutation et réannonce les routes affectées sous le nouvel état. L’émetteur doit réannoncer les routes touchées et peut également renvoyer les autres.

DEFER stocke les changements sans modifier immédiatement le flux visible. Un refresh simple ultérieur, ou un ORF marqué IMMEDIATE, réalise le commit. Lorsque des changements de politique locale exigent aussi une réannonce complète, la séquence prévue est DEFER puis refresh simple.

L’intervalle permet de préparer plusieurs entrées de façon atomique. Il crée aussi un piège : le client et le pair peuvent afficher la nouvelle liste alors que l’ancien Adj-RIB-Out reste actif.

Chaque DEFER doit donc avoir un identifiant, un hash attendu, un propriétaire, un commit prévu, une échéance et un rollback. Un état différé qui dépasse sa fenêtre est une transaction incomplète, pas un succès partiel.

Un Route Refresh simple ne supprime pas les ORF reçus. Il rediffuse en continuant de les appliquer. Les marqueurs Enhanced Route Refresh délimitent un échange, mais ne décrivent pas la mutation ORF. Une enveloppe commune ne signifie pas une autorité commune.

Supprimer la demande ne supprime jamais le refus local

Retirer un DENY fourni par le pair peut élargir le flux. Retirer la dernière entrée fait disparaître cet ORF. L’élargissement s’arrête pourtant à la politique d’export locale et à la volonté de l’émetteur d’honorer les préférences.

Le rollback est donc asymétrique. Le client peut restaurer son ancien ORF, le vider ou cesser de négocier. Aucun de ces actes ne doit affaiblir le filtre explicite du fournisseur. Si celui-ci utilise l’ORF du client comme unique barrière de sécurité, il a confondu économie et autorisation.

Le récepteur conserve lui aussi sa défense d’import. Le pair peut ignorer la préférence, perdre l’état, ne pas partager le type ou renégocier autrement. L’optimisation des ressources ne doit jamais devenir l’unique contrôle d’admission.

Une valeur inconnue peut effacer l’ORF antérieur

Un AFI/SAFI ou un type non négocié est ignoré. Un REMOVE visant une entrée absente est également ignoré. Ces chemins préservent normalement l’état existant.

Une valeur de champ inconnue dans un ORF sélectionné déclenche une règle plus tranchante : RFC 5291 demande de retirer tout l’ORF précédemment reçu pour ce type. Le protocole évite ainsi un filtre compris à moitié, mais le flux peut s’élargir jusqu’à la limite locale.

Il faut tester cette branche sur une relation isolée. Prédire si le message, l’entrée ou l’ORF entier disparaîtra, puis vérifier l’Adj-RIB-Out. Un log de parsing n’établit pas la conséquence sur les routes.

Les limites de fréquence et de volume font aussi partie du contrat. Un récepteur compromis peut provoquer calculs et réannonces par mutations répétées ; un émetteur compromis peut prétendre respecter une demande qu’il ignore. Ni l’un ni l’autre ne doit disposer d’une automatisation illimitée.

La session fixe l’expiration naturelle

Un ORF ne vit que pendant la session où il a été échangé. La fermeture détruit cet état fourni par le pair. Une capture antérieure au reset ne prouve rien après la reconnexion.

La nouvelle session renégocie les capabilities et attend, selon l’intersection, son premier refresh qualifiant. Une course au démarrage ou une capability modifiée peut changer le flux sans aucune modification du prefix-list local.

L’epoch doit lier OPEN, premier message ORF ou simple, état reçu, activation et premier snapshot d’Adj-RIB-Out. Des routes apparues avant la demande attendue, ou une demande jamais reçue, sont des anomalies.

Un reset nettoie certes l’état, mais il touche toute la session. Le rollback normal est une mutation inverse observée. La reconnexion n’est acceptable que si le plan prédit la reconstruction complète.

Le canari doit observer les deux côtés

On commence avec un pair de faible impact et une famille. La base mesure candidats à l’export, updates transmis, entrées reçues et rejets locaux avec les filtres ordinaires.

Après négociation, un IMMEDIATE étroit est envoyé avant le flux initial. Le pair confirme les entrées décodées et leur intersection avec l’export local. Adj-RIB-Out, fil et RIB récepteur doivent démontrer que les updates exclus n’ont jamais été envoyés.

Une seconde version passe par DEFER : l’état stocké change, le flux non. Un refresh simple commit la version et l’on compare la delta exacte. REMOVE, REMOVE inexistant, REMOVE-ALL et suppression de la dernière entrée sont testés séparément.

Enfin, le reset prouve la disparition de l’ancien ORF puis sa reconstruction par capability et premier refresh. L’exercice est répété pour chaque AFI/SAFI.

Le résultat n’est pas « ORF activé ». C’est la preuve d’un travail évité et de frontières conservées : quelles updates n’ont pas été générées, quelles règles locales ont continué à refuser la divulgation, quelle demande exacte a causé la différence et ce que le récepteur a réellement vu.

ORF donne le droit limité de demander au voisin de parler moins. Il ne donne ni le droit d’exiger davantage, ni celui d’effacer ses règles. Cette retenue n’affaiblit pas la coopération : elle la rend vérifiable.