Zusammenfassung

  • RFC 9617 definiert ein YANG-Modell, um IOAM einzuschalten und Profile mit Filtern, Protokollen und unterstützten Datentypen zu verbinden; standardisiert wird Konfigurationsabsicht, kein End-to-End-Beobachtungsurteil.
  • Ein Paket muss weiterhin den referenzierten ACE mit der Aktion accept treffen, die vorgesehene Option erhalten, teilnehmende Knoten passieren, Kapazitätsgrenzen überstehen und einen Evidenzempfänger erreichen.
  • Belastbarer Betrieb benötigt getrennte Belege für aktiven Datastore, Paketauswahl, Ausführung, Knotenbeiträge, Exportfolge, Collector-Verwahrung, Analyse, Autorisierung, Installation und Dienstergebnis.

Der sauberste Konfigurationszustand kann über ein Paket schweigen

Im aktiven Datastore steht admin-config/enabled auf true. Das Profil ist vorhanden, der Filter verweist auf den erwarteten ACE, IPv6 ist als Protokoll gewählt und das Trace-Teilprofil enthält die gewünschten Felder. Das Konfigurationssystem darf diesen Zustand mit gutem Grund als fehlerfrei anzeigen.

Wenn anschließend für ein Paket kein Datensatz auftaucht, beantwortet die grüne Anzeige aber keine der entscheidenden Fragen. Traf das Paket wirklich diesen ACE? Lautete dessen Weiterleitungsaktion accept? Wurde die Option am Eingang eingefügt? Unterstützten die Zwischenknoten das Merkmal? Reichte der vorreservierte Platz? Ging ein Export verloren oder verwarf der Collector den Datensatz?

Die Leistung von RFC 9617 besteht darin, Konfiguration präzise lesbar zu machen. Erst die unzulässige Beförderung dieser Lesbarkeit zur Beobachtung erzeugt Gefahr. Eine Modellinstanz beschreibt Anweisung und deklarierte Fähigkeit. Der tatsächliche Paketpfad liefert eine andere Evidenzklasse.

Das YANG-Modell ordnet die Steuerfläche

Das Modul ietf-ioam folgt der Network Management Datastore Architecture. Es stellt schreibgeschützte Informationen, die administrative Aktivierung und eine Liste benannter Profile bereit. Profile können Filter, Trägerprotokoll und Teilprofile für Incremental Trace, Pre-allocated Trace, Direct Export, Proof of Transit oder Edge-to-Edge-Daten festlegen.

Das ist ein starkes gemeinsames Vokabular. Controller müssen grundlegende Entscheidungen nicht in herstellerspezifischen Befehlen ausdrücken. Importierte ACL-, Interface- und Zeittypen begrenzen Werte; Feature-Anweisungen machen optionale Zweige erkennbar; Referenzen bleiben überprüfbar.

Doch Schemakonformität ist kein Paketmitschnitt. Ein beworbenes Feature ist kein Beleg für die Teilnahme jedes Geräts. Aktuelles Readback ist kein Nachweis, dass derselbe Wert zum früheren Paketzeitpunkt galt. Die YANG-Instanz steuert eine Beobachtungsmaschine, sie ist nicht deren Ereignisprotokoll.

enabled=true ist notwendiger Zustand, keine rückwirkende Aussage

Die administrative Einstellung aktiviert IOAM-Konfiguration und Datenebenenfunktionen auf Systemebene. Damit kann konfiguriertes Verhalten stattfinden. Sie sagt nicht, dass jedes Paket oder auch nur ein benannter Flow IOAM-Daten trug.

Profile, Filter, Protokoll, Interface, lokale Fähigkeiten und Knotenrollen begrenzen weiterhin den tatsächlichen Wirkungsbereich. Der Schalter ähnelt einer scharf geschalteten Anlage: Sein Zustand ist wichtig, aber das Ereignisjournal muss zeigen, welcher Mechanismus wann auslöste.

Hinzu kommt die Zeitachse. Ein späteres Readback beweist keinen früheren Zustand, sofern Konfigurationsepochen und ihre Wirksamkeitszeitpunkte nicht erhalten und mit Paket- oder Exportzeiten verknüpft werden. Gegenwartswahrheit darf nicht stillschweigend zur Vergangenheitswahrheit werden.

Am ACE wird aus Absicht entweder Ausführung oder Nichtausführung

Ein Profil kann auf einen Access-Control Entry verweisen. RFC 9617 setzt eine wesentliche Bedingung: IOAM-Aktionen werden von akzeptierten Paketen ausgelöst, wenn die Weiterleitungsaktion des tatsächlich passenden ACE accept lautet.

Die bloße Referenz macht den ACE nicht zum universellen Flow-Label. ACL-Reihenfolge, Interface-Geltungsbereich, Richtung, Adressfamilie und Implementierungsverhalten bestimmen den Treffer. Eine frühere Regel kann zuerst greifen. Das Paket kann die gedachte ACL verfehlen. Ein nominal passender ACE kann eine andere Aktion haben.

Forensische Evidenz braucht deshalb aktive ACL-Revision, Identität des tatsächlich getroffenen ACE, Interface, Richtung, Paket-Fünfertupel oder gleichwertigen Selektor, Match-Ergebnis, Aktion und Konfigurationsepoche. „Das Profil verweist auf ACE-7“ ist Entwurf. „Dieses Paket traf unter Revision X auf ACE-7, wurde akzeptiert und löste IOAM aus“ ist ein Ausführungsbeleg.

