Résumé

  • RFC 9857 transporte vers un contrôleur l’état opérationnel d’un chemin candidat SR Policy, directement depuis la tête ou par l’intermédiaire d’un PCE.
  • Un état reçu n’atteste ni son instant d’observation, ni son actualité, ni une confirmation indépendante du FIB, du trafic ou du service.

Une réponse utile, mais sans date de naissance

Avant RFC 9857, un contrôleur externe pouvait connaître l’intention d’une SR Policy sans disposer d’un compte rendu BGP-LS normalisé sur son état opérationnel. Le RFC ajoute des NLRI et attributs capables de décrire une politique, ses chemins candidats et leurs listes de segments. Ce retour est précieux : le contrôleur n’est plus condamné à déduire la situation à partir de ce qu’il avait demandé.

Mais la présence de la route dans une table BGP-LS répond d’abord à une question de distribution : « quel état m’a été annoncé ? » Elle ne répond pas automatiquement à « quand le système d’origine l’a-t-il observé ? ». Un horodatage d’arrivée local mesure le dernier passage par le récepteur. Il ne révèle pas le temps passé avant l’émission, dans un PCE intermédiaire, au travers d’une session interrompue ou dans une file de mises à jour.

La distinction compte au moment précis où l’automatisation semble la plus rassurante. Un tableau peut afficher active avec une mise à jour récente alors que cette mise à jour répète une observation plus ancienne. Sans identité de génération et sans borne d’âge, la fraîcheur apparente appartient au transport, pas nécessairement à l’état observé.

La tête décrite n’est pas toujours l’observateur direct

RFC 9857 impose que les Local Node Descriptors désignent la tête de la SR Policy. Si un PCE relaie un état appris d’un PCC au moyen de PCEP, il ne doit pas substituer ses propres identifiants à ceux de la tête. Il peut exposer son BGP Router-ID, son numéro de système autonome ou son identifiant de confédération dans l’attribut BGP-LS.

Cette règle préserve correctement l’objet décrit, mais elle crée deux provenances qu’un consommateur doit conserver séparément : la provenance du sujet — la tête dont la politique est décrite — et celle du producteur BGP-LS qui a livré le rapport. Confondre les deux revient à transformer un relais autorisé en témoin direct.

Le champ Protocol-Origin apporte encore autre chose. Il indique le protocole ou le composant à l’origine de l’instanciation, par exemple PCEP, BGP SR Policy ou configuration locale. Il ne constitue ni une signature de l’observateur, ni une horloge de mesure, ni un accusé de réception matériel. De même, le BGP-LS Instance-ID distingue une instance de routage ; son nom ne doit pas être interprété comme un compteur temporel.

Les bits d’état ont une portée précise

Le bit A indique qu’un chemin candidat est actif et, selon la sémantique reprise de RFC 9256, qu’il est provisionné dans le plan de transfert. C’est une déclaration substantielle du producteur. Elle ne devient pourtant pas, par magie, un accusé distinct émis par l’ASIC ou par chaque line card. Les autres bits répondent à d’autres questions : S pour l’arrêt administratif, B pour le secours, E pour l’évaluation, V pour l’existence d’au moins une liste de segments valide, D pour la délégation, C pour le provisionnement par un PCE. I, T et U décrivent des modes de rejet ou de transit définis par le RFC.

Les listes de segments disposent elles aussi d’états de calcul, de vérification et de résolution. Le bit M signale qu’une liste a été retirée après un défaut détecté par le suivi. Ces informations décrivent donc mieux la décision locale. Elles ne disent pas combien de paquets ont emprunté la liste, si la télémétrie observée correspond à la même génération, ni si l’objectif de service a tenu.

Le contrôleur doit construire l’epoch que le protocole ne fournit pas

RFC 9857 ne définit pas d’horodatage d’observation produit par la tête, de numéro monotone de génération, d’accusé SRPM séparé ou de confirmation FIB. RFC 9552 rappelle par ailleurs que le rythme des mises à jour BGP-LS peut être réglé par politique afin de maîtriser le volume. Cette liberté est saine pour le réseau, mais elle interdit d’assimiler silence et stabilité récente.

Le consommateur doit donc créer une enveloppe d’epoch autour de chaque affirmation : identité du sujet, identité du producteur, session et redémarrages, instant de réception, âge maximal accepté, génération de l’intention et durée de validité. Après une reconnexion, un basculement de PCE ou une reprise de session, l’état conservé doit redevenir « non corroboré » jusqu’à une observation compatible avec le nouvel epoch.

Ce n’est pas une extension cachée du RFC. C’est une règle d’usage : le protocole transporte les faits qu’il définit ; le système de décision conserve les limites de ces faits.

Cinq reçus, cinq questions

Une exploitation rigoureuse sépare au moins cinq reçus. Le premier est le rapport BGP-LS : quelle politique et quel chemin candidat le producteur annonce-t-il ? Le deuxième est le reçu SRPM : quelle génération l’agent local de politique a-t-il acceptée ? Le troisième vient du FIB ou du matériel : quelles entrées ont réellement été programmées et où ? Le quatrième est comportemental : les paquets ou compteurs montrent-ils que le trafic utilise ce chemin ? Le cinquième est le résultat de service : latence, perte et disponibilité restent-elles dans l’objectif ?

Ces reçus peuvent arriver dans le désordre et à des cadences différentes. Leur jointure exige une clé de politique stable, une génération comparable et une fenêtre temporelle explicite. Un contrôleur peut utiliser le rapport RFC 9857 pour déclencher cette enquête, mais ne doit pas laisser le premier reçu répondre à la place des quatre autres.

Le résultat pratique est une échelle d’assurance. « Reçu » signifie visible. « Corroboré » signifie associé à un reçu local compatible. « Observé en usage » signifie soutenu par la télémétrie du trafic. « Service vérifié » ajoute un résultat mesuré. L’interface et l’automate doivent afficher le niveau réellement atteint, pas le niveau souhaité.

Ce que les registres confirment

Le registre IANA BGP-LS en vigueur répertorie les nouveaux types et TLV nécessaires au mécanisme. La page d’errata du RFC recense l’erratum vérifié 8709, qui remplace dans trois passages « SR Binding SID sub-TLV » par « SR Binding SID TLV ». La correction clarifie la terminologie ; elle n’ajoute aucun signal de temps ou d’installation. Ces deux sources permettent de contrôler les numéros et le texte, pas de conclure sur une implémentation particulière.

Sources