Résumé

  • L’IETF a publié le 5 septembre 2026 la révision 18 de Traffic Steering using BGP FlowSpec with SR Policy. À la clôture de cette enquête, le document restait un Internet-Draft en AD Evaluation::External Party, et non une RFC approuvée.
  • La révision 17 imposait un retour vers Redirect-to-IP lorsqu’une annonce portait une cible de redirection sans Color valable. La révision 18 interdit ce repli si l’annonce exprime une intention SR incomplète : le trafic correspondant doit être rejeté ou soumis à la politique locale d’échec.
  • La route FlowSpec peut rester dans la Loc-RIB et être propagée alors que l’action SR n’est pas installée dans la FIB ou la TCAM. Voir l’annonce ne prouve donc pas le sort des paquets.
  • Le chapitre de compatibilité précise qu’un headend ne prenant pas en charge le projet peut ignorer l’attribut Prefix-SID et revenir à Redirect-to-IP. Dans un parc mixte, la même annonce peut provoquer un rejet ici et une redirection ailleurs.
  • La dernière consultation du groupe IDR portait sur la révision 13. Après la révision 17, l’Area Director a demandé aux présidents de vérifier à nouveau le consensus. Cette vérification doit désormais nommer la version et la matrice d’échec acceptées.

Le repli qui a changé de sens

FlowSpec permet de distribuer par BGP des critères de sélection de paquets et les actions qui leur sont associées. Le projet ajoute une liaison avec Segment Routing : la cible portée par Redirect-to-IP et une Color Extended Community composent le couple (Endpoint, Color) qui désigne une SR Policy. Un second mode peut joindre un attribut BGP Prefix-SID afin de demander, à la sortie d’un domaine SRv6, une fonction de service déterminée.

Trois messages proches ont alors des sens différents. Une cible Redirect-to-IP seule reste une redirection IP ordinaire. La cible accompagnée d’une Color valable demande un transport par SR Policy. La présence d’un Prefix-SID à côté de la cible, sans Color valable, révèle au contraire une intention SR dont la clé de sélection est incomplète.

Dans la révision 17, ce troisième cas devait retomber sur la redirection IP ordinaire ; l’attribut de service était ignoré. Dans la révision 18, il ne le peut plus. Un headend compatible ne doit ni chercher une policy par défaut, ni utiliser le Prefix-SID, ni suivre Redirect-to-IP comme si l’intention SR n’avait jamais existé. Les paquets sont rejetés ou traités selon une politique locale d’échec.

Ce n’est pas une règle générale ordonnant de jeter toute annonce sans Color. Lorsque seule la redirection IP est présente, son traitement normal demeure. Le changement vise le message ambigu qui contient assez d’éléments pour annoncer une volonté SR, mais pas assez pour l’exécuter. La nouvelle version préfère rendre l’échec visible plutôt que choisir un autre chemin sans l’avouer.

Une route vivante, une action morte

La révision 18 sépare explicitement l’existence de la route de son exécution. Si la SR Policy correspondante est indisponible, impossible à résoudre ou absente du plan de données, la route FlowSpec reste valable dans la Loc-RIB dès lors qu’elle satisfait les contrôles BGP. Elle continue aussi d’être annoncée aux pairs en aval. Une panne de transport ne doit pas devenir automatiquement un retrait de l’instruction.

Dans le plan de données, le résultat est inverse : l’entrée de steering ne doit pas être activée, ou doit être marquée inactive. La même protection s’applique si la policy existe mais que le SID de service de sortie est injoignable. Le texte refuse alors un passage silencieux vers le plus court chemin IP. Le rejet est l’action locale recommandée par défaut, sans retirer à l’opérateur la possibilité de définir une autre politique. Les actions FlowSpec valables qui ne pilotent pas le chemin, telle une limitation de débit, restent applicables.

Cette dissociation protège la cohérence du contrôle et facilite un retour lorsque la policy redevient disponible. Elle rend aussi insuffisant un écran où la route apparaît en vert. Il faut observer séparément l’acceptation dans la Loc-RIB, la propagation, l’installation du steering et le résultat sur un paquet témoin.

Le projet demande des notifications, des motifs d’échec et des compteurs de paquets ou d’octets rejetés. Lors d’une rafale d’erreurs ou d’un épuisement de ressources, les messages individuels peuvent être agrégés, limités ou supprimés pour protéger le plan de contrôle. Dans ce cas, l’absence d’alarme ne vaut pas absence d’échec : l’état de suppression et les compteurs agrégés font partie de la preuve.

Le vieux headend ne lit pas l’intention nouvelle

La branche la plus délicate concerne un récepteur qui sait appliquer FlowSpec et Redirect-to-IP, mais pas cette extension. L’attribut Prefix-SID est optionnel et transitif. Un tel équipement peut le propager sans le comprendre, l’ignorer pour sa propre décision et appliquer la redirection IP habituelle.

Les octets peuvent donc traverser le réseau sans être altérés tout en recevant deux interprétations opérationnelles. Le headend conforme à la révision 18 reconnaît une intention SR incomplète et refuse le repli. L’ancien équipement ne connaît pas cette catégorie et redirige. Ni l’un ni l’autre n’a nécessairement subi une erreur de parsing ; la différence vient de la capacité annoncée — ou, ici, non annoncée.

