Résumé

  • draft-ietf-spring-resource-aware-segments-20 associe des SID SR-MPLS et des locators/SID SRv6 existants à un NRP ou à un sous-ensemble local de ressources, sans créer un nouveau type de SID.
  • Le SID indique le traitement attendu. Il ne démontre ni l’allocation sur chaque nœud, ni la cohérence des liaisons, ni l’absence de repli best effort, ni le résultat applicatif.

Le paquet est arrivé. Le SID était valide, le contrôleur avait choisi la bonne partition et aucun test de connectivité n’a rougi. Pourtant, sur un routeur intermédiaire, la file réservée n’existait pas. Le trafic a été rejeté ou versé dans le service ordinaire. La destination était joignable ; la prestation achetée ne l’était plus.

C’est la frontière décisive de la révision 20 de Introducing Resource Awareness to SR Segments, publiée le 30 septembre 2026. L’Internet-Draft actif du groupe SPRING vise le statut Proposed Standard et reste en IESG Evaluation / AD Followup, avec un DISCUSS. Il ne s’agit ni d’un RFC, ni d’une décision finale, ni d’une démonstration d’interopérabilité ou de SLA en production.

Donner un sens aux ressources ne crée pas les ressources

Le Segment Routing classique attache une instruction de transmission à un SID. La révision 20 ajoute une association à des ressources. Un Adj-SID resource-aware peut désigner à la fois le prochain saut et une part locale d’un lien. Un Prefix-SID peut porter le chemin vers un nœud et le contexte d’un Network Resource Partition. En SRv6, le locator situe le NRP ; End.X ou d’autres SID sélectionnent l’action et les ressources locales.

L’idée répond à une limite concrète : DiffServ offre peu de classes, alors que de nombreux services peuvent réclamer une isolation distincte. Des SID supplémentaires permettent de construire une politique SR qui garde sa sémantique de chemin tout en choisissant une réserve de bande passante, de buffers ou de files.

Mais le SID reste une clé. Il ne voit pas la configuration effective de l’ordonnanceur, le maintien d’une file après redémarrage, l’adhésion d’un lien au bon NRP ou l’accord du nœud suivant. Sa présence dans le paquet prouve une sélection ; elle ne constitue pas l’inventaire du matériel disponible.

Un NRP global dépend d’engagements locaux

Le projet distingue les segments locaux, liés aux ressources d’un nœud ou d’un lien, et les segments globaux, associés à l’ensemble d’un NRP. Le mot « global » décrit la portée de la convention. La réalisation demeure une suite d’actes locaux.

La révision 20 interdit d’utiliser un NRP avant son provisionnement complet. Une mise à jour n’est terminée qu’après réussite sur tous les nœuds concernés. Un échec partiel doit être signalé et le système de gestion devrait pouvoir revenir en arrière. Lorsqu’un nœud détecte une liaison incohérente, les SID touchés ne doivent pas transmettre et l’erreur doit être journalisée.

Ces règles fixent la fin logique d’une opération, pas le mécanisme transactionnel qui l’obtient. Le découpage des ressources, plusieurs extensions de contrôle et les augmentations YANG restent hors périmètre. L’opérateur doit donc fabriquer sa propre preuve : intention autorisée, membres du NRP, quantité promise, SID/locator exact, acceptation par nœud, allocation matérielle, activation, contrôle de cohérence et résultat du rollback.

Le repli conserve la route et détruit la promesse

Si un nœud de transit ne trouve pas les ressources locales du NRP indiqué, le comportement par défaut est de rejeter le paquet. Un réglage peut autoriser le best effort. Pour un trafic excédentaire, la politique peut également choisir le rejet, la baisse de priorité ou le service ordinaire.

Le repli est pratique pour la disponibilité, mais dangereux pour la preuve. Un paquet peut arriver après avoir perdu son isolation ou son objectif de latence. Un tableau de bord de reachability annonce alors un succès, tandis que le registre SLA constate un échec. La révision demande de journaliser et signaler le repli best effort précisément pour rendre cette différence observable.

L’authentification protège le message, pas la vérité du nœud

Les opérations d’allocation, d’association et de diffusion doivent passer par des canaux assurant authentification mutuelle, autorisation, intégrité et protection contre le rejeu ; la capacité et la topologie devraient rester confidentielles. Un contrôle d’admission doit empêcher les partitions de priver le plan SR de base.

Ces garanties ne rendent pas un équipement compromis sincère. Le document envisage un nœud qui prétend avoir alloué la ressource, exagère sa capacité ou dégrade sélectivement un NRP. Un rapport signé et intact établit sa provenance, pas l’existence physique de la file annoncée.

Le texte cite des familles de routeurs Huawei comme implémentations déclarées en production au 28 août 2025. Conformément au RFC 7942, il précise que cette information vient des contributeurs, n’a pas été vérifiée et ne vaut pas approbation IETF. Le dossier gelé ne contient ni essai multi-constructeur ni mesure reproductible de SLA.

La chaîne de preuve doit donc aller de l’intention autorisée au résultat : version exacte, NRP, ressources, SID, admission locale, allocation réelle, liaison cohérente, activation après dernier reçu, classification des paquets, compteurs de rejet ou de repli, mesure de performance et observation applicative. Après maintenance ou panne, la chaîne doit être renouvelée même si le SID ne change pas.

La doctrine de spécification initiale minimale de Heng Lu convient à cette architecture. Le commun définit une sémantique portable et des défauts sûrs ; le dimensionnement, la tarification, l’admission et la réparation restent sous l’autorité locale. La primauté du code en fonctionnement ajoute que la forme d’un standard n’est pas une preuve d’adoption. Le SID choisit la voie ; seuls les reçus de bout en bout prouvent qu’elle a existé et tenu sa promesse.

Sources