Résumé

  • Un nouveau projet du groupe MPLS permet à l’ingress RSVP-TE de demander aux points de réparation locale des objectifs d’optimisation et des bornes métriques strictes pour leurs LSP de secours. Le PLR active FRR_EXT protection s’il respecte la demande ; s’il n’y parvient pas, il peut appliquer sa politique locale sans activer ce drapeau.
  • Ce bit constitue une attestation minimale, pas l’historique de la décision. Il faut conserver, pour chaque PLR, la demande exacte, sa capacité à la comprendre, la politique locale effectivement utilisée, l’âge des métriques, le contexte de calcul et les preuves ultérieures de validité.

Le quatrième routeur ne répond pas à la même question

Un opérateur protège un LSP traversant plusieurs nœuds. À l’ingress, il demande que chaque chemin de secours minimise le délai moyen, reste sous une borne cumulée et évite tout lien dépassant une variation maximale. Trois points de réparation renvoient le nouveau drapeau. Le quatrième n’en renvoie pas.

Le centre d’exploitation aimerait traduire l’écran en deux couleurs : conforme ou défaillant. Or le quatrième résultat peut correspondre à des réalités différentes. Le routeur peut ne pas connaître l’extension et l’avoir ignorée conformément aux règles de compatibilité. Il peut la connaître, ne trouver aucun chemin satisfaisant toutes les bornes, puis revenir à sa politique locale. Il se peut aussi que l’ingress n’ait transmis aucune configuration explicite, laissant dès le départ la décision au PLR.

Dans chacun de ces cas, un secours peut exister. Dans aucun, l’absence du bit ne suffit à identifier la règle qui a produit ce secours. Le problème n’est donc pas de forcer un sens supplémentaire dans un drapeau. Il est d’empêcher qu’une interface compacte efface la chaîne d’autorité qui se trouve derrière.

Une extension devenue travail du groupe MPLS

draft-ietf-mpls-frr-ext-00 a été publié le 23 août 2026 sous le titre Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels. Le Datatracker le classe parmi les documents actifs du groupe MPLS, avec l’état IESG I-D Exists. Son en-tête vise le Standards Track et annonce une expiration au 24 février 2027. Il ne s’agit ni d’un RFC, ni d’une approbation de l’IESG, ni d’une preuve de déploiement.

Cette première version au nom du groupe succède à draft-deshmukh-mpls-frr-ext-02. Le 18 août, le président du groupe a enregistré l’adoption du texte précédent et demandé sa republication sous le nom draft-ietf. L’annonce du 23 août confirme que la nouvelle version est un élément de travail du groupe. L’adoption précise qui porte le travail ; elle ne préjuge pas de sa forme finale.

Le point de départ est le RFC 4090. Celui-ci définit la réparation locale des LSP RSVP-TE et l’objet FAST_REROUTE, qui transporte notamment priorités, affinités, limite de sauts et bande passante. Le nouveau texte ajoute un objet compagnon extensible, FAST_REROUTE_EXT, pour transmettre des objectifs d’optimisation et des métriques bornées.

L’ingress peut demander que le secours hérite des objectifs et des bornes du LSP protégé, ou fournir d’autres valeurs. En l’absence de configuration explicite, la politique locale du PLR reste décisive. Le protocole distribue donc une intention ; il ne déplace pas tout le calcul vers un contrôleur unique.

Objectif et borne n’ont pas le même rôle

Un objectif classe les chemins admissibles. Le projet prévoit les métriques IGP et TE, la bande passante non réservée, ainsi que le délai minimal, moyen ou maximal. Les coûts et les délais sont minimisés ; la bande passante disponible est maximisée. Plusieurs objectifs distincts peuvent être présents, assortis d’un poids servant à la normalisation.

Une borne élimine au contraire les candidats qui ne satisfont pas une contrainte. Elle peut porter sur la totalité du chemin ou sur chaque lien. La variation du délai n’existe que comme borne de lien. Une même métrique peut donc recevoir une limite cumulée et une limite par lien. Si deux TLV répètent la même métrique avec la même portée, seul le premier est traité.

Cette mécanique offre une syntaxe exploitable par les équipements. Elle ne définit pas pourquoi l’opérateur a choisi telle borne, quelle marge protège un contrat, ni comment plusieurs unités ont été normalisées. Le texte dit expressément que les critères de sélection des objectifs et des métriques bornées se situent hors de son périmètre.

Cette frontière est saine pour un protocole. Elle devient dangereuse pour la gouvernance si l’organisation conserve les TLV mais pas la décision qui les a rendus autoritatifs.

Les quatre issues ne doivent pas être confondues

La première issue est la délégation voulue. Sans demande étendue explicite, le PLR calcule selon sa politique locale. La centralisation n’a jamais été promise.

La deuxième est la compatibilité. Un PLR qui ne comprend pas FAST_REROUTE_EXT doit ignorer l’objet et le transférer sans modification. Il applique sa politique. Le réseau mixte continue de fonctionner, mais l’inventaire des capacités devient un élément indispensable pour interpréter le résultat.

La troisième est le repli après échec de contrainte. Un PLR qui comprend l’objet traite les bornes comme des contraintes dures. S’il ne peut satisfaire la demande, il peut utiliser les objectifs et bornes de sa politique locale. Il ne doit alors pas positionner FRR_EXT protection dans le sous-objet RRO de la réponse Resv.

