Zusammenfassung

  • Revision 20 definiert wiederverwendbare YANG-Identitäten, Typen und Groupings für Layer 1 und OTN. Das Modul selbst stellt weder schreibbare Knoten noch schreibgeschützten Zustand oder RPCs bereit.
  • Schemaerfolg belegt gemeinsame Form. Gerätefähigkeit, Zugriffsentscheidung, Datastore-Transaktion, angewandter Zustand, Slot-Zuteilung und optischer Dienst brauchen jeweils einen eigenen Beleg.

Ein fehlerfreier Build ohne Gerätewirkung

Der Validator lädt das Modul, löst Imports auf und akzeptiert jede Identity, Choice und Range. Die Pipeline ist grün. In einer Softwarebibliothek wäre das ein plausibler Abschluss.

In einem Transportnetz ist es der Anfang einer längeren Kette. Der Validator hat kein Gerät nach seinem Module-Set gefragt, keinen Principal authentifiziert, keine NACM-Regel ausgewertet, keine Konfiguration committed und keine Tributary Slots an zwei Endpunkten belegt.

Revision 20 von Common YANG Data Types for Layer 1 Networks trägt das Datum 14. September 2026 und läuft am 18. März 2027 ab. Datatracker führt sie als CCAMP-Arbeitsgruppendokument mit Zielstatus Proposed Standard in der RFC-Editor-Warteschlange. Der Entwurf ist weit fortgeschritten, aber weder RFC noch Implementierungs- oder Betriebsnachweis.

Dass das Schema Kapazität kennt, bedeutet, dass es Kapazität konsistent beschreiben kann. Es bedeutet nicht, dass es über Kapazität verfügt.

Gemeinsame Semantik ist ein Produktionsgewinn

Optische Automatisierung verbindet Topologie-, Tunnel-, Client-Signal- und Servicemodelle. Ohne gemeinsame Typen entstehen private Übersetzungen: ein ODU-Name hier, eine andere Slot-Struktur dort, uneinheitliche Einheiten und Grenzwerte.

ietf-layer1-types stellt gemeinsame Bausteine bereit. Tributary-Slot-Granularitäten umfassen 1,25G, 2,5G und 5G. odu-type bildet eine erweiterbare Identity-Hierarchie. client-signal benennt unter anderem Ethernet-, STM-, OC- und Fibre-Channel-Familien. OTN-Groupings ergänzen allgemeine TE-Label- und Bandbreitenstrukturen um optische Attribute.

Das senkt Integrationskosten, macht Validierung reproduzierbarer und erlaubt Werkzeugen, geprüfte Formen wiederzuverwenden. Der Nutzen ist nicht symbolisch.

Ebenso real ist die Grenze. Vendor-Module können vom gemeinsamen odu-type ableiten. Der Entwurf weist darauf hin, dass eine zugehörige Container-Spezifikation die Interoperabilität im Datenpfad nicht garantiert. Ein gültiger Name kann also auf beiden Seiten existieren, während die praktische Abbildung inkompatibel bleibt.

Das Basismodell schafft Vergleichbarkeit. Eine Capability- und Interoperabilitätsprüfung bleibt nötig.

Das Grouping besitzt noch keinen Datastore-Ort

Die Security Considerations formulieren den Kern: Das Modul definiert Identitäten, Typen und Groupings für andere Module. Allein exponiert es keine schreibbaren Datenknoten, keine Read-only-State-Knoten und keine RPCs.

Ein rw im Baum eines Groupings beschreibt die Form nach der Instanziierung. Erst ein importierendes Modul setzt diese Form an einen konkreten Schema-Pfad. Erst eine Geräteimplementierung, ein Datastore und ein Managementprotokoll machen den Pfad zugänglich.

Auch die Sensibilität entsteht beim Verbraucher. Instanziierte OTN-Bandbreite und Labelbereiche können vertrauliche Topologie offenlegen. Das nutzende Modul muss Bedrohungen und Zugriffsschutz beschreiben.

Für eine Capability-Aussage braucht ein Betreiber daher das angekündigte YANG-Library-Inventar, Revisionen, Features, Deviations und Live-Knoten. „YANG-fähig“ ist zu breit. „Importiert Layer-1-Typen“ sagt nur, dass ein Schema die Bibliothek referenziert.

Bandbreitenansichten sind keine addierbaren Bestände

Der Entwurf zeigt einen 100G-Link, der alternativ ein ODU4, zehn ODU2 oder achtzig ODU0 unterstützen kann. Diese Zahlen beschreiben verschiedene Aufteilungen derselben Ressource. Ihre Summe wäre doppelte oder dreifache Buchführung.

otn-link-bandwidth strukturiert die Sicht nach ODU-Typ. Die aktuelle Verfügbarkeit hängt zusätzlich von Belegung, Fragmentierung, Priorität, Endpunktfähigkeit und Pfadbedingungen ab.

Ein OTN-Label enthält typischerweise Tributary Port Number und zugehörige Tributary Slots. Für denselben LSP muss an beiden Link-Enden dasselbe Label zugeteilt werden. Ein Labelbereich beschreibt Werte, die unter den angegebenen Bedingungen zur Einrichtung verwendet werden können.

