Résumé

  • La section 2.1 de RFC 9791 décrit le besoin de marquer un paquet déjà dévié par FRR afin d’empêcher une nouvelle réparation susceptible de créer une boucle. Le document est Informational, publié en juillet 2025 : il expose un cas d’usage, pas une action NFFRR complète.
  • NFFRR déplace un droit de décision. Le premier point de réparation locale ne choisit plus seulement un détour ; il peut, en marquant le paquet, demander aux nœuds suivants de renoncer à une réparation qu’ils auraient autrement considérée utile. Ce veto n’est sûr que si les hypothèses de panne, de topologie, de capacité et de confiance restent valides.
  • Les deux brouillons NFFRR cités ici sont expirés. Leur encodage, leur signalisation et, dans le brouillon MNA, le bit « TBA1 » ne constituent ni une allocation IANA actuelle ni une preuve de déploiement. Au 20 septembre 2026, le registre IANA « Network Action Flags Without Ancillary Data » ne comportait aucune entrée NFFRR.
  • Une politique crédible de retenue FRR doit produire davantage qu’un bit. Elle doit permettre de reconstruire pourquoi une première réparation a été autorisée, pourquoi la suivante a été refusée et quelles observations permettent ensuite de juger si cette retenue a protégé le réseau ou simplement transformé une possibilité de livraison en perte.

Deux décisions locales raisonnables peuvent former une mauvaise décision globale

L’exemple EVPN du draft-kompella-mpls-nffrr-04 est utile précisément parce qu’il n’exige aucun routeur manifestement irrationnel. CE2 est indisponible. PE2 interprète la situation comme une défaillance de son lien vers CE2 et utilise le chemin de secours vers PE3. PE3 observe symétriquement l’échec de son propre attachement et protège ce qu’il croit être une seconde panne locale en renvoyant vers PE2. La panne unique du CE se présente donc comme deux défaillances distinctes aux deux PE.

La boucle est une propriété de composition. Chaque nœud agit avec une information locale cohérente ; le résultat collectif est pourtant un ping-pong jusqu’à expiration du TTL, avec consommation inutile de ressources sur le chemin de secours. NFFRR propose de casser cette composition : une fois le paquet réparé, une marque signifie en substance « ne tentez pas une deuxième FRR ».

RFC 9791, section 2.1, retient ce cas d’usage dans le cadre MNA. Mais son statut compte : RFC 9791 est Informational, daté de juillet 2025. Il établit le problème et l’intérêt d’un indicateur ; il ne définit pas à lui seul une action NFFRR déployable avec toutes ses règles d’encodage, d’interopérabilité, de sécurité et d’exploitation.

Une marque qui ressemble à un bit mais exerce un veto

Considérer NFFRR comme un simple mécanisme anti-boucle masque le transfert d’autorité qu’il introduit. Le premier PLR — le Point of Local Repair au sens de la tradition FRR de RFC 4090 — prend deux décisions au lieu d’une. D’abord : « cette panne mérite une réparation locale ». Ensuite : « toute réparation locale ultérieure de ce même paquet doit être interdite ».

La seconde décision est plus forte. Elle lie un nœud aval qui peut observer un autre symptôme, disposer d’un autre chemin de secours et avoir une connaissance plus récente de son environnement. Refuser cette nouvelle réparation revient à préférer une perte déterministe à un risque de boucle.

Ce choix peut être rationnel, mais il dépend du modèle. RFC 5286 rappelle que l’existence d’un alternate sans boucle dépend de la topologie et de la nature de la panne considérée. RFC 7490 examine explicitement des situations où deux points de réparation peuvent se protéger l’un via l’autre et former une boucle, notamment lorsque le modèle de panne devient plus complexe. RFC 9855 montre à son tour combien les garanties de réparation sont liées à la représentation de la topologie et du scénario protégé.

La question correcte n’est donc pas : « une deuxième FRR est-elle mauvaise ? » Elle est : « dans quelles conditions l’information détenue par le premier réparateur suffit-elle pour retirer aux suivants leur droit de réparer ? »

Le statut normatif impose de séparer cadre, encodage et action

RFC 9789 fournit le cadre des MPLS Network Actions, notamment les notions de portée et de capacités nécessaires au traitement. Il ne transforme pas chaque cas d’usage cité ailleurs en action automatiquement disponible.

RFC 9994, Proposed Standard publié en juin 2026, définit l’encodage générique in-stack des MNA. Il spécifie notamment les portées I2E, Hop-by-Hop et Select, le placement des sous-piles d’actions et le traitement d’une action inconnue. Pour une action que le nœud ne comprend pas, U=0 conduit à passer à l’action suivante ; U=1 conduit à abandonner le paquet, avec maintien d’un compteur local recommandé et possibilité de notification limitée en débit.

Ces règles sont importantes pour NFFRR, mais elles ne définissent pas NFFRR. Elles disent comment transporter et traiter des actions selon un cadre commun ; elles ne décident pas qu’un bit donné signifie « No Further Fast Reroute ».

Cette distinction est visible dans le registre IANA MPLS Network Actions. Au 20 septembre 2026, « Network Action Flags Without Ancillary Data » ne contenait aucune inscription. Le draft-li-mpls-mna-nffrr-01 proposait un indicateur à la position « TBA1 » et des portées Hop-by-Hop et Select, mais ce brouillon est expiré. Le draft Kompella est lui aussi expiré et ses propositions de mécanisme et de signalisation restent des éléments documentaires, pas des allocations actuelles ni des preuves de comportement en production.

