Zusammenfassung

  • draft-ietf-ivy-network-inventory-topology-11 ordnet logische Knoten und Abschlusspunkte über ne-ref und port-ref physischen Elementen zu. Das schreibgeschützte port-breakout nennt mögliche Hardwarekanäle, belegt aber weder die aktuelle Aufteilung noch Betrieb oder freie Kapazität.
  • Zuordnungen können entdeckt, manuell erklärt, importiert oder für geplante Ressourcen angelegt werden. Herkunft, Konfigurationsabsicht, Geräte-Readback, Zustand, Kapazität, Orchestrierungsentscheidung und Dienstresultat brauchen daher getrennte Belege.

Ein Inventar ist noch kein Regal

Der Orchestrator sieht einen 400G-Port und vier breakout channels. Ein Auftrag verlangt 100G. In einer Bestandsansicht liegt es nahe, den ersten Eintrag zu reservieren.

Doch port-breakout ist config false. Der Text beschreibt eine intrinsische Fähigkeit, unabhängig davon, ob der Port gegenwärtig als trunk oder breakout konfiguriert ist. Die vier Einträge können zu einem Port gehören, der weiterhin als ein einziges 400G-Interface arbeitet.

Es fehlen Aussagen über erzeugte Child-Interfaces, Optik, Verkabelung, Lane-Zustand, Alarme, Reservierungen und Restkapazität. Die Fähigkeit kann vollkommen korrekt sein, während keine einzige 100G-Schnittstelle nutzbar ist. Das Problem entsteht, wenn eine Antwort auf „Was könnte dieses Bauteil?“ als Antwort auf „Was darf ich jetzt zusagen?“ verwendet wird.

Präzise Referenzen brauchen Herkunft

Revision 11 definiert auf RFC 8345 eine inventory-topology. ne-ref verbindet einen Knoten mit einem physischen Netzelement, port-ref einen Termination Point mit einer physischen Portkomponente. Mapping-Attribute unterscheiden innerhalb des Modells physische von abstrakten oder logischen Objekten.

Die standardisierte Referenz verbessert Austausch und Prüfbarkeit. Sie ist trotzdem eine Behauptung einer Quelle, keine unabhängige Besichtigung. Dass Mapping-Felder schreibbar sind, macht diesen Punkt ausdrücklich sichtbar.

Entdeckung ist der Normalfall, erreicht aber nicht jede Ressource. CPE kann außerhalb der Managementdomäne liegen. Gemietete Infrastruktur kann intern verborgen sein. Planung benötigt hypothetische künftige Objekte. Ein Bediener kann einen Discovery-Wert übersteuern.

Solche Einträge sind nicht minderwertig, solange ihre Herkunft erhalten bleibt. Der Beleg sollte Produzent, Methode, Zeitpunkt, Geltungsbereich, Änderungsbefugnis und den Status discovered, manual, imported oder hypothetical enthalten. Verschwindet das Etikett, wirkt eine Planung wie eine Beobachtung und eine handschriftliche Korrektur wie Telemetrie.

Was Read-only wirklich stärkt

port-breakout kann über dieses Modell nicht manuell gesetzt werden. Die Information wird durch die Hardware bestimmt und macht deshalb eine stärkere Aussage über die Fähigkeit des konkreten Bauteils.

Diese Aussage bleibt an Gerät, Komponente, Software oder Firmware, Erfassungsweg und Zeit gebunden. Ein Line-Card-Tausch kann den logischen Namen erhalten und die Fähigkeit ändern. Ein Cache kann die alte, damals richtige Antwort weiterreichen.

Aktuelle Konfiguration belegt erst ein genehmigtes Soll zusammen mit einem Readback nach dem Commit. Betrieb belegen vorhandene Child-Interfaces, Administrative und Operational State, Optik, Alarme und Zähler. Allokierbare Kapazität benötigt eine frische Messung für genau die gewählte Lane.

Mit getrennten Belegen lässt sich unterscheiden, ob Unterstützung fehlte, die Umstellung ausblieb, die Lane gestört ist oder Kapazität bereits gebunden wurde. Ein gemeinsames „available“ verhindert diese Diagnose.

