Résumé

  • Le projet draft-ietf-teas-actn-poi-applicability-20, destiné à un RFC informatif, reste en consultation finale de l’IESG jusqu’au 23 septembre 2026. Les avis « Not ready » de deux rapporteurs ne sont pas une décision de l’IESG.
  • Yaron Sheffer réclame une analyse des menaces propre aux relations de confiance entre contrôleurs. Nick Buraglio demande des réponses sur la divergence MDSC–PNC, les notifications perdues, les redémarrages et les opérations qui ne réussissent que dans une couche.
  • Un exploitant devrait éprouver les droits d’action, la fraîcheur des états et la reprise d’une transaction interrompue avant de déléguer la configuration entre paquets et optique. Ce cadre d’essai est une analyse éditoriale, pas une nouvelle prescription de l’IETF.

Le statut « terminé » peut cacher deux résultats

Prenons une modification ordonnée par un coordinateur à un contrôleur paquet et à un contrôleur optique. Le premier confirme, le second ne répond plus. Afficher « opération terminée » serait trompeur ; relancer sans identifier la première tentative pourrait l’être aussi. Il s’agit d’un scénario de test imaginé ici, nullement d’une panne observée. Il montre pourquoi la relation entre les composants ne suffit pas à définir l’état du service.

La version 20 du projet ACTN/POI expose en détail le rôle du Multi-Domain Service Coordinator (MDSC), des Provisioning Network Controllers (PNC) des domaines paquet et optique, des interfaces et des modèles YANG. L’appel final de l’IESG, ouvert le 9 septembre, se termine le 23. Le texte vise un statut informatif ; au contrôle du 21 septembre, il demeure un Internet-Draft, sans approbation ni numéro de RFC. Il comprend déjà des parties sur la sécurité et l’exploitation. La question des évaluateurs porte sur leur portée effective.

Les résultats publics doivent se lire séparément. L’avis de sécurité de Yaron Sheffer, achevé le 18 septembre, et l’avis d’exploitation de Nick Buraglio, achevé le 19, portent tous deux la mention « Not ready ». Buraglio parle de préoccupations mineures dans son résumé, puis qualifie l’insuffisance de la partie exploitation de problème majeur dans son examen détaillé. L’avis du domaine routage de Zheng Zhang est, lui, « Ready » et propose surtout des clarifications. Aucune de ces notes ne vaut rejet formel ni preuve d’un incident sur un réseau déployé.

Une interface chiffrée n’authentifie pas la vérité d’une topologie

Sheffer observe que la section 7 aborde la protection des protocoles et s’attarde sur LLDP. Selon lui, une architecture qui traverse plusieurs administrations, fournisseurs et contrôleurs mérite aussi une courte analyse de ses actifs et frontières de confiance. Il demande de traiter les contrôleurs compromis ou malveillants, les informations de ressources fausses ou périmées, les opérations non autorisées entre couches, la divulgation, l’épuisement des ressources et les états paquet/optique incohérents. Il suggère une analyse d’ordre architectural, plutôt qu’un inventaire exhaustif.

Il précise ne pas disposer de l’expertise nécessaire pour juger tous les détails techniques du long document : son avis ne peut donc être transformé en découverte d’une faille exploitée.

Le cadre ACTN du RFC 8453 distingue les fonctions des MDSC et PNC ainsi que l’abstraction régie par des politiques. Un canal protégé peut garantir l’origine d’un message et limiter l’accès. Il ne garantit pas que la représentation des ressources est encore actuelle ni qu’un PNC redémarré connaît toujours l’opération qu’il avait acceptée. L’exploitant doit savoir qui a établi la vue, à quel moment, pour quel demandeur et avec quel droit d’agir sur chaque couche. C’est cette articulation que l’avis de sécurité veut voir examinée, au-delà d’une liste de transports sécurisés.

Le coordinateur et le domaine peuvent conserver deux « présents »

Buraglio part des notifications sur lesquelles le MDSC construit sa base de topologie et de services. Si un PNC redémarre, qu’une notification manque ou qu’une défaillance n’affecte qu’une partie du système, le MDSC et le PNC peuvent diverger. Comment le coordinateur détecte-t-il cet écart, comment reconstruit-il l’état et que deviennent les demandes en cours pendant le redémarrage ou le basculement ? Quelle est la conséquence d’une indisponibilité du MDSC sur les services déjà établis ? Le projet, estime le rapporteur, ne donne pas assez de prise à ces questions.

Il souligne aussi la succession d’interactions entre MDSC, PNC paquet et PNC optique. Le texte ne propose guère de repères pour la durée de configuration, les délais d’attente et les nouvelles tentatives. Il ne décrit pas suffisamment le cas où la reconfiguration paquet réussit et l’opération optique échoue, ni l’inverse. Un système exploitable doit au moins distinguer la demande initiale d’une relance, puis savoir quelle couche a réellement confirmé avant d’autoriser une compensation.

Cette dernière phrase exprime la conséquence opérationnelle que nous tirons de l’avis ; elle ne prétend pas que le projet définit un protocole universel de retour arrière.

Le même examen réclame une trajectoire pour les réseaux existants, où les systèmes de gestion paquet et optique ne disparaîtront pas au premier déploiement d’ACTN. Il relève le besoin de compétences communes aux deux domaines, de limites de montée en charge intelligibles, de persistance des binding SID après redémarrage, de gestion des abonnements aux notifications et de traces des changements. Plusieurs points peuvent relever d’une réalisation locale. Justement, l’acheteur doit savoir lesquels sont laissés au produit, à l’intégrateur ou à son équipe de permanence.

Éprouver l’interruption, pas seulement la démonstration

Avant d’autoriser la configuration de production, une organisation peut demander cinq pièces reliées pour chaque changement : l’identité et le périmètre du demandeur, la version des états utilisés, l’identifiant durable de l’opération en cours, la réponse effective de chaque PNC et l’observation du service après exécution. Elle peut ensuite perdre volontairement une notification, redémarrer un PNC pendant une demande, basculer le MDSC entre deux réponses et ne faire aboutir qu’une seule couche. Le bon résultat n’est pas nécessairement « succès » ; il peut être « inconnu, nouvelles actions suspendues, état à reconstruire ».

Cette vérification proposée par la rédaction n’est pas un format d’enregistrement imposé par l’IETF. Elle distingue le sujet de cet article d’une discussion antérieure sur la topologie abstraite en tant que vue politique plutôt qu’inventaire physique. L’enjeu nouveau est la responsabilité après la délégation d’une action à plusieurs contrôleurs. La consultation peut encore conduire à un amendement ou à une approbation. Rien dans le dossier actuel ne permet d’annoncer un RFC refusé, une attaque avérée ou une interruption de service.

Sources

Projet ACTN/POI et statut ; avis du domaine sécurité ; avis du domaine exploitation ; avis du domaine routage ; RFC 8453, cadre ACTN.