Résumé

  • L’extension approuvée par l’IESG permet d’associer un chemin candidat SR Policy à l’identifiant de la Network Resource Partition qu’il est censé utiliser.
  • Cet identifiant décrit une intention de contrôle dans un domaine donné. Il ne réserve ni capacité ni file, ne prouve pas le sélecteur installé et ne garantit pas l’isolation observée.

Deux chemins, un même service, deux intentions

Prenons deux chemins candidats ayant la même couleur et le même point de terminaison. Le premier transporte l’identifiant NRP 17, le second l’identifiant 29. Pour le contrôleur, la différence est nette : chaque chemin doit mobiliser une partition de ressources sous-jacentes différente.

Pour l’exploitant, l’enquête ne fait pourtant que commencer. L’annonce ne contient pas l’état des files, la capacité disponible, la configuration des interfaces ni une mesure d’isolation. Elle ne démontre pas davantage que le headend a choisi le chemin, traduit l’identifiant en sélecteur de plan de données et orienté le service vers les ressources prévues.

Ce cas est une illustration, non un incident signalé. Il montre la limite d’autorité du nouveau champ : BGP peut transporter une association sans accomplir les opérations auxquelles elle fait référence.

Le 25 août 2026 à 18 h 03 UTC, l’IETF a annoncé que l’IESG avait approuvé la révision 13 de « BGP SR Policy Extensions for Network Resource Partition » en vue de sa publication comme Proposed Standard. L’événement est important, mais il ne faut pas confondre approbation, publication finale et déploiement.

Une approbation encore entourée de dépendances

Le texte provient du groupe de travail Inter-Domain Routing. L’annonce décrit un consensus approximatif après des discussions sur ses dépendances envers les travaux TEAS et SPRING. Le choix a été de laisser les références normatives se résoudre dans la file du RFC Editor.

Au gel des preuves du 28 août, Datatracker affichait encore un Internet-Draft actif. Le RFC Editor indiquait « blocked: Reference Not Received ». Chez l’IANA, la version devait être réexaminée et l’action restait en cours. Aucune de ces étapes ne permet donc d’annoncer prématurément un numéro de RFC définitif.

L’annonce mentionne deux implémentations. Le rapport public du groupe IDR cite des surfaces Huawei VRP et H3C Comware. Il comporte cependant des formulations liées à une version antérieure et des cases fonctionnelles encore marquées TBD. Il atteste un travail d’implémentation, pas une conformité exhaustive à la révision 13, une interopérabilité à grande échelle ou une activation commerciale.

La partition ne tient pas dans son numéro

Le RFC 9543 définit une Network Resource Partition comme un sous-ensemble de ressources du réseau sous-jacent, accompagné des politiques qui permettent de servir un ou plusieurs services de tranche. Le RFC 9732 replace cette construction dans le cadre des VPN enrichis : une connectivité peut être associée à une NRP, mais l’ingénierie des ressources, l’orientation du trafic et le résultat de service demeurent des couches séparées.

L’identifiant NRP n’est donc ni une quantité de bande passante ni une preuve d’exclusivité. Dans la révision 13, il s’agit d’un identifiant de contrôle de 32 bits, unique à l’intérieur d’un domaine NRP. La configuration locale relie ce nom à un NRP Selector ID utilisé dans le plan de données.

Le périmètre est volontairement limité au cas d’un sélecteur dédié et commun au domaine, transporté dans les paquets. D’autres conceptions de sélection d’une NRP peuvent ne pas nécessiter ce signal explicite dans SR Policy. Étendre la conclusion à toutes les architectures serait donc incorrect.

Six octets pour une assertion bien délimitée

La spécification ajoute un sous-TLV NRP ID à l’attribut BGP Tunnel Encapsulation lorsque le type de tunnel est SR Policy. Dans la révision 13, le type vaut 123 et la longueur doit être de six octets : un octet de drapeaux, un octet réservé et quatre octets pour l’identifiant.

Les drapeaux et bits réservés sont émis à zéro et ignorés à la réception. La valeur NRP ID zéro est réservée : l’émetteur ne doit pas l’utiliser et le récepteur ignore un sous-TLV qui la contient. Le sous-TLV est facultatif, mais ne peut apparaître qu’une seule fois pour un chemin candidat.

