Résumé

  • La RFC 9862 représente une politique SR par une association PCEP et chacun de ses chemins candidats par un LSP. Le chemin est l'unité de signalisation, mais certaines décisions ne prennent sens qu'à l'échelle de l'association entière.
  • Le TLV INVALIDATION place le drapeau de configuration D sur un chemin candidat. Dès qu'un chemin l'active, Drop-Upon-Invalid est activé pour toute la politique SR ; ses effets n'apparaissent toutefois que lorsque tous les chemins candidats sont invalides.
  • Un reçu de rejet à l'échelle de la politique devrait réunir capacités négociées, membres complets, drapeaux configurés et opérationnels, instant du seuil collectif, porteur choisi et résultat observé sur les paquets. C'est une proposition éditoriale de Daniel Kade, non un champ de la RFC ni une obligation de l'IETF.

Un voyant rouge placé à côté d'un chemin semble décrire ce seul chemin. Il arrive dans un objet LSP, porte l'identifiant d'un chemin candidat et se range sans difficulté dans une ligne de base de données. Cette représentation est fidèle au protocole. L'interprétation locale qui en découle ne l'est pas nécessairement.

La configuration Drop-Upon-Invalid se trouve dans le TLV INVALIDATION d'un chemin candidat, mais la fonction ne s'applique pas à ce chemin isolé. Si un seul chemin candidat a le drapeau D de configuration, toute la politique SR possède la fonction. Rien n'est encore rejeté. Il faut qu'une autre condition se réalise : tous les chemins candidats de la politique deviennent invalides. La politique entre alors en état de rejet, retient le chemin activé dont la préférence est la plus élevée et continue d'attirer le trafic pour le jeter à la tête de réseau au lieu de le laisser rejoindre une solution de repli.

L'objet qui porte l'instruction, l'ensemble qui franchit le seuil, la politique qui change d'état et les paquets qui subissent la conséquence sont quatre unités différentes. Une seule valeur booléenne ne suffit pas à raconter leur relation.

Une grammaire de chemins pour une décision collective

Une politique SR peut disposer de plusieurs chemins candidats. La RFC 9862 introduit la SR Policy Association, ou SRPA, afin de représenter la politique dans PCEP ; chaque LSP membre représente alors un chemin candidat. Ce choix suit la grammaire de PCEP, dont l'unité de signalisation est le LSP. Le protocole peut ainsi annoncer, mettre à jour et rapporter chaque réalisation possible de la politique.

La commodité du modèle crée une exigence de preuve. Les informations relatives à la politique sont transportées au niveau du chemin candidat, même lorsque leur portée dépend de tous les membres. La SRPA fournit la relation, mais une télémétrie qui ne conserve que le LSP ayant déclenché une alarme perd l'ensemble au moment où elle en a le plus besoin. Un redémarrage de session, un ajout de chemin ou un échantillonnage incomplet peut effacer le contexte historique.

La couleur et le point de terminaison identifient la politique ; l'origine et le discriminateur distinguent le chemin candidat. Un chemin ne peut appartenir qu'à une SRPA, son identifiant demeure stable pendant la session PCEP et les doublons au sein d'une politique sont invalides. Ces garanties rendent la jointure réalisable. Elles ne créent pas à elles seules une photographie datée des membres utilisés lors de la décision.

La négociation de capacité a, elle aussi, une portée précise. Les deux pairs doivent annoncer leur prise en charge de l'association avant de l'employer. Un émetteur qui annonce cette capacité doit joindre une SRPA à chaque LSP de politique SR qu'il émet. Le TLV SRPOLICY-CAPABILITY détaille en outre la priorité de calcul, la politique Explicit NULL, l'invalidation et le mode sans état. Recevoir une SRPA sans la capacité requise provoque une erreur et la fermeture de la session. Cela prouve que les deux pairs partageaient le vocabulaire, non que les membres étaient tous invalides ni que des paquets ont été rejetés.

Deux D, deux natures de fait

Le TLV INVALIDATION comporte un champ Config et un champ Oper. Dans Config, D indique que Drop-Upon-Invalid est activé sur le chemin candidat. Dans Oper, D indique que le LSP rejette actuellement le trafic parce que la fonction a été déclenchée. La lettre est identique ; le niveau de preuve ne l'est pas.

La configuration exprime une intention conditionnelle. Le drapeau opérationnel rapporte un état après réalisation de la condition. Le résultat dans le plan de données reste encore autre chose : le trafic a-t-il continué d'être dirigé vers la politique, combien de paquets ont été jetés et pendant quelle durée ? Aucun bit de contrôle ne peut répondre seul à ces questions.

Le sens du message compte aussi. De PCE vers PCC, la configuration demande l'activation ou la désactivation. De PCC vers PCE, le rapport renvoie le réglage actuel et l'état de rejet. Une base qui ne garde que la « dernière valeur D », sans identité de locuteur, direction, session et heure, transforme l'ordre en accusé de réception et l'intention en résultat.

