Résumé

  • La RFC 9903 est une spécification IETF Standards Track qui définit le module YANG ietf-ospf-sr-mpls pour le Segment Routing sur MPLS avec OSPFv2 et OSPFv3.
  • Elle étend le modèle OSPF de la RFC 9129 et dépend de la RFC 9020 pour les ressources SR indépendantes du protocole.
  • Elle fournit une surface de gestion commune, mais l’état opérationnel doit être vérifié dans la famille propre à la version : LSAs Opaque pour OSPFv2, Extended LSAs et TLV pour OSPFv3.

Le mécanisme sépare l’intention de sa preuve protocolaire. La RFC 9903 augmente le modèle OSPF de la RFC 9129. Elle réutilise les groupements de la RFC 9020 pour les liaisons de Mapping Server au niveau de l’instance, le SRGB propre à chaque protocole et les Adj-SIDs au niveau des interfaces. Le module décrit la configuration et l’état opérationnel ; il n’assure ni le transfert, ni le calcul de chemin, ni l’attribution des labels.

L’activation SR-MPLS au niveau d’une aire vaut pour toutes les interfaces de cette aire et entraîne l’annonce des informations SR-MPLS dans les LSAs. Ce n’est donc pas une activation locale à une interface. Au niveau de l’interface, le modèle représente les Adj-SIDs de voisins déterminés sur des interfaces multi-accès broadcast ou NBMA, ainsi que TI-LFA sur MPLS. TI-LFA et Remote LFA fondé sur SR sont optionnels ; remote-lfa-sr ne s’applique que si Remote LFA est activé. L’utilisation d’un Mapping Server n’est pas obligatoire.

La lecture de l’état doit suivre la version en fonctionnement. En OSPFv2, les informations Prefix Range et Prefix-SID sont associées aux Extended Prefix Opaque LSAs ; l’algorithme, la SID/Label Range, le SR Local Block et la préférence SRMS sont associés aux Router Information Opaque LSAs. En OSPFv3, les données de préfixe traversent les Extended Prefix LSAs et leurs TLV ; Adj-SID et LAN Adj-SID apparaissent dans les Router-Link TLV ; l’algorithme, la range, le bloc local et la préférence SRMS apparaissent dans les Router Information LSAs. Une même structure YANG ne rend pas ces familles filaires identiques.

La vérification préalable doit être concrète. Identifier d’abord OSPFv2 ou OSPFv3. Confirmer ensuite les aires visées et l’effet sur toutes leurs interfaces. Comparer le SRGB propre au protocole et les liaisons de Mapping Server avec la demande approuvée. Inventorier chaque Adj-SID lié à un voisin et toute dépendance TI-LFA ou Remote LFA. Capturer l’état LSDB correspondant avant l’activation, puis vérifier après celle-ci la famille attendue. Une divergence entre configuration et état versionné doit arrêter l’opération ; l’encodage de l’autre version ne constitue pas un substitut.

L’accès de gestion fait partie du périmètre de contrôle. NETCONF ou RESTCONF doit employer un transport sécurisé et une authentification mutuelle. NACM peut limiter les utilisateurs aux opérations et contenus autorisés. Une modification non autorisée de l’activation SR, des liaisons, du SRGB, des Adj-SIDs ou de TI-LFA peut perturber, rediriger ou refuser le trafic. La lecture des augmentations LSDB OSPFv2 et OSPFv3 peut révéler des préfixes, algorithmes, ranges, blocs locaux, données SRMS et informations de topologie utiles à un attaquant.

Analyse de Theo March : le point durable n’est pas seulement « un modèle contre deux modèles ». C’est une intention commune avec deux grammaires de preuve. Cette distinction compte pour les décisions de software-lifecycle-and-lock-in : une abstraction peut simplifier la rédaction tout en conservant une validation, une autorisation et un retour arrière propres à chaque protocole. Le corpus ne permet pas de conclure sur le support des contrôleurs ou des fournisseurs, l’adoption, les performances, les incidents, le coût de migration ou les valeurs par défaut.

Parcours de décision opérateur

  1. Inventorier : noter la version OSPF, les aires, interfaces, voisins, SRGB, liaisons et fonctions existantes.
  2. Autoriser : distinguer les droits d’instance, d’aire et d’interface dans NACM et dans la revue de changement.
  3. Prévalider : contrôler les attentes LSA/TLV de la version et conserver une référence d’état.
  4. Déployer par étapes : choisir la plus petite aire approuvée ; une modification d’aire n’est pas limitée à une interface.
  5. Vérifier : confirmer les Opaque LSAs OSPFv2 ou les Extended LSAs/TLV OSPFv3, puis contrôler Adj-SIDs et protections optionnelles.
  6. Revenir en arrière : annuler de façon versionnée l’activation, les liaisons, le SRGB, les Adj-SIDs et TI-LFA, avec une preuve séparée du retour de chaque famille d’état.

Sources