Résumé

  • La révision 20 définit des identités, des types et des groupements YANG réutilisables pour les réseaux Layer 1 et l’OTN ; le module seul n’expose ni nœud inscriptible, ni état en lecture seule, ni RPC.
  • Une description cohérente de la bande passante ou des créneaux est un reçu de schéma. L’importation, la capacité réelle, l’autorisation, la transaction, l’état appliqué et le service restent des reçus distincts.

La même phrase sur deux écrans

Le premier progrès est presque invisible. Un contrôleur et un équipement utilisent enfin la même identité pour ODU4, la même structure pour une plage de Tributary Slots et la même forme pour une demande ODUflex. Une traduction propriétaire disparaît. Une ambiguïté cesse de circuler entre l’inventaire, la topologie et le tunnel.

C’est exactement ce que doit produire un bon module de types communs. Mais la phrase commune ne dit pas que les deux écrans observent la même capacité au même instant. Elle ne dit pas que l’équipement sait instancier tous les types importés. Elle ne dit pas qu’une écriture a été autorisée, validée, engagée et appliquée.

La révision 20 de Common YANG Data Types for Layer 1 Networks date du 14 septembre 2026 et expire le 18 mars 2027. Datatracker la place dans la file du RFC Editor, comme document du groupe CCAMP destiné au statut Proposed Standard. Le travail est mûr et approuvé, mais ce n’est pas un RFC, encore moins une preuve de déploiement ou d’interopérabilité.

L’erreur de lecture vient de la précision du vocabulaire. Les arbres contiennent bande passante, client, étiquette, plage, priorité et redimensionnement. Ces mots ressemblent à un plan d’exécution. Le document fournit cependant une bibliothèque à importer. La précision d’une bibliothèque ne met aucun laser sous tension.

Ce que le module rend réellement commun

ietf-layer1-types établit les formes partagées nécessaires aux modèles de topologie, de tunnel, de signal client et de service de connectivité. Il complète les types génériques d’ingénierie de trafic par des attributs propres à l’OTN.

Les identités de granularité distinguent 1,25G, 2,5G et 5G. La hiérarchie odu-type permet de nommer les unités optiques normalisées et d’étendre la base dans un module fournisseur. client-signal couvre notamment Ethernet, STM, OC et Fibre Channel. Les groupements d’étiquette ajoutent le Tributary Port Number et les ensembles de Tributary Slots aux restrictions génériques. Les groupements de bande passante décrivent ce qu’un lien peut porter ou ce qu’un chemin demande.

Ce socle est de l’infrastructure. Sans lui, chaque intégrateur reconstruit les mêmes concepts avec des limites, des unités ou des cardinalités différentes. Avec lui, les outils peuvent comparer des objets dont la forme a été revue publiquement.

Mais une identité dérivée n’est pas un certificat de capacité. Le texte signale lui-même qu’une extension fournisseur peut nommer des formes pour lesquelles une spécification connexe ne garantit pas l’interopérabilité du plan de données. Une valeur peut donc être valide dans le schéma et rester inutilisable face à un pair.

La bonne conclusion est étroite : le module autorise un langage commun. Il n’autorise pas à conclure que tout système parlant ce langage sait réaliser toutes ses phrases.

Aucun nœud à écrire dans la bibliothèque

La limite la plus nette figure dans les considérations de sécurité. Le module définit des identités, des types et des groupements destinés à être réutilisés. Pris seul, il n’expose aucun nœud de données inscriptible, aucun nœud d’état en lecture seule et aucune RPC.

Cette phrase empêche plusieurs raccourcis. Installer le fichier YANG n’est pas créer un objet dans un datastore. Importer un groupement n’est pas exposer une ressource sur un équipement. Voir rw dans l’arbre d’un groupement montre comment les feuilles pourraient apparaître une fois instanciées ; cela ne montre ni l’endroit où elles ont été instanciées, ni le protocole disponible, ni les droits de l’utilisateur.

Le risque commence dans les modules consommateurs. Une topologie qui instancie otn-link-bandwidth ou une plage d’étiquettes peut divulguer des informations sensibles. Le module consommateur doit donc préciser sa surface, son contrôle d’accès et ses conséquences. La bibliothèque ne peut pas écrire ces considérations à sa place.

Pour auditer une capacité, il faut la liste YANG annoncée par l’équipement, la révision exacte, les features, les deviations et le chemin de données instancié. Pour modifier une ressource, il faut en plus une session, une identité authentifiée, une décision NACM, une opération et un datastore. Le fichier commun n’émet aucun de ces reçus.

La capacité est une vue, pas un stock additionnel

Le groupement de bande passante d’un lien peut exprimer le nombre d’ODU pris en charge pour chaque type. L’exemple du projet est parlant : un lien de 100G peut porter un ODU4, dix ODU2 ou quatre-vingts ODU0.

Ces nombres décrivent des découpages alternatifs de la même capacité. Les additionner produirait une ressource fictive. Les lire sans l’occupation courante produirait une disponibilité fictive. Le modèle sait représenter une vue ; l’allocateur doit toujours résoudre la concurrence entre vues, demandes et contraintes.

Une plage d’étiquettes a la même nature. L’étiquette OTN combine un TPN et les slots associés. Pour un même LSP, les deux extrémités du lien doivent recevoir la même étiquette. La plage annonce les valeurs disponibles selon la granularité, le type d’ODU et la priorité.

Entre cette annonce et la réservation, un autre contrôleur peut prendre la ressource. La topologie peut être périmée. Une extrémité peut accepter une combinaison que l’autre refuse. Une transaction peut réussir dans le datastore cible puis être annulée lors de l’application matérielle.

