Résumé

  • Le TLV BFD Reverse Path de RFC 9612 permet à l’entrée d’un LSP MPLS de demander que les paquets BFD Control reviennent par un FEC déterminé. Il rend la demande vérifiable, pas l’alarme directionnelle.
  • Le code 193 peut coexister avec une session BFD active : le retour demandé est introuvable, tandis qu’une politique locale autorise un retour IP différent. Refus, chemin réel et disponibilité sont trois reçus.
  • Une attribution sérieuse relie intention, TLV, réponse, trajet effectivement pris, résultat BFD, vérification Reply Path, redirection, notification et résultat applicatif.

À 02 h 14, l’alarme tombe. Le centre d’exploitation sait qu’un échange BFD ne respecte plus son délai. Il ne sait pourtant pas encore quel côté du voyage a cessé de fonctionner. Le LSP aller peut être rompu. Le FEC choisi pour le retour peut avoir changé. Le routeur de sortie peut ne plus trouver le retour demandé. Une voie IP locale peut même maintenir la session après le refus de cette demande.

Cette incertitude n’est pas une faiblesse accidentelle de l’alarme. Elle vient de l’objet observé. BFD reçoit un signe de vie après un aller et un retour. L’absence du signe indique que la boucle n’a pas été complétée ; elle ne désigne pas spontanément le segment fautif. Donner à l’alarme le nom du LSP aller reviendrait à ajouter une conclusion qui n’a pas traversé le réseau.

RFC 9612, publié dans la catégorie Experimental, réduit cette ambiguïté sans promettre de l’abolir. Il ajoute aux requêtes MPLS LSP echo un TLV BFD Reverse Path. L’entrée peut y placer des sous-TLV Target FEC Stack non multicast afin que la sortie expédie les paquets BFD Control sur le retour choisi. Le trajet observé devient intentionnel et documentable.

Le mécanisme respecte une frontière utile. Les pairs partagent la syntaxe minimale de la demande et des erreurs. La sortie conserve sa politique locale de repli. L’exploitation doit ensuite produire les preuves de ce qui a réellement circulé. Une norme commune ne remplace ni la table de transfert, ni la capture de paquets, ni le résultat du service.

Ce que l’alarme sait exactement

RFC 5880 fournit une détection rapide de continuité entre deux systèmes. Dans l’usage MPLS de RFC 5884, le paquet peut suivre le LSP surveillé à l’aller et une route IP au retour. Cette combinaison est pratique, mais elle répond à « les extrémités échangent-elles encore ? », pas à « l’aller est-il seul en bon état ? ».

Le TLV inverse introduit un retour déterminé. Son type IANA est 16384. Il accepte zéro ou plusieurs sous-TLV FEC compatibles. Les FEC multicast sont exclus et provoquent le code de retour 192. La limite par défaut de 128 entrées évite qu’une requête gonflée impose un travail ou un état sans borne à la sortie.

Ces détails rendent la conversation précise. Ils ne changent pas la nature composite de l’observation. Si le contrôle BFD s’arrête, l’aller ou le retour peut être en cause. Si le retour choisi ne correspond plus au FEC, la session peut tomber avant que le contrôle périodique n’ait constaté le changement. Le premier reçu est donc une rupture de continuité, pas une attribution.

Une équipe qui ouvre automatiquement un incident « LSP aller en panne » fabrique une certitude. Elle risque d’envoyer les techniciens vers les mauvais nœuds, de masquer un changement sur le retour et de mesurer un temps de réparation qui ne correspond à aucune cause réelle. La bonne étiquette est provisoire : boucle BFD interrompue, direction à vérifier.

Le refus peut être vrai pendant que le service de contrôle vit

Le code 193 est la démonstration la plus nette de cette discipline. La sortie doit le renvoyer lorsqu’elle ne trouve pas le chemin inverse spécifié. Il atteste l’échec de la demande précise. Il n’atteste pas l’impossibilité de toute session BFD.

Si la configuration locale l’autorise, la sortie peut envoyer les paquets de contrôle par un autre chemin, notamment par routage IP. Le tableau peut alors afficher BFD Up alors que le chemin demandé n’existe pas. Il faut conserver les deux faits. Effacer le code 193 parce que la session est verte confond disponibilité de secours et conformité. Déclarer une panne totale parce que le code existe ignore le repli réel.

Ce cas oblige à séparer au moins quatre états : retour demandé trouvé ou non ; voie de repli autorisée ou non ; session BFD active ou non ; service utilisateur livré ou non. Les combinaisons ont des sens opérationnels différents. Une session active sur le mauvais retour peut violer une exigence de diversité physique tout en préservant la connectivité. Un BFD en panne peut coexister avec un service déplacé ailleurs.

