Résumé

  • RFC 9830 permet à BGP d’annoncer des Candidate Paths de SR Policy, mais confie au module SRPM leur validation sémantique, leur comparaison et leur installation éventuelle.
  • Le Distinguisher évite que plusieurs annonces se confondent dans une même sélection BGP ; il n’exprime ni préférence opérationnelle, ni mandat, ni qualité du chemin.
  • Une preuve exploitable sépare réception, meilleure route BGP, import par le headend, admission SRPM, candidate active, Binding SID, programmation du plan de transfert et paquets observés.

Deux tableaux verts, deux questions différentes

Le cas d’ouverture est une expérience de raisonnement, pas le récit d’un réseau réel. Le premier voyant vert répond à une question de BGP : parmi les routes qui décrivent ce NLRI précis, laquelle a survécu aux règles de sélection et de propagation ? Le second répond à une question de SR Policy : parmi toutes les candidates encore admissibles pour ce couple Color–Endpoint, laquelle le headend a-t-il activée ?

La différence est inscrite au cœur de RFC 9830. Le protocole BGP crée, reçoit et propage les NLRI SR Policy. La route retenue entre dans la table BGP, puis ses informations sont remises au SR Policy Module, le SRPM. C’est ce dernier qui connaît les candidates venues d’autres mécanismes — configuration locale, NETCONF, PCEP ou CLI — et qui applique l’architecture de RFC 9256.

Dire « BGP l’a sélectionnée » ne suffit donc pas. BGP a sélectionné une route dans un concours déterminé par son NLRI. Le SRPM sélectionne une candidate dans un concours déterminé par l’identité de la policy, l’origine, la préférence, la validité des segments et les règles locales. Le premier résultat est une entrée de contrôle. Le second peut déclencher une allocation de Binding SID et une programmation du plan de transfert. RFC 9830 précise que BGP lui-même n’installe pas les Candidate Paths dans ce plan.

Le Distinguisher ne raconte aucune histoire

Le NLRI comprend trois éléments : Distinguisher, Color et Endpoint. Color et Endpoint désignent la SR Policy. Le Distinguisher rend plusieurs NLRI distincts lorsque l’origine veut annoncer plusieurs candidates de la même policy, ou viser plusieurs headends sans les faire concourir comme une seule route.

Cette séparation est utile, mais le RFC retire toute tentation d’y lire davantage : le Distinguisher n’a pas de valeur sémantique. Deux valeurs différentes ne disent pas que deux chemins servent des clients différents. Une valeur plus grande n’est pas meilleure. Une valeur stable ne prouve pas que l’intention, le calcul ou l’approbation humaine sont restés identiques.

Il faut donc conserver plusieurs identités côte à côte. Color–Endpoint dit à quelle policy la candidate appartient. Le Distinguisher dit quelle annonce BGP elle représente. L’information d’originator aide à retrouver sa provenance protocolaire. Protocol-Origin et Discriminator distinguent la candidate dans le modèle SRPM. Le ticket de changement et le propriétaire de service établissent qui a autorisé l’objectif. Aucun de ces éléments ne remplace les autres.

Cette discipline protège aussi contre les jointures paresseuses. Un nom de policy est symbolique et peut être tronqué lors de la signalisation. Un Router-ID peut désigner le réflecteur immédiatement visible plutôt que le contrôleur initial. Un même Color peut être réutilisé pour plusieurs endpoints. Construire un audit sur un seul libellé transforme rapidement plusieurs décisions en une fausse continuité.

La syntaxe s’arrête là où commence la policy

BGP n’est pas aveugle. Il vérifie la structure dont il est responsable : AFI et SAFI, longueur du NLRI, présence et forme du Tunnel Encapsulation Attribute, type SR Policy et cardinalité de certains TLV. Une combinaison interdite ou une structure inutilisable reçoit un traitement de type treat-as-withdraw. L’information affectée est retirée sans qu’un défaut de route ne doive abattre toute la session.

Mais cette robustesse a une frontière. RFC 9830 interdit à BGP d’effectuer la vérification sémantique des champs SR Policy individuels. Les segments, le Binding SID, les préférences et les comportements SRv6 appartiennent au SRPM. Une route peut donc être saine pour BGP et inutilisable pour la policy.

Les journaux doivent garder cette géographie des refus. « Malformé au niveau BGP », « sous-TLV ignoré », « non importé par ce headend », « rejeté par SRPM », « admissible mais non actif » et « actif mais absent du FIB » ne sont pas six formulations d’un même échec. Ce sont six lieux de décision, avec des responsables et des remèdes différents.

Les règles d’extension rendent cette précision encore plus nécessaire. Des bits réservés sont ignorés. Des sous-TLV non applicables peuvent être supprimés en propagation. Lorsqu’un champ à instance unique apparaît plusieurs fois, seule la première occurrence peut être retenue. Ainsi, les octets émis, les octets reçus et la vue transmise au SRPM peuvent diverger sans que le réseau soit en panne. Seul un relevé par étape permet d’expliquer la divergence.

La Preference n’est pas la préférence de BGP

Les mots du format peuvent tromper. La Preference d’une candidate sert au choix SRPM, pas au best path BGP. La Priority détermine l’ordre de recalcul des policies après une évolution topologique ; elle ne classe pas deux routes BGP. Le poids d’une Segment List répartit le trafic entre listes valides d’une candidate sélectionnée ; il ne prouve ni programmation matérielle, ni partage mesuré.