Les cinq états dangereux d’une marque

Une marque NFFRR ne mérite confiance que si sa provenance et sa fraîcheur sont aussi solides que sa syntaxe.

Fausse. Le brouillon Kompella avertit qu’un LSR malveillant ou compromis peut insérer NFFRR et empêcher une réparation qui aurait réussi. Le mécanisme anti-boucle devient alors un mécanisme de suppression de résilience. Le problème rejoint la sécurité MPLS plus générale exposée par RFC 5920 et les préoccupations de frontière reprises par le cadre MNA.

Absente. Si le premier PLR répare sans marque alors que le second applique à son tour une FRR incompatible, le risque initial réapparaît. L’absence peut provenir d’un nœud non capable, d’une politique différente, d’un problème de placement ou simplement d’une action NFFRR inexistante dans l’environnement considéré.

Périmée. Une retenue correcte au moment de la première panne peut devenir incorrecte après convergence, modification de topologie ou apparition d’un événement indépendant. Une marque qui survit au contexte ayant justifié son insertion transforme une décision temporelle en interdiction sans réévaluation.

Usurpée. Une action acceptée depuis une frontière insuffisamment filtrée donne à une partie extérieure un droit indirect sur les mécanismes de protection du domaine. La capacité à reconnaître une syntaxe MNA ne doit donc jamais être confondue avec l’autorisation de faire confiance à sa provenance.

Mal comprise. Un chemin peut contenir des nœuds capables de lire une sous-pile MNA, d’autres qui ne le peuvent pas, et des nœuds qui comprennent MNA sans connaître une action particulière. RFC 9994 définit des règles génériques de portée, de profondeur de lecture et d’action inconnue. Cela ne constitue pas une preuve qu’un chemin donné possède une interprétation NFFRR homogène.

Les capacités mixtes rendent le veto partiel

Un opérateur pourrait être tenté de traiter la capacité MNA comme une propriété binaire : capable ou incapable. Pour NFFRR, cette abstraction est trop faible. Il faut distinguer au moins la capacité à exposer correctement le NAS, la profondeur lisible, la compréhension de l’action particulière, la politique associée et la confiance accordée à l’entité qui l’a insérée.

Un veto qui n’est compris que sur une partie du chemin ne possède pas la même sémantique qu’un veto de bout en bout. À l’inverse, choisir un traitement strict d’action inconnue peut protéger la cohérence au prix d’un abandon supplémentaire. Le choix U=0/U=1 de RFC 9994 illustre exactement ce type d’arbitrage générique sans résoudre le cas NFFRR lui-même.

La capacité partagée entre plusieurs trafics ajoute une autre dimension. Une boucle de réparation peut consommer un chemin de secours au détriment de flux qui n’ont rien à voir avec la panne initiale. Interdire la deuxième réparation peut donc protéger une ressource commune. Mais le coût est individuel et immédiat : le paquet marqué qui aurait pu être sauvé par une deuxième réparation est volontairement abandonné. La politique doit dire qui est autorisé à effectuer cet échange entre protection collective de capacité et probabilité de livraison d’un flux particulier.

Proposition éditoriale : un « reçu de retenue FRR »

Ce qui manque à un simple indicateur est une preuve exploitable après l’événement. Je propose donc, comme proposition éditoriale de Daniel Kade et non comme exigence d’un RFC, un « reçu de retenue FRR ». Il ne s’agit pas nécessairement de transporter tous ces éléments dans le paquet. Le reçu peut être construit par corrélation de télémétrie, d’état de contrôle et d’observations du plan de données.

Il devrait conserver :

  • la classe de service concernée ;
  • la première observation de panne et la seconde observation de panne ;
  • l’identité du premier PLR et la méthode de réparation utilisée ;
  • la version de topologie employée et le modèle de panne supposé ;
  • l’identité de l’action, sa portée, son point d’insertion et son placement dans la pile ;
  • la preuve de capacité des nœuds dont le traitement était attendu ;
  • la provenance de la marque et le filtrage appliqué aux frontières ;
  • la reconnaissance aval observée et la disposition finale du paquet ou du flux ;
  • les compteurs pertinents, ainsi que les observations de congestion et de pertes ;
  • le propriétaire de la politique ayant autorisé la retenue ;
  • le déclencheur prévu de révision ou d’expiration de cette décision.

Le but n’est pas d’alourdir chaque paquet avec un journal d’audit. Il est de rendre falsifiable l’affirmation selon laquelle « empêcher la deuxième FRR était l’option la plus sûre ». Sans reconstruction possible, une baisse des boucles et une hausse des pertes peuvent être confondues ; inversement, des abandons volontaires peuvent être présentés comme une protection réussie faute de pouvoir montrer les alternatives réellement disponibles.

Aucune des sources examinées ici ne fournit de mesure d’incident NFFRR en production, de preuve d’implémentation fournisseur, de résultat d’interopérabilité, de mesure de prévalence ou d’effet quantifié. Le reçu proposé vise précisément à définir le type de preuve qu’un futur déploiement devrait produire avant que la retenue ne soit traitée comme une propriété de sûreté établie.

Sources