Résumé

  • Le 25 août 2026, l’IESG a approuvé draft-ietf-idr-sr-policy-seglist-id-14 comme Proposed Standard. Au gel des preuves, le texte restait un Internet-Draft actif dans la file du RFC Editor et l’IANA affichait encore la valeur 19 comme attribution temporaire.
  • Le Segment List ID de 32 bits n’est unique qu’à l’intérieur d’un Candidate Path. Le même numéro peut désigner ailleurs une autre liste et peut être conservé quand la suite de SID change. Il faut donc relier le couple contextualisé au contenu courant, à la validation SRPM et au transfert effectivement observé.

Le tableau de bord n’a pas vu la rupture

Avant une fenêtre de changement, un contrôleur associe l’identifiant 42 à trois instructions ordonnées. Un collecteur de statistiques, une opération NETCONF et l’outil d’assurance reprennent tous ce numéro. Pendant l’intervention, le contrôleur remplace la suite de SID mais conserve 42. La courbe reste continue et l’objet reste vert.

Le libellé a survécu, pas le contenu.

Cette scène est un test analytique, pas l’incident d’un opérateur nommé. Elle montre pourquoi la nouvelle norme doit être lue comme un mécanisme de référence, non comme une attestation d’identité du chemin. Si un système ne conserve que le numéro, il a déjà perdu une partie de la clé. S’il conserve aussi le Candidate Path mais pas la version du contenu, il peut encore confondre deux états successifs.

Une approbation, trois états procéduraux

L’annonce officielle du 25 août approuve la révision 14 de « BGP SR Policy Extensions for Segment List Identifier » comme Proposed Standard, issue du groupe Inter-Domain Routing.

Le 28 août, le Datatracker indiquait pourtant toujours Active Internet-Draft, RFC Ed Queue et « Awaiting Reference Checker, formatting ». L’action IANA était en cours après un changement de version. Le texte, daté du 24 août et mis à jour le 26 dans le Datatracker, devait expirer le 25 février 2027.

Le registre public de l’IANA rend la séparation encore plus nette. Dans « SR Policy Segment List Sub-TLVs », la valeur 19 figurait toujours comme attribution temporaire, enregistrée le 19 décembre 2025, expirant le 19 décembre 2026 et renvoyant à une ancienne révision. L’approbation de l’IESG, la finalisation éditoriale et l’inscription permanente sont des faits distincts. Aucun ne prouve qu’un headend a accepté l’extension.

Le gain réel est un rapprochement moins coûteux

Une SR Policy contient des Candidate Paths, chacun composé d’une ou plusieurs listes de segments. RFC 9830 permet à BGP de distribuer ces chemins candidats au headend qui inscrit ensuite les instructions dans les paquets.

Sans identifiant, la télémétrie par liste peut devoir répéter tous les SID. Le contrôleur compare alors chaque séquence pour retrouver l’objet correspondant. Le projet de norme cite aussi une configuration YANG/NETCONF qui doit viser une liste apprise par BGP. Un entier compact réduit les octets, les comparaisons et l’ambiguïté humaine lors du dépannage.

L’encodage reste volontairement limité. Le sous-TLV Segment List ID, facultatif, se place dans le sous-TLV Segment List de type 128, lui-même sous le Tunnel Type SR Policy de type 15. Son type vaut 19, sa longueur six octets et quatre octets portent l’entier non signé. Les valeurs de 1 à 0xffffffff sont utilisables ; zéro signifie qu’aucun identifiant n’a été attribué.

Ce format facilite la désignation. Il ne transforme pas la désignation en objet universel.

Le périmètre fait partie de l’identité

Un identifiant non nul doit être unique parmi les listes d’un seul Candidate Path. Il ne l’est ni entre deux Candidate Paths, ni entre deux SR Policies, ni entre deux headends. Toute référence externe doit donc joindre le Candidate Path au numéro.

La règle suivante est plus importante encore : l’identifiant ne promet pas l’immutabilité de la séquence. Le contrôleur peut garder le même ID après avoir changé les SID. Le couple Candidate Path–ID fonctionne alors comme un emplacement mutable, pas comme une empreinte du contenu.

Pour une preuve historique, il faut au minimum le NLRI de la SR Policy — Distinguisher, Color, Endpoint —, l’identité du Candidate Path, l’ID, la séquence ordonnée et l’instant ou la révision de validité. Une empreinte de contenu empêche deux systèmes de parler de « 42 » tout en décrivant des instructions différentes.

RFC 9857 emploie déjà un identifiant de liste dans la remontée BGP-LS, tandis que le nouveau texte évoque YANG et NETCONF. Une sémantique voisine n’institue pas un espace de noms mondial. Chaque jointure doit préserver le contexte, le type et la fraîcheur.

Une option peut rendre le chemin inutilisable

Une longueur différente de six octets rend le NLRI BGP SR Policy malformé ; la stratégie treat-as-withdraw de RFC 7606 s’applique. Ce retrait de contrôle ne démontre pas que le trafic a basculé correctement.

Si le même sous-TLV apparaît plusieurs fois dans une liste, seule la première occurrence est utilisée. Si plusieurs listes d’un Candidate Path portent le même ID non nul, l’erreur est sémantique et relève du SRPM ; le récepteur peut supprimer l’association d’identifiant pour toutes ces listes.

Dans une flotte mixte, le cas le plus contre-intuitif vient d’un headend qui ne reconnaît pas le sous-TLV. Selon le comportement par défaut de RFC 9830, le Candidate Path peut être considéré comme inutilisable. Le projet recommande donc une annonce sélective uniquement vers les nœuds compatibles. Une capacité facultative n’est pas forcément sans effet.

Les objets de gestion doivent aussi préserver le type utilisé comme index. Une conversion silencieuse entre nombre, chaîne ou espace de noms peut casser la référence sans produire de BGP malformé.

Le numéro s’arrête avant l’exécution

BGP transporte la description du Candidate Path ; il ne valide pas le tunnel. Le SRPM interprète et valide les informations. Puis viennent encore l’utilisabilité, la sélection active, la programmation du forwarding et le passage réel des paquets.

Une preuve exploitable doit relier : révision du texte et état IANA ; versions du contrôleur et du headend ; capacité et portée de l’annonce par pair ; mise à jour BGP reçue ; tuple Candidate Path–ID–contenu ; résultat du parseur et du SRPM ; chemin actif ; état programmé ; compteurs rattachés à la même révision ; résultat du trafic.

Le registre, l’UPDATE reçu, l’objet SRPM et les paquets observés répondent à des questions différentes.

Le texte signale aussi un risque de confidentialité : un identifiant compact peut révéler une structure opérationnelle sensible. Sa diffusion doit rester limitée aux routeurs et applications de contrôle de confiance du domaine SR. La politique d’allocation, les collisions entre contrôleurs, la réutilisation, les versions et la rétention restent hors du champ de la norme.

Enfin, les déclarations d’implémentation H3C et ZTE portent sur une ancienne révision 3 et datent de février 2025. Le document précise qu’elles ne constituent ni approbation de l’IETF ni vérification indépendante. Elles ne mesurent pas l’adoption actuelle.

Sources