Il faut donc horodater la vue, conserver sa source, relier la sélection au transaction ID et relire l’état opérationnel des deux extrémités. Ensuite seulement viennent le contrôle de continuité et les mesures du signal client. Une plage disponible n’est que le premier reçu.

ODUflex résiste au compteur unique

ODUflex accepte plusieurs formes dont le débit nominal se calcule différemment. Le choix YANG distingue un débit générique, un client CBR, les paramètres GFP n et k, FlexE, FlexE-aware et le débit d’une charge paquet.

Le cas générique facilite la compatibilité future dans un domaine de transit où le type exact n’est pas nécessaire à l’établissement. Le texte recommande pourtant de ne l’utiliser qu’en cas de besoin et de préférer le cas spécifique dès que possible. L’abstraction aide un nœud à avancer ; elle retire aussi une information qu’un autre nœud peut exiger.

Le projet ajoute une mise en garde décisive : le seul nombre d’ODU disponibles ne suffit pas à déduire la bande passante disponible pour des LSP ODUflex. Le nombre de slots et le type d’ODTU interviennent dans le calcul. Les contraintes de matrice de connectivité et du lien local ajoutent encore le chemin sous-jacent.

Un tableau de bord qui affiche « 1 ODUflex libre » sans ces entrées transforme une structure riche en certitude pauvre. Le remède n’est pas un nouveau slogan. Il faut conserver le type de choix, le calcul, la granularité, l’ODTU, les contraintes de chaque segment et l’âge de la donnée.

Une identité “resizable” ne mesure aucune interruption

La révision 20 sépare ODUflex non redimensionnable et ODUflex-resizable. L’identité signale la prise en charge des procédures de redimensionnement sans interruption et permet de représenter des limites de capacité différentes.

Dans le schéma, cette identité prouve qu’un concept possède un nom et une relation de dérivation. Dans l’inventaire d’un équipement, elle peut indiquer une capacité déclarée. Dans la configuration, elle peut porter une intention. Aucune de ces apparitions ne prouve qu’un LSP déterminé a changé de taille sans perte.

La preuve opérationnelle exige des extrémités compatibles, des ressources supplémentaires, une coordination temporelle, un état avant/après et des compteurs observés durant la transition. Le mot “hitless” appartient au résultat, pas à l’étiquette seule.

Ce détail illustre l’utilité du modèle : il rend l’ambition explicite et testable. Il n’abolit pas le test.

De NETCONF à la lumière, plusieurs autorités

NETCONF et RESTCONF donnent une surface de protocole aux données définies par YANG. Le transport sécurisé et l’authentification mutuelle établissent les pairs selon la confiance configurée. NACM décide quelles opérations et quels contenus un utilisateur peut atteindre.

Une charge valide répond à la grammaire du nœud instancié. Une réponse de protocole indique ce que le serveur a accepté dans le cadre de l’opération. L’architecture NMDA sépare ensuite l’intention et l’état opérationnel. Une configuration validée peut attendre un commit ; un commit peut ne pas devenir immédiatement effectif ; l’état opérationnel peut contenir des valeurs dérivées par le système.

Pour une liaison optique, une étape supplémentaire subsiste. Le contrôleur peut voir le cross-connect comme actif alors que la couche physique signale une perte, un taux d’erreur ou une adaptation client incorrecte. Le modèle de gestion fournit le témoignage de l’implémentation. La télémétrie et le trafic fournissent le témoignage du service.

Réduire ces étapes à un voyant “succès YANG” détruit la possibilité d’expliquer une panne partielle. Les conserver séparées rend l’automatisation plus robuste : chaque frontière a son erreur, son horodatage et son rollback.

Le dossier de preuve à demander

Le dossier commence par la révision du projet, le hash du module, les dépendances et la version des validateurs. Il compare ensuite le module-set de chaque équipement, ses features et ses deviations.

La transaction conserve le principal authentifié, la décision NACM, l’opération, le datastore cible, le hash de la charge, l’identifiant de transaction, la validation, le commit et le rollback éventuel. La relecture opérationnelle doit être associée au même changement.

La couche ressource ajoute le snapshot de topologie, le type d’ODU, le signal client, la granularité, le TPN, les slots, l’ODTU, la priorité, les contraintes de matrice et l’état concurrent. ODUflex ajoute le cas choisi et les entrées du calcul. Un redimensionnement ajoute les capacités avant/après et la fenêtre de mesure.

Enfin, l’observation indépendante retient alarmes, continuité, erreurs optiques et trafic client. Une affirmation de bout en bout exige des reçus pour chaque segment inclus dans cette affirmation.

La discipline du code en fonctionnement proposée par Heng Lu s’applique sans opposer document et réalité. Le document doit être fort sur la structure commune. L’implémentation doit être forte sur ce qu’elle exécute. Le réseau doit être fort sur ce qu’il démontre. Aucun niveau ne gagne à emprunter le vocabulaire de preuve du suivant.

Ce que les sources ne démontrent pas

Les sources gelées établissent la structure du modèle, son historique, ses dépendances et les limites déclarées des protocoles de gestion. Elles ne démontrent pas qu’un produit nommé implémente la révision 20, qu’un opérateur l’a déployée, qu’un chemin particulier a été réservé ou qu’un service a satisfait ses objectifs.

Cet Article ne classe ni fournisseurs ni réseaux. Il conclut plus précisément qu’une syntaxe commune peut réduire les erreurs de traduction sans devenir l’autorité de l’état réel. Le vocabulaire est partagé ; la capacité, l’action et le résultat doivent encore être observés.

Sources