Zusammenfassung

  • Revision 07 schlägt YANG-Modelle für einzelne OAM-Tests und nutzergeordnete Testfolgen mit Zeitraum, Wiederholung, Status und eingehängten Gerätemodellen vor.
  • success kann im Orchestrator wahr sein, ohne zu beweisen, welche Version wann lief, ob alle Schritte und Messungen vergleichbar waren, ob eine Ursache eindeutig ist, wer ändern durfte oder ob der Dienst wiederhergestellt wurde.

Eine gemeinsame Ablaufbeschreibung, kein universelles Urteil

Netzdiagnose besteht meist aus mehreren Schritten: Erreichbarkeit prüfen, Pfad verfolgen, Verlust und Verzögerung messen, den verdächtigen Abschnitt eingrenzen und während des relevanten Zeitfensters erneut testen. draft-ietf-opsawg-scheduling-oam-tests-07 überführt diesen Ablauf in zwei vorgeschlagene Modelle. ietf-oam-unitary-test beschreibt Test und Zielknoten. ietf-oam-test-sequence ordnet mehrere Tests nach Vorgabe des Nutzers und ergänzt Zeitraum oder Wiederholung.

Die Struktur verbessert Planung und Vergleichbarkeit von Abläufen. Sie kann zugleich einen falschen Eindruck erzeugen: Plan vorhanden, Zähler erhöht, Status grün – also Ursache gefunden. Tatsächlich sagt jeder dieser Einträge nur etwas über die Schicht aus, die ihn erzeugt.

Der Datatracker führt Revision 07 als aktiven OPSAWG Working Group Internet-Draft mit beabsichtigtem Standards-Track-Status. Es gibt keine RFC-Nummer; die IESG-Bearbeitung hat nicht begonnen. Die Historie verzeichnet OPSDIR- und PERFMETRDIR-Frühgutachten jeweils mit Has Issues; die YANG-Doctors-Prüfung ist noch offen. Daraus folgt weder Implementierung noch Einsatz oder Konformität.

Beleg 1: der freigegebene Plan

Der Entwurf übernimmt aus RFC 9922 Schedule-Status, Version, Ortszeit, letzte und nächste Ausführung sowie Zähler. Einzeltests können mehrere ne-config-Ziele und unter root ein eingehängtes Gerätemodell enthalten.

Ein belastbarer Planbeleg braucht den Hash der gesamten Konfiguration, Testreihenfolge, Knoten, Parameter, Zeitregel, Zeitzone, YANG-Library- und Modulidentität sowie den Genehmigenden. RFC 9922 lässt die Versionspflege beim einbettenden Modell und erlaubt, das Feld nicht zu verwenden. Die Zahl allein ist deshalb kein Inhaltsnachweis. Jede Ausführung muss auf den exakten Stand zeigen, der ausgelöst wurde.

Beleg 2: angewendet statt nur angenommen

Revision 07 definiert planned, configured, ready, on-going, stop, error und success; für Folgen kommt failure hinzu. Diese Zustände bilden die Sicht einer konkreten Implementierung ab.

Eine akzeptierte NETCONF- oder RESTCONF-Änderung beweist nicht die Anwendung auf jedem Gerät. RFC 8342 trennt running, intended, angewandte Konfiguration und operational. Gewollte Daten können vorhanden sein, ohne wirksam zu werden. Der Beleg muss intended und operational je Knoten vergleichen, Fähigkeiten und Schema festhalten und Teilfehler offenlegen.

Das OPSDIR-Frühgutachten weist zudem darauf hin, dass der Entwurf On-Demand-Nutzung verspricht, aber weder normative RPC noch action für den Sofortstart definiert. Eine solche Funktion darf ihm nicht zugeschrieben werden.

Beleg 3: die konkrete Ausführung

Eine Wiederholungsregel ist kein Ausführungsobjekt. Verzögerung, Neustart, Retry, Überlappung, Controller-Failover oder Uhrkorrektur können last-occurrence und einen Zähler mehrdeutig machen.

Jeder Lauf braucht eine eigene ID mit Sollzeit, tatsächlichem Start und Ende, Planversion, Orchestrator, Zeitquelle und Fehlergrenze, Retry-Abstammung und tatsächlich erreichten Knoten. Ein erfolgreicher Lauf außerhalb des Störungsfensters beschreibt die damalige Netzlage nicht.

Beleg 4: vollständige Schritte und Abhängigkeiten

