Résumé

  • RFC 9514 permet à BGP-LS de transporter vers les consommateurs les capacités, liens, Locators, SID, comportements et structures SRv6.
  • Un Prefix NLRI portant le SRv6 Locator TLV 1162 n’est qu’une déclaration de Locator tant que le Prefix Metric TLV 1155 n’est pas également présent ; l’erratum vérifié 7737 corrige la référence erronée à 1095.
  • Déclaration, qualification de joignabilité, association du SID, calcul, installation et forwarding observé doivent rester des preuves distinctes.

La première vue d’exploitation paraît complète. Le consommateur BGP-LS a accepté un Prefix NLRI contenant le SRv6 Locator TLV 1162, un algorithme et une métrique. Le Locator figure dans l’inventaire et l’objet se rattache à un nœud connu. Aucun défaut de syntaxe n’apparaît.

Il manque pourtant une réponse : ce préfixe exprime-t-il une joignabilité ordinaire, ou seulement l’espace couvrant sous lequel le nœud instancie ses SID ?

RFC 9514 propose un test sans ambiguïté. Le Locator est annoncé par un Prefix NLRI accompagné du SRv6 Locator TLV. Le même objet ne devient aussi un préfixe normalement joignable que s’il comporte le Prefix Metric TLV approprié. Sans ce second champ, il reste une annonce de Locator.

Un numéro corrigé change la proposition

Le texte publié cite l’IGP Metric TLV 1095. C’est une erreur. Le registre d’errata vérifiés du RFC Editor remplace ce champ par le Prefix Metric TLV 1155 : le 1095 est associé au Link NLRI, tandis que le Locator appartient au Prefix NLRI.

La correction n’est pas cosmétique. Un consommateur fondé sur l’ancien numéro peut chercher la preuve dans la mauvaise classe d’objet, confondre la métrique interne du Locator TLV avec la preuve de joignabilité manquante ou diverger d’une autre version logicielle. « Ce préfixe organise des SID SRv6 » et « ce préfixe est annoncé comme joignable » sont deux affirmations.

Le Locator TLV possède bien une métrique copiée depuis l’annonce Locator IS-IS ou OSPFv3 d’origine. Elle décrit la déclaration de Locator ; elle ne se transforme pas en Prefix Metric TLV 1155. Deux métriques ne reçoivent pas le même pouvoir de décision parce qu’elles partagent un nom.

RFC 9514 exporte un graphe d’objets SRv6

Le document couvre quatre surfaces. Les attributs de nœud portent capacités, algorithmes et types Maximum SID Depth. Les attributs de lien portent End.X, LAN End.X et limites propres au lien. Les attributs de préfixe portent les Locators. Enfin, un nouveau SRv6 SID NLRI de type 6 décrit individuellement les SID associés au nœud.

Ce NLRI séparé répond à un problème d’échelle. Placer tous les SID dans un attribut de nœud agrandirait les mises à jour et obligerait à réémettre un grand objet au changement d’un seul SID. La granularité individuelle réduit ce coût, mais impose une discipline de cycle de vie : le consommateur doit raccorder chaque SID au bon nœud, au protocole source, à l’identifiant de topologie, au comportement et à la génération du Locator. La survie d’un objet voisin ne prouve pas qu’un SID retiré existe encore.

Chaque SID NLRI exige un Endpoint Behavior TLV. Les SID EPE PeerNode ou PeerSet ajoutent le contexte du pair ; un SID Structure TLV facultatif peut exposer les longueurs locator-block, locator-node, function et argument. RFC 8986 définit les comportements de terminaison et RFC 8402 l’architecture Segment Routing. Un code de comportement reste une instruction déclarée, non la trace d’un paquet prouvant son exécution.

La provenance doit rester visible. RFC 9514 copie les champs issus des extensions SRv6 pour OSPFv3 ou des extensions SRv6 pour IS-IS. Pour BGP EPE ou le Protocol-ID Direct, le nœud local annonce pour son propre compte. RFC 8814 fournit le transport BGP-LS des limites MSD. Le stockage commun de ces sources dans un contrôleur ne les transforme pas en constat omniscient.

BGP contrôle l’enveloppe, le consommateur répond du sens

RFC 9514 laisse expressément au consommateur les contrôles de contenu et de sémantique, notamment l’association correcte d’un TLV avec un NLRI ou un BGP-LS Attribute. BGP peut imposer le contrat d’encodage ; il ne certifie ni la joignabilité du Locator, ni l’instanciation présente d’un SID, ni l’autorisation de l’algorithme, ni l’adéquation d’un chemin calculé au réseau en fonctionnement.

Les considérations de gestion sont explicites : une erreur d’encodage ou de décodage peut priver un SR PCE d’information ou lui fournir une donnée erronée, conduisant à l’échec de l’optimisation ou à un comportement inattendu et incohérent. Le traitement applicatif dépend de l’implémentation et sort du périmètre. Cette limite désigne le propriétaire de la preuve suivante.

Le modèle BGP-LS actuel de RFC 9552 distingue producteur, propagateur et consommateur. Le premier dérive une projection, le second sélectionne et transmet l’information BGP, le troisième assemble et exploite le résultat. Une UPDATE valide atteste un passage d’interface, pas la conclusion du consommateur.

Conserver la transition, pas seulement le voyant vert

Le dossier doit nommer protocole source, producteur, Protocol-ID, Identifier et Local Node Descriptors. Il retient le Prefix NLRI exact, le Locator TLV 1162, l’algorithme, la métrique du Locator et l’époque topologique. Il indique si le Prefix Metric TLV 1155 était présent, absent, dupliqué ou rejeté, ainsi que la règle d’errata appliquée.

Pour un SID utilisé, il ajoute le SID NLRI, l’Information TLV 518, l’Endpoint Behavior TLV 1250, le contexte de pair, les longueurs de structure et l’historique de retrait. Le calcul reçoit son propre reçu : instantané consommé, contraintes, politique, candidats, chemin choisi et heure. L’acceptation par l’équipement, l’installation SR/FIB et l’observation de paquets restent encore séparées.

La piste officielle montre à la fois la règle et sa réparation. Le RFC Editor fournit la fiche d’information, le texte brut et le XML. Le Datatracker conserve l’historique du RFC, la dernière révision du projet et le graphe des références. Le registre IANA BGP-LS enregistre les codes. L’ensemble établit le vocabulaire corrigé, non un résultat de déploiement.

Trois essais de Heng Lu fournissent la discipline éditoriale : la primauté du code en fonctionnement, la spécification initiale minimale et l’adoption volontaire et les couches de réalité. Ils ne sont pas des exigences IETF. Ils rappellent seulement qu’un symbole normalisé, un modèle de contrôleur ou une entrée installée ne doit pas se faire passer pour un résultat observé.