Résumé

  • La RFC 9902 est une spécification IETF Standards Track qui définit le module YANG ietf-isis-sr-mpls pour le routage segmenté IS-IS sur le plan de données MPLS.
  • Elle étend le modèle IS-IS de la RFC 9130 et dépend du modèle SR indépendant du protocole de la RFC 9020.
  • Le modèle sépare l’activation, l’annonce et la réception du Mapping Server, les fonctions de protection optionnelles, la configuration et l’état opérationnel.

Le contrat opérationnel commence avec enable. Lorsque ce leaf est défini à true, IS-IS SR-MPLS est activé et les extensions pertinentes sont annoncées avec les paramètres configurés dans le modèle SR de base. Ce leaf n’alloue donc pas les étiquettes, ne calcule pas les chemins et n’assure pas le transfert. Avant de le modifier, l’opérateur doit contrôler le SRGB, le SRLB, les algorithmes et les autres ressources du modèle RFC 9020, puis les comparer à l’état IS-IS visé.

La RFC 9902 étend la RFC 9130, tandis que la RFC 9020 fournit le socle SR commun. Cette séparation est importante pour la revue : une modification propre à IS-IS peut dépendre de ressources configurées dans une autre arborescence. Une prévalidation sérieuse doit donc lire les deux niveaux, les capacités annoncées et l’état opérationnel attendu.

L’échange avec un Mapping Server possède deux contrôles distincts. bindings/advertise/policies sélectionne les politiques dont les bindings peuvent être annoncés. bindings/receive contrôle la réception et le traitement. Par défaut, IS-IS n’annonce ni ne traite les entrées du Mapping Server. Activer un sens ne déclenche pas silencieusement l’autre, et la présence de ressources SR ne permet pas de déduire une politique d’échange.

Le modèle étend également le Fast Reroute des interfaces. TI-LFA peut être activé lorsqu’il est pris en charge, et Remote LFA peut utiliser un chemin SR au lieu d’un chemin LDP lorsque l’option correspondante est disponible et que Remote LFA est lui-même activé. Ces fonctions sont optionnelles : la RFC 9902 ne les impose pas. Les critères de sélection TI-LFA peuvent notamment inclure la protection de nœud et la disjonction SRLG ; leurs priorités sont configurables, une valeur plus basse étant préférée.

L’état observable comprend les indicateurs de capacité SR, les algorithmes, les informations SRGB et SRLB, la préférence du Mapping Server, les Prefix-SID, les Adj-SID et les TLV de liaison SID/étiquette. Les augmentations de configuration et d’état opérationnel de la LSDB rendent ces éléments vérifiables. Elles ne garantissent toutefois ni le transfert, ni le calcul de chemins, ni l’attribution d’étiquettes, ni la sécurité ou l’interopérabilité d’une implémentation.

Vérifications concrètes de conformité

  1. Vérifier que l’implémentation annonce le support de ietf-isis-sr-mpls et des fonctions optionnelles envisagées avant d’écrire leurs contrôles.
  2. Lire les ressources SR de la RFC 9020 et comparer SRGB, SRLB, algorithmes, Prefix-SID, Adj-SID et bindings attendus avec l’état IS-IS planifié.
  3. Maintenir enable à false pendant la préparation, puis ne l’activer qu’après approbation de la comparaison.
  4. Confirmer qu’aucune politique de publicité du Mapping Server n’est sélectionnée sans autorisation explicite, et que la réception reste désactivée lorsqu’aucun traitement entrant n’est prévu.
  5. Contrôler après activation les capacités, algorithmes, plages, SID, bindings et résultats de la LSDB.
  6. N’écrire les contrôles TI-LFA ou Remote LFA basé sur SR que si les fonctions sont supportées ; pour ce dernier, vérifier aussi que Remote LFA est activé.
  7. Utiliser NETCONF ou RESTCONF sur un transport sécurisé avec authentification mutuelle, et appliquer NACM aux opérations et contenus permis.

La RFC 9902 distingue deux catégories de risques. Une modification non autorisée de SR, des bindings du Mapping Server ou de TI-LFA peut supprimer ou détourner du trafic et provoquer un déni de service. La lecture peut divulguer les capacités du routeur, les algorithmes, le SRGB, le SRLB, la préférence du Mapping Server et les augmentations de la LSDB. L’état opérationnel n’est donc pas une information inoffensive.

Dans cette analyse de Theo March, les contrôleurs devraient valider les deux couches, détecter les dérives des plages et de l’état annoncé, déployer progressivement et séparer les rôles d’autorisation pour les écritures, l’échange de politiques et les lectures sensibles. Il s’agit d’une analyse, pas d’une exigence RFC. Les RFC ne fournissent pas ici de preuve sur un fournisseur, un contrôleur, une performance, une adoption, un incident, un coût de migration ou un seuil de retour arrière.

Parcours de décision opérateur : si capacités, ressources, autorisations et politiques concordent, déployer le modèle sur un périmètre maîtrisé, conserver l’état initial, activer, puis comparer l’état opérationnel à l’inventaire approuvé. En cas d’écart, d’annonce inattendue, de changement de binding ou de protection non prévu, retirer les nouveaux paramètres dans l’ordre inverse, restaurer les valeurs enregistrées, désactiver enable si nécessaire et vérifier la LSDB et l’état de contrôle du trafic. Cette procédure locale ne garantit ni l’absence d’interruption ni la sécurité.

Sources