Résumé
- Un point de fusion assurant la protection d’un nœud doit conserver l’état du LSP après un Conditional PathTear compatible. Un autre destinataire peut devoir le supprimer et transmettre un PathTear ordinaire.
- Remote PathTear permet au point de réparation de nettoyer l’état distant sans attendre la fin de la signalisation de secours, notamment après une annulation, un échec de réparation ou un changement de chemin.
- Une capacité annoncée à tort peut laisser des états périmés en place ou, au contraire, détruire trop tôt un état nécessaire. Le fonctionnement mixte se décide par direction et par LSP.
Deux erreurs qui se ressemblent peu
Une réservation demeure après la panne : le nettoyage semble incomplet. Une réservation disparaît aussitôt : le nettoyage paraît efficace. Cette lecture récompense parfois la mauvaise action. Un état conservé peut être indispensable à la protection, tandis qu’une suppression immédiate peut empêcher la continuité prévue.
Le RFC 9705, publié en mars 2025 sur la voie de normalisation, rend cette distinction explicite. Son Conditional PathTear ne signifie pas « effacer partout ». Le destinataire doit tenir compte d’un rôle déjà établi. Le document décrit des scénarios normatifs, pas les résultats d’un déploiement observé.
La difficulté vient du temps laissé à la signalisation. Les procédures de protection par tunnel de contournement du RFC 4090 utilisaient l’expiration des rafraîchissements pour éliminer certains états abandonnés. Si une suppression arrive avant la signalisation de secours, elle peut effacer l’état nécessaire au point de fusion. Allonger l’intervalle de rafraîchissement expose au problème inverse : les états réellement inutiles restent longtemps. La nouveauté consiste à préciser pourquoi conserver et quel événement autorise à supprimer.
Le rôle précède le message
Un LSP est un chemin à commutation d’étiquettes. RSVP distingue son état de chemin, PSB, de son état de réservation, RSB. Le point de réparation locale, PLR, détourne le chemin protégé vers un contournement ; le point de fusion, MP, raccorde cette protection à la suite du LSP.
Un LP-MP protège le lien depuis le saut précédent. Un NP-MP correspond à la protection offerte par le routeur situé deux sauts en amont, autour du routeur intermédiaire. Ces rôles appartiennent à un LSP donné. Un équipement peut cumuler les deux sans les exercer pour tous les chemins qu’il transporte.
Le rôle ne découle pas seulement de la topologie. Il faut une association B-SFRR-Ready correspondante désignant le destinataire du contournement, une adjacence de signalisation Node-ID opérationnelle avec le PLR identifié et l’annonce de la capacité RI-RSVP. Le mécanisme d’association provient du RFC 8796. Prendre en charge la signalisation récapitulative de ce texte ne prouve pas que l’équipement exécute le nettoyage défini par RFC 9705.
Le rôle établi avant l’incident donne donc son sens à la consigne négative reçue ensuite. Un routeur ne peut pas se déclarer point de protection après coup pour justifier un état qui persiste.
Le détour exige parfois de ne rien effacer
Dans la topologie du RFC, A–B–C–D, A dispose d’un contournement de B qui rejoint C. C est le NP-MP de A. Si le lien A–B tombe et que B n’est pas lui-même un MP pour ce LSP, B efface son PSB et son RSB. Lorsque l’entrée a demandé une protection de nœud et qu’aucun PathTear amont n’a été reçu, B émet un Conditional PathTear.
C conserve l’état du LSP. Un destinataire qui n’est pas NP-MP le supprime, retire l’objet facultatif CONDITIONS et transmet un PathTear ordinaire. La condition ne doit pas voyager aveuglément de routeur en routeur.
L’annonce de capacité est une autre condition préalable. Si le voisin émetteur n’a pas annoncé la prise en charge des nouvelles procédures, le message conditionnel est traité comme un PathTear normal : suppression et propagation. L’objet CONDITIONS n’accorde aucun pouvoir autonome à son expéditeur.
Cet objet porte le numéro de classe 135 et le C-Type 1. Son indicateur de condition de fusion active le traitement selon le rôle ; sans lui, le traitement reste ordinaire. Il faut lire la règle détaillée : elle exige le rôle NP-MP pour la conservation, et ne confère pas ce privilège à tout équipement appelé « point de fusion ».
Préserver le chemin, retirer une ancienne promesse
Supposons que B ait aussi annoncé une protection de nœud dont D est le point de fusion. Après sa suppression locale, B ne peut plus soutenir cette ancienne association. C doit pourtant conserver le LSP pour A.
Les deux obligations se concilient. C retire de son Path l’association B-SFRR-Ready de B et déclenche un Path vers D. D supprime alors l’état de chemin distant associé à B. Si le retrait de cette association constitue l’unique changement, D ne propage pas ce Path plus loin. La réservation utile survit, tandis que l’ancien rôle de protecteur disparaît.
Cet état distant sert à identifier une future suppression explicite. Son RSVP_HOP contient l’adresse Node-ID du PLR. Il ne constitue pas une réservation supplémentaire pour le client. Effacer cette référence n’équivaut donc pas nécessairement à effacer les PSB et RSB du chemin protégé.
La conservation n’est pas illimitée. Un LP-MP peut garder l’état après la panne du lien précédent tant que l’adjacence avec le PLR subsiste ; la panne de ce routeur précédent impose une suppression normale. Un NP-MP peut survivre à la perte du lien ou du nœud intermédiaire tant que son PLR plus distant reste présent, sous réserve des événements de suppression prévus. Quand un routeur cumule les deux rôles, la perte d’une seule adjacence après une panne de lien ne suffit pas forcément. Les délais de grâce d’un redémarrage gracieux interviennent aussi avant de déclarer l’adjacence défaillante.
Une voie distincte pour mettre fin à l’attente
Remote PathTear traite le cas où l’attente n’a plus d’objet. L’entrée ordonne le retrait du LSP alors que le PLR commence une réparation locale, avant la fin de la signalisation de secours. Si le PLR effaçait uniquement son propre état, le MP pourrait attendre une opération déjà annulée.
Le PLR adresse donc une suppression au Node-ID du MP, avec l’identité correspondant à leur adjacence. La procédure ne suppose ni contournement fonctionnel ni signalisation de secours achevée. Le PLR supprime son état ; le MP supprime les PSB et RSB correspondants. En cas d’échec de la réparation locale, le MP propage aussi la suppression vers la sortie.
Un changement du RRO reçu dans Resv peut également retirer l’ancien NP-MP du chemin. Le PLR doit alors lui envoyer directement un Remote PathTear. Dans l’exemple du RFC, B a déjà établi la signalisation de secours vers D quand A fait nettoyer l’ancien point C. C transmet un PathTear normal à D, mais D conserve l’état soutenu par la nouvelle signalisation de B. Une suppression distante n’ordonne donc pas l’effacement universel de tout état en aval.
La préemption crée encore un autre ordre d’événements. Si un MP perd la réservation après la panne du lien amont, mais avant l’arrivée de la signalisation de secours, il supprime l’état et transmet un PathTear normal. Le RFC décrit le rejet d’un Path de secours arrivé ensuite, faute d’état à retrouver. Il ne rapporte pas une panne actuelle chez un fournisseur.
La compatibilité a un sens de circulation
Le RFC 8370 associe des rafraîchissements espacés à des exigences de fiabilité, d’accusé de réception et de détection des adjacences. Le RFC 2961 fournit les mécanismes de livraison fiable. RFC 9705 complète cet ensemble pour la protection par contournement partagé. Une implémentation de cette protection ne doit pas annoncer RI-RSVP sans prendre en charge toutes les nouvelles procédures.
Une annonce mensongère produit deux risques différents. Un B incapable d’envoyer le message attendu peut laisser l’état périmé survivre jusqu’au long délai d’expiration. Un C incapable de comprendre CONDITIONS peut appliquer une suppression ordinaire et détruire un LSP qu’il devait préserver. Le même indicateur erroné n’entraîne pas le même symptôme selon la place du routeur.
Le fonctionnement mixte correct revient volontairement à des délais courts. L’absence de support en aval raccourcit le rafraîchissement porté par Path et interdit les nouveaux Conditional et Remote PathTear sur le segment concerné. L’absence de support en amont modifie les valeurs pertinentes de Resv, parfois aussi de Path, et désactive les nouvelles procédures de conservation du MP. La protection de nœud exige aussi le support du routeur intermédiaire. Les deux directions d’un même équipement peuvent ainsi fonctionner différemment.
Ces règles établissent une logique de nettoyage, pas un délai de rétablissement mesuré, une capacité disponible ou un taux d’adoption. Leur intérêt opérationnel est de rendre la conservation aussi explicable que la suppression.
Sources
- RFC 9705 : protection et suppression indépendantes des courts rafraîchissements
- RFC 4090 : protection locale et contournements
- RFC 8796 : associations et signalisation récapitulative FRR
- RFC 8370 : passage à l’échelle et capacités RSVP-TE
- RFC 2961 : réduction des rafraîchissements et livraison fiable
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