Ces contraintes protègent l’unicité de l’assertion sur le fil. Si la longueur diffère de six ou si le sous-TLV est dupliqué, l’information NRP liée au NLRI est mal formée et le récepteur applique le traitement « treat-as-withdraw » du RFC 7606.

Cette réaction tranche un conflit syntaxique. Elle ne détecte pas un identifiant non nul, correctement encodé, mais relié au mauvais sélecteur local. Une annonce peut ainsi être impeccable pour le protocole et fausse pour les ressources.

Le meilleur chemin BGP n’est pas le dernier verdict

Quand un chemin candidat est instancié dans une NRP et que le domaine utilise le sélecteur dédié, l’origine doit inclure le sous-TLV. À la réception, le locuteur BGP applique d’abord les règles de validité et d’utilisabilité du RFC 9830. L’algorithme habituel de sélection BGP reste inchangé.

Les meilleures routes retenues pour la SAFI SR Policy sont ensuite transmises au SR Policy Module. Ce passage matérialise une frontière de responsabilité. Une route acceptée peut ne jamais devenir le chemin candidat actif. Le module peut recevoir le chemin sans réussir son installation. Une installation peut encore appliquer un sélecteur erroné si le mappage local a dérivé.

La chaîne de preuve doit donc couvrir la sélection du chemin candidat, l’installation de la liste de segments, le mappage entre l’identifiant NRP et le sélecteur, l’ajout du sélecteur aux paquets, l’orientation du service, les files et liens provisionnés, puis les résultats mesurés. Une annonce réussie ne prouve au mieux que l’émission et l’acceptation d’une association de contrôle dans un contexte connu.

La cohérence doit survivre au basculement

La révision 13 autorise des chemins candidats d’une même SR Policy à viser des NRP différentes, tout en qualifiant cette configuration de valide mais déconseillée. Dans le fonctionnement normal, les chemins devraient conserver la même association NRP.

La raison apparaît lors d’une panne ou d’un changement de préférence. Le service peut conserver la même clé de politique tandis que le chemin actif change. Si le nouveau chemin désigne silencieusement une autre partition, le basculement modifie aussi l’isolation, la capacité, le coût ou le degré d’exposition de l’intention réseau.

Répéter le même entier ne suffit pas. Chaque headend doit lui attribuer le même sens, le plan de données doit appliquer le même sélecteur et les ressources correspondantes doivent exister. Un nombre uniforme au-dessus de mappages divergents n’est qu’une syntaxe coordonnée.

L’échelle se concentre aux extrémités de contrôle

Le document reconnaît que le nombre de SR Policies et de chemins candidats peut croître avec celui des NRP. Le volume d’informations échangées entre contrôleur et headends peut augmenter dans la même proportion.

L’extension ne change ni la procédure d’annonce SR Policy ni le meilleur chemin BGP. Les chemins sont installés par les headends concernés, et non comme nouvel état sur chaque nœud de transit. C’est une limite de portée utile, pas l’absence de coût opérationnel.

Contrôleurs et headends doivent toujours créer, valider, rapprocher et installer cet état. Une supervision qui ne distingue pas les objets annoncés, acceptés, sélectionnés et installés peut afficher un contrôle nominalement sain tout en cachant la saturation d’un headend.

La confiance dans le pair ne garantit pas l’association

La section de sécurité reprend les protections de BGP, de SR Policy et des NRP, puis formule le risque local : une association incorrecte peut dégrader l’isolation du trafic et les garanties de ressources.

Un pair authentifié peut émettre le mauvais identifiant. Un headend de confiance peut traduire le bon identifiant vers le mauvais sélecteur. Un sélecteur correct peut aboutir sur une configuration de ressources périmée. Dans les trois cas, des composants autorisés produisent un résultat qui ne l’est pas.

L’association peut aussi révéler une intention sensible, par exemple une structure réservée à une mission critique ou commercialement importante. L’exploitant doit limiter les émetteurs et récepteurs à des routeurs et applications de contrôle de confiance, puis vérifier la justesse de l’association.

Pour chaque épisode, il faut conserver l’identité du contrôleur et du pair, la clé NLRI, l’origine et la préférence du chemin, les octets du sous-TLV, les décisions de validation et de sélection, l’état reçu par SRPM, la liste de segments installée, la version du mappage, la configuration des ressources, l’orientation du service, le sélecteur observé dans les paquets, les mesures de file, perte, latence et isolation, ainsi que les horodatages qui relient ces preuves.

Sources