La quatrième est l’erreur structurelle. Si un PLR capable reçoit l’extension sans l’objet FAST_REROUTE compagnon, il doit rejeter le message Path avec une erreur de contrôle de politique. Cette erreur explicite n’est pas un simple repli.

Attribuer le même commentaire « non conforme » aux trois premières issues détruit l’information nécessaire à l’action. La délégation peut être acceptable. L’incompatibilité appelle une décision de migration. L’impossibilité de satisfaire une borne peut révéler une topologie, une mesure ou une exigence devenue irréaliste. L’erreur de structure doit être corrigée chez l’émetteur. Le drapeau seul n’organise pas ces responsabilités.

Ce que l’indicateur positif laisse encore ouvert

Lorsqu’un PLR satisfait la demande, il doit positionner l’indicateur dans le sous-objet RRO correspondant. L’ingress peut ainsi examiner chaque point de réparation plutôt que de déduire l’obéissance de tous à partir du succès global de la réservation. C’est un progrès réel.

L’attestation reste datée et limitée. Elle signifie que le PLR déclare avoir calculé un secours conforme aux objectifs et aux bornes reçus à cet instant. Elle ne transporte pas l’âge de la base TE, l’origine de la mesure, la version de l’algorithme, les candidats écartés ou la méthode de normalisation. Elle ne garantit pas que les valeurs resteront sous les bornes après un changement de topologie ou de charge.

Surtout, le bit n’est pas une preuve de basculement. Le RFC 4090 prépare des chemins locaux afin que le trafic puisse être détourné rapidement lors d’une panne. Une réponse Resv conforme ne démontre pas que le détecteur de panne agira correctement, que l’état de transfert restera installé, que le secours évite tous les risques physiques communs, ou que le trafic client respectera un objectif de bout en bout.

L’authentification cryptographique RSVP protège l’intégrité des messages lorsqu’elle est correctement déployée. Elle ne rend pas une mesure ancienne actuelle et ne documente pas une règle locale. Authentifier la déclaration et expliquer le jugement sont deux fonctions complémentaires.

Les chiffres ont une provenance

Les RFC 7471 et 7810 encadrent la diffusion d’attributs de performance pour OSPF et IS-IS. Ils aident à donner un sens technique au délai, à sa variation ou à la bande passante dans une base de trafic. Ils ne décident pas quelle observation un opérateur doit considérer comme suffisamment fraîche pour un secours donné.

Une moyenne mesurée récemment, une valeur configurée manuellement et un échantillon vieux de plusieurs minutes peuvent tenir dans le même type numérique. Une bande passante dite non réservée dépend elle aussi de la classe, du rythme de mise à jour et de l’état des réservations. Lorsque plusieurs objectifs sont combinés, leur normalisation ajoute une décision de méthode : le poids transmis ne raconte pas à lui seul comment des unités différentes ont été rendues comparables.

En cas de contestation, « la borne était 20 » n’est donc qu’un début de réponse. Il faut encore savoir quelle métrique a été lue, à quelle date, dans quelle topologie et par quelle version du calcul.

Le registre de provenance par PLR

Daniel Kade propose de conserver un registre de provenance des contraintes pour chaque couple LSP protégé–PLR. Ce registre n’est pas une extension normative du projet. Il appartient au plan opératoire de l’organisation.

Il commence par les identités : session protégée, ingress, PLR, ressource à protéger et point de fusion. Il conserve une empreinte exacte des objets FAST_REROUTE et FAST_REROUTE_EXT, puis chaque type de métrique, poids, borne, valeur et portée. Il enregistre la capacité du PLR, le résultat d’analyse, la présence de l’objet compagnon et le sous-objet RRO retourné.

Si le drapeau manque, le registre inscrit une cause observée : absence de demande, extension non comprise, contrainte impossible à satisfaire ou autre état établi. Il nomme la politique locale et sa version, l’autorité ayant approuvé une exception et sa date d’expiration. Il ne déduit pas une cause de la seule valeur binaire.

Le contexte de calcul suit : source et unité des métriques, heure d’observation, époque de la topologie ou de la base TE, méthode de normalisation, version du calculateur et identité du chemin de secours. Si l’indépendance physique est pertinente, le registre conserve les données de risques partagés réellement examinées au lieu d’assimiler deux routes logiques à deux destins indépendants.

Enfin, les preuves ultérieures restent dans une couche séparée. Les rafraîchissements indiquent quand l’attestation a été renouvelée. Un exercice de panne ou un incident réel montre si le basculement s’est produit. Ces événements peuvent être reliés au choix initial sans le réécrire.

Le dispositif ne publie pas la topologie, n’impose pas un algorithme commun et ne surcharge pas RSVP d’un journal. Il donne à l’autonomie locale une mémoire vérifiable.

Conserver le minimum commun sans perdre la décision locale

Un protocole n’a pas besoin de transporter toute la politique pour améliorer la responsabilité. La demande structurée et le drapeau par PLR constituent un minimum commun utile. Ils permettent aux implémentations de diverger tout en parlant d’un même résultat borné.

Mais le minimum ne doit pas devenir le maximum de ce que l’organisation sait. Un bit activé résume une conformité ponctuelle. Un bit non activé regroupe plusieurs chemins vers la politique locale. L’exploitation doit garder le complément : quelle autorité a choisi, avec quelles données, pour quelle durée et avec quelle procédure de retour.

L’alternative n’est pas entre obéissance centrale et chaos distribué. Elle est entre un repli local opaque et un repli local reconstructible. La seconde option protège à la fois la disponibilité du réseau et la possibilité de demander des comptes.

Sources