Der Protokolltyp benennt den Träger, nicht das beobachtete Paket

protocol-type bestimmt, wo IOAM-Daten eingebettet werden sollen, etwa in IPv6 oder den Network Service Header. Damit kann ein gemeinsames Profil die anzuwendenden Kapselungsregeln auswählen.

Der gespeicherte Wert IPv6 beweist dennoch keine IOAM-Option in einem bestimmten Paket. Das Paket könnte an einem anderen Knoten eingetreten sein, durch einen Tunnel einen neuen äußeren Header erhalten haben, an einer Größenrichtlinie gescheitert sein oder auf einen Knoten ohne Optionserkennung gestoßen sein.

Ein Ingress-Beleg muss die ursprüngliche Paketidentität mit dem passenden Profil verbinden und Kapselungsaktion, entstandenen Optionstyp und -umfang, Namespace, Trace-Type-Bitmap sowie nach Möglichkeit einen stabilen Korrelationswert erfassen. Ohne diese Verbindung beschreibt die Konfiguration einen Weg zur Evidenz, nicht die Evidenz selbst.

Unterstützte Features können unvollständige Spuren erzeugen

Incremental- und Pre-allocated-Trace-Profile wählen Knotenaktion, Namespace, Trace-Typen und maximale Länge. Die Platzzuweisung unterscheidet sich, doch beide Verfahren benötigen wirkliche Knoten, die die verlangten Informationen beitragen.

Feature-Werbung gilt lokal. Eine Implementierung kann Incremental Trace beherrschen, die nächste nicht. Ein angeforderter Wert kann vor Ort nicht verfügbar sein. Bei Vorallokation begrenzt der physische Platz die Zahl der Einträge. Vier aufgezeichnete Knoten beweisen daher nicht allein, dass der Pfad nur vier Knoten umfasste.

Ein fehlender Beitrag kann Pfadvermeidung, fehlende Unterstützung, Nichtteilnahme, erschöpften Speicher, Optionsentfernung, Exportverlust oder Decodierfehler bedeuten. Das Modell konfiguriert Mechanismen, es reduziert diese unterschiedlichen Ursachen nicht auf eine einzige Aussage.

Direct Export eröffnet eine eigene Beweiskette

Das Direct-Export-Profil kann Flow ID und Sequenznummer verwenden. Die Flow ID erleichtert die Korrelation; Sequenznummern machen manche Lücken sichtbar. Beide Felder sind nützlich, aber keine Vollständigkeitsgarantie.

Ein Collector kann erst nach dem ersten Datensatz beginnen, sodass ein fehlendes Präfix keine interne Lücke erzeugt. Reset und Überlauf benötigen eine Epoche. Mehrere Exporter können lokale Sequenzräume wiederverwenden. Ein Datensatz kann erzeugt und vor dem Transport verloren werden. Die Flow ID ist ein Korrelator unter festgelegtem Geltungsbereich, keine weltweit maßgebliche Identität.

Der Exportbeleg muss Exporteridentität, Boot- oder Konfigurationsepoche, Flow-ID-Scope, Sequenzverhalten, Sendezeit, Transportergebnis, Empfangszeit, Decodierergebnis und Aufbewahrungsstatus enthalten. Erst dann trägt eine fehlende Nummer eine begrenzte Verlustfolgerung.

Ein Profilname erzeugt keinen Proof of Transit

Das Modell enthält ein Proof-of-Transit-Profil, doch RFC 9617 definiert einen Basistyp und erwartet für konkrete Varianten Ergänzungen. Ein vorhandener Konfigurationszweig stellt daher weder kryptografischen Beweis noch operative Verifikation her.

Ähnlich konfiguriert das Edge-to-Edge-Profil Daten, die ein kapselnder Knoten hinzufügt und ein entkapselnder Knoten auswertet. Seine Existenz beweist nicht, dass beide Endpunkte dasselbe Paket bearbeiteten oder der Dienst zwischen ihnen erfolgreich war.

Diese Grenze hält auch die bereits separat behandelte IOAM-Integritätsfrage sauber. Ein Integritätsprüfer kann unter seiner Methode beantworten, ob geschützte Felder verändert wurden. RFC 9617 beantwortet, wie Verhalten konfiguriert wird. Keine der beiden Antworten beweist automatisch die vollständige Kette der anderen.

Eine Belegleiter, die ehrlich scheitern darf

Der erste Beleg hält aktive Konfiguration fest: Modellrevision, Datastore, Features, Interfaces, Profil, ACL-Referenz, Protokoll und Teilprofilfelder. Der zweite belegt Auswahl: Das Paket traf den beabsichtigten ACE und wurde akzeptiert. Der dritte belegt Ausführung: Der Eingang fügte die konfigurierte Option ein oder löste den Export aus.

Danach folgen Beobachtungsbelege. Jeder teilnehmende Knoten schrieb das erwartete Feld im richtigen Namespace; Grenzen und nicht unterstützte Funktionen wurden offengelegt; Exportdatensätze behielten Scope und Sequenz; der Collector empfing, decodierte und bewahrte sie. Die Analyse erzeugt erst danach Hypothese oder Entscheidung. Autorisierte Aktion, installierte Änderung und beobachtete Wirkung bleiben eigene Stufen.

Kein einzelner grüner Zustand darf diese Leiter vertreten. RFC 9617 macht ihre erste Stufe interoperabel. Operative Wahrheit entsteht, wenn die späteren Stufen getrennt und prüfbar bleiben.

Quellen