Die Folge ist ordered-by user. Ein Fehler in einem Einzeltest muss spätere Tests nicht stoppen. Das erhält weitere Beobachtungen, trennt jedoch Listenende von vollständiger Diagnose.

Das PERFMETRDIR-Frühgutachten fragt, warum stop beim Einzeltest zu Erfolg und bei der Folge zu Fehlschlag führt. OPSDIR fordert klarere Semantik, Benachrichtigungen, Korrelation, Mehrknotenkonsistenz und Rollback. Ein Vollständigkeitsbeleg listet jeden Pflichtschritt, seine Voraussetzung, Knoten, Zeiten, Ergebnisreferenz, Überspringen und Fortsetzungsentscheidung sowie die dadurch offenen Hypothesen.

Beleg 5: Bedeutung des Messwerts

Der Scheduling-Entwurf definiert die detaillierten OAM-Ein- und Ausgaben nicht neu. Er verweist auf Gerätemodelle wie das TWAMP-YANG-Modell aus RFC 8913. RFC 8528 verbindet Modelle durch Schema Mount, setzt aber keine Quelle für Instanzdaten voraus und lässt Instanziierung und Steuerung von Mount Points teilweise offen.

Der Messbeleg muss Testart und Revision, Eingaben, Quelle, Ziel, Richtung, Paketpopulation, Klasse, Größe, Rate, tatsächliches Zeitfenster, Einheit, Uhr, Gerät, Rohwert oder Hash und Aufbewahrung nennen. Eine Referenz auf ein eingehängtes Blatt ist nicht dessen vollständige Semantik.

RFC 7799 unterscheidet aktive, passive und hybride Messverfahren. Erzeugte Testpakete und beobachteter Produktionsverkehr sind ohne weitere Begründung nicht dieselbe Population.

Beleg 6: Vergleichbarkeit mit dem betroffenen Dienst

RFC 10014 trennt topologische Pfadkongruenz von gleicher Weiterleitungsbehandlung. Ein Testpaket kann dieselben Knoten und Links nutzen, aber in einer anderen Queue liegen, anderes QoS erhalten, einen anderen ECMP-Zweig nehmen oder dem Polic­ing und der Last des Kundentraffics entgehen.

Der Vergleichsbeleg benennt, was tatsächlich gemeinsam war: Topologie, Kapselung, Klasse, Hash-Eingaben, Wartungsdomäne, Zeitfenster, Last und Fehlerart. Wenn nur der Pfad gleich ist, darf auch nur über den Pfad geschlossen werden. Scheduling erzeugt keine Fate-Sharing-Eigenschaft.

Beleg 7: Ursachenhypothese und Befugnis

Der Entwurf spricht zu Recht von candidate root causes. RFC 9940 trennt Event, Fault, Problem, Symptom, Cause, Alert, Alarm und Incident; Ursachen können mehrere Eingaben benötigen. RFC 8632 behandelt mögliche Root-Cause-Ressourcen als Hinweise für die Client-Anwendung.

Ein Diagnosebeleg hält Beobachtungen, konkurrierende Erklärungen, ausgeschlossene Hypothesen, Konfidenz, Geltungsbereich und Widerlegungsbedingung fest. Danach braucht die Änderung eine eigene Freigabe. Wer Tests anlegen darf, darf nicht automatisch Routing oder QoS ändern. RFC 8341 hält Zugriffskontrolle getrennt; zusätzlich sind Verantwortlicher, Richtlinie, genaue Änderung, Wirkungsradius, Fenster und Rollback nötig.

Beleg 8: Dienstwirkung nach der Änderung

Eine Änderung kann akzeptiert und der ursprüngliche Test grün werden, obwohl Kunden weiter betroffen sind. Verkehr könnte verlagert, ein Symptom verdeckt oder eine neue Verschlechterung erzeugt worden sein.

Der Ergebnisbeleg muss von der Fläche kommen, die das Leistungsversprechen trägt: Dienstpopulation, SLA-Kriterium, Nachbeobachtungsfenster, unabhängige Signale, Restalarme, Rollback-Status und Stabilitätsdauer. Derselbe Test ist ein nützlicher Wiederholungswert, aber kein unabhängiger Zeuge, wenn seine Vergleichbarkeit strittig war.

Geplante OAM-Tests ordnen den Beginn der Beweiskette. Verlässlichkeit entsteht, wenn Plan, Anwendung, Ausführung, Schritte, Messung, Vergleich, Ursache, Befugnis und Ergebnis verbunden bleiben, ohne ineinander aufzugehen.