Le comportement ordinaire offre le contraste nécessaire. Un LSP invalide cesse normalement d'attirer le trafic, qui peut partir vers un autre LSP ou l'IGP. Drop-Upon-Invalid choisit délibérément l'inverse : attirer encore et rejeter à la tête de réseau. Ce choix peut protéger un service pour lequel une route de repli imprévue serait pire qu'une interruption franche. Un réglage obsolète ou mal circonscrit peut au contraire convertir une panne récupérable en coupure volontaire. La norme rend le mécanisme interopérable ; elle ne décide pas quel risque l'opérateur doit accepter.

Le dernier chemin valide est l'événement décisif

Selon la RFC 9256, une politique SR devient invalide lorsque tous ses chemins candidats sont invalides. C'est un prédicat d'ensemble. Le premier chemin perdu diminue la résilience ; le suivant peut changer le meilleur choix ; seul le dernier chemin valide qui bascule fait franchir la limite à la politique.

À cet instant, la politique cherche si l'un des chemins a Drop-Upon-Invalid activé. Si oui, elle entre en état de rejet et active, parmi eux, celui dont la préférence est la plus élevée. La RFC 9862 précise qu'un seul chemin candidat doit être signalé au PCE avec le drapeau opérationnel Dropping. Cette économie de signalisation n'est pas un récit causal complet.

Imaginons trois chemins. Un ancien chemin de faible préférence conserve D à la suite d'une décision prise pour un service précis. Les deux chemins mieux classés n'ont pas D. Leur invalidation successive ne déclenche rien tant qu'un chemin reste valide. Lorsque le dernier tombe, l'ancien réglage rend toute la politique éligible au rejet. Le LSP portant le D opérationnel montre le porteur présent ; il ne désigne ni l'auteur de l'autorisation, ni sa date, ni la transition qui a achevé le prédicat collectif.

Il faut aussi séparer préférence et priorité de calcul. La préférence d'un chemin candidat choisit le meilleur chemin : la valeur la plus grande gagne et la valeur par défaut de la RFC 9256 est 100. La priorité de calcul de la RFC 9862 ordonne les recalculs après changement de topologie : la plus petite valeur passe d'abord et sa valeur conditionnelle par défaut est 128. Un schéma qui les appelle toutes deux « priorité » peut produire une explication inversée tout en restant crédible.

Une absence de TLV n'est pas une absence de décision

La RFC 9862 prévoit plusieurs formes d'absence. Lorsque la capacité correspondante est disponible, l'absence du TLV de priorité de calcul appelle la valeur 128. Sans TLV de politique Explicit NULL, la configuration locale décide. Ce dernier TLV vise SR-MPLS et doit être ignoré pour SRv6 ; une valeur inconnue est ignorée ; l'opérateur peut également remplacer le comportement signalé par sa configuration locale.

Un champ vide peut donc invoquer un défaut, déléguer un choix au site, être inapplicable ou avoir été supplanté. Le réduire à « aucune politique » efface le véritable décideur. Pour un incident de rejet, il faut connaître la valeur effective, sa provenance, sa précédence, la version qui l'a interprétée et la session à laquelle elle appartenait.

La RFC 9862 exige que l'opérateur puisse voir les identifiants de politique et de chemin annoncés dans une SRPA. Elle recommande également la visibilité sur les capacités des pairs et sur les LSP associés à un identifiant de politique. Cette visibilité est indispensable. L'explication durable doit encore réunir ces vues dans une transition datée.

Le reçu de rejet à l'échelle de la politique

Le reçu de rejet à l'échelle de la politique proposé ici commence par l'identité : couleur, point de terminaison, SRPA, session PCEP et capacités telles que vues par chaque pair. Il fige ensuite la liste complète des chemins candidats employée pour la décision, avec origine, discriminateur, préférence, D de configuration et validité de chacun.

La chronologie vient après. Pour chaque chemin, conserver le moment où il devient invalide et la source de l'observation. Identifier le dernier chemin valide, l'instant où le prédicat « tous invalides » devient vrai, les chemins qui avaient D à cet instant, celui qui est choisi comme porteur du rejet et le rapport opérationnel D, avec le sens PCE/PCC.

Enfin, joindre le résultat. Le trafic a-t-il continué d'être orienté vers la politique ? Quels compteurs montrent les rejets à la tête de réseau ? Quand commencent-ils et s'arrêtent-ils ? Le rétablissement vient-il du retour d'un chemin, d'un changement de configuration, d'une modification des membres ou du retrait de la politique ? Le propriétaire de la décision, le service protégé, la date de révision et la marche arrière font partie de la preuve.

Ce reçu n'appelle pas à centraliser la topologie. La SRPA et ses TLV peuvent révéler des informations sensibles. La RFC 9862 reprend donc la recommandation d'utiliser des sessions PCEP authentifiées et chiffrées par TLS entre PCE et PCC relevant de la même autorité administrative. Le reçu doit rester local, contrôlé et limité aux données utiles à la décision.

Il ne s'agit pas davantage d'une extension de la RFC. C'est une méthode éditoriale destinée à empêcher un système de gestion de prendre le lieu d'encodage d'un bit pour le lieu où s'exerce le pouvoir.

Sources