Le projet répond par des contrôles administratifs : permettre ou interdire l’envoi des attributs de service par voisin et par service, puis filtrer aux frontières du domaine de confiance. Cette clôture reste aveugle si l’émetteur ne sait pas quelle version chaque destinataire exécute. Un inventaire de capacités et une mise en service par groupe homogène sont donc nécessaires avant toute diffusion large.

Le test décisif est négatif. Il faut envoyer les combinaisons pertinentes à un équipement compatible et à un équipement non compatible, retirer la Color, rendre la policy indisponible, rendre le SID injoignable et provoquer un échec d’installation. Pour chaque cas, le dossier doit montrer Loc-RIB, annonce aval, FIB, compteur de rejet, compteur de redirection, paquet témoin, alarme et reprise.

Le consensus ne se transmet pas d’une révision à l’autre

Le shepherd write-up rattache l’accord antérieur à une consultation brève d’une semaine sur la révision 13, avec un soutien positif. Le contrôle par l’Area Director a ensuite fait apparaître deux modes, une résolution séquentielle des attributs, davantage de fonctions de service, de nouvelles règles de compatibilité et un traitement plus précis des défaillances.

Le 26 août, après la révision 17, l’Area Director responsable a demandé aux présidents IDR de sonder à nouveau le groupe avant toute progression. Le Datatracker a placé le document en External Party. Le 5 septembre, la révision 18 a encore modifié le contrat : elle a inversé le repli du cas incomplet, ajouté l’injoignabilité du SID, détaillé la construction de la liste de segments et renforcé les obligations de filtrage et de visibilité.

Redemander un avis n’est pas une formalité décorative. On peut soutenir le mécanisme général tout en considérant qu’une coupure est plus grave qu’un détour, ou l’inverse. La réponse dépend du service, de l’autorité opérationnelle et de la possibilité de prouver la défaillance. Un consensus sur un tableau qui prescrivait la redirection ne vaut pas mécaniquement consentement à un tableau qui refuse cette redirection.

La question publique devrait donc citer la révision et ses choix : refus du fallback pour une intention SR incomplète, conservation de la route dans le contrôle, policy locale d’échec, cas du SID injoignable et comportement d’un headend non compatible. Les objections et le raisonnement des présidents doivent rester consultables avec le résultat.

Le code ancien ne certifie pas la sémantique actuelle

Le projet recense quatre routeurs et quatre contrôleurs ayant participé à des essais d’interopérabilité organisés par China Mobile entre juillet et octobre 2021. Il indique également une utilisation en production sur le backbone de China Mobile depuis août 2022. Ce sont des éléments utiles, mais le texte rappelle qu’ils proviennent des contributeurs, n’ont pas été vérifiés indépendamment et ne constituent pas une approbation de l’IETF.

La chronologie empêche un raccourci supplémentaire. Ces essais peuvent prouver qu’une famille de mécanismes fonctionnait. Les sources examinées ne montrent pas qu’ils aient testé le tableau de la révision 18, le SID de service devenu injoignable, le choix remplacer-ou-ajouter dans la liste de segments ou la coexistence d’équipements compatibles et anciens. Une phrase écrite en 2026 ne peut pas ajouter rétroactivement un cas à une campagne de 2021.

Il faut conserver l’expérience plutôt que l’amplifier. Chaque entrée d’implémentation devrait porter une version de projet, une version logicielle, les fonctions activées, les combinaisons testées et le résultat observé sur les paquets. Un nouvel essai pourra alors prolonger le dossier historique sans emprunter son autorité.

Un reçu lié à la version

Le premier volet du reçu proposé fixe la révision 18 et son empreinte, les dates de la consultation, la question, les réponses archivées, les objections techniques et l’évaluation des présidents. Le second reproduit la matrice d’essai : redirection simple, modes 1 et 2 valables, Color absente ou malformée, policy indisponible, SID injoignable et échec FIB.

Chaque ligne relie l’état du contrôle à l’effet réel : route acceptée, route propagée, action installée, paquet rejeté ou redirigé, compteur, notification et éventuelle suppression des journaux. Une colonne distincte indique le comportement d’un récepteur ne prenant pas en charge l’extension.

Le volet de déploiement nomme l’émetteur, les groupes de récepteurs, leurs capacités, les filtres, les plages de SID autorisées, la politique locale d’échec, la reprise automatique et le seuil de retour arrière. Les adresses sensibles peuvent être pseudonymisées. La correction d’un résultat s’ajoute au dossier au lieu d’effacer le premier constat.

La discipline de spécification minimale de Heng Lu ne sert ici que de grille éditoriale. Le noyau commun doit avoir un sens assez déterministe pour être testé. L’opérateur garde la décision locale sur la perte acceptable et le périmètre. Sans version, sans inventaire des capacités et sans observation du paquet, ni le standard ni l’autonomie locale ne sont réels.

La révision 18 peut constituer un meilleur choix. Elle n’a pas encore le droit d’emprunter le consentement de la révision 13 ni les essais de 2021. Il faut accepter le texte présent et vérifier les deux générations de headends avant de donner au projet l’autorité d’une norme.

Sources

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — texte de la révision 18
  3. IETF — texte de la révision 17
  4. IETF Author Tools — comparaison des révisions 17 et 18
  5. IETF Datatracker — historique du document
  6. Liste IDR — demande de nouvelle vérification du consensus
  7. IETF — rapport du shepherd
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification