Résumé

  • draft-ietf-idr-fsv2-ip-basic-08 ajoute ordre utilisateur, composants obligatoires ou optionnels et chaînes de dépendance, mais chaque équipement en tire une décision locale ; il n’existe pas de validation collective de l’installation.
  • Une opération responsable doit recueillir, pour chaque cible, la règle reçue, les éléments compris ou omis, l’ordre effectif, l’état logiciel et matériel, les compteurs, le retrait et le résultat sur les paquets.

Tous les voisins sont verts, pas tous les filtres

Le contrôleur annonce une règle de mitigation. Les route reflectors la relaient. Les sessions restent établies et les journaux confirment la réception. Le tableau de bord conclut : déploiement terminé.

Un premier routeur installe la règle entière. Un deuxième ne sait pas exécuter un composant obligatoire et invalide aussi les règles qui partagent la même chaîne de dépendance. Un troisième retire un composant déclaré optionnel et installe le reste. Un nœud plus ancien propage une communauté d’action qu’il ne comprend pas.

La distribution est cohérente ; le comportement des paquets ne l’est pas nécessairement. La révision 08, datée du 28 septembre 2026, décrit elle-même cette surface. Sa formule la plus utile est aussi la plus restrictive : BGP ne possède toujours pas de fonction d’action-réponse.

Un UPDATE reçu prouve la livraison d’un objet de contrôle. Il ne constitue pas le reçu de son exécution.

Une version de travail, pas un constat de déploiement

Le Datatracker classe la révision 08 comme Internet-Draft actif du groupe IDR, à l’état I-D Exists. Le texte indique Standards Track, tandis que la fiche laisse vide le statut RFC visé. Plusieurs valeurs AFI, SAFI et types restent TBD, des notes éditoriales subsistent et une solution complète pour certaines interactions entre actions est renvoyée à d’autres travaux.

Il faut conserver ces limites. Le document atteste une architecture étudiée par l’IETF, non la prise en charge par un produit, un opérateur ou un réseau nommé.

Les RFC 8955, 8956 et 9117 forment le socle de FSv1. FSv2 utilise d’autres familles afin que les deux versions coexistent comme des navires qui passent sans se voir. Un réseau de transition peut réunir des pairs prenant en charge les deux versions, une seule ou aucune.

Or un paquet ne traverse pas deux architectures abstraites. Il rencontre une seule liste de filtres réellement installée.

User Order exprime l’intention

Chaque NLRI FSv2 porte un User Order de 32 bits ; la valeur la plus basse a la meilleure priorité. Ce champ permet de remplacer l’ordre par défaut quand celui-ci ne traduit pas l’intention de l’opérateur.

L’ordre est décisif. Une exception étroite placée avant une règle générale de rejet ne produit pas le même résultat dans l’ordre inverse. La révision recommande de placer FSv2 avant FSv1 et d’inscrire les deux familles dans une base locale commune.

Mais l’ordre annoncé doit encore être combiné aux règles locales, validé, traduit dans le modèle de l’équipement et programmé. BGP ne renvoie ni la liste finale ni la génération de table effectivement active. Le dossier d’exploitation doit donc conserver l’ordre demandé et l’ordre installé.

La chaîne de dépendance reste locale

Le Dependent Filters Chain, ou DFC, répond à un danger précis. Le draft imagine une règle spécifique qui autorise SMTP et marque le DSCP, puis une règle plus large qui rejette le trafic. Si le premier équipement ne sait pas marquer et n’installe que le rejet général, le trafic légitime disparaît.

Une valeur DFC non nulle lie des règles qui doivent partager leur sort. Lorsqu’une règle est localement invalide, les autres règles du même DFC sont également invalidées sur ce nœud. C’est un mécanisme local de refus prudent.

Ce n’est pas une transaction distribuée. Un appareil peut accepter le groupe et son voisin le refuser. Un reflector peut vérifier la syntaxe sans comprendre la sémantique. Le DFC ne compare pas les résultats du parc, ne répond pas à l’émetteur et n’annule pas automatiquement les règles déjà actives ailleurs.

Il garantit un destin commun dans une décision locale, pas un commit atomique dans le réseau.

« Optionnel » peut modifier la portée

Un composant de correspondance non pris en charge et obligatoire rend la règle invalide. S’il est optionnel, l’équipement peut le supprimer et installer le reste comme règle valide.

Cette souplesse facilite une migration progressive, mais elle transforme parfois l’ensemble des paquets visés. Un préfixe accompagné d’un nouveau critère restrictif sera précis sur un équipement récent ; si le critère optionnel disparaît sur un ancien, l’action restante peut couvrir un ensemble plus large.

L’omission doit donc devenir un événement observable : quel composant manque, quelle portée demeure, quelle action continue et qui a autorisé cette variante ?

Les actions connaissent une incertitude comparable. Si l’appareil ne peut en installer une, sa configuration ou ses défauts peuvent décider si la règle entière reste valide. La révision reconnaît que l’ordre et la validation avancés des actions relèvent encore de travaux futurs.

Les octets franchissent un nœud qui ignore leur sens

Les actions FSv2 sont associées aux filtres par des Extended Communities. RFC 4360 fournit leur mécanisme de transport et de transitivité. Un nœud ignorant une action nouvelle peut la propager correctement sans savoir qu’une action a été demandée.

Le draft appelle alors le comportement « best effort » pour les actions connues. La conservation de l’objet de contrôle est plus forte que la conservation de sa signification locale.

Dans une mitigation qui combine marquage, échantillonnage et redirection, certains équipements peuvent ne réaliser qu’un sous-ensemble. La révision étudie les interactions, mais renvoie la solution complète à un futur conteneur d’actions. La présence de la communauté dans Adj-RIB-In ne prouve pas l’existence de l’ensemble ordonné dans le matériel.

Valide, éligible et installé sont trois états

FSv2 vérifie la structure du NLRI, les propriétés de la route et les actions. Par défaut, la faisabilité dépend notamment d’un préfixe de destination et de la route unicast correspondante, même si une configuration explicite peut assouplir certains tests.

Une erreur dont les limites sont irrécupérables peut réinitialiser la session. D’autres erreurs utilisent le treat-as-withdraw de RFC 7606. Le texte avertit qu’un retrait mal formé d’une route auparavant valide peut laisser une règle bloquée et exige une notification opérateur.

La disparition de l’annonce n’est donc pas la preuve de la disparition du filtre. Il faut observer le retrait dans la RIB, le magasin de politique, le classificateur logiciel, le matériel et enfin le trafic.

Deux vitesses pour une même opération

RFC 4760 permet à BGP de distribuer rapidement plusieurs familles. Les reflectors donnent l’échelle ; les Extended Communities transportent les actions. Cette rapidité existe précisément parce que BGP n’attend pas la programmation de chaque cible.

La révision 08 propose d’associer la diffusion BGP à des demandes plus lentes par NETCONF ou RESTCONF afin d’obtenir un état d’installation. RFC 6241 et RFC 8040 fournissent des échanges structurés, mais aucun ne crée spontanément un reçu FSv2 commun à tous les constructeurs. Une réponse peut confirmer une requête, un datastore ou une table logicielle sans démontrer le matériel ni le paquet.

Le bon modèle utilise BGP pour ouvrir vite une action bornée, puis une boucle probante pour confirmer nœud par nœud le filtre exact, ses compteurs, son expiration et son retrait.

Le reçu à conserver

Le dossier doit lier la version du protocole et ses identifiants ; l’autorité et les cibles ; le NLRI complet, User Order et DFC ; les composants obligatoires ou optionnels ; les communautés d’action ; les données de validation ; les horodatages par pair ; les capacités de chaque nœud ; les omissions et inconnues ; le verdict de chaque DFC ; l’ordre FSv1/FSv2 effectif ; les identités des entrées logicielles et matérielles ; les compteurs ; l’expiration, le retrait et la suppression observée ; enfin la décision de poursuivre ou d’annuler.

La réception établit le transport. La validation établit la conformité à une règle. Une table établit une programmation locale. Les compteurs établissent qu’un trafic a rencontré le classificateur. Aucun de ces reçus n’autorise à inventer les suivants.

La primauté du code exécuté ne nie pas la norme. Elle exige de confronter la norme à l’état produit par chaque implémentation.

Sources