Le retrait est lui aussi explicite. Un TLV Reverse Path vide annule le chemin inverse précédemment demandé et remet la décision entre les mains de la politique locale. Après l’installation d’un retour spécifique, une requête LSP ping qui contient le discriminateur BFD mais omet le TLV Reverse Path ramène également l’émission périodique au comportement RFC 5884. L’absence du TLV a donc un effet de transition qu’il faut journaliser.

La résolution d’un FEC n’est pas immobile

Une configuration valable lors de l’établissement peut devenir fausse plus tard. Maintenance, reconvergence ou modification de politique peuvent changer la façon dont un FEC inverse se résout. RFC 9612 exige pour cette raison que le changement de retour soit supporté après la création de la session.

La chronologie crée une zone d’incertitude. Les paquets BFD circulent rapidement afin de détecter la rupture en peu de temps. Les vérifications de plan de contrôle et de plan de données au moyen de LSP ping et du TLV Reply Path sont beaucoup plus espacées. Un changement de FEC peut donc produire d’abord une alarme, puis seulement ensuite une explication.

L’entrée doit vérifier la validité du FEC inverse à l’aide du Reply Path TLV. Si le FEC a changé, elle doit rediriger la session vers un autre FEC et informer un opérateur. Ces verbes décrivent trois responsabilités distinctes : apprendre la réalité, modifier l’action automatique et rendre l’écart visible à une personne responsable.

La maintenance planifiée peut déplacer le retour de façon proactive. Elle réduit certains incidents mais n’annule pas l’écart des horloges. Une modification imprévue peut toujours se produire entre deux vérifications. La promesse honnête n’est pas « aucune alarme ambiguë » ; c’est « toute ambiguïté conserve sa preuve et déclenche une vérification bornée ».

Demander n’est pas commander

Le TLV exprime une préférence interopérable. Il ne transfère pas à l’entrée la propriété de la politique de sortie. Celle-ci décide si un repli est permis, combien de sous-TLV elle accepte et quelles ressources elle consacre à la recherche. Ce partage protège l’autonomie opérationnelle des deux domaines.

L’autonomie ne doit toutefois pas devenir opacité. Si la sortie choisit une route IP différente, ce fait doit apparaître dans la télémétrie. Sinon le pair pense surveiller une paire de chemins maîtrisée alors qu’il surveille une boucle choisie localement. La liberté de repli est saine ; le repli silencieux détruit la valeur de la demande.

Les limites de sécurité confirment cette lecture. Une liste de FEC sans borne créerait une surface d’épuisement. La limite par défaut de 128 permet une défense commune, sans imposer que 128 soit une cible. Le code 192 refuse précisément les constructions multicast incompatibles. Une erreur nommée protège mieux qu’un comportement implicite.

Le statut Experimental doit rester dans sa couche. Il indique le cadre de publication et l’apprentissage attendu. Il ne prouve pas qu’un équipement implémente correctement le TLV, qu’un opérateur l’a activé ou que le mécanisme bénéficie de la maturité Standards Track. Seul un essai du produit et du réseau courant peut établir ces propositions.

Constituer le dossier de preuve

Avant toute panne, le dossier doit contenir le LSP aller voulu, le FEC inverse demandé, le contenu du TLV, la réponse et le chemin réellement observé. Les compteurs BFD ajoutent le résultat de continuité, mais ne doivent pas écraser les champs précédents.

Après une alarme, l’équipe ajoute le résultat Reply Path, la résolution actuelle du FEC, la nouvelle cible éventuelle, l’heure de redirection et la notification. Elle mesure ensuite la livraison à la frontière applicative. Cette dernière étape est essentielle : le réseau de contrôle n’est pas le client du réseau.

Un test de conformité doit exercer le succès, mais aussi les transitions. Il demande un FEC existant, vérifie le trajet des paquets, puis change le FEC après établissement. Il demande ensuite un FEC inexistant et observe le code 193 avec et sans repli. Il présente un FEC multicast pour obtenir le code 192, envoie un TLV vide, puis un discriminateur sans TLV inverse. Enfin il dépasse la limite configurée et confirme un refus borné.

Chaque essai rapproche messages et réalité de transfert. Une API peut annoncer la sélection correcte alors que le matériel en utilise une autre. Une capture peut montrer un repli que le système de gestion ne signale pas. Les deux plans doivent concorder avant de conclure à l’identité du chemin.

Le dossier idéal n’essaie pas de réduire toutes les réponses à vert ou rouge. Il peut conclure : « le FEC inverse demandé a disparu ; la sortie a renvoyé 193 ; un repli IP a gardé BFD actif ; le service est resté disponible ; Reply Path a trouvé un nouveau FEC ; la session a été redirigée et l’opérateur averti ». Cette phrase est plus longue parce qu’elle décrit la réalité au lieu de la remplacer.

Sources