Die ehrliche Unvollständigkeit von leased-fiber

link-type ist ein leichter Wegweiser zu Kategorien wie fiber, copper, coax, microwave, WLAN und leased fiber. Er verweist auf spezialisierte Bestandsmodelle, ersetzt sie aber nicht.

Bei gemieteter Faser kann der Kunde die Abhängigkeit und Endpunkte kennen, ohne Strecke, Fasern und Zwischenkomponenten des Anbieters zu sehen. Der Wert ist wahr und die Sicht bleibt begrenzt.

Aus leased-fiber dürfen weder physische Diversität noch Kapazität erfunden werden. Ebenso falsch wäre es, die Abhängigkeit wegen fehlender Details zu löschen. Eine belastbare Darstellung hält die bekannte Beziehung und die Grenze der eigenen Beobachtungsmacht gleichzeitig fest.

Der Validator prüft das Modul

Zum Forschungsstichtag war Revision 11 ein aktiver Standards-Track Internet-Draft, beim IESG eingereicht und auf AD Go-Ahead wartend. Die IANA-Prüfung stand noch nicht auf OK. Der Datatracker zeigte für YANG null Fehler und null Warnungen.

Das ist ein Beleg für die Struktur des Moduls. Es ist kein Nachweis für Anbieterimplementierung, Rollout, Datenfrische oder Dienstzustand. Gesicherter Transport schützt auch einen veralteten Wert. NACM begrenzt Rechte, garantiert aber keine richtige Entscheidung eines Berechtigten.

Dokument, Implementierung, Konfiguration und Ergebnis dürfen nicht denselben grünen Status erben.

Der Weg von der Zuordnung zur Lieferung

Das Provisionierungsbeispiel ordnet zunächst einen SAP einem Port zu und prüft anschließend mit weiteren Topologiemodellen die Kapazität. Reichen Ressourcen nicht, kann ein anderer SAP oder menschlicher Eingriff folgen. Mapping allein ist kein Kapazitätsurteil.

Ein belastbarer Auftrag nennt Gerät, Parent-Port, Breakout-Modus, erwartete Kinder, optische Annahmen, Wartungsfenster und Genehmigung. Nach der Änderung wird das Gerät zurückgelesen: Welcher Modus ist aktiv, welche Interfaces existieren?

Danach folgen Zustand, Alarme, Fehler, Optik und ungebundene Kapazität. Der Orchestrator protokolliert Policy-Version, gelesene Snapshots, Kandidaten, Ausschlüsse, SAP- oder Pfadwahl und manuelle Ausnahmen. Erst Aktivierung, beobachteter Traffic-Pfad und Kundenergebnis schließen die Kette.

Ein akzeptierter Befehl ist kein Dienst. Ein Interface in Zustand up ist allein noch keine Lieferung.

Zehn Belege statt eines überladenen Graphen

Aufbewahrt werden sollten:

  1. die von Werkzeugen verstandene Draft- oder RFC-, Modul- und Registry-Version;
  2. Controller, Gerät, Methode und Zeitpunkt des Snapshots;
  3. ne-ref, port-ref und link-type samt Herkunft;
  4. Referenzintegrität und Befugnis für Anlage oder Override;
  5. port-breakout gebunden an Komponente und Firmware;
  6. genehmigtes Konfigurationsziel und Change Record;
  7. Readback nach Commit und tatsächlich vorhandene Kinder;
  8. Zustand, Optik, Zähler und Kapazität der Lane;
  9. Policy, Kandidaten, gewählter SAP oder Pfad und Eingriff; und
  10. Aktivierung, beobachteter Traffic und Kundenergebnis.

Der Entwurf warnt, dass veraltete oder falsche Zuordnungen Fehlprovisionierung, unerwartete Wege, Aktivierungsfehler und ungenaue Kapazitätsplanung verursachen können. Getrennte Belege zeigen, welche Schicht zu korrigieren ist.

Quellen