Résumé

  • Dans draft-ietf-ivy-network-inventory-topology-11, ne-ref et port-ref relient un objet topologique à un élément physique, tandis que port-breakout, en lecture seule, décrit ce que le matériel peut exposer. Aucun de ces champs ne prouve qu’un canal est configuré, actif ou disponible.
  • Les correspondances peuvent venir de la découverte, d’une saisie manuelle ou d’une ressource encore hypothétique. Leur provenance doit donc rester distincte de la configuration, de la télémétrie, du choix d’orchestration et du résultat du service.

La capacité existe avant le service

Le piège apparaît dans une vue d’inventaire très convaincante. Un port 400G possède quatre entrées sous port-breakout. Une demande de service cherche 100G. L’écran semble avoir déjà fait le travail : choisir un des quatre canaux.

En réalité, l’écran a seulement montré une possibilité matérielle. Le conteneur est config false et le projet précise que la liste représente une capacité intrinsèque, que le port soit actuellement configuré en trunk ou en breakout. Cette nuance empêche une lecture comptable des canaux : quatre capacités décrites ne sont pas quatre interfaces créées, encore moins quatre ressources vendables.

Pour passer de « peut » à « fonctionne », il faut un changement approuvé, une configuration écrite, une relecture du dispositif, la présence des interfaces enfants, leur état, leurs compteurs et une mesure de capacité. Puis il faut encore la décision de l’orchestrateur et la preuve que le trafic du service suit le chemin attendu.

Une topologie qui reconnaît ses propres limites

La révision 11 ajoute au modèle de topologie de RFC 8345 un type inventory-topology. Les nœuds peuvent pointer vers un élément réseau par ne-ref; les points de terminaison peuvent pointer vers un composant de port par port-ref. La présence des attributs de correspondance distingue, dans ce modèle, les objets physiques des objets abstraits.

Cette normalisation est utile : deux systèmes peuvent échanger une relation sans partager une convention privée de noms. Mais la relation reste une affirmation du modèle. Elle ne réalise pas une inspection indépendante du châssis, du câble ou de l’optique.

Le texte le montre en autorisant l’écriture de ne-ref, port-ref, link-type et du conteneur de présence. La découverte est le cas ordinaire, mais elle ne voit pas tout. Un CPE peut être hors du domaine de gestion. Une liaison louée peut cacher son infrastructure. Un planificateur peut préparer une ressource future. Un opérateur peut devoir remplacer manuellement une valeur découverte.

La saisie manuelle n’est pas une faute. La faute serait de la présenter plus tard comme une observation automatique. Un reçu de correspondance doit conserver l’auteur ou le contrôleur, la méthode, l’heure, le périmètre, l’autorité de modification et le statut — observé, importé, tiers ou hypothétique. Une valeur précise sans cette histoire devient dangereusement anonyme.

Pourquoi port-breakout est plus fort, mais pas absolu

Contrairement aux références de correspondance, port-breakout n’est pas configurable. Le matériel détermine cette information. Elle soutient donc une affirmation plus robuste sur la capacité intrinsèque du composant.

Cette robustesse a une frontière. Le champ ne dit rien du mode actuel du port parent, de l’existence des interfaces enfants, de la compatibilité de l’optique, de l’état des lanes ni de l’affectation de capacité. Une carte remplacée ou un micrologiciel différent peut aussi changer la capacité alors que le nom logique reste identique.

La preuve utile attache donc la réponse au dispositif exact, au composant, à la version logicielle, à la méthode de collecte et au temps. Le modèle peut affirmer honnêtement : « ce port peut être ventilé ». L’exploitation doit répondre séparément : « ce port a été ventilé ainsi, ces enfants sont présents, et celui-ci est utilisable maintenant ».

La fibre louée et la vérité partielle

link-type joue un rôle volontairement léger. Fibre, cuivre, coaxial, micro-ondes, WLAN ou fibre louée orientent le consommateur vers des modèles plus spécialisés. Ces identités ne constituent pas un inventaire physique complet.

La fibre louée rend cette économie particulièrement claire. Le locataire peut savoir qu’une arête dépend d’une infrastructure tierce sans voir le trajet, les brins, les équipements intermédiaires ou la capacité physique détaillée. L’indication reste vraie et précieuse. Elle signale aussi une limite d’autorité.

Deux erreurs symétriques sont alors possibles. La première consiste à inventer le détail manquant et à traiter leased-fiber comme une inspection de la plante. La seconde consiste à supprimer la dépendance du modèle parce qu’elle n’est pas entièrement visible. Une gouvernance mature conserve les deux informations : le type de liaison est connu, le détail physique demeure chez un tiers.

Zéro erreur de schéma, zéro preuve d’exploitation

Au moment de la recherche, la révision 11 était un Internet-Draft actif, destiné à la voie Standards Track, soumis à l’IESG et en attente du feu vert d’un Area Director. L’examen IANA n’était pas encore « OK ». Le Datatracker indiquait aussi zéro erreur et zéro avertissement de validation YANG.

Cette dernière information concerne le document et le module. Elle ne prouve ni l’implémentation d’un fournisseur, ni la fraîcheur d’un contrôleur, ni l’état d’un port. Un modèle impeccable peut transporter une correspondance périmée. TLS peut protéger son transport sans corriger son contenu. NACM peut limiter l’accès sans garantir que l’utilisateur autorisé choisira le bon SAP.

Le vert de la validation ne doit donc pas devenir un vert d’exploitation. Chaque couche possède son propre verdict.

Le test décisif : relire le dispositif

Une chaîne responsable commence par l’intention : dispositif et port concernés, mode demandé, identifiants attendus des canaux, contraintes d’optique, fenêtre et approbation. Elle poursuit avec la transaction de configuration et sa relecture. Le parent a-t-il changé de mode ? Les enfants attendus sont-ils réellement apparus ?

Viennent ensuite l’état opérationnel, les alarmes, les compteurs, la télémétrie optique et la capacité du canal exact. La correspondance du SAP au port ne suffit pas. L’exemple de fourniture de service du projet consulte d’autres modèles topologiques pour vérifier la capacité; si les ressources manquent, un autre SAP ou une intervention manuelle peut être nécessaire.

Enfin, il faut documenter la politique d’orchestration, ses candidats, le choix, l’activation et le chemin de trafic observé. Une configuration réussie n’est pas encore un service livré. Une interface « up » n’est pas encore la preuve que le client reçoit le résultat attendu.

Dix reçus plutôt qu’un seul graphe

Un dossier auditable devrait conserver séparément :

  1. la version exacte du projet ou RFC et du module comprise par l’outil ;
  2. l’identité du contrôleur, du dispositif et l’heure de l’instantané ;
  3. les valeurs ne-ref, port-ref et link-type avec leur provenance ;
  4. les contrôles d’intégrité et l’autorité de modification ;
  5. la capacité port-breakout liée au composant et à sa version logicielle ;
  6. l’intention de configuration et son approbation ;
  7. la relecture après commit et les interfaces réellement créées ;
  8. l’état, les compteurs, l’optique et la capacité du canal ;
  9. la politique, le SAP ou chemin choisi et toute intervention humaine ;
  10. l’activation, le trafic observé et le résultat visible par le client.

Les avertissements de sécurité du projet justifient cette séparation. Une correspondance obsolète ou erronée peut provoquer une mauvaise fourniture, un chemin inattendu, un échec d’activation ou une planification de capacité fausse. Ces effets n’ont pas la même cause et ne se réparent pas avec le même contrôle.

Sources