Le Binding SID illustre encore mieux l’autorité locale. Une annonce peut proposer une valeur et des indicateurs sur la manière de la traiter. Le headend reste chargé de vérifier, d’allouer, d’accepter ou de refuser selon le type de plan de données et sa politique. Pour certains champs SRv6, une valeur opaque laisse explicitement le choix du comportement au headend.

Même les détails de transfert gardent une marge locale. L’origine peut recommander des valeurs TC ou TTL ; le récepteur peut les remplacer. En l’absence d’ENLP, le choix d’un Explicit NULL relève de la configuration locale, et un comportement annoncé peut encore être remplacé pour les besoins du déploiement. La réception n’est donc jamais une procuration générale.

Cette lecture évite un mauvais modèle d’automatisation. Un contrôleur ne « pousse » pas un résultat fini. Il publie une candidate structurée. Le headend reçoit des éléments dont la force varie : certains identifient, certains suggèrent, certains bornent la validité, certains déclenchent une décision locale. Un unique champ status=active ne peut pas rendre cette diversité auditable.

Être destinataire ne signifie pas être utilisateur

Dans le cas simple, le contrôleur ouvre une session BGP directe vers chaque headend. Pour éviter cette multiplication, les annonces peuvent passer par des route reflectors ou plusieurs AS au sein d’un domaine SR de confiance. Des Route Targets servent alors à signaler les headends visés.

Importer un Route Target est un choix d’audience. Il signifie que la politique locale accepte de présenter cette annonce au rôle destinataire. Il ne signifie pas que le contenu a passé la validation SRPM, qu’il a gagné contre PCEP ou la configuration locale, ni que le FIB l’utilise. Inversement, un Route Target absent peut empêcher une candidate techniquement correcte d’arriver au module qui devait la juger.

L’audience est aussi une frontière de confidentialité. Les annonces peuvent révéler endpoints, adresses de nœuds, SIDs et architecture de chemins commercialement sensibles. Une session BGP configurée ne constitue pas, à elle seule, l’autorisation d’exporter cette famille d’adresses à tous les pairs. L’AFI/SAFI autorisé, les Route Targets, les rôles des pairs et la limite du domaine SR doivent figurer dans une décision de divulgation explicite.

La réflexion de routes complique la provenance. RFC 9830 reconstitue le Router-ID de l’originator selon un ordre qui peut utiliser une Route Origin Community, ORIGINATOR_ID ou, en dernier recours, le Router-ID du pair. Cette chaîne est essentielle pour savoir d’où vient la candidate au niveau protocolaire. Elle ne prouve toujours ni l’identité juridique du contrôleur, ni le mandat de déplacer le trafic.

Un retrait ne prédit pas le prochain paquet

Retirer une annonce BGP enlève une contribution. Il peut rester une autre candidate BGP distinguée, une candidate PCEP, une configuration locale ou une sauvegarde valide. Le SRPM peut conserver la policy active, basculer vers une autre, la déclarer invalide ou la supprimer. Le message de retrait ne contient pas le verdict final.

L’arrivée d’une meilleure route BGP n’est pas davantage un compteur de changements de FIB. La candidate peut perdre dans le concours SRPM, échouer sur un segment, demander un Binding SID inutilisable ou être neutralisée par une règle locale. Mesurer les UPDATE sans capturer les décisions du headend produit une activité de contrôle, pas une preuve de service.

Le dossier minimal doit relier : l’UPDATE brut et son empreinte ; le résultat structurel BGP ; la route retenue pour le NLRI ; l’import Route Target ; l’originator reconstruit ; le verdict sémantique SRPM ; l’ensemble des candidates au même instant ; le choix actif ; l’état du Binding SID ; les Segment Lists et leurs poids ; le RIB et le FIB programmés ; enfin les paquets observés. Chaque saut mérite son heure, sa version logicielle et son code de raison.

Une norme minimale laisse la responsabilité au bon endroit

RFC 9830 accomplit un travail commun considérable : format du NLRI, attributs, règles de propagation, champs de candidate et confinement des erreurs. Il permet à des systèmes indépendants de parler d’une même candidate. Il n’a pas besoin de décider à la place du headend pour être une bonne norme.

La doctrine de spécification minimale de Heng Lu éclaire ce choix. La coordination commune fixe ce qui rend l’échange interopérable. La décision locale reste auprès de l’opérateur qui en supporte les conséquences. La primauté du code en fonctionnement exige ensuite un reçu venant du SRPM et du plan de transfert, pas une déduction tirée du statut de RFC. La séparation des couches de réalité empêche enfin qu’une annonce, une décision et un paquet deviennent un seul symbole administratif.

Le meilleur essai place deux candidates BGP sous un même Color–Endpoint avec deux Distinguishers, puis ajoute une candidate PCEP de Preference supérieure. Il observe séparément le tableau BGP, l’entrée dans SRPM, les refus, le choix actif, le Binding SID, le FIB et le trafic. Ensuite, chaque source est retirée à tour de rôle. Si l’outil ne peut expliquer la transition sans dire simplement « BGP a changé la policy », l’audit a perdu la frontière que le RFC avait conservée.

Sources