Eine Bereichsabfrage reserviert keinen Wert. Zwischen Snapshot und Commit kann eine konkurrierende Transaktion den Slot belegen. Eine Seite kann akzeptieren, die andere ablehnen. Ein Candidate-Datastore kann validieren, ohne dass ein Commit erfolgt.

Der Reservierungsbeleg muss Snapshot-Zeit, TPN/TS, Transaction-ID, Locking, Ergebnisse beider Enden, Commit und Operational Readback enthalten. Dienstbeobachtung folgt danach.

ODUflex braucht die Formel hinter der Zahl

ODUflex umfasst sechs Formen mit unterschiedlichen Berechnungen der nominalen Bitrate. Das YANG-Choice unterscheidet generische Rate, CBR-Client, GFP-n/k, FlexE, FlexE-aware und Packet-Payload-Rate.

Der generische Fall dient Forward Compatibility in Transitdomänen, deren Setup nicht vom genauen Typ abhängt. Revision 20 empfiehlt zugleich, ihn nur bei Bedarf zu verwenden und wann immer möglich den typspezifischen Fall zu wählen, um Interoperabilität zu vereinfachen.

Die Abstraktion ist damit absichtlich begrenzt. Sie kann Transit ermöglichen, enthält aber nicht jede Information für die Edge-Anpassung. Ein Audit muss festhalten, welcher Choice-Zweig verwendet wurde.

Außerdem reicht die Zahl verfügbarer ODUs nicht aus, um ODUflex-Linkbandbreite abzuleiten. Anzahl der Tributary Slots und ODTU-Typ gehören zur Berechnung. Connectivity Matrix und Local-Link-Einträge können weitere Underlay-Grenzen hinzufügen.

Ein einzelner Wert „ODUflex frei“ ist nur dann belastbar, wenn seine Eingaben und sein Geltungsbereich erhalten bleiben.

Resizable benennt eine Fähigkeit, keinen verlustfreien Vorgang

Revision 20 trennt nicht-resizables ODUflex von ODUflex-resizable. Die zweite Identity beschreibt Unterstützung für Hitless-Resize-Verfahren und abweichende Kapazitätsgrenzen.

Im Schema ist sie ein gültiger Begriff. In einer Capability-Anzeige ist sie eine Aussage der Implementierung. In Intended Configuration ist sie ein gewünschter Zustand. Keine dieser Ebenen misst den tatsächlichen Übergang.

Ein Hitless-Nachweis braucht kompatible Endpunkte, zusätzliche Ressourcen, koordinierte Zeitpunkte, Vorher-/Nachher-Zustand sowie Alarme, Fehlerzähler und Client-Traffic während des Fensters. Die Identity definiert, was zu testen ist; sie liefert das Testergebnis nicht.

Zwischen Authentisierung und Licht liegen weitere Entscheidungen

NETCONF und RESTCONF transportieren Operationen auf YANG-Daten. Sicherer Transport und gegenseitige Authentisierung identifizieren die Peers im konfigurierten Vertrauensmodell. NACM entscheidet über Operation und Inhalt.

Ein schema-valider Payload kann unautorisiert sein. Ein autorisierter Payload kann an Ressourcenkonflikten scheitern. Eine erfolgreiche Candidate-Validierung ist kein Commit. Ein Commit in Intended State ist nicht automatisch angewandter Operational State.

NMDA hält diese Zustände auseinander. Damit werden asynchrone Anwendung, abgeleitete Werte und Hardwaregrenzen sichtbar. Nach dem Device State folgt der physische Nachweis: Active Cross-connect, Signalqualität und Client-Dienst sind nicht dieselbe Beobachtung.

Ein einzelnes „configured“ verdeckt diese Trennungen. Separate Belege ermöglichen eine präzise Wiederholung oder einen begrenzten Rollback.

Ein revisionsfester Nachweis

Der erste Abschnitt enthält Dokument- und Modulrevision, Hashes, Dependencies und Validator. Der zweite vergleicht Module-Set, Features und Deviations aller Endpunkte.

Der dritte hält Principal, NACM-Entscheidung, Operation, Datastore, Payload-Hash, Transaktion, Validierung, Commit und Rollback fest. Der vierte vergleicht Intended und Operational mit Zeitstempeln.

Der Ressourcenabschnitt enthält ODU, Client Signal, Granularität, TPN, TS, ODTU, Priorität, Pfadrestriktionen, Konkurrenz und ODUflex-Berechnung. Der Ergebnisabschnitt enthält Cross-connect, Alarme, optische Messwerte, Fehler und Traffic.

Heng Lus Running-Code-Disziplin macht Spezifikationen nicht klein. Sie bindet ihre Autorität an den definierten Bereich. Das Dokument ist maßgeblich für die gemeinsame Form; die Implementierung für ihre Operation; die Beobachtung für den Dienst.

Was die Quellen nicht beweisen

Die eingefrorenen Quellen belegen Modell, Publikationsstatus und normative Grenzen von YANG, Datastores und Zugriff. Sie belegen keine Konformität eines genannten Produkts, keine Einführung in einem Netz, keine konkrete Reservierung und kein Serviceergebnis.

Dieser Artikel bewertet weder Hersteller noch Adoption. Seine Aussage ist enger: Das Schema kann Kapazität präzise kennen, ohne je einen Lichtpfad zu schalten. Verlässliche Automation bewahrt genau diese Trennung.

Sources